Система инициализации s6-overlay. Вариант образа Lighttpd для Docker

За основу возьмем ранее созданный мной образ Lighttpd, в котором за старт php-fpm отвечает сам веб-сервер благодаря параметру bin-path в настройках mod_fastcgi. Этот образ, в свою очередь, основывается на официальном php:fpm, а конкретная версия веб-сервера компилируется из исходного кода.

s6-overlay

В отличие, например, от Supervisor, s6-overlay весьма компакта – помещается в два или чуть больше архивов (в зависимости от того, требуются ли вам дополнительные симлинки или эмуляция syslogd) объемом килобайт в 700-800, а всего образ увеличивается на 5-6 мегабайт. Заявлено, что система может использоваться практически в любом контейнере.

Одной из особенностей s6 является не только управление длительными процессами (демонами, longrun), но и возможность выполнения каких-то операций при запуске контейнера (oneshot). Последние могут представлять собой, например, скрипты применения миграций к БД. В рамках статьи мы не будем их рассматривать, так как в нашем случае потребуются только демоны.

Сама же конфигурация представляет собой набор мелких или даже вовсе пустых файлов в определенной иерархии каталогов. При этом обеспечивается управление последовательностью запуска сервисов, причем при необходимости под нужными пользователями, корректное завершение и т.д. Надеюсь, по ходу дела станет более понятно, пока же установим s6-overlay в контейнер.

Начало s6.dockerfile:

ARG PHP_VERSION LIGHTTPD_VERSION
FROM dmkos/php:${PHP_VERSION}-lighttpd-${LIGHTTPD_VERSION}-trixie

# Switch from `www-data` set in base image
USER root

# Install s6-overlay
ARG S6_OVERLAY_VERSION
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /usr/src/
ARG S6_OVERLAY_ARCH=x86_64
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-${S6_OVERLAY_ARCH}.tar.xz /usr/src/
RUN set -eux; \
        tar -C / -Jxpf /usr/src/s6-overlay-noarch.tar.xz; \
        tar -C / -Jxpf /usr/src/s6-overlay-${S6_OVERLAY_ARCH}.tar.xz

STOPSIGNAL SIGTERM
ENTRYPOINT ["/init"]

Сразу же переключаемся в root, так как в базовом образе был принудительно задан www-data. Затем скачиваем два архива s6-overlay – общий и для конкретной архитектуры (у нас x86_64) – и извлекаем их прямо в корень. Возвращаем SIGTERM в качестве стоп-сигнала контейнера (то есть для s6) и переопределяем точку входа, это соответственно скрипт инициализации.

Добавляем сервис в compose.yaml:

services:
  lighttpd-s6:
    build:
      context: .
      dockerfile: s6.dockerfile
      args:
        - PHP_VERSION=${PHP_VERSION}
        - LIGHTTPD_VERSION=${LIGHTTPD_VERSION}
        - S6_OVERLAY_VERSION=${S6_OVERLAY_VERSION}

А в .env – версию s6-overlay:

PHP_VERSION=8.4.13
LIGHTTPD_VERSION=1.4.82
LIGHTTPD_SHA256=abfe74391f9cbd66ab154ea07e64f194dbe7e906ef4ed47eb3b0f3b46246c962
S6_OVERLAY_VERSION=3.2.1.0

Этот файл у меня общий, отсюда присутствие нужной только для базового образа контрольной суммы архива Lighttpd.

Если прямо сейчас запустить контейнер (docker compose up lighttpd-s6), то отработает лишь система инициализации:

[+] Running 2/2
 ✔ Network trixie_default          Created                                 0.0s
 ✔ Container trixie-lighttpd-s6-1  Cre...                                  0.0s
Attaching to lighttpd-s6-1
lighttpd-s6-1  | s6-rc: info: service s6rc-oneshot-runner: starting
lighttpd-s6-1  | s6-rc: info: service s6rc-oneshot-runner successfully started
lighttpd-s6-1  | s6-rc: info: service fix-attrs: starting
lighttpd-s6-1  | s6-rc: info: service fix-attrs successfully started
lighttpd-s6-1  | s6-rc: info: service legacy-cont-init: starting
lighttpd-s6-1  | s6-rc: info: service legacy-cont-init successfully started
lighttpd-s6-1  | s6-rc: info: service legacy-services: starting
lighttpd-s6-1  | s6-rc: info: service legacy-services successfully started
Gracefully Stopping... press Ctrl+C again to force
 Container trixie-lighttpd-s6-1  Stopping
lighttpd-s6-1  | s6-rc: info: service legacy-services: stopping
lighttpd-s6-1  | s6-rc: info: service legacy-services successfully stopped
lighttpd-s6-1  | s6-rc: info: service legacy-cont-init: stopping
lighttpd-s6-1  | s6-rc: info: service legacy-cont-init successfully stopped
lighttpd-s6-1  | s6-rc: info: service fix-attrs: stopping
lighttpd-s6-1  | s6-rc: info: service fix-attrs successfully stopped
lighttpd-s6-1  | s6-rc: info: service s6rc-oneshot-runner: stopping
lighttpd-s6-1  | s6-rc: info: service s6rc-oneshot-runner successfully stopped
lighttpd-s6-1 exited with code 0
 Container trixie-lighttpd-s6-1  Stopped

Так что переходим к настройке сервисов.

PHP

Определения сервисов s6-overlay размещаются в поддиректориях каталога /etc/s6-overlay/s6-rc.d. Минимально необходимо объявить тип сервиса, зависимости, скрипт запуска и добавить сервис в пространство пользователя. В случае PHP-FPM дополнительно укажем SIGQUIT для корректного завершения.

Файл /etc/s6-overlay/s6-rc.d/php-fpm/type – объявляем «длительный» тип сервиса:

longrun

/etc/s6-overlay/s6-rc.d/php-fpm/dependencies.d/base – пустой файл. Это означает зависимость только от базовых сервисов.

This tells s6-rc to only start myapp when all the base services are ready: it prevents race conditions.

/etc/s6-overlay/s6-rc.d/php-fpm/run – скрипт запуска:

#!/command/execlineb -P
with-contenv
/usr/local/sbin/php-fpm

Обратите внимание на специальную оболочку скрипта – /command/execlineb -P. Теоретически можно использовать обычные shell-скрипты, но не нужно.

with-contenv говорит о том, что сервису будут доступны переменные окружения контейнера. Я не вполне уверен, что это правильно, но возможно в скриптах потребуются какие-то значения из официального образа PHP, да и в serversideup/php (на которые я в немалой степени ориентируюсь) тоже так сделано. Кстати я и сам в примерах передавал настройку доверенных прокси через переменную.

Установить конкретного пользователя для запуска демона можно с помощью программы s6-setuidgid, но в нашем случае это вновь привело бы к невозможности доступа к stderr. В результате возвращаемся к стандартной схеме запуска мастер-процесса от имени root, так что вскоре мы вернем настройку пользователя в www.conf.

К вызову самого php-fpm не обязательно добавлять параметр --nodaemonize (как вы могли бы видеть у Серверсайдов), поскольку данный режим и так включен в базовом образе (в файле /usr/local/etc/php-fpm.d/zz-docker.conf).

/etc/s6-overlay/s6-rc.d/user/contents.d/php-fpm – пустой файл, который и ставит наш сервис в «автозагрузку».

Соответствующий фрагмент s6.dockerfile выглядит примерно так:

# PHP
ENV WWW_USER=www-data
RUN set -eux; \
        mkdir -p /etc/s6-overlay/s6-rc.d/php-fpm/dependencies.d; \
        cd /etc/s6-overlay/s6-rc.d/php-fpm; \
        touch dependencies.d/base; \
        echo 'longrun' > type; \
        echo 'SIGQUIT' > down-signal; \
        \
        { \
            echo '#!/command/execlineb -P'; \
            echo 'with-contenv'; \
            echo '/usr/local/sbin/php-fpm'; \
        } > run; \
        chmod +x run; \
        \
        mkdir -p /etc/s6-overlay/s6-rc.d/user/contents.d; \
        touch /etc/s6-overlay/s6-rc.d/user/contents.d/php-fpm; \
        \
        # php-fpm user defined in environment variable
        sed -i 's#;user = www-data#user = ${WWW_USER}#' /usr/local/etc/php-fpm.d/www.conf; \
        sed -i 's#;group = www-data#group = ${WWW_USER}#' /usr/local/etc/php-fpm.d/www.conf; \
        # remove suffix from socket filename
        sed -i 's#www.sock-0#www.sock#' /usr/local/etc/php-fpm.d/zz-docker.conf; \
        # allow web-server to interact with socket
        echo 'listen.owner = ${WWW_USER}' >> /usr/local/etc/php-fpm.d/zz-docker.conf

В данном случае я решил не создавать всякую мелочевку на хосте, а сразу формировать ее в образе командами touch и echo. Благодаря тому, что в конфигурации PHP можно обращаться к переменным окружения, параметризуем пользователя дочерних процессов (оставив по умолчанию www-data). Наконец, перенастраиваем сокет: убираем суффикс из имени, который использовался в качестве индекса процесса FastCGI, и назначаем вышеуказанного пользователя в качестве владельца (иначе веб-сервер не сможет взаимодействовать с php-fpm).

Lighttpd

Я хочу запускать Лайти тоже от имени root, указав непривилегированного пользователя в конфигурации. Это заодно позволит тюнинговать максимальное количество открытых файлов подобно моему другому источнику вдохновения – образу jitesoft/lighttpd.

Я решил позаимствовать комментарии из doc/config/lighttpd.annotated.conf, поставляемого с исходными кодами, поэтому создал файл s6/000-s6.conf на хосте:

##
##  Basic Configuration
## ---------------------
##
## Run as a different username/groupname.
## This requires root permissions during startup.
##
server.username  = env.WWW_USER
server.groupname = env.WWW_USER

##
##  Tuning/Performance
## --------------------
##
## corresponding documentation:
## https://wiki.lighttpd.net/Docs_Performance
##
## As lighttpd is a single-threaded server, its main resource limit is
## the number of file descriptors, which is set to 1024 by default (on
## most systems).
##
## If you are running a high-traffic site you might want to increase this
## limit by setting server.max-fds.
##
## Changing this setting requires root permissions on startup. see
## server.username/server.groupname.
##
## By default lighttpd would not change the operation system default.
## But setting it to 16384 is a better default for busy servers.
##
## With SELinux enabled, this is denied by default and needs to be allowed
## by running the following once: setsebool -P httpd_setrlimit on
##
server.max-fds = env.LIGHTTPD_MAX_FDS

Настраиваем сервис:

# Lighttpd
RUN set -eux; \
        mkdir -p /etc/s6-overlay/s6-rc.d/lighttpd/dependencies.d/; \
        cd /etc/s6-overlay/s6-rc.d/lighttpd; \
        touch dependencies.d/php-fpm; \
        echo 'longrun' > type; \
        echo 'SIGINT' > down-signal; \
        \
        { \
            echo '#!/command/execlineb -P'; \
            echo 'with-contenv'; \
            echo '/usr/local/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf'; \
        } > run; \
        chmod +x run; \
        \
        touch /etc/s6-overlay/s6-rc.d/user/contents.d/lighttpd; \
        # remove php-fpm start settings
        sed -i '27,29d' /etc/lighttpd/conf.d/500-fastcgi.conf
COPY s6/*.conf /etc/lighttpd/conf.d/
ENV LIGHTTPD_MAX_FDS=1024

В качестве зависимости у нас выступает php-fpm, который в свою очередь зависит от базовых сервисов. Это обеспечивает правильную последовательность запуска. Сигнал корректного завершения Lighttpd – SIGINT. Поскольку для настройки веб-сервера сплошь и рядом применяются переменные окружения, вновь оборачиваем команду запуска в with-contenv. Далее удаляем строки, связанные с запуском php-fpm через bin-path в 500-fastcgi.conf, подкидываем ранее созданный конфигурационный файл и объявляем упомянутую в нем переменную окружения LIGHTTPD_MAX_FDS.

Готовность сервисов s6

Когда я говорил, что Lighttpd запускается после PHP-FPM, то немного соврал. Если проанализировать логи, команда старта веб-сервера действительно идет после интерпретатора, но фактически они запускаются параллельно. Об этом говорит последовательность вывода сообщений от самих демонов:

lighttpd-s6-1  | s6-rc: info: service php-fpm: starting
lighttpd-s6-1  | s6-rc: info: service php-fpm successfully started
lighttpd-s6-1  | s6-rc: info: service lighttpd: starting
lighttpd-s6-1  | s6-rc: info: service lighttpd successfully started
lighttpd-s6-1  | s6-rc: info: service legacy-services: starting
lighttpd-s6-1  | s6-rc: info: service legacy-services successfully started
lighttpd-s6-1  | 2025-10-06 09:06:52: (server.c.1971) server started (lighttpd/1.4.82)
lighttpd-s6-1  | [06-Oct-2025 09:06:52] NOTICE: fpm is running, pid 56
lighttpd-s6-1  | [06-Oct-2025 09:06:52] NOTICE: ready to handle connections

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

Правильный подход заключается в том, что по готовности демон добавляет новую строку в заданный файловый дескриптор (например 3) и закрывает его. Каким образом провернуть такой финт ушами с PHP-FPM – непонятно. Для подобных ситуаций существует субоптимальный, как пишут авторы, способ с опросом сервиса утилитой s6-notifyoncheck:

• определить дескриптор в файле notification-fd, начиная с 3;
• в скрипте data/check реализовать проверку готовности сервиса:
  • код возврата скрипта должен быть 0, если сервис готов;
• добавить вызов s6-notifyoncheck в скрипт run сервиса.

Вновь обратимся к опыту Server Side Up. Проверить работоспособность PHP-FPM можно скриптом php-fpm-healthcheck. Он, в свою очередь, зависит от программы cgi-fcgi и переменной окружения FCGI_CONNECT, в которой нужно указать путь к сокету. Еще потребуется настроить страницу состояния в конфигурации пула.

Фрагмент s6.dockerfile:

# PHP readiness
ADD --chmod=755 https://raw.githubusercontent.com/renatomefi/php-fpm-healthcheck/master/php-fpm-healthcheck /usr/local/bin/
RUN set -eux; \
        # install cgi-fcgi
        apt-get update; \
        apt-get install -y --no-install-recommends libfcgi-bin; \
        apt-get dist-clean; \
        # configure s6
        cd /etc/s6-overlay/s6-rc.d/php-fpm; \
        mkdir data; \
        { \
            echo '#!/command/with-contenv sh'; \
            echo 'php-fpm-healthcheck'; \
        } > data/check; \
        chmod +x data/check; \
        echo 3 > notification-fd; \
        sed -i '/php-fpm/is6-notifyoncheck -d' run; \
        # php-fpm status page
        echo 'pm.status_path = /status' >> /usr/local/etc/php-fpm.d/zz-docker.conf
ENV FCGI_CONNECT=/tmp/www.sock

Вызов s6-notifyoncheck я возможно не очень наглядно добавил sed’ом в режиме вставки перед строкой с шаблоном. Флаг -d означает двойной форк, т.е. утилита запускается как «внук» основного процесса, а не прямой потомок:

-d : doublefork. s6-notifyoncheck will run as the grandchild of prog... instead of its direct child. This is useful if prog... never reaps zombies it does not know it has.

Тут, как говорится, мои полномочия всё . Будем надеяться, для применения этого флага у Серверсайдов были веские основания. Возможно это связано с тем, что php-fpm сам создает дочерние процессы.

Подобным образом реализуется и проверка готовности Lighttpd, только в качестве проверочного скрипта мы можем запросить страницу статуса веб-сервера curl’ом (без echo последняя строчка с закрывающей скобкой не выводилась):

# Lighttpd readiness
RUN set -eux; \
        cd /etc/s6-overlay/s6-rc.d/lighttpd; \
        mkdir data; \
        { \
            echo '#!/command/with-contenv sh'; \
            echo 'curl -fs http://127.0.0.1:${LIGHTTPD_PORT}/_webserver-status?json && echo'; \
        } > data/check; \
        chmod +x data/check; \
        echo 4 > notification-fd; \
        sed -i '/lighttpd/is6-notifyoncheck' run

На всякий случай я объявил другой файловый дескриптор, хотя вроде как можно обойтись одним и тем же. Флаг -d на этот раз вроде бы не нужен.

Теперь сервисы запускаются строго последовательно:

lighttpd-s6-1  | s6-rc: info: service php-fpm: starting
lighttpd-s6-1  | [06-Oct-2025 12:33:58] NOTICE: fpm is running, pid 56
lighttpd-s6-1  | [06-Oct-2025 12:33:58] NOTICE: ready to handle connections
lighttpd-s6-1  | s6-rc: info: service php-fpm successfully started
lighttpd-s6-1  | s6-rc: info: service lighttpd: starting
lighttpd-s6-1  | 2025-10-06 12:33:59: (server.c.1971) server started (lighttpd/1.4.82)
lighttpd-s6-1  | {
lighttpd-s6-1  |        "RequestsTotal": 0,
lighttpd-s6-1  |        "TrafficTotal": 0,
lighttpd-s6-1  |        "Uptime": 0,
lighttpd-s6-1  |        "BusyServers": 1,
lighttpd-s6-1  |        "IdleServers": 340,
lighttpd-s6-1  |        "RequestAverage5s":0,
lighttpd-s6-1  |        "TrafficAverage5s":0
lighttpd-s6-1  | }
lighttpd-s6-1  | s6-rc: info: service lighttpd successfully started

Оптимизация s6.dockerfile

Получившийся файл имеет не слишком оптимальную структуру. Сгруппируем загрузку файлов и установку программ в начале, затем выполним настройку PHP и Lighttpd (заодно будет чуть меньше sed’а), и только в конце объявим переменные окружения, чтобы они не мешались в слоях образа. Кстати раз у нас внезапно образовалась переменная для пути к сокету, то заменим хардкод в конфигурациях.

ARG PHP_VERSION LIGHTTPD_VERSION
FROM dmkos/php:${PHP_VERSION}-lighttpd-${LIGHTTPD_VERSION}-trixie

# Switch from `www-data` set in base image
USER root

# Install php-fpm-healthcheck and required packages
ADD --chmod=755 https://raw.githubusercontent.com/renatomefi/php-fpm-healthcheck/master/php-fpm-healthcheck /usr/local/bin/
RUN set -eux; \
        apt-get update; \
        apt-get install -y --no-install-recommends libfcgi-bin; \
        apt-get dist-clean

# Install s6-overlay
ARG S6_OVERLAY_VERSION
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /usr/src/
ARG S6_OVERLAY_ARCH=x86_64
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-${S6_OVERLAY_ARCH}.tar.xz /usr/src/
RUN set -eux; \
        tar -C / -Jxpf /usr/src/s6-overlay-noarch.tar.xz; \
        tar -C / -Jxpf /usr/src/s6-overlay-${S6_OVERLAY_ARCH}.tar.xz

STOPSIGNAL SIGTERM
ENTRYPOINT ["/init"]

# PHP
RUN set -eux; \
        mkdir -p /etc/s6-overlay/s6-rc.d/php-fpm/dependencies.d; \
        cd /etc/s6-overlay/s6-rc.d/php-fpm; \
        touch dependencies.d/base; \
        \
        mkdir data; \
        { \
            echo '#!/command/with-contenv sh'; \
            echo 'php-fpm-healthcheck'; \
        } > data/check; \
        chmod +x data/check; \
        \
        echo '3' > notification-fd; \
        echo 'longrun' > type; \
        echo 'SIGQUIT' > down-signal; \
        \
        { \
            echo '#!/command/execlineb -P'; \
            echo 'with-contenv'; \
            echo 's6-notifyoncheck -d'; \
            echo '/usr/local/sbin/php-fpm'; \
        } > run; \
        chmod +x run; \
        \
        mkdir -p /etc/s6-overlay/s6-rc.d/user/contents.d; \
        touch /etc/s6-overlay/s6-rc.d/user/contents.d/php-fpm; \
        \
        # php-fpm user defined in environment variable
        sed -i 's#;user = www-data#user = ${WWW_USER}#' /usr/local/etc/php-fpm.d/www.conf; \
        sed -i 's#;group = www-data#group = ${WWW_USER}#' /usr/local/etc/php-fpm.d/www.conf; \
        # remove suffix from socket filename
        sed -i 's#/tmp/www.sock-0#${FCGI_CONNECT}#' /usr/local/etc/php-fpm.d/zz-docker.conf; \
        # allow web-server to interact with socket
        echo 'listen.owner = ${WWW_USER}' >> /usr/local/etc/php-fpm.d/zz-docker.conf; \
        # php-fpm status page
        echo 'pm.status_path = /status' >> /usr/local/etc/php-fpm.d/zz-docker.conf

# Lighttpd
COPY s6/*.conf /etc/lighttpd/conf.d/
RUN set -eux; \
        mkdir -p /etc/s6-overlay/s6-rc.d/lighttpd/dependencies.d/; \
        cd /etc/s6-overlay/s6-rc.d/lighttpd; \
        touch dependencies.d/php-fpm; \
        \
        mkdir data; \
        { \
            echo '#!/command/with-contenv sh'; \
            echo 'curl -fs http://127.0.0.1:${LIGHTTPD_PORT}/_webserver-status?json && echo'; \
        } > data/check; \
        chmod +x data/check; \
        \
        echo '4' > notification-fd; \
        echo 'longrun' > type; \
        echo 'SIGINT' > down-signal; \
        \
        { \
            echo '#!/command/execlineb -P'; \
            echo 'with-contenv'; \
            echo 's6-notifyoncheck'; \
            echo '/usr/local/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf'; \
        } > run; \
        chmod +x run; \
        \
        touch /etc/s6-overlay/s6-rc.d/user/contents.d/lighttpd; \
        # parametrize socket
        sed -i 's#"/tmp/www.sock"#env.FCGI_CONNECT#' /etc/lighttpd/conf.d/500-fastcgi.conf; \
        # remove php-fpm start settings
        sed -i '27,29d' /etc/lighttpd/conf.d/500-fastcgi.conf

ENV WWW_USER=www-data
ENV LIGHTTPD_MAX_FDS=1024
ENV FCGI_CONNECT=/tmp/www.sock

Н-да, слегка длинновато, но, надеюсь, более-менее понятно. На этом, я считаю, образ готов.

Заключение

Исходный код на момент написания статьи доступен во все том же репозитории контейнеров PHP:

https://git.dmkos.ru/containers/php/-/tree/11-lighttpd-s6-overlay/linux/lighttpd/8.4/trixie

Или его актуальная версия:

https://git.dmkos.ru/containers/php/-/tree/main/linux/lighttpd

Сами образы доступны непосредственно у меня, в Docker Hub и GitHub. Среди всего многообразия тегов наиболее практичным скорее всего будет 8.4-lighttpd-s6 или 8.5-lighttpd-s6 после выхода PHP 8.5.

dmkos/php:8.4-lighttpd-s6
ghcr.io/dmkos/php:8.4-lighttpd-s6
glcr.dmkos.ru/containers/php:8.4-lighttpd-s6

В целом применение контейнера аналогично базовому. Основное отличие – вариант s6 снова запускается от имени root. Вернуть обратно непривилегированный режим можно…

FROM dmkos/php:8.4-lighttpd-s6

ARG WWW_UID=1000
ARG WWW_USER=lighty
# change environment variable accordingly
ENV WWW_USER=$WWW_USER

RUN set -eux; \
        useradd -m -c 'World Wide Web Owner' -u $WWW_UID $WWW_USER; \
        chown -R ${WWW_USER}:${WWW_USER} /var/www/html

# switch to the newly created user if you really want to
USER $WWW_USER

Только осторожно . Как минимум вновь появятся предупреждения о бесполезности установки пользователя в www.conf и, согласно документации, перестанет иметь смысл настройка LIGHTTPD_MAX_FDS. К тому же сами разработчики s6-overlay относятся к директиве USER скептически. Без этой директивы мы получим контейнер, все еще работающий под root, но веб-сервер и дочерние процессы php-fpm будут принадлежать нужному пользователю, что наверное и требуется в большинстве случаев.

Советую присмотреться и к s6-overlay как таковому. В числе однозначных плюсов – компактность. Проста ли настройка? Уже не факт, возможно кому-то иерархия с кучей файлов не понравится. Однако задачи можно решать самые разнообразные, например в одном из личных проектов помимо веб-сервера в контейнере работает обработчик очереди заданий. Тут возможна дискуссия, а таков ли Путь? Авторы оверлея считают (и я с ними согласен), что принцип контейнеризации нужно толковать в широком смысле: не одна программа – один контейнер, а одна вещь (сущность, задача) – один контейнер. По-моему, веб-сервер поверх PHP, да и обработчик очереди вполне укладываются в такую концепцию.