3

在工作中，我们开发了 Nagios 的脚本和扩展。我们为大约 30 位客户（每个客户都有一个 Nagios 服务器）提供监督服务。一些客户有特定的配置（新模块来检查一些非常具体的东西，尚未包含在主线中......或不包含）。

目前，Nagios 服务器的版本差异很大（有些服务器已有 2 年历史，没有计划更新）。

我想知道是否切换到 git 来自动化部署，并使用持续集成来确保我们不会破坏客户端 Nagios 上的某些内容。

这是我的想法：

                        1 single server
                                    \___________________________________________________
                                     |                                                 |
 dev1 -----\               /---------|---> remote1 (bare) ----> remote1 (nagios etc/)  |
            \             /          |_________________________________________________|
             \           /
              \         /
 dev2 ---- main server (bare) -----------> remote2 (bare) ----> remote2 (nagios etc/)

 ...

开发人员和主服务器位于办公室，而裸遥控器 + 遥控器位于客户处。

我已经设法使用 post receive 钩子自动推送到遥控器。

从 remote1（裸机）到 remote1，我可以使用另一个可以 cd 到 remote1 的钩子，然后 git pull。然后我可以通过一个简单的 Nagios 命令测试配置，并在出现问题时恢复到之前的提交。

关于文件在遥控器之间是不同的，我可以暂时将它们 gitignore 或在主服务器上使用不同的分支（这样我可以将 customer1 分支推送到 remote1）。

你怎么看待这件事 ？我愿意接受任何建议或建议:-)

裸 + 非裸存储库似乎有点奇怪，如果某些提交没有按预期工作，我也不确定回滚。

4

1 回答 1

0

尽管可以使用 git 作为部署工具，但这并不是它真正的预期功能。也许您应该考虑cfengine或Capistrano。

于 2013-05-06T21:42:23.613 回答