转载

基于GitOps的企业级CI/CD

实现企业级的持续交付（CD）是一个巨大的挑战。每一个公司都在对他们的软件交付方式做创新，我们需要允许各个团队学习构建并优化他们自己的交付流水线。在云原生的世界里正在发生，许多的最佳实践正在萌芽。尽管如此，给予团队灵活性做创新试验时，也需要兼顾公司的安全和合规方面的要求。在这篇文章里面，我将讲述我们如何为一个大型企业客户成功使用GitOps架构模型来获得灵活性和安全性之间的平衡。

背景

这篇文章关注的对象是拥有数十个或者数百个开发团队的公司。我假定他们都以K8S作为应用的运行平台。虽然文章里面的原则也可以用在其他地方，但是K8S确实让我们的持续交付平台的实现变得简化，这种简化也使得这篇文章能更加聚焦在我们需要讨论的问题上。最后声明，虽然这是一篇技术文档，但是不会非常的深入。我将会使用方框和箭头来描述解决方案，以后我可能会另写一篇文章叙述技术细节。

灵活性激发创新

如果一个大公司里面的每个团队都被锁定在同一个开发流程里面，创新是非常困难的。因为创新常需要从上至下而且常常充满风险；任何新的方法都是为了取代旧的。在一个大的复杂组织里面改变工作流程是一项困难的工作，所以：从小处开始非常必要；之后有足够大的空间去成长。

这里给出两个例子来描述一个团队可能采用的不同流程。第一个严重依赖人力工作和批准；第一个比较成熟一些，依赖于自动化测试且省去了管理批准。这2个例子说明了在一个组织里面给几十或者几百个团队强制一种解决方案是多么的荒唐。每个团队有自身的独特情况，会基于此来对他们的软件交付方式做创新。

P1：通过人工的QA批准的持续交付流程

P2: 通过全自动的测试实现的持续交付流程

合规与安全

让我们近距离观察合规与安全需求！在合规方面，企业自身有严格的需求之外，也必须符合政府相关的规范。

在软件交付领域中一般有如下的合规&安全需求

1. 访问控制 - 控制谁能够在什么环境部署什么内容

2. 审计追溯 - 记录对环境的所有变更，包括谁改动了什么，为什么而改

3. 批准流程 - 对特定环境的变更需要得到授权批准以后才能进行

由于持续交付流程改变了关键的软件环境，它在满足这些需求方面也有很大的责任。如果开发团队不准接触生产环境，那么CD平台也不行，除非它有能够做这个部署操作的授权。这仅仅是一个例子而已。我们接下来深入阐述创建一个满足灵活，安全，合规的平台有多困难。

从Jenkins部署

我们先看一下使用流行的Jenkins Pipeline插件实现的原生的持续交付流水线。这是实现CD流水线的一种简单方式，对大多数环境已经足够了，但是不适用于我们的场景。

这个流水线会构建Docker image并部署到K8S上，非常好。但是问题在哪？

首先，Jenkins必须有访问所有K8S集群的帐号信息（包括生产的）。这意味着对Jenkins的admin权限必须限制到有权限访问生产的人，这就限制了开发团队选择自己工具的能力。

其次，任何可以访问Jenkinsfile的人都可以修改流水线，他们可以直接打印生产环境的访问账户，并对生产环境做修改。这表示我们甚至不能让开发人员去修改Jenkinsfile。这会是一个极大的限制，因为每个团队的pipeline都是不同的，甚至同一个团队的不同服务也是不同的（灵活性的需求）。

总之，我们在jenkins里面存放访问信息会严重限制开发团队的灵活性。这明显不是我们希望的，也说明了这种直接的方式为什么是不够的。

GitOps

我们已经看到我们的目标是实现一个CI/CD系统来满足安全，合规，并灵活这些“冲突的”目标。如何做呢？

我们可以从将部署交付流程从部署流程中剥离开始。这样集群的访问信息就从执行交付的Jenkins 流水线里面移除了。部署流程可以放到另一个jenkins或者其他工具中 -- 这里我为了简单起见仍然用jenkins。

隔离以后，我们需要一种方式让交付流程通知部署流程：你需要部署某个应用的某个版本或者对环境做变更（比如增加一个新的环境变量）。一种简单或者相当强大的解决方案是让GIt当作这两个流程的中间人。我们可以创建一个Git repo，里面包括我们所有的环境相关信息，然后让部署流程监听这个repo的变化。

P3: 基于GitOps的持续交付架构

注意Git repo是如何将我们的部署流程从交付流程中剥离的。从交付流程来看，部署就代表着往中间的git repo做一个commit。这样交付流程不会接触到K8S集群。同时任何时候有代码merge进这个git repo中交付流程就会启动。

GitOps最近由Weaveworks的Alexis Richardson 基于GitOps的企业级CI/CD

，已经获得了很多瞩目。基础设施即代码的思想已经存在好几年了，它随公有云而生，因为所有的资源都可以定义为代码。GitOps是将这种思想逻辑延伸到K8S里面运行着的应用上。K8S的部署机制允许我们以文本文件描述我们的应用，并放到Git中。

让我们看看GitOps是如何帮助我们解决三个合规性问题的：

1. 访问控制 ：只有对环境的配置的git repo有写权限的人才能对这个环境做部署

2. 批准流程 ：对于敏感的环境，我们可以允许开发团队的jenkins创建PR，但是只有授权的人才能merge。这就用很小的实现开销创建了一个非常好的批准流程。

3. 审计：因为Git是一个版本控制系统，它天然的记录的更新的所有信息。每个Git commit的都包括了谁做的更改，已经对更改的描述。

最后引入GitOps让我们能够在满足合规需求的情况下创建了一个安全的软件交付流程。如果运维的repo上的用户管理配置合理--只有授权以后的人才能做merge PR的操作。开发团队在没有运维团队授权的情况下是无法更改生产环境的。

我们只是重新做了一遍“基础设施即代码”？

基础设施即代码的思想还没到达GitOps这个层次。类似于CloudFormation 和 Terraform的工具很流行，可以让我们轻松的管理基础设施代码。这些工具用来描述基础设施，而K8S聚集于以容器的方式运行应用（微服务）。在容器里面不断更新的代码是我们需要做持续交付的地方。我们喜欢利用已经有的CI工具来处理这些快速的发布，而且CD本身就是CI的持续。

结论

使用Git做为中介来将部署流程从交付流水线里面解耦是一种有效的方式来实现在安全和合规限制严苛的环境下实现持续交付的手段。它省去了我们必须找到一个完美的工具，既能够做好持续交付和部署的灵活性；同时又有高级的用户管理，授权以及审计的能力。虽然解耦后的方案增加了一定的复杂度，但是我们能够实现为不同的交付流水线和执行部署选择不同工具的目标。

在一个企业的环境中，这样的自由性有很大的收益 - 可以允许一次改动一小部分，也让未来迁移到更好的工具变得容易许多。

原文链接： https://container-solutions.co ... tops/

原文 http://dockone.io/article/8476

正文到此结束