令我困惑的是，诸如 Puppet 之类的配置管理工具非常棒，并且可以直接从头开始设置服务器，但每个文档都忽略了我想要在新配置的服务器上使用现有数据（例如 PostgreSQL 数据库）的情况。
最完美的例子就是托管服务提供商之间的迁移。当然，Puppet 会使用与之前几乎相同的配置来设置新服务器，但设置代码（Puppet 清单）假设这个新数据库服务器处于初始状态，而其中有一些宝贵的业务数据需要恢复。
首次设置基础设施无疑是一项值得自动化的任务，但意外总是会发生，当需要恢复服务器时，我只能进行半手动设置：
- Puppet：设置服务器前数据目录已初始化并且服务已启动
- 我在 shell：将备份中的数据恢复到正确的位置
- Puppet：继续其余操作，即启动服务
这种情况并不罕见。第一次设置服务器时没有现有数据是一次性事件，但恢复它们可能会发生多次，我希望这种情况至少会发生一次（这就是我们备份宝贵数据的原因）。
编写 Puppet 清单以解决节点可以第二次设置且需要恢复数据的情况的常见做法是什么？
您如何处理 Puppet 管理的服务器迁移？
谷歌搜索这个是没用的。你看到的大多是描述如何恢复 Puppet DB/服务器的页面，但那部分基础设施大多不是你的企业盈利的来源，对吧？
我知道 Puppet 服务器有一个文件服务器，但是与使用 Puppet 清单管理配置相比，保持备份数据在那里可用并设置适当的访问控制感觉非常繁琐。
我假设企业使用 Bacula 或 Amanda 等完整网络备份解决方案，或者可能使用基于 Borg、Restic、Burp、Duplicati 或普通 rsync 的自定义备份解决方案。您是否将这些集成到您的 Puppet 清单中？如何集成？
答案1
如果您这样做是为了实现完全自动化的灾难恢复，那么这可能是值得的，但除此之外，您必须考虑是否真的可以节省任何东西，因为您需要投入大量时间来可靠地（！）自动化本来应该是非常罕见的一次性操作（如果您必须一直这样做，那么您的环境就出了问题）。拥有 Puppet 并不意味着您必须不惜一切代价实现一切自动化……
也就是说：如果您需要它，这并不难：只需有一个支持从 Puppet 执行此操作的备份解决方案 - 这种支持可以只是运行一个脚本，执行您在 Puppet 运行中手动执行的操作（确保只运行一次......）。
答案2
使用 Puppet、Ansible、Chef 或 Salt 等配置管理 (CM) 工具需要从根本上改变您对配置的看法。
如果您将配置视为一次性事件，那么您将永远不会看到（或意识到）使用 CM 的任何好处。
CM 的主要功能是能够将您所需的配置表达为代码。一旦您拥有了这种能力，您的服务器配置将是：
可测试。您可以编写单元测试以确保不会引入任何错误，而无需重新启动服务或配置整个测试/暂存环境。这节省了大量的时间和金钱。
可重复。您可以使用相同的基本配置创建一台、两台、十台或一百台服务器，无需任何开销。您只需编写一次代码，然后多次应用。如果您有一组标准的配置选项（例如，SSH 守护程序设置、强化步骤），CM 可以自动完成这些操作。
可版本化。推出更改就像进行 Git 提交一样简单。推出后退更改非常简单
git revert。您有一个可验证、可审计的数据源（您的 Git 历史记录）。您可以分支您的 CM 代码库，进行更改，获得同行评审并将这些更改合并到您的master分支中。