Docker Compose, когда использовать изображение поверх сборки

Question

Docker Compose documentation и его example use case были полезны, чтобы разобраться в различных возможностях разделить различные рабочие среды (разработка, производство и т. Д.).

web: 
    image: example/my_web_app:latest 
    links: 
    - db 
    - cache 

db: 
    image: postgres:latest 

cache: 
    image: redis:latest 

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

Это единственное доступное описание, которое идет с их только image: example/my_web_app:latest например:

Другой распространенный случай использования работает AdHoc или административные задачи против одного или нескольких услуг в Compose приложение. В этом примере демонстрируется запуск резервного копирования базы данных.

Остальные их пример случаев использует build: .

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

• [разработка] Разработчики могли бы изменить конфигурацию Dockerfile (и им нужно будет как-то протестировать ее до нажатия любых изменений).
• [разработка] Файлы исходного кода будут меняться (но я думаю, вы можете легко это исправить, разделив тома).
• [производство] Возможно, вы не всегда хотите быть в версии :latest (или вы?).
• [any] с использованием изображений (и тега :latest), у вас нет контроля над файлами, которые вы касаетесь. Но каждый раз, когда вы включаете docker-compose up, он будет обновляться до последней рабочей версии.

Некоторые из предыдущих пунктов могут быть неверными. Не стесняйтесь разбирать их.

Answer 1

Обычно вы хотели бы использовать build . в следующих случаях:

• развития
• автоматизированного тестирования

Это обычно делается, когда вы разрабатываете или тестирования, а код не производство готово. например тесты терпят неудачу, код не компилируется, ошибки кода и т. д.

Обычно вы создадите изображение только тогда, когда оно будет готово к отправке для развертывания. В этот момент вы создадите изображение, вернете его через свой тег и подтолкните его к своему персональному DTR или Docker Hub.

При работе с версиями в докере вы не привязаны к :latest, вы можете указать любую версию, которую хотите обеспечить, чтобы правильная версия работала в любой заданной среде.Например, в производстве вы можете создать файл с именем создания сообщения docker-production.yaml, который настроен таким образом:

web: 
    image: "example/my_web_app:${TAG}" 
    links: 
    - db 
    - cache 
db: 
    image: postgres:9.5.2 
cache: 
    image: redis:3.0.7 

Где ${TAG} является переменной среды, подставляются во время выполнения, например, docker-compose up -d -f docker-production.yaml. Вы можете больше узнать о замене переменных here.

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

Примечание:

1. Как команды запуска их сборки, корабль, развертывание значительно варьируется, как они выяснить, что работает лучше всего для них и их продукции так вышеуказанных build . сценариев не может быть точной для всех случаев, но является точным для использования моей компанией.
2. Предполагается, что build . в docker-compose context, а не в контексте docker build.

Answer 2

Как сказал @ GHETTO.CHILD, это зависит от ваших потребностей и рабочего потока. На самом деле мы не выполняем ручные сборки. Я собираюсь объяснить, как мы справляемся с этим и почему. Он отлично вписывается в наш поток, но не подходит для других сценариев.

• Мы не создаем изображения вручную. CI делает это (GitLab CI в нашем случае)
• У нас есть 2-х типов изображений, разработки/тестирования и производства.

• Существует docker-compose.yml, что облегчает управление окружающей средой. Они просто запускают docker-compose up и извлекают изображение из реестра и монтируют его каталог внутри контейнера.

  version: "2" 
  
  services: 
      web: 
      build: 
       context: ../../ 
       dockerfile: dockerfiles/dev/Dockerfile 
      image: registry.my.domain/my_image:dev 
      volumes: 
       - ../../:/opt/app 
      working_dir: /opt/app 
  

• Если они внесли изменения в Dockerfile (например, они нуждаются в новую библиотеку), они могут создать изображение в своей машине (docker-compose build), но изображение не прижимаются в реестр.

• Когда они счастливы, они нажимают новый код (который включает в себя файл Docker), а CI создает новое изображение dev и запускает тесты.
• CI каждый раз создает изображения в одном и том же хосте, поэтому он может использовать кеширование. Если Dockerfile не имеет никаких изменений, сборка занимает менее секунды.
• Когда создается новый тег, CI создает изображение с изображением $TAG в качестве тега изображения.
• Для производства мы используем orchestrator, а не состав YAML. Мы не хотим хранить конфиденциальные данные, которые могут находиться в docker-compose.yml в репозитории проекта. Чтобы обновить, мы просто вытаскиваем новый тег из реестра (мы можем сделать это автоматически, но я пока не уверен, что нужно развертывать его на производстве без тестирования пользователя раньше: D).

Конечно, вы можете создавать изображения каждый раз для разработки, но есть проекты, которые могут занять много времени.Например, Python3 + pandas может занять 25 минут, так что это удручает, если вам приходится часто переключаться между проектами. С другой стороны, вытягивать изображение занимает меньше минуты.

Мы используем этот подход, поскольку GitLab дает нам CI, Registry и runners для создания изображений и запуска тестов. Вы можете сделать это без него, но вам нужно будет интегрировать все компоненты самостоятельно. Поток не идеален, он имеет некоторые недостатки, но незначителен в нашем сценарии.