Является ли «Правильный путь» для разделения Docker связанных файлов и Python связанных файлов в разных git репозиториях?

Question

Я создаю приложение с другом и пишу весь код на конце.

Я начал создавать API, а также настраивал docker -compose, оба в одном Git хранилище. Каталог / app, который содержит app.py, а также мои docker -compose.yml, Dockerfile- flask и Dockerfile- nginx, все в настоящее время находятся в одном каталоге. Мой друг увидел мой код и говорит, что все связанные с Docker файлы должны быть извлечены в его собственные Git Репо, и при работе с микросервисом они должны просто ссылаться на репозитории Business logi c.

Это правильно? И если да, то может ли кто-нибудь указать мне, как реализовать этот шаблон?

Answer 1

Я видел этот шаблон с инструментами развертывания более высокого уровня (файлы YAML для развертывания Kubernetes, диаграммы Helm, мультисервисные Docker создание файлов YAML), но для Dockerfile. * 1002 он не имеет смысла. *

В контексте одной службы я бы поместил Dockerfile, локальный docker-compose.yml, который запускает эту службу, и другие подобные артефакты в каталоге root сервисный репозиторий; или в подкаталоге; но не в другом хранилище. Для вещей, которые охватывают службы размещение их в другом хранилище может иметь смысл.

Для самого Dockerfile проблема в том, что команда COPY не может ссылаться ни на какие файлы за пределами каталога «context», который передается команде docker build, а для опции docker build -f требуется, чтобы там тоже был Dockerfile. Если Dockerfile находится в каталоге root службы, то это просто; если это где-то еще, то у вас есть неловкая настройка, в которой вы должны загружать все, что вы извлекли, как контекстный каталог docker build.

git clone ... build-scripts
git clone ... myapp
# This uploads everything you have checked out as the context
docker build -f build-scripts/myapp/Dockerfile -t myapp:latest .

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

Если вам нужно развернуть несколько служб вместе, то может иметь смысл хранить их в каком-то отдельном хранилище.

# What directory should this `docker-compose.yml` file go in?
version: '3'
services:
  service-a:
    image: me/service-a:latest
  service-b:
    image: me/service-b:latest
    environment:
      - SERVICE_A_URL=http://service-a
    ports:
      - '8000:8000'

Файлы YAML Kubernetes могут быть небольшим исключением из этого. Обычно их бывает несколько (развертывание, служба, настройка зависимости от базы данных, ...), и они несколько специализированы; они также зависят от имени изображения в качестве ссылки, но не от самого исходного кода приложения. Я видел установку, где YAML-файлы Kubernetes или диаграммы Хелма находятся в их собственном хранилище. Я также видел настройки, где каждый репозиторий имеет свои собственные файлы Kubernetes. В основном это зависит от того, отвечают ли авторы службы за их обслуживание или у вас есть специальная команда, которая занимается всем, что связано с Kubernetes (модель «структура источника отражает вашу организационную структуру»).