问题描述
想了解是否有配置管理工具能够轻松实现回滚操作。目前使用 Ansible、Chef 和 Puppet 等工具时，需要编写回滚任务、配方等来恢复到先前的状态。用户在个人兴趣和对 NixOS 的经验中看到，使用纯粹的不变基础设施可以轻松进行回滚。但是在企业环境中，不太可能使用 NixOS。如何能够在支持 Windows 和企业级 Linux 发行版的情况下更好地实现回滚操作呢？
解决方案
请注意以下操作可能存在版本差异或变动，请在操作前做好备份。
不变基础设施与回滚
不变基础设施是一种方法，通过在更新时不直接更改现有服务器，而是启动新的服务器并应用更改，从而实现回滚的目的。理论上，标准的配置管理工具可以通过检出先前的提交并重新运行配置来进行回滚。然而，在实际操作中，这通常并不适用，因为可能已经引入了新的配置规则，或者编写了不易反转的规则（例如，执行了某些破坏性的数据操作）。如果在编写 Playbooks 时非常小心，可以避免这些问题，但更稳妥的解决方案是采用不变基础设施的方法。
回滚与回退的区别
实际上，“回滚”和“回退到上一个版本”之间存在很大差异。理论上，应该有一种方法来实现回滚和前进回滚（rollforward）。但是，大多数工具实际上并不具备实现这些操作的智能性。将目标环境还原为 N-1 版本只是手动在服务器上进行更改的一步。有位 Ansible 的讲师在课程中甚至说 Ansible 无法实现回滚。具体来说，回滚是指在复制新版本之前，保留目标环境文件状态的快照副本，以便可以随时恢复原始状态。与此同时，确保暂时保存了文件的完全副本。而“回退到上一个版本”是指从源代码库中提取 n-1 版本的文件，并将其部署到目标环境中。回滚是立即执行的，因为它是一个完全的副本。而 n-1 版本的恢复可以手动回滚先前的文件。理论上，Ansible Playbooks 可以实现这一点。
实施方法
在企业环境中，为了更好地实现回滚和回退操作，可以采取以下方法之一：
使用配置管理工具
- 首先，确保你的配置管理工具（如 Ansible、Chef、Puppet）的 Playbooks 或配方文件是良好组织的，易于理解和维护。
- 在版本控制系统（如 Git）中维护你的配置文件和 Playbooks。
- 对于每次更改，都创建一个新的版本，并使用配置管理工具来部署该版本。
- 在需要回滚时，从版本控制系统中检出先前的版本，并使用配置管理工具进行部署。
不变基础设施方法
- 采用不变基础设施方法，即在每次更改时，不直接更改现有服务器，而是启动新的服务器并部署更改。
- 在新服务器上进行测试和验证，确保新版本的稳定性和正确性。
- 如果发现问题，可以轻松地切换回旧的服务器，从而实现回滚操作。
总结
虽然标准的配置管理工具理论上可以实现回滚，但在实际操作中，不变基础设施方法可能更加稳妥。对于企业环境，你可以选择配置管理工具的方法，确保良好的组织和版本控制，或者采用不变基础设施方法，通过启动新的服务器来实现更容易的回滚操作。
参考：
– Immutable Infrastructure: The Future of DevOps
– Ansible – Rollback a playbook
请根据具体情况选择合适的方法，并确保在实际操作中进行适当的测试和验证。
请注意，以上方法可能存在工具特性变动或版本差异，建议在操作前详细了解你所使用的工具的最新文档和指南。