Linux 系统配置管理：版本控制和部署

Question

我正在寻找最佳方法（适合我的目的和情况）来版本化系统配置文件并管理两台机器（实时和备份，两者都应视为“生产”）之间的部署（所有权和模式）。我希望能够使用此系统自动（但有选择地）复制和管理备份机器（EC2 实例）上的相关和指定配置。

目前，这些机器主要是 Web 和 SMTP 服务器（我们不存储用户邮箱），但我们的项目正在发展，谁知道未来的需求是什么。例如，我们有可能在未来某个时候实现广播和基于 Web 的聊天。

我更喜欢以传统方式管理服务器（即根据需要进入实时服务器并进行更改），然后将这些更改（一旦确定）存储在管理系统中。（好吧，如果我诚实的话，我应该说有机地：我不想失去根据需要和情况要求做事的灵活性。）我发现这种方法，而不是部署在其他地方调整和测试的配置，更可预测并且可能减少意外（除了在实时系统上搞砸配置的可能性之外！）

我意识到，从哲学角度来说，这是本末倒置的，如果我有资源（测试基础设施，更重要的是人力），我可能会反过来做。事实上，我必须利用我所拥有的东西。我很喜欢结构，但过多的基础设施会自行发展，到某个时候，它的价值就会丧失。

我做了一些功课，审查了几个选项，但似乎没有一个能真正达到我想要的效果，所以我现在很想自己想办法。这个问题的目的是看看我还没有想到什么，并在我做错事之前进行合理性检查。

选项

1. 声明式元配置系统，例如 Puppet，除其他外，在涉及多台服务器且服务器之间几乎没有区别的情况下，可能是不错的选择，尤其是当提前明确配置应该是什么样子时。我认为，在没有准备基础设施的情况下使用这样的工具是不明智的。

   它也有点繁重和过于复杂。我是唯一一名管理员，我利用业余时间做这件事，如果我出了什么事，我留下的任何东西都必须合理地保护在我之后接手的幸运儿。

2. etckeeper 可能可以，但据我所知，它实际上并不适合管理 /etc 以外的任何东西。也就是说，它不适合存储传统上位于 /usr/local/bin 中的自定义脚本。此外，etckeeper 大概可以管理全部/etc，我认为我更喜欢只对特定的东西进行版本控制（例如postfix，apache，fail2ban，ssh以及可能的munin）。

3. 简单的 git 或 svn repo 肯定不行，因为虽然 git 跟踪权限，但它不跟踪所有权，而 svn 也不跟踪。

   .svnsvn在每个跟踪目录中保留一个子目录，而.gitsvn 仅存在于工作副本的根目录中。这两种情况都有好处和坏处。.svn在某些地方（例如 /etc/apache2/sites-enabled），某个位置存在目录可能没问题，但其他地方会破坏无用的脚本/工具。（我确信我之前读过一些东西：是不是 cron 可以接受.svn/etc/cron.d 中的目录，但 depmod 不能接受 /lib/modules？）

   另一方面，对于.git/ 中的，git 认为一切一个可供跟踪的候选者，甚至（大概）是其他 git 仓库！

定制解决方案

我建议这样做：在主机上存储一个 subversion repo（例如 /usr/local/sc-repo）和一个用蟠尾藻实现以下内容：

• 添加（但默认情况下不递归），将文件的模式和所有权存储为自定义属性。此外，我喜欢$Id$配置文件中的标签，因此这将确保svn:keywords正确设置。

• 犯罪

• 更新，在文件写入后应用所有权和模式

• 恢复原状，同上

• 权限，像 diff，但针对所有权和模式，带有修复标志，以便在需要时进行更正。

备份机将通过 ssh 访问存储库并每晚执行更新操作。（它还将执行其他操作，例如从主机的备份存储库 (S3) 恢复站点 SQL 和应用程序文件系统，并且我可能必须编写一些 hack 来查找主机上添加的新软件包并将它们添加到备份机上 — 但所有这些都超出了本问题的范围。）

为何颠覆？

• 我知道，喜欢并且正在很多我对 svn 的熟悉程度超过了对 git 的熟悉程度。是的，我可能已经过时了。

• Pysvn 很方便，我以前用过。

• svn 支持版本控制的自定义属性，而 git 似乎不支持

• 这不是分布式开发：分布式存储库使事情变得复杂而没有好处。远程存储库的可用性无关紧要，因为来自远程计算机的提交很少见。

我将非常感激您的反馈。我已经尽可能仔细地考虑了这个问题，但我肯定遗漏了一些东西。

Answer 1

不要重新发明轮子。现有的工具可以满足您的需要。您可能需要查看BCGF2，尤其是你似乎特别关注配置文件。也考虑一下服务。中央存储库相对于生产服务器需要位于哪里？

也许一个折衷方案是仔细修改蓝图工具。我使用 Blueprint 对现有系统进行逆向工程。Blueprint 运行的输出可以创建 shell 脚本、Puppet 模块或 Chef Cookbook... 在生产服务器上拥有经过验证的配置后，您可以使用此工具捕获系统状态，然后标记和版本化结果。阅读通过例子如果这似乎适合您的使用情况，请报告。

Answer 2

声明式元配置系统（例如 Puppet）可能是涉及许多服务器且彼此之间几乎没有区别的良好选择，尤其是当提前明确配置应该是什么样子时。我认为，在没有准备基础设施的情况下使用这样的工具是不明智的。

即使是单机设置，我也使用 Puppet（当然，Chef、Ansible 和 Salt 等也存在）。我还没有遇到过有人提前清楚机器配置应该是什么样子的情况（可以说，很多人事后都不清楚配置应该是什么样子，但那是完全不同的问题）

至于“阶段性基础设施”，这是流浪汉和虚拟盒（或其他支持虚拟化技术） - 在您的开发机器上运行它，无需花费。如果没有它，我不会进行任何 Puppet 清单开发。还可以使用特拉维斯·西

它也有点繁重和过于复杂。我是唯一一名管理员，我利用业余时间做这件事，如果我出了什么事，我留下的任何东西都必须合理地保护在我之后接手的幸运儿。

这样说然后描述你如何计划一个自主开发的解决方案而不是现有的具有大量文档、示例、现有“库”和积极开发的解决方案，这似乎不一致。