str*_*rix 4 linux deployment configuration version-control
我正在寻找最好的方法（就我的目的和情况而言）来版本系统配置文件并管理两台机器（实时和备份，两者都应被视为“生产”）之间的部署（所有权和模式）。我希望能够使用该系统自动（但有选择地）复制和管理备份机器（EC2 实例）上的相关和指定配置。
目前，这些机器主要是 web 和 SMTP 服务器（我们不存储用户邮箱），但我们的项目正在增长，谁知道未来的需求可能是什么。例如，我们有可能在未来某个时候实施广播和基于网络的聊天。
我更喜欢以传统方式管理服务器（即，根据需要进入并更改实时服务器），然后将这些更改（一旦确定）存储在管理系统中。（好吧，老实说，我应该有机地说：我不想失去根据需要和情况做事的灵活性。）我发现这种方法，而不是部署在其他地方经过调整和测试的配置，更可预测，并且有可能减少意外（除了在实时系统上搞砸配置的可能性之外，就是这样！）
我意识到，从哲学上讲，这是从后到前的，如果我有资源（测试基础设施，更重要的是人力），我可能会反过来做。事实上，我必须用我所拥有的来凑合。我很喜欢结构，但是过多的基础设施会失去它自己的生命，并且在某些时候它的价值会丢失。
我做了一些功课并审查了几个选项，但它们似乎都没有真正按照我的意愿行事，因此我目前很想推出自己的解决方案。这个问题的目的是看看我没有想到什么，并在我去吠错树之前进行理智检查。
像木偶，声明metaconfiguration系统特别，可能是不错的选择，许多服务器都参与了他们之间几乎没有差异，特别是当它的时间提前明确应该看什么样的配置等。我认为在没有临时基础设施的情况下使用这样的工具是不明智的。
它也有点重量级和过于复杂。我是唯一的管理员，我在业余时间做这件事，如果发生什么事，我留下的任何东西都需要对跟随我的幸运的男人/女孩保持合理的理智。
etckeeper 可能会，但就我所见，它并不适合管理除 /etc 之外的任何内容。即，它不适合存储传统上位于 /usr/local/bin 中的自定义脚本。此外，etckeeper 大概管理所有/etc，我想我更喜欢只对特定内容进行版本控制（例如 postfix、apache、fail2ban、ssh 和可能的 munin）。
一个简单的 git 或 svn repo 肯定不会做，因为 git 跟踪权限，它不跟踪所有权，而 svn 也不跟踪。
svn.svn在每个跟踪目录中保留一个子目录，而.git仅存在于工作副本的根目录中。这两种情况各有利弊。.svn在某些地方（例如 /etc/apache2/sites-enabled），某个位置的目录的存在可能没问题，但会在其他地方扰乱脑残脚本/工具。（我确定我之前读过一些东西：cron 是否可以与.svn/etc/cron.d 中的目录一起使用，但 depmod 与 /lib/modules 不同？）
另一方面，使用.gitin /，git 将所有内容都视为跟踪的候选对象，甚至（可能）其他 git 存储库！
这是我建议做的：一个存储在主机上的 subversion 存储库（比如 /usr/local/sc-repo）和一个用Pysvn编写的管理脚本，它实现了以下内容：
添加（但默认情况下，不是递归的），它将文件的模式和所有权存储为自定义属性。另外，我喜欢$Id$我的配置文件中的标签，所以这将确保svn:keywords正确设置。
犯罪
更新，在写入文件后应用所有权和模式
恢复，同上
perms，如 diff，但对于所有权和模式，如果需要，可以使用修复标志进行更正。
备份机将通过 ssh 访问 repo，并在每晚执行更新操作。（它也会做其他事情，比如从主机的备份存储库 (S3) 中恢复站点 SQL 和应用程序文件系统，我可能需要编写一些hackery 来查找主机上添加的新包并将它们添加到备用机器——但所有这些都不在本问题的范围内。）
为什么要颠覆？
我知道，像我和很多更熟悉SVN比我用git。是的，我可能是一只恐龙。
Pysvn 很简单，我以前用过。
svn 支持版本化的自定义属性，而 git 似乎不支持
这不是分布式开发：分布式存储库使事情变得复杂而没有好处。远程仓库可用性无关紧要，因为来自远程机器的提交很少见。
我会很感激你的反馈。我已经尽可能多地考虑了这一点，但我肯定会错过一些东西。
| 归档时间： |
|
| 查看次数： |
1715 次 |
| 最近记录： |