pipe理docker-compose覆盖文件
我们正在开发一个由mongodb，java后端和基于express-js的前端组成的小型项目。 我们已经select了docker-compose作为除了生产用途之外的所有部署工具，到目前为止它已经相当不错了，只有一个例外。
目前，我们使用它来：
- 运行本地开发集群;
- 运行集成testing（有一些调整和额外的依赖）;
- 为负载testing准备环境（更多的调整）;
- 在单独的云计算机上运行登台/演示环境。
为了处理每个环境的所有不同的调整，我们推导了一系列docker-compose.yml -compose文件： docker-compose.yml ， dc.override.yml ， dc.test.yml ， dc.load.yml和dc.demo.yml为了简洁起见，用docker-composereplacedocker-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
而且情况变得更糟。
到目前为止，我们已经有了一些关于改进的想法：
- 使用完整的docker-compose文件而不是部分地保存input – 但是当应用程序结构改变/额外的参数被引入时额外的维护;
- （前者的变化）
extends用于服务，并最小化复制粘贴（但增加了额外的复杂性）; - 将所有这些冗长的命令存储在一个
Makefile（或一个bash脚本）中。 使用方便，但感觉像地毯下的复杂性; - （前者的变体）开发docker-compose插件/自己的工具 – 在处理我们的需求时可能更加明确，但额外的维护和部署的复杂性。
所有这些想法都有其缺陷 – 我想知道什么是适当的解决scheme，以及已经存在的工具。
我认为3听起来是一个很好的解决scheme。 这不是“隐藏复杂性”，它只是自动执行重复任务（input长命令行）。
一个Makefile可以工作，但是你也可能对dobi感兴趣（免责声明：我是这个工具的作者）。 dobi允许您在yaml文件中定义所有项目任务，包括使用不同文件和项目名称运行Compose。 您的项目configuration示例可能看起来像这样
compose=dev: files: [docker-compose.yaml, dc.override.yml] compose=test: files: [docker-compose.yaml, dc.test.yml] compose=load: files: [docker-compose.yaml, dc.load.yml]
然后你可以用dobi dev等来运行一个任务
你甚至可能会发现，一些一次性的任务可以移动到dobiconfiguration，消除了需要额外的撰写覆盖。