Я только начал работать с Docker и Kubernetes, и я смотрел много стеков, в которых некоторые люди собирают nginx + php в одном образе, а некоторые создают образ с помощью nginx, а другой - с php (монтируют по тому же пути и включают оба контейнера в одном и том же месте в Кубернетесе).
Каковы будут преимущества создания двух образов докеров вместо установки обоих nginx + php в один и тот же?
Ответы:
PHP с nginx обычно выполняется с использованием php-fpm, который представляет собой отдельный процесс.
Сохраняя основную идею докера одного процесса (подробности см. В конце ответа) для каждого контейнера, имеет смысл иметь процессы nginx и php-fpm в отдельных контейнерах.
Поскольку связь между nginx и php-fpm возникает через fastcgi, контейнер php-fpm также может находиться на отдельном хосте, что позволяет использовать кластер контейнеров php-fpm за nginx.
За стеной комментариев приведем еще немного предыстории, в документации докера есть параграф о том, что у контейнера должен быть только один интерес .
Основная идея контейнера Linux ( lxc ) состоит в том, чтобы запустить процесс в изолированном пространстве имен на уровне процессора и памяти, а Docker добавляет к этому изоляцию на уровне файловой системы.
Преимущество состоит в том, что компрометация процесса в этом пространстве имен не позволяет читать память других процессов и, следовательно, должна предотвращать другие компрометации на хосте.
Говоря о nginx и php-fpm, они работают в паре, но у каждого есть свои проблемы, nginx выполнит HTTP-часть, маршрутизацию, проверку заголовков и т. Д., А php-fpm выполнит интерпретацию кода и вернет html-часть в nginx. , Хотя обычно оба вместе подают одно приложение, это не обязательно.
В зависимости от контекста может быть проще иметь контейнер, включающий весь стек для приложения, на рабочей станции разработчика, например. Но в идеале для производственного использования старайтесь поддерживать меньшее количество взаимодействий внутри контейнера, поскольку разделение процессов в одном и том же контейнере с супервизором приносит свою долю проблем с точки зрения процесса зомби и обработки журналов (пример приведен здесь только для иллюстрации).
Итак, наконец, я процитирую страницу докера с некоторым акцентом:
Хотя «один процесс на контейнер» часто является хорошим практическим правилом, это не жесткое и быстрое правило. Делайте все возможное, чтобы контейнеры были максимально чистыми и модульными .
Не существует «правила серебряной пули», которое применимо ко всему, это всегда баланс между сложностью внутри контейнера и сложностью организации самих контейнеров.
На самом деле, здесь не хватает одной точки - горизонтальная масштабируемость. Есть статья от Джейми Алкизы, давным-давно адресованная этому:
Короче говоря, вы масштабируете php-fpm по горизонтали для достижения более высокой производительности. Совместное масштабирование Nginx + php-fpm не принесет вам никакой пользы. Я рекомендую вам провести некоторое стресс-тестирование (например, Tsung, Gatling и т. Д .; пожалуйста, не делайте Apache ab, это очень старая игрушка) самостоятельно, чтобы проверить, о чем говорилось в статье. У меня лично есть несколько реальных опытов, доказавших, что статья в целом верна
Но есть два недостатка (возможно, не для Kubernetes) для чистых металлических машин / виртуальных машин:
РЕДАКТИРОВАНИЕ: Теперь это почти половина года 2019. Старая модель, php-fpm + nginx в том же модуле, имеет другое использование. Если вы знакомы с сервисной сеткой, то nginx (или так называемая Nginmesh) служит коляской для обработки трафика, направленного с востока на запад. Трафик, привязанный к востоку и западу, в основном используется для аутентификации среди сервисов или других причудливых функций, тогда как чистый php-fpm не мог этого сделать.
Нет значимого преимущества, которое перевешивает необходимость управлять двумя контейнерами. Пока у вас есть отношения 1: 1 между процессами, и они служат одной цели, поместите их в один и тот же контейнер.