Docker-рекомендации по настройке веб-приложения с Redis, Postgres, ElasticSearch, NGINX, рабочими и несколькими приложениями ruby

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

Мои Настройки

есть несколько сервисов / демонов, которые я запускаю (Redis, ES, PG, NGINX), а также несколько рабочих (нужно поговорить с PG и Redis). У меня есть 3 ruby Web application services и сервис faye, который все должны поговорить с Redis, PG и ES. NGINX нужно будет поменять прокси на приложения.

контейнер стратегия

Первое, что я хочу знать, какую стратегию вы бы использовали с Docker и эти услуги.

  • не могли бы вы создать (например, ubuntu) контейнер для каждой службы, а затем запустить их с соответствующими туннелями (-link) к контейнерам?
  • вы бы связали услуги на одном контейнере и ваши приложения на другом?
  • или вы создаете один массивный контейнер?

Dockerfile

могли бы / могли бы вы сделать один файл Dockerfile для всех контейнеров или разделить их? т. е. Redis-Dockerfile, Web01-Dockerfile и т. д.

Развитие против производства

в разработке я хочу, чтобы изменения файлов мгновенно обновлялись в контейнерах (т. е. путь, установленный в контейнерах с хоста FS). Точка монтирования может отличаться от разработчика к разработчику. Как бы вы это устроили?

в производстве я могу либо клонировать репозитории приложений на главной машине и монтировать в VMs, либо клонировать код приложения внутри самого контейнера.

Я знаю флаг-v для монтирования томов, поэтому я бы предположил, что вы можете настроить некоторые переменные среды, чтобы сделать точки монтирования хоста настраиваемыми.

10
docker

2 ответов

контейнер стратегия: это часто задаваемый вопрос. Это действительно зависит от того, что вы хотите сделать с вашим приложением.

  • если ваше приложение будет иметь большое количество развертываний (например, если ваше приложение является SAAS, и вы будете развертывать один новый экземпляр на клиента), но эти развертывания, как ожидается, будут довольно небольшими, тогда вы можете поместить все в один контейнер, потому что развертывание будет намного проще.
  • если ваш приложение может быть значительно масштабировано (т. е. если вы ожидаете, что вам понадобится несколько интерфейсов, рабочих и т. д.), вы, вероятно, хотите поместить каждую службу в другой контейнер, чтобы вы могли масштабировать каждую службу отдельно.
  • если ваше приложение будет иметь большое количество развертываний и должен масштабироваться, тогда вам понадобится несколько контейнеров, и убедитесь, что вы также правильно используете ссылки: -)

Dockerfile: вам нужен Dockerfile на изображение. Итак, если вы создадите контейнер "все-в-одном", это один файл Dockerfile; если вы разделите приложение на несколько контейнеров с разными ролями (Redis, DB, Web...) вот как много разных Dockerfiles.

Dev vs Prod: это действительно зависит от языка/фреймворка/и т. д. которые вы используете.

  • иногда вы можете работать на своей локальной машине и создавать контейнеры (и тестировать их) время от времени (немного похоже на то, что вы "тестируете, чтобы постановка", за исключением того, что это намного быстрее). Это хороший подход, если создание новых контейнеров занимает некоторое время (например, если вы используете ADD затем следуют дорогостоящие шаги сборки / зависимости).
  • если контейнерные сборки быстрые, вы можете перестроить+повторно развернуть новые контейнеры непрерывно, каждый раз, когда вы что-то изменили.
  • вы также можете использовать два немного разных Dockerfiles. Предположим, что ваш источник будет в /myapp. В файле Dockerfile разработки вы объявите /myapp будет VOLUME, и разработчик должен будет привязать-монтировать свою локальную копию источника к /myapp. В производственном Dockerfile вы будете использовать ADD скопировать источник /myapp. Будут также незначительные различия в процессе сборки.

последний метод не идеален (так как лучше, когда среды dev и prod максимально близки!) но в некоторых случаях (при построении нового контейнера очень долго) это очень помогает.

16

контейнер стратегия контейнер используется для разделения службы, службы в контейнере, так это службы и как организовать службу!--3-->

Dockerfile

Dockerfile используется для создания изображений, которые используются для запуска контейнеров, поэтому сделайте Dockerfile с каждым контейнером

0