时间戳

首页 > 解决方案 > 在不同的 git 存储库中分离 Docker 相关文件和 Python 相关文件是否是“正确的方法”？

python - 在不同的 git 存储库中分离 Docker 相关文件和 Python 相关文件是否是“正确的方法”？

问题描述

我正在和一个朋友构建一个应用程序，并且我正在编写所有后端代码。

我开始在一个 Git 存储库中构建 API 以及设置 docker-compose。包含 app.py 的 /app 目录，以及我的 docker-compose.yml、Dockerfile-flask 和 Dockerfile-nginx 目前都位于同一个目录中。我的朋友看到​​了我的代码，并告诉我所有与 Docker 相关的文件都应该被拉入它自己的 Git 存储库中，并且应该在运行微服务时只引用业务逻辑存储库。

这个对吗？如果是这样，有人可以指出如何实现这种模式的方向吗？

标签： pythondockergithubarchitecturemicroservices

解决方案

我已经在更高级别的部署工具（Kubernetes 部署 YAML 文件、Helm 图表、多服务 Docker Compose YAML 文件）中看到了这种模式，但对于Dockerfile.

在单个服务的上下文中，我将启动该服务本身Dockerfile的本地以及其他类似的工件放在服务存储库的根目录中；docker-compose.yml或者在子目录中；但不在不同的存储库中。 对于跨服务的事物，将它们放在不同的存储库中是有意义的。

就其Dockerfile本身而言，问题在于该COPY命令无法引用传递给该docker build命令的“上下文”目录之外的任何文件，并且该docker build -f选项也需要Dockerfile存在。如果Dockerfile它位于服务的根目录中，那么这很简单；如果它在其他地方，那么你有一个尴尬的设置，你必须上传你已经签出的所有内容作为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'

Kubernetes YAML 文件可能是一个例外。它们往往有几个在一起（部署、服务、数据库依赖项的设置，...），而且它们有些专业；它们还依赖于图像名称作为参考，而不是应用程序源代码本身。我已经看到 Kubernetes YAML 文件或 Helm 图表位于它们自己的存储库中的设置。我还看到了每个存储库都有自己的 Kubernetes 文件的设置。这主要取决于服务作者是否负责维护它们，或者您是否有专门的团队来管理与 Kubernetes 相关的所有内容（“源布局反映您的组织结构”模型）。

推荐阅读