Docker, Supervisord и протоколирование - как консолидировать журналы в журналах докеров?

Итак, экспериментируйте с приложением Docker + Supervisord + Django через uWSGI. У меня весь стек работает нормально, но нужно убрать регистрацию.

Если я запускаю диспетчер в режиме без демона,

/usr/bin/supervisord -n

Затем я получаю вывод журнала для супервизора, который воспроизводится в протоколе stdout docker. Однако, если supervisord находится в режиме демона, его собственные журналы сбрасываются в файловой системе контейнера, а журналы его приложений тоже - в их собственных файлах app__stderr/stdout.

То, что я хочу, - это зарегистрировать как супервизор, так и приложение stdout в журнале докеров.

Начинает ли супервизор в не-демонах разумную идею для этого или вызывает непредвиденные последствия? Кроме того, как мне получить журналы приложений, которые также воспроизводятся в журналах докеров?

Ответы

Ответ 1

Я согласен, что использование режима демона не является лучшим решением, но я бы, вероятно, использовал ту же стратегию, которую вы использовали бы, когда у вас были фактические физические серверы или какая-то настройка виртуальной машины: централизовать ведение журнала.

В контейнере можно использовать что-то самоорганизующееся, например logstash, чтобы собирать журналы и отправлять их на центральный сервер. Или используйте коммерческую услугу, такую как loggly или papertrail, чтобы сделать то же самое.

Ответ 2

Я сделал это с помощью.

Установите supervisor-stdout в изображении Docker:

RUN apt-get install -y python-pip && pip install supervisor-stdout

Конфигурация супервизора

Измените свой supervisord.conf так:

[program:myprogram]
command=/what/ever/command
stdout_events_enabled=true
stderr_events_enabled=true

[eventlistener:stdout] 
command = supervisor_stdout 
buffer_size = 100 
events = PROCESS_LOG 
result_handler = supervisor_stdout:event_handler

Ответ 3

Докер-контейнер похож на kleenex, вы его используете, а затем бросаете. Чтобы быть "живым", Docker нуждается в чем-то, работающем на переднем плане (тогда как демоны работают в фоновом режиме), поэтому вы используете Supervisord.

Таким образом, вам нужно выполнить "переадресацию/добавление/объединение" процесса (доступ и ошибка) к выходу Supervisord, который вы видите при запуске вашего контейнера.

Как сказал Дрю, каждый использует https://github.com/coderanger/supervisor-stdout для его достижения (для меня это должно быть добавлено в проект супервизора!). Что-то Дрю забыло сказать, вам может понадобиться добавить

stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0

В блок конфигурации программы супервизора.

Что-то очень полезное, представьте, что ваш процесс регистрируется в файле журнала вместо stdout, вы можете попросить supervisord просмотреть его:

[program:php-fpm-log]
command=tail -f /var/log/php5-fpm.log
stdout_events_enabled=true
stderr_events_enabled=true

Это приведет к перенаправлению содержимого php5-fpm.log в stdout, затем в stdout supervisord через superisord-stdout.

Ответ 4

supervisor-stdout требует установки python-pip, который загружает ~ 150mb, для контейнера, я думаю, это просто для установки другого инструмента.

Перенаправление файла журнала в /dev/stdout работает для меня:

stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0

http://veithen.github.io/2015/01/08/supervisord-redirecting-stdout.html

Ответ 5

Сегодня самая лучшая практика - иметь минимальные изображения Докера. Для меня идеальный контейнер с приложением Python содержит только мой код, поддерживающие библиотеки и что-то вроде uwsgi, если это необходимо.

Я опубликовал одно решение на https://github.com/msgre/uwsgi_logging. Это просто приложение Django за uwsgi, которое настроено для отображения журналов из uwsgi и приложения Django на контейнерах stdout без необходимости supervisor.

Ответ 6

В самом деле, самое лучшее решение - запуск супервизора в не-демоном режиме.

Вы также можете использовать тома, чтобы монтировать журналы супервизора в центральное место.