问题描述
想知道在使用不可变服务器/容器时，是否需要像Chef、Puppet、Ansible或Salt这样的配置管理工具。这些配置管理工具的设计目的是建立一个配置并进行维护。用户想知道在部署不可变服务器时，是否只需要将配置管理工具用于初始配置。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在不可变基础设施中，配置管理工具仍然有一些作用：
1. 构建不可变镜像：虽然在已知的起始状态下使用传统的脚本构建镜像可能更容易（例如Dockerfile），但随着时间的推移，这种方法可能变得非常复杂，特别是当你需要为不同的软件版本、不同的环境等创建多个不同的镜像时。Packer和其他镜像构建工具与Chef、Ansible、Puppet、Salt等工具可以很好地集成。
2. 不可变性是一个连续的过程：即使在非常不可变的部署中，仍然可能有一些需要在运行时进行管理的配置文件。在这种情况下，你可以使用CAPS工具，或者根据整体基础设施的情况选择更轻量级的选项，如Consul Templates或etcd。例如，如果你的应用服务器是不可变的，但数据库服务器是使用Chef进行传统管理的，那么在不可变部分中使用Chef来进行一些管理任务可能是有意义的。
3. 零日管理：不可变性很好，但当下一个OpenSSL 0day漏洞出现时，你该怎么办？如果你的构建流水线能够创建即时的热修复镜像并部署它们，那就太好了。但很多人可能没有那种快速反应的能力。
4. 无法实现不可变性的事物：整个基础设施很少是100%不可变的。例如，数据库服务器和开发人员工作站（是的，它们也是你的基础设施的一部分）在某种程度上很难甚至不可能实现不可变性。
方案2
使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。
示例：
以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：
#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b
在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。