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

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

Моя настройка

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

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

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

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

Dockerfile

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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

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

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

Ответ 2

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

Dockerfile

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