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