GitOps:Kubernetes多集群环境下的高效CICD实践

为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题没法快速解决等问题，云原生这一律念横空出世。云原生能够改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策，能够说，云时代的云原生应用大势已来。在容器领域内，Kubernetes已经成为了容器编排和管理的社区标准。它经过把应用服务抽象成多种资源类型，好比Deployment、Service等，提供了一个云原生应用通用的可移植模型。在这样的背景下，咱们如何在云原生的环境下实践更高效的DevOps来达到更有生产力的表现就成为了一个新的课题和诉求。

与GitOps这个概念相比，你们可能对DevOps的概念已经耳熟能详了。起初DevOps是为了打破开发测试、运营这些部门之间的壁垒，经过自动化的构建、程式化的脚本，最低限度减小人工偏差，必定程度上提升应用版本的迭代效率；容器技术出现之后，轻量、标准化的能力使得DevOps技术才有了日新月异的发展。无论技术怎样更新迭代，DevOps最主要的核心诉求是不变的，那就是提升应用迭代的频率和下降成本。GitOps就是DevOps的逻辑扩展，它的核心目标是为了更加高效和安全的应用发布。

首先咱们提取出一些用户在作devops的过程当中遇到的痛点进行分析。第一个问题是如何自动化推动应用在环境栈中的无差异发布.这里我列举了三种环境，测试环境、生产环境和预发环境，对于一个应用来讲，咱们一般的设定都是把不一样分支部署到对应环境，好比master分支的源码对应的是线上环境，latest分支对应的是预发环境，其余开发分支对应地部署到测试环境；目前大多数的作法是建立不一样的job，拉取不一样的源码分支、部署到不一样的环境，或者同一个job，经过添加不一样的构建参数来决定进行怎样的构建和发布动做。 很是容易产生混乱和不便于管理。

第二个问题就是，生产环境的发布权限通常都是须要严格控制的，一般只有应用管理员或者运维管理员才有生产发布权限。咱们在跟一些客户的交流中发现，一种方式是在同一套cicd环境中建立不一样的job，而后经过基于角色访问控制策略来作job的隔离，只有管理员权限的人员才能看到用于发布生产的job； 更直接的一种作法就是再建一套cicd环境专门作生产环境的发布， 但这样既浪费资源又下降了应用迭代的频率。

第三个问题是说咱们想要提升应用迭代的频率进而下降人力成本、时间成本、把精力放在新业务或创新业务的拓展上，但目前咱们的开发测试人员在应用运行状态或测试结果的同步与反馈上有必定的隔阂，另一个是线上业务出现问题的时候，如何快速定位、复现和回滚，这是一个咱们能够重点思考的地方。以上三点只是我列举出来的咱们用户在实际使用cicd的过程当中的一些痛点的子集，那接下来咱们就带着这些问题来看一下gitops模型的设计思路是怎样的

咱们在设计gitosp发布模型的时候是有如下这些核心诉求的：第一个是版本管理，咱们但愿每个发布的应用的版本号都能跟git commit id关联，这样的好处就是每个变动都有历史记录查询、能够更快进行故障定位和修复，第二个是基线管理，这里咱们一下子会讲到分两种类型的基线，第三个是怎么作安全发布，包括发布权限管理以及安全审批的内容；最后一个是如何让开发测试人员快速获取反馈

首先gitops的核心思想就是将应用系统的声明性基础架构和应用程序存放在Git版本库中，全部对应用的操做变动都来源于Git仓库的更新，这也是gitops这个名称的由来。另一个问题是，按照以往通用的作法，咱们可能会把应用如何构建如何部署的脚本以及配置文件跟应用源码自己存放在同一个仓库里，这样带来的问题有两个，一是开发人员可能还须要维护这个部署脚本或配置文件，不能把精力集中到产品开发上，另一个问题是部署脚本有时候会涉及环境敏感信息，安全性不够，因此咱们这里必定要把应用源码仓库与构建仓库分开管理。

接下来就是基线管理，基线管理分两种，一种是环境栈基线，如图所示，咱们的设定是，生产环境只能部署master分支的代码，预发环境只能部署latest分支的代码，预览环境用来部署其余开发分支，这里有个名词叫预览环境，其实也就是测试环境，但咱们会在开发分支经过测试、经过验证成功合并到latest分支之后动态销毁这个测试环境，固然这在kubernetes容器集群下是很是容器作到的，在其余具体的场景下能够用不一样的策略。这个基线咱们能够把它称为小基线，它是用来明确管理应用在预览、预发、生产环境中的推动的。大基线是针对线上发布版本的管理的，这能保证咱们在线上出现故障的时候能快速回滚到上一个稳定的版本。这在生产发布管理中是必不可少的，在gitops中咱们还能快速定位故障精确到某个git commit。

而后是应用发布的权限管理和安全审批，gitops中的权限管理是经过代码合并的控制来作的，在这个模型中，普通的开发人员没有cicd环境好比jenkins的访问权限，更精确地说的话是只有日志查看的权限，在git这一端，普通开发者只有向开发测试分支推送代码的权限，并能够申请向latest分支合并代码，即提交MR/PR的权限，当普通开发者新建MR/PR后，就会触发构建把应用部署到预览环境，管理员经过查看这个新分支的构建部署是否经过一系列测试和验证来决定是否接受这个MR/PR， 只有管理员接受MR/PR的合并后，latest分支代码才会从新构建和部署到预发环境，这样就经过MR/PR的接受和拒绝来达到应用发布安全审批的目的。

最后是如何进行快速反馈和团队成员间的互动，这包括两部份内容：一个是普通开发测试人员在推送源码后，能经过邮件、钉钉、slack等工具实时地获取构建结果，对本身的应用进行高效开发测试，；另外一方面是能在MR/PR的页面上查看自动化测试的反馈结果、应用预览连接、其余团队成员的comment等。

下面是使用GitOps管理应用发布到不一样kubernetes集群的架构图和时序图。首先是应用源码与构建源码分离。最上面有一条虚线，虚线上面是普通开发者能看到的，或者说是有权限进行操做的部分，剩下其余的部分都是管理员才有权限作的，绿色区域是Jenkins的流水线任务。普通开发者没有Jenkins环境的建立Job和构建Job的权限，他有的只是构建Job的日志查看权限。这个普通应用是在Git仓库里，它有不一样的
分支，有必定设定的关系，每次有构建的时候会从另一个Git仓库里作，好比preview-plpeline、prod-plpeline，在这里面能够存放一些信息，只有应用管理员才能看到，普通开发者没有权限看到信息。 而后咱们须要设置应用发布环境栈，这在个示例中咱们有预览环境、预发环境、生产环境的设置，应用在预发环境和生产环境中的发布是须要通过管理员安全审批的。

最后是一个时序图，开发人员提交新的feature，建立指向latest分支的MR，建立MR的动做会触发preview-plpeline的构建，构建会拉取preview-plpeline的构建仓库，构建仓库存放的是构建脚本以及要部署的环
境信息。而后就是自动化的构建流程，首先会从应用源码仓库把应用源码拉取下来作构建，静态代码测试、单元测试，测试结果会反馈到MR上，而后打包容器镜像并把镜像推送到镜像仓库，最后会把应用经过文件部署到Kubernetes的集群里并进行功能测试，测试结果反馈到MR上，部署以后会收集应用相关信息，经过钉钉通知发送到开发群里。开发人员收到钉钉通知，能够直接点击连接查看应用状态，若是有问题，能够返回来本身从新开发，再从新进行提交，把前面的流程再走一遍，没问题就能够请求管理员进行审批，把代码合并到latest分支。latest分支和master分支有更新时，就会触发与前面的构建相似的流程把应用推动到预发环境和生产环境。

 

---

本文做者：流生

原文连接

本文为云栖社区原创内容，未经容许不得转载。