在多容器，多存储库项目中保留部署文件的位置？

Question

我有一个由三个git存储库和应用程序组成的堆栈：

• 前端申请
• 后端应用程序
• 工人申请

它们都与docker-compose.yml文件一起使用，该文件还包含部署应用程序所需的其他资源和图像。

当我部署应用程序时，我只需要推送docker-compose.yml文件，或者在AWS的情况下，它将是Dockerrun.aws.json文件。所以我的问题是......我应该在哪里保存这个文件？它不属于任何上述存储库，因为它协调了所有这些存储库。

我应该设置一个名为“部署存储库”的第四个存储库来保存我的所有部署文件和配置吗？或者我从上面选择一个我认为是“我部署的回购”的存储库，我保留了所有存储库？或者我是否可以在所有存储库中存储部署的副本，以便无论我正在处理哪个存储库，我都可以部署完整的应用程序？

Answer 1

发表这个问题几个月后，我得出以下结论：

1。单声道存储库

在某些情况下，最简单的解决方案可能是创建一个包含所有应用程序的存储库。这违背了Heroku编写的12 Factor Methodology，但是如果你所做的只是管理前端和后端应用程序，它可能会为你节省大量额外的工作和开发。

您的git存储库将是：

.git/
frontend_app/
  ...
  Dockerfile
backend_app/
  ...
  Dockerfile
deployment/
  nginx/
  docker-compose-dev.yml
  docker-compose-prod.yml

2。多个存储库

如果您坚持使用多个存储库的想法，可能是因为您严格遵循最佳实践并希望分离代码，或者可能因为您拥有可能膨胀到数十个或数百个存储库的多服务基础架构，我推荐以下内容：

1. 每个应用程序都有自己的存储库，它自己的CI / CD管道以及它自己的构建过程。每当更新一个repo时，它都会触发构建并创建一个docker镜像。 它不会“部署”任何内容。

2. 您有一个单独的部署存储库，该存储库仅包含协调系统的文件，可能包含任何Web服务器配置或其他部署配置。这是部署的repo。

3. 每当您的部署检测到更改时，它都会下载构建的最新映像并更新您的应用程序。这可以在触发更新的第一步中通过CI / CD管道完成，也可以由服务器上的代理监听更新。

第三部分是棘手的部分，有多种方法可以解决它。有多种软件可以帮助管理此类基础架构，例如AWS ECS，Docker Swarm或Kubernetes。

Answer 2

尝试任意方法，评估利弊并稍后重新考虑。我不认为有一种标准方法。

您可以想象“打包”或仅仅“暴露”源控件存储库之外的docker-compose定义（此时它们是部署工件，而不是源），当然原始源文件应受版本控制。

我们喜欢git甚至是部署，因为它允许我们跟踪每个部署的配置更改（在提交日志中使用特定于部署的注释）。背景可能有点特别;有问题的应用程序通常需要在不同站点之间进行非常不同的配置，因此实际的docker-compose.yml文件实际上每个部署都是不同的。因此，我们每个部署都使用一个git存储库。 YMMV。