Правильная настройка Docker для нескольких сайтов
Мне интересно, каков правильный порядок настройки для размещения нескольких веб-сайтов с использованием простого стека LEMP. Предположим, у меня есть виртуальная машина из Digital Ocean. Я хочу разместить 3 сайта на этой виртуальной машине.
Чтобы принимать запросы, у меня либо контейнер HAproxy, либо контейнер виртуального хоста Nginx, расположенный спереди. Затем он направляет конкретные запросы в стек контейнеров, которые обрабатывают приложение
Запросы => Nginx / HAproxy =>
(website1.com) => (Nginx, php-fpm, стек mysql)
(website2.com) => (Nginx, php-hpm, mysql stack)
(website3.com) => (Nginx, php-hpm, стек mysql)
Если это правильная настройка, как мне масштабировать отдельные сайты? Если веб-сайт 2 получает намного больше трафика и нуждается в большем количестве контейнеров, я бы увеличил весь стек (nginx, php-fpm, mysql) x2 или я позволил бы контейнеру Nginx в передней части стека балансировать нагрузку между несколькими php-fpm случаи?
website2.com => 1 (nginx, php-fpm, mysql) или 2 (nginx, php-fpm, mysql) с использованием циклического перебора.
ИЛИ ЖЕ
website2.com => (nginx, php-fpm, php-fpm, php-fpm, mysql), где этот контейнер nginx обрабатывает циклический перебор между контейнерами php-fpm.
Дополнительное примечание: где я могу разместить свои сертификаты SSL для каждого сайта? Я помещаю их в контейнер виртуального хоста HAproxy / Nginx, или я просто имею существующий в контейнере стека nginx.
Решение
Прежде всего, имейте в виду, что контейнеры должны запускать один процесс, а не стеки. Хотя возможно запустить INIT-как процесс порождения нескольких процессов внутри одного контейнера, или даже что-то вроде Supervisord чтобы достичь этого, это не лучшая практика. Контейнеры предназначались для использования в качестве микроуслуг.
Таким образом, без учета базы данных, одним из возможных сценариев будет:
- множественный контейнеры для приложений, по одному на сайт, работает PHP-FPM;
- Один сингл контейнер веб-сервера, Бег Nginx и в том числе ВХост Конфигурация для каждого веб-сайта и ссылки на все контейнеры вашего приложения;
- Один сингл балансировщик нагрузки Контейнер, запускающий все, что вы выберете в качестве решения для балансировки прокси, со всей конфигурацией, необходимой для веб-сайтов, включая SSL.
Итак, я понимаю, что у вас будет, по крайней мере, 2 слоя: Балансировщик нагрузки / Прокси -> Приложения. Итак, 3) переходит в верхний уровень, а 1) и 2) переходит в другой, который должен работать на том же сервере.
Что касается службы базы данных, я не уверен, что это хороший выбор для запуска ее в контейнере. Вам придется сопоставить каталог данных с хоста (потому что контейнеры эфемерны, а ваши данные — нет), и не имеет смысла перемещаться по вашему контейнеру на другие серверы без перемещения данных, поэтому контейнер выглядит довольно бесполезно в этом случае. И в любом случае вы не будете использовать контейнер для использования развертываний в этом случае, поэтому я не вижу в этом большого преимущества. Было бы лучше просто иметь другой сервер для базы данных.
Что касается масштабирования, если вы решите запустить все сайты на одном сервере, у вас не будет большого выбора, кроме как масштабировать все вместе. Кроме того, вы можете разделить вещи по услугам. У вас будет группа машин для каждого «микросервиса» (скажем, website1 + nginx1, website2 + nginx2, так далее). Таким образом, вы можете масштабировать каждую услугу независимо, но это, вероятно, будет означать много накладных расходов и растрату ресурсов. Все зависит от того, насколько сложным вы думаете, что вам нужно получить.
На этот вопрос нелегко ответить, и в том, что касается подобных архитектур, нет ничего правильного и неправильного. Это всего лишь вопрос выбора хорошего компромисса для вас.
Другие решения
Других решений пока нет …