基于GitOps的企业级CI/CD
实现企业级的持续交付(CD)是一个巨大的挑战。每一个公司都在对他们的软件交付方式做创新,我们需要允许各个团队学习构建并优化他们自己的交付流水线。在云原生的世界里正在发生,许多的最佳实践正在萌芽。 尽管如此,给予团队灵活性做创新试验时,也需要兼顾公司的安全和合规方面的要求。在这篇文章里面,我将讲述我们如何为一个大型企业客户成功使用GitOps架构模型来获得灵活性和安全性之间的平衡。
灵活性激发创新
这里给出两个例子来描述一个团队可能采用的不同流程。第一个严重依赖人力工作和批准;第一个比较成熟一些,依赖于自动化测试且省去了管理批准。这2个例子说明了在一个组织里面给几十或者几百个团队强制一种解决方案是多么的荒唐。每个团队有自身的独特情况,会基于此来对他们的软件交付方式做创新。
P1: 通过人工的QA批准的持续交付流程
P2: 通过全自动的测试实现的持续交付流程
在软件交付领域中一般有如下的合规&安全需求:
访问控制——控制谁能够在什么环境部署什么内容
审计追溯——记录对环境的所有变更,包括谁改动了什么,为什么而改
批准流程——对特定环境的变更需要得到授权批准以后才能进行
这个流水线会构建Docker image并部署到Kubernetes上,非常好。但是问题在哪?
首先,Jenkins必须有访问所有Kubernetes集群的帐号信息(包括生产的)。 这意味着对Jenkins的admin权限必须限制到有权限访问生产的人, 这就限制了开发团队选择自己工具的能力。
其次,任何可以访问Jenkinsfile的人都可以修改流水线,他们可以直接打印生产环境的访问账户,并对生产环境做修改。这表示我们甚至不能让开发人员去修改Jenkinsfile。这会是一个极大的限制,因为每个团队的pipeline都是不同的,甚至同一个团队的不同服务也是不同的(灵活性的需求)。
总之,我们在Jenkins里面存放访问信息会严重限制开发团队的灵活性。这明显不是我们希望的,也说明了这种直接的方式为什么是不够的。
我们可以将部署交付流程从部署流程中剥离开始。 这样集群的访问信息就从执行交付的Jenkins流水线里面移除了,部署流程可以放到另一个Jenkins或者其他工具中——这里我为了简单起见仍然用Jenkins。
隔离以后,我们需要一种方式让交付流程通知部署流程: 你需要部署某个应用的某个版本或者对环境做变更(比如增加一个新的环境变量)。一种简单或者相当强大的解决方案是让Git当作这两个流程的中间人。 我们可以创建一个Git repo,里面包括我们所有的环境相关信息,然后让部署流程监听这个repo的变化。
P3: 基于GitOps的持续交付架构
注意Git repo是如何将我们的部署流程从交付流程中剥离的。 从交付流程来看,部署就代表着往中间的git repo做一个commit。 这样交付流程不会接触到Kubernetes集群。同时任何时候有代码merge进这个git repo中交付流程就会启动。
GitOps最近由Weaveworks的Alexis Richardson提出,已经获得了很多瞩目。基础设施即代码的思想已经存在好几年了,它随公有云而生,因为所有的资源都可以定义为代码。GitOps是将这种思想逻辑延伸到Kubernetes里面运行着的应用上。Kubernetes的部署机制允许我们以文本文件描述我们的应用,并放到Git中。
让我们看看GitOps是如何帮助我们解决三个合规性问题的:
访问控制:只有对环境的配置的git repo有写权限的人才能对这个环境做部署。
批准流程:对于敏感的环境,我们可以允许开发团队的Jenkins创建PR,但是只有授权的人才能merge。 这就用很小的实现开销创建了一个非常好的批准流程。
审计:因为Git是一个版本控制系统,它天然的记录的更新的所有信息。 每个Git commit的都包括了谁做的更改,已经对更改的描述。
结论
在一个企业的环境中,这样的*性有很大的收益——可以允许一次改动一小部分,也让未来迁移到更好的工具变得容易许多。
原文链接:https://container-solutions.com/enterprise-grade-ci-cd-with-gitops/