Заявление об ограничении ответственности: это мое собственное мнение по этому поводу, заданное г-ном Марсом. Несмотря на то, что я сделал все возможное, чтобы подкрепить свой ответ фактическими источниками, он в основном основан на моем собственном опыте и немного здравом смысле

Какой из этих сценариев наиболее типичен при использовании Docker для разработки?

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

• Dev и Prod Docker Compose близки друг к другу, что означает, что среда разработки максимально приближена к среде Prod.
• Вам не нужно постоянно перестраивать образ при разработке, но это легко сделать, когда вам нужно
• Многие технологии поддерживают такой сценарий, такие как Spring Dev Tools, как вы упомянули, но также Python Flask и т. Д.
• Вы можете легко использовать Docker Compose расширяет механизм общего доступа к конфигурации (также возможно в сценарии 2)

Хорошо ли рассмотрен сценарий 1? То есть докеризуйте только внешние службы, такие как базы данных, очереди и т. Д., И выполняйте разработку и отладку приложения с помощью IDE, не используя для этого Docker.

Сценарий 1 довольно распространен, но среда IDE, вероятно, будет отличаться от среды контейнера Docker (и было бы сложно поддерживать соответствие версии для каждой библиотеки, зависимостей и т. Д. Из среды IDE в среду Docker). Также, вероятно, потребуется пройти промежуточный этап между Dev и Production, чтобы фактически протестировать образ Docker, созданный после того, как Dev работает, прежде чем перейти в производство.

По моему собственному опыту, делать это здорово, когда вы не хотите слишком много работать с Docker, когда фактически занимаетесь разработкой и / или язык или технология, которые вы используете, не адаптированы для динамической перезагрузки, как описано в сценарии 3. Но в конце концов это только добавляет дрейф между средами и усложняет метод развертывания Dev и Prod.

необходимость перестроить образ и снова запустить контейнеры - значительная трата времени. Короче говоря, возникает вопрос: как этого избежать?

Помимо описанных вами сценариев, у вас есть способы прилично (даже резко) сократить время сборки образа, используя Кэш сборки Docker и создание файла Dockerfile. Например, приложение Python обычно копирует код в качестве последнего (или почти последнего) шага сборки, чтобы избежать недействительности кеша, а для приложения Java можно было бы разделить код, чтобы избежать компиляции всего приложения каждый раз. изменений кода - это будет зависеть от вашей реальной настройки.

Я лично использую рабочий процесс, примерно соответствующий сценарию 3, например:

• файл docker-compose.yml, соответствующий моей производственной среде
• docker-compose.dev.yml, который переопределит некоторые аспекты моего основного файла Docker Compose, такие как код подключения с моей машины, добавление специальных флагов разработчика к командам и т. д. - он будет запускаться, например,

  docker-compose -f docker-compose.yml -f docker-compose.dev.yml 
  

  , но также можно было бы иметь docker-compose.override.yml as Docker Compose по умолчанию использует для переопределения
• в некоторых ситуациях мне пришлось бы использовать другие переопределения для конкретных ситуаций, таких как docker-compose.ci.yml на моем CI, но обычно основного файла Docker Compose достаточно для описания моей среды Prod (и если это не так, docker-compose.prod.yml делает трюк)

Я использую что-то похожее на ваш третий сценарий для своего веб-разработчика, но он основан на Node. Итак, у меня есть 3 файла docker-compose (на самом деле 4, один базовый, а содержит все обычные вещи для других) для сред разработки, подготовки и производства.

Поэтапная конфигурация docker-compose аналогична производственной конфигурации, за исключением SSL, портов и других вещей, которые могут не позволять использовать ее локально.

У меня есть отдельный контейнер для каждой службы (например, БД, очередь), а для разработчиков у меня также есть дополнительная база данных разработчика и контейнеры очереди, в основном для запуска автоматических тестов. В среде разработки весь исходный код монтируется в контейнеры, поэтому он позволяет использовать IDE / редактор по выбору вне контейнера и видеть изменения внутри.

Я использую supervisor для управления моими воркерами внутри контейнера с воркерами, и у меня есть несколько команд для перезапуска моих воркеров вручную, когда мне это нужно. . Может быть, у вас есть что-то похожее на перекомпиляцию / перезапуск вашего Java-приложения. Или, если у вас есть представление о том, как организовать обнаружение изменений исходного кода приложения и автоматическую перезагрузку приложения, это может быть лучший вариант. Кстати, вы подали мне идею исследовать что-то подобное, подходящее для моего случая.

Для промежуточной и производственной среды мой исходный код включен в соответствующий контейнер с использованием рабочего Dockerfile. И у меня есть несколько команд для перезапуска всего, что мне нужно, и это обычно включает перестройку контейнеров, но из-за кеша Docker это не занимает много времени (около 20 секунд). А учитывая, что переключение между средами - не слишком частая операция, мне это вполне комфортно.

Производственная конфигурация docker-compose используется только во время развертывания, потому что она включает SSL, правильные порты и имеет некоторые дополнительные производственные возможности.

Обновите информацию о перезапуске серверного приложения с помощью Supervisor:

Вот как я использую его в своих проектах:

Часть моего Dockerfile с установкой Supervisor:

FROM node:10.15.2-stretch-slim

RUN apt-get update && apt-get install -y \
  # Supervisor
    supervisor \
    ...

...

# Configs for services/workers managed by supervisor
COPY some/path/worker-configs/*.conf /etc/supervisor/conf.d/

Это пример одной из конфигураций Supervisor для воркера:

[program:myWorkerName]
command=/usr/local/bin/node /app/workers/my-worker.js
user=root
numprocs=1
stopsignal=INT
autostart=true
autorestart=true
startretries=10

В этом примере в вашем случае command должно запустить ваше приложение Java.

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

# Used to run all workers
su-start:
    @docker exec -t MY-WORKERS-CONTAINER-NAME supervisorctl start all

# Used to stop all workers
su-stop:
    @docker exec -t MY-WORKERS-CONTAINER-NAME supervisorctl stop all

# Used to restart all workers
su-restart:
    @docker exec -t MY-WORKERS-CONTAINER-NAME supervisorctl restart all

# Used to check status of all workers
su-status:
    @docker exec -t MY-WORKERS-CONTAINER-NAME supervisorctl status

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

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

Я видел, как все они использовались в разных сценариях. Есть несколько ошибок, которых следует избегать:

1. Приложения внутри контейнера не должны зависеть от того, что работает вне контейнера на хосте. Таким образом, все ваши зависимости должны быть сначала помещены в контейнер.

2. Права доступа к файлам с хост-томами могут быть сложными в зависимости от вашей версии докера. Некоторые из новых установок Docker Desktop автоматически обрабатывают сопоставления uid, но если вы разрабатываете непосредственно в Linux, вам необходимо убедиться, что контейнеры работают с тем же uid, что и ваш пользователь хоста.

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

Рассматривая каждый из вариантов, вот моя оценка каждого:

1. Контейнеризация только БД: это хорошо работает, когда у разработчиков уже есть среда разработки для выбранного языка, и нет риска появления внешних зависимостей, например разработчик обновляет свою установку JDK до более новой версии, чем создается образ. Он следует идее контейнеризации зависимостей в первую очередь, а также дает разработчикам знакомую интеграцию IDE с их приложением.

2. Восстановление изображения для каждого изменения. Это, как правило, наименее идеальный вариант для рабочего процесса разработчика, но самый быстрый для реализации, когда вы не знакомы с инструментами. Я дам 4-й вариант, который считаю улучшением этого.

3. Все в контейнере, том монтируется и выполняется оперативная перезагрузка: это наиболее сложно реализовать, и для его поддержки требуется, чтобы сам язык поддерживал такие вещи, как оперативная перезагрузка. Однако, когда они это делают, разработчики почти без проблем могут быстро освоить новый проект без необходимости устанавливать какие-либо другие инструменты для начала работы.

4. Перестройте приложение в контейнере с монтированием тома: это промежуточная точка между 2 и 3. Если у вас нет оперативной перезагрузки, вам, вероятно, придется перекомпилировать или перезапустить интерпретатор, чтобы увидеть какие-либо изменения. Вместо того, чтобы перестраивать образ, я помещаю этап перекомпиляции в точку входа в образ для разработки. Я смонтирую код в контейнер и запускаю полный JDK вместо JRE (или любого другого компилятора). Я использую именованные тома для любых кешей зависимостей, поэтому их не нужно загружать при каждом перезапуске. Затем способ увидеть изменения - перезапустить этот контейнер. Шаги идентичны скомпилированному двоичному файлу вне контейнера: остановка старой службы, повторная компиляция и перезапуск службы, но теперь это происходит внутри контейнера, в котором должны быть те же инструменты, что и при создании производственного образа.

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

Прежде всего, docker-compose предназначен только для фазы разработки и тестирования, а не для производства. Пример:

При минимальной и базовой компоновке докеров все ваши контейнеры будут работать на одном компьютере? Для целей разработки это нормально, но при производстве размещать все приложения на одном компьютере - это риск.

• Официальная ссылка https://docs.docker.com/compose/production/

Мы будем предполагать

• 01 Java API
• 01 база данных mysql
• 01 веб-приложение, которому требуется api
• все эти приложения уже работают

Быстрый ответ

Если вам нужно исправить или добавить новую функцию в java api, я советую вам использовать ide, например eclipse или IntelliJ Idea. Почему?

• Потому что Java требует компиляции.
• Компиляция внутри контейнера докеров займет больше времени из-за зависимостей maven
• В IDE есть автозаполнение кода
• так далее

На этом этапе разработки Docker помогает вам с помощью одной из самых мощных функций: переносить производственные контейнеры на ваш локальный хост. Да, в этом случае docker-compose.yml - лучший вариант, потому что с одним файлом вы можете запустить все, что вам нужно: базу данных mysql и веб-приложение, но не свой java api. Откройте свой java api с вашим любимым ide.

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

Базовый жизненный цикл Devops с докером

• Изменения исходного кода разработчика push с помощью git
• Your continuous integration (C.I) platform detect this change and perform
  • docker build ... (In this step, unit test are triggered)
  • docker push в ваш частный хаб. Контейнер загружается на этом этапе и будет использоваться для развертывания на других серверах.
  • запуск докера или развертывание контейнера в следующей среде: тестирование
• Люди-тестеры, селен или другая автоматизация начинают свою работу
• Если ошибок не обнаружено, ваш C.I выполняет окончательное развертывание загруженного контейнера в производственной среде. Сборка докера не требуется, просто разверните или запустите докер.

Несколько советов

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

Java и Nodejs - стабильные языки, и ваши остальные api или веб-приложения не нуждаются в сумасшедших настройках. Просто компиляция maven и java -jar ... или npm install и npm run start.

Для журналов вы можете использовать https://www.graylog.org/, google stasckdriver или другое управление журналом.

И, как и в случае с Heroku, по возможности прекратите использовать зависимость от жесткого диска. В платформе heroku диски одноразовые, то есть исчезают при перезапуске приложения. Таким образом, вместо локального хранилища файлов вы можете использовать другую службу хранилища файлов с множеством функций.

Благодаря такому подходу ваши контейнеры могут быть легко развернуты в любом месте.