DevOps最后一刻：完全自动化容器的启动和配置

Question

在我们的小型开发组织的范围内，我们正在尝试使多个服务的部署/更新尽可能自动化。这些服务主要位于Docker容器中（还有一些Vagrant框用于无法直接在Linux上运行的事物，例如macOS构建节点）。

当前状态

我们依靠Docker文件和Compose文件（部署有docker stack）来实现自动化的很大一部分：通过构建Dockerfile以可复制的方式安装各个VM，然后一起启动直接依赖的服务通过撰写文件。

然而，越来越明显的是，每个环境配置和基础架构部署的最终步骤还没有得到同样好的形式化。为了说明这一点，让我们想象一下我们的目标是在给定的环境中部署两个堆栈（Jenkins和Artifactory）。

当前，我们将为此目标部署创建一个私有存储库A，以完成最后的步骤。该存储库将包含配置（包括机密信息）和一个单独的bash脚本，以在为每个堆栈提供相应配置的同时对其进行部署。如果堆栈已在运行，则通用的主脚本仅负责停止堆栈，然后按顺序执行各个脚本。 然后，要实际部署（或更新），可以将SSH SSH到目标环境中，克隆A存储库，然后运行主脚本。

限制

与优雅的容器化方法相比，这种方法感觉不足。我们的一些悲伤：

• 这是非常临时的，我们必须维护几个与容器接口耦合的专用脚本（“容器如何期望给出配置？”“参数是什么？”）以及配置数据结构（“配置文件是要安装在容器上的文件吗？在部署堆栈之前还是在堆栈的一个容器内要获取的.env文件？”）
• 违反DRY原则：如果我们要将堆栈的子集部署到另一个环境或具有不同配置的同一堆栈，则必须创建一个单独的存储库，并且它将重叠。
• 没有一种干净的方法可以首先在测试环境中进行部署（以测试更新是否会破坏功能，测试是自动还是手动进行），不建议像上面那样维护单独的A-test存储库。
li>
• 秘密秘密存储在私有A存储库中。
• 实施维护功能将意味着需要更多特别的bash脚本：例如备份部署中的所有服务或多或少意味着每个堆栈需要一个额外的脚本。
• 不容易监控
• 实际部署仍然需要几个手动步骤（连接到正确的环境，克隆存储库，启动脚本然后检查其返回状态）

---

答案可以采取几种形式，包括学习资源，关于如何从开发人员的角度解决这一最后步骤的一般建议，或者通常针对此问题推荐的推荐工具和软件。