我在这里难过。很多这已经到位,它只是我无法弄清楚的包装。
我们有一个微服务架构,有许多独立的存储库。我们使用Docker和Docker Compose来构建和运行开发环境,它的工作非常精彩。
我遇到的问题是如何打包主要的存储库集合。所以,如果我有一个文件夹结构,如:
\
service1
.git
Dockerfile
service2
.git
Dockerfile
service3
.git
Dockerfile
docker-compose.yml
README.md
...其中service1,service2,service3各自都是他们自己的git存储库。
我的第一个想法是使用git子模块,将工作,但是我们强制执行策略以要求开发人员分叉存储库而不是由于持续集成约束和代码审查而在主存储库之外工作。在我想到这个警告之前,我对使用git子模块并不过分兴奋,因此更倾向于使用替代解决方案。
目前我只能想写脚本来存储存储库列表;为每个运行一个查询,看看登录的开发人员是否有每个分支,如果没有,则创建一个,然后进入主文件夹;然后启动docker-compose。这似乎是一个可怕的解决方案,足以让我可能只需要编写文档来告诉开发人员如何手动执行此过程......
思想??
感谢您的时间:)
答案 0 :(得分:3)
我遇到了与工作流程类似的问题(除了我没有使用分叉)。最终我的要求归结为一件事:
project bootstrap
来引导我的环境我建议做一些事情来优化工作流程,这对我来说非常好:
在JSON文件中存储服务列表,其中每个服务都有“url”,“fork_url”,“name”以及docker-compose所需的其他常用属性,以了解如何处理此服务。看起来您团队中的每个团队成员都会有fork url或base repo url
构建一个命令行应用程序(有许多选项可用 - 取决于您选择的语言,Ruby的宝石Thor,Go it的软件包Cobra等)。通常只需几个小时即可构建一个简单的命令行应用程序结构和第一对命令,但这种类型的自动化将每天节省您的时间,您将拥有扩展命令行的基础应用程序随着您的需求增加而且该概念被证明是可行和有用的。您还将拥有一个统一的界面来为所有团队成员配置您的环境,然后由团队负责维护它。
project bootstrap
命令以配置您的环境。例如,它将:
docker-compose.yml
答案 1 :(得分:1)
这可能取决于您的工作流程。您是否可能同时对多项服务进行更改?
如果您通常只在任何指定时间对一项或两项服务进行更改,则可以将docker-compose.yml
设置为仅使用image
字段(而不是build
),并且不使用任何主机卷。使用此设置,检查代码的位置并不重要,因为docker-compose.yml
只使用docker守护程序可用的图像。
这将要求您在每个仓库中包含其他docker-compose.yml
个文件(或bash脚本,makefile等),以便为每个服务构建映像。
如果您需要主机卷进行交互式开发,可以使用docker-compose.override.yml
根据需要添加它们(但这取决于开发人员将其指向正确的路径)。
答案 2 :(得分:0)
我必须在工作中解决类似的问题(虽然我们不使用Docker;而是我们有一个Vagrantfile
为我们的每个微服务配置VM。)
创建一个包含develop
的{{1}}存储库。每个开发人员都应该将docker-compose.yml
存储库以及他或她的微服务分支克隆到公共目录(例如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
(和所有其他代码)均可用。