Comments 25
Зачем вам именно на сокетах? Разницу в скорости вы скорее всего не заметите, а проблем с портативностью и настройкой добавляется знатно.
Кстати, я уже почти 3 года как сделал набор контейнеров, в котором кроме Nginx, PHP и ротации логов есть SSH, MariaDB и прочие плюшки (включая резервное копирование и восстановление): https://github.com/nazar-pc/docker-webserver
docker-compose.yml там получается гораздо проще, хотя под капотом делает многое описанное в статье.
Никто не отправляет. Logrotate крутится в отдельном контейнере и просто обрезает старые файлы до 0 байт. Никакого перезапуска не требуется, вот используемый конфиг: https://github.com/nazar-pc/docker-webserver/blob/master/logrotate/logrotate.conf
Думаю, вы ошибаетесь. truncate есть truncate, файл будет уменьшен сразу. На сколько я понимаю, USR1 нужен если вы файл перемещаете и создаете на старом месте новый пустой, в этом случае USR1 заставит Nginx открыть новый файл. В случае с truncate мы обрезаем исходный файл и переоткрывать ничего не нужно, Nginx без проблем дописывает новые записи в тот же файл. По крайней мере так оно у меня на сервере выглядит.
У меня новая версия сайта выкладывается посредством git push, для этого использую контейнер с SSH, там же стоит Composer. Зависит от workflow, контейнер совершенно опциональный, используйте если и когда нужно.
А ещё
Этот сервер имеет другое по сравнению с nginx расположение каталогов с файлами. Но все остальное абсолютно идентично.
Описание выглядит так, как будто это nginx с нескучными обоями. Впрочем я не в курсе, может быть так и есть. А может быть автор опять сбивает с толку людей.
Обои тут это расположение файлов, которое не неотъемлемая часть программы, а все лишь вопрос того как вы её настроите. От вашей фразы создаётся впечатление, что сменить строчку с указанием расположения какого-нить access_log'а в конфиге для вас равноценно пересборке всего сервера, так же как для какого-то школьника было непосильной задачей залить новую картинку в список обоев.
nginx запускается не как демон (daemon off; в конфиге или nginx -g «daemon off;»), логи выводятся в stdout и stderr соответственно и готово.
Почему так правильно:
0 — При краше докер контейнера логи не будут потеряны, см. п 4.
1 — nginx написан грамотно и никаких зомби процессов оставлять он не будет, если вы из него что-нибудь запускаете, поэтому супервизор ему как таковой не нужен.
2 — Перезапуски при крашах управляются через докер (или под чем у вас кластер), там есть соответствующие параметры.
3 — Мониторинг и перезапуск правильно делать отдельным процессом, потому что рано или поздно захочется нотификаций, графиков нагрузки, вот это всё.
4 — Логи управляются через докер, там есть пачка плагинов чтобы этим рулить как надо, заводить в системы мониторинга и агрегации логов, или на крайний случай делать таки логротейт но уже логов докера (не пиная нгинкс)
Пост из разряда вредных советов. Из-за ротации логов, которые докер может может отправлять куда угодно, автор топика сделал очередной велосипед
Если потребовалась ротация логов сервиса, который крутится внутри контейнера, то это первый признак, что ты делаешь что-то не правильно. А добавив сюда еще взаимодействие через сокеты, я в этом убедился еще раз. В общем все проходят через то, что воспринимают контейнер докера как виртуальную машину, как только начнешь воспринимать контейнер как приложение, тогда все станет на свои места.
Попробуйте масштабировать приложение, которое будет крутиться в контейнере, который создал автор топика и вы поймете что у вас увеличивается количество телодвижений. А докер это про то, чтобы это количество не увеличивалось
По сокетам vs 9000 порт вопрос неоднократно обсуждался и я даже не буду приводить за и против сокет vs 9000 порт. Я просто скажу что у администратора должна быть возможность выбора. Если 9000 порт работет «их коробки» во всех образах php-fpm (кстати, есть issue как раз по этому поводу на UNEXPOSE) то для работы через сокет нужны дополнительные действия. Это и было разобрано в статье. И не утверждается что сокеты это всегда лучше чем порты. Каждый выбирает то что ему подходит в кажом конкретном случае.
Решение с супервизором, кстати это тоже из документации докера docs.docker.com/engine/admin/multi-service_container.
Согласен что для масштабируемых решений логирование это отдельная проблема и должна решаться централизовано.
Докеризация nginx и php на сокетах с ротацией логов