问题描述
听说过一种部署模式，听起来像是”构建一次，多次部署”。如果用户通过ansible模板、chef或其他配置管理工具来管理配置，他们没有任何预生成的配置。他们在每次部署时都会生成配置。用户想知道为什么没有工具遵循这种（逻辑上的）配置模式？这种模式是否值得使用？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
大多数工具之所以不遵循”构建一次，多次部署”的模式，是因为从未知状态到期望状态的过程并不是一个构建步骤。在构建过程中，你从一个已知状态开始，该状态可能是空白或空的，并创建出一个东西。
但你可能忽略了一点，使用代码作为配置，你只需构建一次期望状态，然后多次部署生成的结果。
以Chef Cookbook为例，你可以按照以下步骤进行操作：
1. 编写代码
2. 使用ChefSpec进行单元测试
3. 使用Kitchen进行功能测试
4. 如果所有测试通过，将其作为一个构件发布到chef-server
5. 逐个环境推广
在这种情况下，所有基于承诺理论（如ansible、chef、puppet、salt等）的工具都符合”构建一次，多次部署”的模式。
方案2
请注意以下操作注意版本差异及修改前做好备份。
另一种方法是使用配置即代码的方式，将配置作为代码进行构建，并将生成的构件多次部署。这种方式可以确保在每次部署时都使用相同的配置，从而实现”构建一次，多次部署”的模式。
使用配置即代码的工具，如Terraform、Ansible、Chef等，可以将配置定义为代码，并使用版本控制系统进行管理。这样一来，你只需在构建阶段定义一次配置，然后在每次部署时使用相同的配置进行部署。
以下是使用Terraform的示例步骤：
1. 创建一个Terraform配置文件，定义你的基础设施和资源。
2. 使用Terraform命令行工具运行terraform init命令，初始化Terraform环境。
3. 运行terraform apply命令，根据配置文件创建基础设施和资源。
4. 在每次部署时，只需运行terraform apply命令，Terraform将根据配置文件的定义，自动创建或更新基础设施和资源。
使用配置即代码的方式，你可以确保每次部署都使用相同的配置，从而实现”构建一次，多次部署”的模式。
请注意，不同的工具可能有不同的实现方式，具体操作步骤可能会有所不同。请参考相应工具的文档以获取更详细的信息。