Question

我们为两个独立的计算机集群（所有系统运行 CentOS 8）提供了两个物理上分离的管理服务器，并且两个管理服务器都运行 xcat。一个是测试环境（调用 test），另一个是生产（调用 prod）环境。它们几乎完全相同，但在管理服务器之间必须维护一些与文件系统相关的重要差异。

我们首先在 test 中测试新的系统更改，检查是否没有损坏，然后将其推出到 prod。两台管理服务器上都有一个目录 /install/，其中包含 xcat 配置文件。当 /install/ 中发生更改时，我们会将这些更改复制到另一个名为 /backup_install 的目录（在同一管理服务器上）。

在两个管理服务器（即 test 和 prod）上，/backup_install 由 git 进行版本控制。

所以一个典型的变化可能是这样的：

在 /install 管理服务器上的 test 中更改配置文件
将更改推出到 test 集群
检查 test 集群的完整性
如果没问题，将 test 管理服务器上的更改从 /install 复制到 /backup_install
使用 /backup_install 提交 git 中的更改
rsync /install 中从 test 管理服务器更改为 /install 管理服务器上的 prod
将 prod 管理服务器上的更改从 /install 复制到 /backup_install
在 /backup_install 上使用 git 提交 prod 中的更改

用户经常忘记在其中一台管理服务器上提交 /backup_install 中的更改。

我的一个想法是将 /install 置于版本控制之下，而不是 /backup_install。但是，xcat / confluent 直接使用这些目录，我有点担心将意外的东西（例如 .git）放在我不完全理解的工具使用的目录中。< /p>

问题：我们在两个不同的管理服务器上的非常相似的系统上笨拙地维护两个单独的 git 存储库。有没有更有效、更不容易出错的方法？

Answer 1

您可以将 .git/ 目录存储在其他位置，并指示 git 使用该其他位置作为其数据库：

git --git-dir=/backup_install/.git --work-tree=/install status
git --git-dir=/backup_install/.git --work-tree=/install add file1 file2 ...
git --git-dir=/backup_install/.git --work-tree=/install commit

您还可以使用 GIT_DIR 和 GIT_WORK_TREE 环境变量来指示这些值。

请参阅 --git-dir option 的文档。

您可以使用这些来为您的用例创建适当的别名或脚本。

在生产和测试环境中使用版本控制

1 个答案: