加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > Linux > 正文

linux – 将git用于多个服务器配置文件

发布时间:2020-12-13 18:05:27 所属栏目:Linux 来源:网络整理
导读:我们已将大量源代码迁移到git,并对我们当前的解决方案非常满意.我们希望我们的服务器配置文件在同一系统上进行版本化,但是有一些东西不能按照我们希望的方式工作,我希望有人可以在这里分享他的经验. 这个问题类似于Using revision control for server config
我们已将大量源代码迁移到git,并对我们当前的解决方案非常满意.我们希望我们的服务器配置文件在同一系统上进行版本化,但是有一些东西不能按照我们希望的方式工作,我希望有人可以在这里分享他的经验.

这个问题类似于Using revision control for server configuration files?,但我们有一些特殊要求不适用于该问题的建议.

当前设置使用subversion配置文件.相应的存储库看起来像这样

 / # root of repository
 +--www.domain.com/     # configuration for www
 |  --etc/
 |     --apache2/
 +--dev.domain.com/     # configuration for dev
 |  +--etc/
 |  --opt/
 |     --app1/         
 |         --conf/     # configuration for app1 on dev
 --staging.domain.com/ # configuration for staging

使用subversion可以正常工作,因为可以只检查存储库的子目录.此外,您可以使用svn:externals指向几种不同配置设置的一个通用结构.我们只需处理所有版本化目录中的.svn文件.另一方面,Git does not have svn:externals和sparse checkouts总是要求从根目录到实际目录的路径是相同的.

在讨论迁移到git时,我试着写下服务器配置版本控制的主要要求:

>我们只想要一个存储库
>应该可以轻松地将更改推送到中央遥控器
> changesets应该包含真正的作者

有没有一种很好的方法可以将所有配置放在一个存储库中,并且只有一个子路径作为工作副本?目前我正在考虑两种方法,但想先在这里提出这个问题

>如果.git存储库位于固定位置,例如在/ var中的某个地方,我们可以链接到“目标”工作目录中的子路径.主要问题:我不知道从/ etc到另一个目录的“链接”方式,只能导入内容,除了符号链接单个文件
>我在this SO question找到了另一个替代方案,建议在一个存储库中有多个分支.这肯定会增加复杂性,但我可以看到我们这样做.

在一台机器上使用git进行配置文件管理工作正常,但我相信必须有人以我们想要的方式使用它.

谢谢
Kariem

解决方法

我以前用过这样的东西;这就是它的工作原理.

回购设置

>创建一个git仓库,“etc_files”.
>为每种机器类型创建一个分支,例如“server / www”,“server / dev”等.

> git支持分支名称中的斜杠.这有助于我将树枝直接放在脑海中.
>如果您的机器足够少,则可以为每台机器分配一个分支.

>为每个共享基础架构创建一个分支,例如“modules / apache”,“modules / cups”等

>这些分支用于保存所有机器之间相同的文件,例如/etc/resolv.conf.这些将是你现在保存在“svn:externals”repos中的文件.

建立一个新机器

>在新计算机上,克隆git repo并检查该计算机类型的分支.

>我将其设为只读克隆,以防止人们在未经测试的情况下从生产机器提交更改.

>设置一个cron作业,每天自动git拉回购.

改变机器分支

更改单个机器分支中的代码很简单;只需git checkout开发环境中的相应分支,进行更改,然后将它们提交回中央存储库.该分支中的所有计算机将在下次运行cron作业时自动获取更改.

更改模块分支

更改模块分支的代码只是稍微棘手,因为它涉及两个步骤:

> git checkout相应的模块分支
>进行更改并将其提交到集中式服务器.
> git checkout使用该模块分支的每个机器分支,然后将模块分支合并到其中. git会发现你之前已经合并了那个模块分支,并且只注意到自那个最后一个普通父代以来发生的变化.

该方法具有优点和缺点.一个好处是我可以对模块分支进行更改并将其应用到需要它的机器分支,这使得机器分支不会保留旧版本,直到它们准备好.因此,缺点是您必须记住将模块分支合并到可能正在使用它的每个机器分支中.我使用一个遍历提交树的脚本并自动为我做这个合并,但仍然很痛苦.

作为替代方案,较新版本的git支持称为“submodules”的东西:

Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree,always pointed at a particular commit.

这将允许您构建一些类似“svn:externals”树的东西,然后您可以以与现在相同的方式更新.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读