Question

我们正在开发一个由mongodb，java后端和基于express-js的前端组成的小项目。我们已选择docker-compose作为除生产用途以外的所有部署工具，到目前为止，除了一个例外情况外它还相当不错。

目前，我们将其用于：

运行本地开发群集;
运行集成测试（带有一些调整和额外的依赖关系）;
准备负载测试环境（更多调整）;
在单独的云计算机上运行登台/演示环境。

为了处理每个环境的所有各种调整，我们推断出一组泊坞文撰写文件：docker-compose.yml，d-c.override.yml，d-c.test.yml，d-c.load.yml和{{1为了简洁起见，d-c.demo.yml替换为docker-compose。

这使得我们使用极长的命令行调用来执行除基本任务之外的任何操作。例如：

d-c

情况变得更糟。

到目前为止，我们已经有了一些关于改善这一点的想法：

使用完整的docker-compose文件而不是部分文件来节省输入 - 但是当引入应用程序结构更改/额外参数时需要额外的维护;
（前者的变体）使用docker-compose -f docker-compose.yml -f docker-compose.test.yml up -d --build docker-compose -f docker-compose.yml -f docker-compose.test.yml exec test_container ./do_tests.sh来提供服务并最小化复制粘贴（但会增加额外的复杂性）;
将所有这些冗长的命令存储在extends（或bash脚本）中。易于使用，但感觉就像地毯下的复杂性;
（前者的变体）开发docker-compose插件/自己的工具 - 可能更明确地处理我们的需求，但额外的维护和部署复杂性。

所有这些想法都有它们的缺点 - 我想知道什么是适当的解决方案以及已经存在的工具。

Answer 1

我认为3听起来是一个很好的解决方案。它不是“隐藏复杂性”，它只是自动执行重复性任务（键入长命令行）。

Makefile可以使用，但您可能也对dobi感兴趣（免责声明：我是此工具的作者）。 dobi允许您在yaml文件中定义所有项目任务，包括使用不同的文件和项目名称运行Compose。您的项目的示例配置可能看起来像这样

compose=dev:
  files: [docker-compose.yaml, d-c.override.yml]

compose=test:
  files: [docker-compose.yaml, d-c.test.yml]

compose=load:
  files: [docker-compose.yaml, d-c.load.yml]

然后您可以使用dobi dev等运行任务

你甚至可能会发现一些一次性任务可以转移到dobi配置，无需额外的compose覆盖。

管理docker-compose覆盖文件

1 个答案: