☰

Git Repo 用于维护多个服务器中的应用程序配置

tag-icon • tag-icon git automation configuration-management
Git Repo 用于维护多个服务器中的应用程序配置

我需要在 GIT 存储库中对特定平台的配置进行版本控制，这些配置分布在多个服务器上。考虑到这些服务器中的每一个都有完全不同的配置，而应用程序是相同的。最好的方法是什么？

  1. 为每个服务器创建一个分支

    • 存储库.git：conf --> [分支服务器 1]
    • 存储库.git：conf --> [分支服务器 2]
    • 存储库.git：conf --> [分支服务器 N]
    • 笔记：在我看来，这种方法很难维护，因为每次服务器配置发生变化时，我都需要创建子分支，这会造成混乱。

  2. 为每个服务器创建一个具有不同目录的存储库

    • 存储库.git:conf/服务器 1
    • 存储库.git:conf/服务器 2
    • 存储库.git：conf/服务器 N
    • 笔记：这很容易维护

  3. 为每个服务器创建一个 repo

    • 存储库_1.git：conf
    • 存储库_2.git：conf
    • 存储库_N.git:conf
    • 笔记：这种方法要求我为每个新服务器创建一个分支。

还有其他方法，在这种情况下最佳做法是什么？我应该使用我觉得最舒服的那个吗？

谢谢，

葡萄牙古尔登

答案1

Bcfg2 是一个出色的配置管理系统，可以与任何版本控制系统一起使用。

我为我管理的所有系统使用一个存储库。Bcfg2 通过将主机名或组名优先附加到文件名来处理不同机器和组的配置文件差异。Bcfg2 为您的系统提供每个 ConfigFile 条目最具体的文件。

因此，在您的配置描述中您将拥有：

<ConfigFile name="/etc/network/interfaces" />

你的配置文件将是：

# ls Cfg/etc/network/interfaces
interfaces
interfaces.H_server1
interfaces.H_server2

我认为 Bcfg2 相对于 Puppet 和 Cfengine 的主要优势在于，Bcfg2 不是运行脚本来配置系统执行操作，而是确定系统如何不符合您的规范并进行必要的更改。

答案2

实际上，最简单的方法是通过配置管理工具运行所有内容。我更喜欢 Chef，但 Puppet 和 cfengine 也解决了同样的问题。Chef 至少在构建时就考虑到或期望配置将存储在版本控制中。

但是，在不重新构建基础架构的情况下，您可能应该编写脚本，将各个配置文件复制到一个公共目录，确保如果文件的名称不是不言而喻的，则将它们包装在一个命名有意义的文件夹中，然后将其包装在服务器名称中。

所以：

--networkDrive
----ServerName1
------WebServerConfig
------AppServerConfig
----ServerName
------AnotherAppConfig
----ServerName

...等等...

从那里开始，很容易启动和提交（这也很容易编写脚本）。

相关内容