共计 3903 个字符，预计需要花费 10 分钟才能阅读完成。
在软件交付畛域，GitOps 是近期的热门趋势，它因循并扩大了 DevOps、基础架构即代码和 CI/CD 等趋势。咱们此前公布了许多对于 GitOps 的入门文章，您能够在【Rancherlabs】公众号后盾回复【Git 文章】获取 GitOps 文章合集。
GitOps 的劣势能够简略地归纳如下：
- 自在地审计更改
- 继续集成和交付
- 更好地管制更改治理
然而，现实情况却是构建 GitOps 流水线并非易事，它波及到许多大大小小的决定，而这些决定会给施行工作带来许多麻烦。咱们将这些决定称为“GitOps 架构”，它可能会导致施行过程中面临许多挑战。
好的方面是只有有肯定的布局和教训，就能够大大减少过渡到 GitOps 交付模式的苦楚。
在本文中，我将通过一家公司的故事来解释其中的一些挑战。这家公司从一个零散的小守业公司采纳 GitOps，成长为一家标准的跨国企业。尽管这种减速成长的状况很少见，但它的确反映了大型组织中的许多团队从概念验证，到最小可行性产品（minimum viable product），再到成熟零碎的教训。
简略的开始
如果你刚刚开始，最简略的做法是创立一个繁多的 Git repo，将所有须要的代码都放在外面。其中可能包含：
- 利用程序代码
- Dockerfile，用于构建应用程序镜像
- 一些 CI/CD 流水线代码（例如 GitLab CI/CD 或 GitHub
Actions） - Terraform，以配置运行应用程序所需资源
此外，所有的更改都是间接对 master 进行改变，因而更改能够间接失效。
这一办法的次要劣势在于你有繁多的参考点，以及所有代码都会严密集成在一起。如果您的所有开发人员都受到齐全信赖，并且速度就是所有，那么这一办法会继续失效。
可怜的是，随着你的业务量一直增长，这种办法的弊病很快就会显现出来。
首先，随着越来越多的代码被增加到代码库中，代码库规模的收缩会使得工程师们陷入困惑，因为他们会遇到更多必须解决的更改之间的抵触。如果团队成员大幅增长，那么随之而来的重新分配工作或合并会导致进一步的凌乱。
其次，如果您须要离开管制流水线运行，则会遇到困难。有时，您只想疾速测试对代码的更改，而不是进行部署以实现残缺的端到端交付。这种办法在整体性方面产生了越来越多须要解决的问题，随着这些更改的进行可能会影响其他人的工作。
第三，随着您的成长，您可能会心愿工程师和团队之间的责任边界更加细化。这能够通过一个繁多的 repo 来实现，并且一个 repo 通常是一个更清晰和更洁净的边界。
拆散 Repository
随着业务的增长，流水线会越来越拥挤，merge 开始变得苦楚。此外，您的团队也须要专业化，将不同的责任畛域划分给不同的成员。
所以你须要将 Repo 分离出来。这时，你首先要面对大量的决定，譬如 repo 应该拆散到什么水平？是否须要为利用程序代码建设一个独自的 repo？看起来是不是很正当？而后把 Docker 构建的货色也一起放进去？那这样的拆散其实没有什么意义。
那所有团队的 Terraform 代码呢？应该放在一个新的 repo 里吗？这听起来很正当，然而：新创建的地方“平台”团队想要管制对 AWS 中外围 IAM（身份和拜访治理）规定定义的拜访，而团队 RDS 配置代码也在其中，开发团队须要定期对其进行调整。
所以你决定将 Terraform 拆散成两个 repo：一个是“平台”repo，一个是“特定应用程序”repo。这就带来了另一个挑战，因为你当初还须要拆散 Terraform 的状态文件。这并不是一个无奈解决的问题，但这也并不是您所习惯的疾速性能交付，所以产品经理将不得不解释为什么性能申请所需的工夫比之前更长。
可怜的是，这些 GitOps 决策还没有既定的最佳实际或模式。
拆散的问题还不止于此。以前，流水线内构建的组件之间的协调是微不足道的（因为所有须要的组件都是共处的），而当初你必须协调 repo 之间的信息流。例如：当构建一个新的 Docker 镜像时，这可能须要触发集中式平台 repo 中的部署，同时将新的镜像名称作为触发的一部分传递过去。
同样，这些也不是无奈解决的问题，但在构建 GitOps 流水线的晚期，这些挑战更容易实现。起初，当步骤、政策和流程更加成熟时，再做出扭转就须要付出更多的工夫代价。
分布式 vs 集中式
你的业务正在增长，你正在构建越来越多的应用程序和服务。越来越显著的是，在如何构建和部署应用程序方面，你须要某种构造上的一致性。地方平台团队须要尝试执行这些规范。然而你可能会受到开发团队的拥护，他们认为与在 DevOps 和 GitOps 呈现之前，在集中式 IT 中他们被赋予了更多的自治和控制权。
如果上述情况您感觉似曾相识，那可能是因为 GitOps 和利用架构畛域的单体与微服务争执之间有些相似。就像你在这些争执中看到的那样，随着零碎的成熟，规模和范畴的扩充，分布式和集中式 IT 之间的缓和关系会越来越频繁地呈现。
从某种层面上来说，你的 GitOps 流程就像其余分布式系统一样，如果你设计得不好，其中一个局部呈现问题可能会产生难以预料的问题。
环 境
在你决定拆散 repo 的同时，你意识到你须要一种统一的形式来治理不同的部署环境。而间接上线曾经行不通了，因为此时须要 QA 团队，在上线之前测试更改。
当初你须要为你的利用镜像在测试和 QA 环境中指定不同的 Docker 标签，你可能还心愿在不同的环境中启用不同大小的实例大小或正本性能。你如何在源码中治理这些不同环境的配置？一个比拟间接的办法是为每个环境建设一个独自的 Git 仓库（如：super-app-dev，super-app-qa，super-app-live）。
拆散 repo 有“若明若暗”的益处，就像咱们在下面划分 Terraform 代码时看到的那样。然而，很少有人最终会喜爱这种解决方案，因为大多数团队不具备 Git 常识和相干业余程度，进而在不同的 repo 之间移植更改。更为简单的是，repo 之间必然会存在很多反复的代码，而且随着工夫的推移，也可能会呈现很多漂移（drift）。
如果你想把事件放弃在一个繁多的 repo 中，你至多有三种抉择：
- 每个环境都有一个目录
- 每个环境都有一个分支
- 每个环境有一个标签
同步步骤抉择
如果你重大依赖 YAML 生成工具或模板，您能够思考另一种形式。例如，Kustomize 强烈激励基于目录的环境拆散。如果您应用的是原始 YAML，那么分支或标记的办法会更适宜您。
运行时环境颗粒度
然而，在您的运行时环境中，能够抉择您想要什么级别的拆散。在集群层面，如果您应用的是 Kubernetes，你能够在以下几种状况下抉择：
- 一个集群治理所有
- 每个环境一个集群
- 每个团队一个集群
在极其状况下，你能够把所有的环境放到一个集群中。不过通常状况下，在大多数组织中至多有一个独自的集群用于生产。
一旦你想好了你的集群策略，在命名空间层面，你依然能够抉择：
- 每个环境都有一个命名空间
- 每个应用程序 / 服务领有一个命名空间
- 每个工程师领有一个命名空间
- 每个构建都有一个命名空间
平台团队通常从“dev”、“test”、“prod”的命名空间设置开始，而后才意识到他们想要更精密地分化团队的工作。
你也能够混合和匹配这些选项——例如，为每个工程师提供 ”desk testing “ 命名空间，以及每个团队的命名空间。
总 结
咱们在这里只是对成熟的 GitOps 流程所需的决策畛域做了一些简略的介绍。如果您的企业真的成长为那家跨国企业，你也能够思考 RBAC/IAM 等要求。
通常状况下，推出 GitOps 会让人感觉只是一种投资，可能最终没有太多令人满意的产出。然而在 GitOps 之前，团队经常会经验凌乱和提早，因为没有人可能确定任何货色应该是什么状态。这些都会导致二次老本，因为审计人员会进行抽查，而因意外和未记录的更改而导致的中断则占据了员工大量的注意力，这是一个很高的老本。
然而，随着你的 GitOps 流程的愈发成熟，益处倍增，该流程会解决许多之前存在的问题。但更多的时候，你面临的压力是要更快地展现出 GitOps 流程的劣势。
目前 GitOps 最大的挑战是，没有既定的模式或是最佳实际来领导你的抉择。GitOps 参谋，通常也只是疏导团队找到最适宜他们的解决方案，并依据教训将团队往某些方向疏导。
但我察看到的状况是，晚期因为看起来“太简单”而被放弃的抉择，往往起初都会为此悔恨。这并不意味着你应该间接跳到为每个构建创立一个命名空间，每个团队领有一个 Kubernetes 集群的水平，起因有二：
每当你给 GitOps 架构减少复杂性时，你最终都会减少交付一个可行的 GitOps 解决方案的老本和工夫
你可能真的永远都不须要这种设置
在咱们承受这个畛域的可行规范之前，正确的 GitOps 架构永远是一门艺术，而不是迷信。
原文链接：
https://blog.container-soluti…
对于 Rancher Labs
Rancher Labs 由 CloudStack 之父梁胜创立。旗舰产品 Rancher 是一个开源的企业级 Kubernetes 治理平台，实现了 Kubernetes 集群在混合云 + 本地数据中心的集中部署与治理。Rancher 一贯因操作体验的直观、极简备受用户青眼，被 Forrester 评为 2018 年寰球容器治理平台领导厂商，被 Gartner 评为 2017 年寰球最酷的云基础设施供应商。
目前 Rancher 在寰球领有超过三亿的外围镜像下载量，并领有包含中国人寿、华为、中国安全、兴业银行、民生银行、安全证券、海航科技、厦门航空、上汽团体、海尔、米其林、丰田、本田、中船重工、中联重科、迪斯尼、IBM、Cisco、Nvidia、辉瑞制药、西门子、CCTV、中国联通等寰球驰名企业在内的共 40000 家企业客户。
