Убедитесь, что главный процесс nginx продолжает работать

В настоящее время я пытаюсь настроить контейнер докеров, используя ubuntu: 14.04 в качестве базового образа, с запущенными внутри nginx и gunicorn / django / celery. Я использую supervisor для запуска всех процессов и проверил, что Gunicorn перезапускается, когда он выходит из строя. Однако я не могу понять, как это сделать с помощью nginx.

Мой supervisord.conf для nginx выглядит следующим образом:

[program:nginx]
command=nginx
autorestart=false

У меня для autorestart установлено значение false, потому что, насколько я могу судить, команда nginx просто запускает главный процесс и рабочие процессы, а затем завершается с кодом состояния 0. Если у меня для autorestart установлено значение true, он просто продолжает попытки перезапустить этот nginx. команда, которая не удастся для последующих попыток, потому что главный / рабочий процессы уже запущены и привязаны к порту.

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


docker nginx supervisord
person Anil Beniwal    schedule 12.06.2015    source источник
comment
Я не уверен, что понимаю вопрос, но нельзя ли использовать для этого monit?   -  person NoDisplayName    schedule 12.06.2015
comment
Не могли бы вы поделиться своим Dockerfile?   -  person christian    schedule 12.06.2015

Ответы (1)


arrow_upward
2
arrow_downward

Вам нужно добавить daemon off; в вашу nginx.conf конфигурацию, указав, что nginx должен работать на переднем плане.

Затем измените строфу супервизора следующим образом:

[program:nginx]
command=nginx
autorestart=true

Он по-прежнему будет порождать главные / рабочие процессы / подпроцессы и может использоваться таким образом в производственных установках. В этом случае это супервизор, который запускает процесс в фоновом режиме, а также контролирует и наблюдает за ним.

См. Этот раздел часто задаваемых вопросов

person James Mills    schedule 13.06.2015
comment
Спасибо, Джеймс, похоже, это сработает! Просто чтобы убедиться, что я понимаю, что я должен увидеть, когда внесу это изменение, если я запустил ps -ef в докере, я должен увидеть строку nginx, строку основного процесса и строку рабочего процесса, правильно? Я до сих пор не понимаю этого по какой-то причине, даже если демон отключен; в качестве первой (без комментариев) строки в моей конфигурации. У меня остались только мастер и рабочий. И когда я убиваю мастера, мастер не перезагружается, поэтому остается только рабочий. Я даже попытался добавить параметр killasgroup = true в конфигурацию супервизора. Есть предположения? - person Anil Beniwal; 13.06.2015
comment
Это очень хороший вопрос; Мне придется поиграть с этим, поскольку я не знаком с внутренним управлением процессами nginx'x. - person James Mills; 13.06.2015
comment
Извините, пояснение, используя ваши предложенные настройки, supervisor.log показывает: 2015-06-15 13:37:53,177 INFO spawned: 'nginx' with pid 16 ps -ef shows: root 16 1 0 13:37 ? 00:00:00 nginx: master process nginx Если я kill -9 16, мастер умирает, а рабочие продолжают работать. Супервизор ДЕЙСТВИТЕЛЬНО пытается перезапустить nginx в соответствии с вашими настройками, но продолжает жаловаться: bind() to 0.0.0.0:80 failed (98: Address already in use) Я думаю, что я должен заставить рабочих умереть вместе с мастером, но killasgroup = true, похоже, не справляется с этим. Какие-либо предложения? Я что-то упускаю? - person Anil Beniwal; 15.06.2015
comment
У вас установлены stopasgroup и killasgroup? - person James Mills; 15.06.2015
comment
Также не используйте SIGKILL/9 в качестве сигнала; НЕТ процесс может это зафиксировать и что-нибудь с этим сделать. используйте вместо этого SIGTERM/15 или SIGINT/2! - person James Mills; 15.06.2015
comment
Вы все время использовали SIGKILL/9, а я не заметил? Это никогда не сработает! - person James Mills; 15.06.2015
comment
Спасибо, Джеймс! SIGTERM/15 и SIGINT/2 оба работали, как ожидалось. Я использовал SIGKILL/9 и ожидал, что он сработает, потому что он действительно работал на Gunicorn (supervisord вернул его), не понимал, что это не будет работать на nginx. - person Anil Beniwal; 15.06.2015
comment
Это не работает на nginx, потому что supervisord не контролирует рабочих nginx; Мастер nginx есть; Если вы УБИВАЕТЕ мастера nginx, никто и ничто не сможет от этого оправиться! - person James Mills; 15.06.2015