为微服务存储子模块，但仍然使用分叉答案

【问题标题】：Storing submodules for micro services, but still using forks为微服务存储子模块，但仍然使用分叉
【发布时间】：2016-03-09 18:31:46
【问题描述】：

我被难住了。其中很多已经到位，只是我无法弄清楚的包装。

我们有一个微服务架构，有许多独立的存储库。我们正在使用 Docker，以及 Docker Compose 来构建和运行开发环境，效果很好。

我的问题是如何打包存储库的主要集合。因此，如果我的文件夹结构如下：

\
    service1
        .git
        Dockerfile
    service2 
        .git
        Dockerfile
    service3
        .git
        Dockerfile
    docker-compose.yml
    README.md

...其中 service1、service2、service3 是各自的 git 存储库。

我的第一个想法是使用 git 子模块，这会工作，但是由于持续集成约束和代码审查，我们强制要求开发人员分叉存储库而不是从主存储库工作。甚至在我想到这个警告之前，我对使用 git 子模块并没有过分兴奋，所以我更喜欢替代解决方案。

目前我只能考虑编写脚本来存储存储库列表；对每个运行一个查询，看看登录的开发人员是否有一个 fork，如果没有，则创建一个，然后拉入主文件夹；然后启动 docker-compose。不过，这似乎是一个可怕的解决方案，足以让我可能只需要编写文档来告诉开发人员如何手动执行此过程...

想法？？

感谢您的宝贵时间 :)

【问题讨论】：

标签： git docker git-submodules docker-compose microservices

【解决方案1】：

我不得不在工作中解决一个类似的问题（尽管我们不使用 Docker；相反，我们有一个 Vagrantfile 为我们的每个微服务配置一个 VM）。

创建一个包含您的docker-compose.yml 的develop 存储库。每个开发人员都应该将develop 存储库以及他或她的微服务分支克隆到一个公共目录（例如~/workspace）：

/Users/conar/workspace
  /develop
    /docker-compose.yml
  /service1
    /Dockerfile
    /app.js
  /service2
    /Dockerfile
    /app.js
  /service3
    /Dockerfile
    /app.js

您的docker-compose.yml 可能如下所示：

service1:
  build: ../service1/Dockerfile
  volumes:
    - ../service1:/app
service2:
  build: ../service2/Dockerfile
  volumes:
    - ../service2:/app
service3:
  build: ../service3/Dockerfile
  volumes:
    - ../service3:/app

现在每个服务的app.js（和所有其他代码）都可以在/app 下获得。

【讨论】：

【解决方案2】：

我在工作流程方面遇到了类似的问题（除了我没有使用分叉）。最终我的要求归结为一件事：

作为开发人员，我想运行 1 个命令 project bootstrap 来引导我的环境

我建议做一些事情来优化工作流程，这对我来说效果非常好：

在 JSON 文件中存储服务列表，其中每个服务都有“url”、“fork_url”、“name”和 docker-compose 了解如何处理该服务所需的其他常用属性。似乎您团队中的每个团队成员都有 fork url 或 base repo url
构建一个命令行应用程序（有许多可用选项 - 取决于您选择的语言，对于 Ruby，它是 gem Thor，对于 Go，它是包 Cobra，等等）。通常只需几个小时即可构建一个简单的命令行应用程序结构和前几个命令，但这种类型的自动化将每天为您节省数小时，并且您将有一个扩展命令行的基础应用程序随着您的需求增加，并且该概念被证明是可行和有用的。您还将有一个统一的界面来为所有团队成员配置您的环境，然后由团队负责维护它。
构建一个project bootstrap 命令来配置您的环境。例如，它将：
- 查看 JSON 文件中的服务列表：
  - 如果不存在则创建一个分叉
  - 克隆你的仓库
  - 向您的 repo 添加另一个远程，它将代表 fork（除了原点）
  - 将从指定目录中的模板生成docker-compose.yml

【讨论】：

我的结局与这里相似。我构建了一个 bash 脚本来从主存储库克隆一个只读副本，并构建每台机器。一旦实例全部运行，还有一个单独的脚本用于配置数据库和诸如此类的东西。所以2个脚本还不错。如果开发人员想要将更改发布到分支，他们只需将其远程源重命名为上游并将其分叉添加为新源。
我对能够保持最新状态并不过分兴奋，但我看到了一些潜在的陷阱......

【解决方案3】：

这可能取决于您的工作流程。您是否可能同时对多项服务进行更改？

如果您通常在任何给定时间只更改一个或两个服务，您可以将您的 docker-compose.yml 设置为仅使用 image 字段（而不是 build），并且不使用任何主机卷。使用此设置，在哪里签出代码并不重要，因为 docker-compose.yml 只使用 docker 守护进程可用的图像。

这将要求您在每个 repo 中有其他 docker-compose.yml 文件（或 bash 脚本、makefile 等）来为每个服务构建图像。

如果您需要用于交互式开发的主机卷，您可以使用 docker-compose.override.yml 在必要时添加它们（但这取决于开发人员将其指向正确的路径）。

【讨论】：