Кластерная кладка докерных контейнеров

Question

Я использовал решение laravel homestead для разработки, но теперь я хотел бы перейти на докер. Вопрос в том, как «раздутые» должны быть моими контейнерами. Когда я говорю «раздутый», я имею в виду, сколько модулей/услуг должно быть за контейнер. Например я создал четыре пользовательских контейнеры, как это:

php 
    -> php-fpm 
    -> composer 
    -> memcached 
    -> redis 
mysql 
    -> mysql 
nginx 
    ->nginx 
node 
    ->gulp 
    ->bower 
    ->npm 
    ->grunt 

Вопрос заключается в том, является ли это правом кластеризации или я должен создать отдельный контейнер скажу для пехотинца, дачи, Memcached и т.д.? Как решить, что происходит вместе и что нужно разделить на контейнер? Есть ли какие-то правила? Должно ли быть развитие так же, как и производство?

Answer 1

Как вы используете компоненты приложения в контейнерах, зависит от ваших целей. Является ли ваша цель упростить управление и администрирование вашего сервера? Вы в первую очередь заинтересованы в том, как масштабировать приложение успешно, поскольку оно получает больше трафика? Вот несколько советов, если основной задачей является масштабирование:

1. Помещение nginx в собственный контейнер имеет смысл, поскольку его основная роль - function as a load balancer. По большей части все nginx - это передача запросов на ваш PHP-сервис для обработки. Поскольку, вероятно, ваше приложение должно обрабатывать сеансы, и поскольку вы не хотите, чтобы ваши контейнеры делили данные сеанса, вы должны использовать стратегию ip_hash для делегирования запросов. Таким образом, вы не столкнетесь с проблемой нон и токенов CSRF, которые не распознаются.
2. Поскольку ваши контейнеры PHP будут выполнять большую часть работы, вы должны, вероятно, сохранить их в контейнерах самостоятельно. Если латентность становится проблемой, вы всегда можете просто развернуть новый контейнер PHP и добавить его в свой виртуальный кластер, чтобы справиться с нагрузкой. Все, что связано с управлением сеансом, например, с Redis или memcached, также можно поместить в этот контейнер. Таким образом, в каждом контейнере есть все инструменты, необходимые для снижения латентности, и открывайте узкие места.
3. Вы хотите разместить свои файлы приложений Laravel в одном контейнере и объединить свои тома в других контейнерах. Таким образом, если ваше приложение делает такие вещи, как загрузка файлов файлов, вам не придется копировать эти файлы в несколько контейнеров. Возможно, вы захотите поставить здесь композитора и ремесленника, поскольку задачи, которые обрабатываются этими программами, в первую очередь связаны с поддержкой файлов в вашем приложении Laravel. Dylan Lindgren suggests putting artisan and composer into their own containers.
4. Поскольку ваши данные также доступны для всего приложения, у вас также должен быть отдельный контейнер для вашей базы данных.Я думаю, вы могли бы подумать о том, чтобы связать свою базу данных с вашими файлами приложений Laravel, но, вероятно, проще не делать этого, так как вы сможете легко найти предварительно сконфигурированные контейнеры для различных типов баз данных.
5. Что касается узла, вам может и не понадобиться это на вашем производственном сервере. Поскольку компоненты узла/npm обычно используются только для объединения и сжатия ресурсов (JS и CSS) до развертывания, вы можете просто выполнить всю предварительную обработку ресурсов на вашей машине dev и создать сжатые/мини-файлы CSS/JS часть вашего контейнера Laravel. Поскольку вся обработка, связанная с CSS/JS, происходит на стороне клиента, их можно по существу рассматривать как статические файлы.

Вот схема, чтобы представить это:

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

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

Одна из интересных вещей о Docker заключается в том, что вы разрабатываете свои контейнеры локально и можете развернуть их «как есть» в облаке. Таким образом, локально у вас будут все эти контейнеры (и вы даже можете поменять некоторые из них, скажем, ваш БД и/или сервер), а затем развертывание просто станет задачей запуска нового экземпляра вашего контейнера на рабочем сервере ,

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

Answer 2

При определении моих контейнеров я всегда думаю о том, насколько определенная услуга будет масштабироваться, и если я смогу масштабировать ее изолированным способом. Чтобы я мог масштабировать определенные сервисы вовремя и точно настраивать, где узкое место действительно. Используя ваш пример, я хотел бы сделать:

• PHP + Nginx + Node (App контейнер)
• MySQL (Mysql контейнер)
• Memcached (Memcached контейнер)
• Redis (Redis контейнер)

Вы всегда можете подумать о добавлении большего количества экземпляров MySQL в кластер MySQL так же, как вы можете делать с Memcached и Redis.

Как конечный уровень рекомендаций, в производственной среде вы должны подумать о том, чтобы использовать что-то вроде Amazon RDS и Amazon Elasticache для MySQL и Memcached + Redis. Это будет проще для настройки и управления.