💡 近日，由微软和英特尔联结发动的第二届开源云原生开发者日（Open Source Cloud Native Developer Day）上海站顺利闭幕。极狐 (GitLab) 资深云原生架构师郭旭东 在会上进行了《深度摸索 GitOps 平台的更多可能》主题演讲，与泛滥开发者共赴技术“狂飙”之旅。
以下内容整顿自本次演讲。Enjoy～
什么是 GitOps？
对于 GitOps 的定义，千人千面。咱们这里将 GitOps 概括为一个公式：
- XaC：Everything as Code，这是 GitOps 的重要个性之一：所有皆代码。例如 Infrastructure as Code 基础设施即代码；
- MR&PR：PullRequst & MergeRequest，合并申请；
- CI + CD：Continuous Integration & Continuous Deployment/Delivery，继续集成与继续交付或部署。
GitOps 领有四个要害准则：
- 申明式形容：因为 Git 充当所有 DevOps 操作的繁多事实起源，因而整个零碎在 Git 中应用 .yaml 文件进行申明性形容。申明式形容指标的性质，让计算机明确指标和后果，而非流程。它不必通知计算机问题畛域，从而防止随之而来的副作用；
- 版本控制：须要的零碎状态在 Git 中进行版本治理，能够齐全跟踪在任何给定工夫点对系统状态所做的所有更改；
- 自动化：能够在 Git 代码中申明零碎所需的状态，而后自动化零碎以将所有批准的更改利用到零碎；
- 保障：当所需状态与零碎的理论状态不匹配时，软件代理会揭示配置更改，来确保差别的修改和告警。
同时，GitOps 也具备 幂等性 个性，即同一个操作，无论执行多少次，跟执行一次的成果一样。这是一个重要的个性，使得 GitOps 模型在各种异常情况下都能正确复原。
因而，GitOps 在 版本治理、分支策略、代码审查、历史记录、用户体验 等方面天生具备劣势。
如何构建高质量的 GitOps 平台？
GitOps 平台 则是 一种将 GitOps 工具与其余工具和服务集成在一起的平台，旨在提供更残缺的 DevOps 自动化解决方案。
GitOps 平台通常须要提供以下能力：
- GitOps 工具治理：将不同的 GitOps 工具集成在一起，能够主动管理应用程序的部署、配置和更新。
- 自动化流水线：提供自动化管道，从代码提交到应用程序部署和监控全过程自动化。
- 代码审查：因为每一次代码提交都可能间接影响到云等根底设置，因而每次批改都须要充沛 Review。
- 平安工具：提供安全性性能，如自动化破绽扫描、访问控制和加密等。
2 种平台计划
搭建 GitOps 平台须要综合思考 老本 + 效率 + 体验，通常有两种计划：
1. DIY（Do It Yourself）工具链
通过多个工具，本人组合造成一个 GitOps 平台。
这种形式有其弊病，例如：
- 工具链比拟软弱，可能导致整个软件研发端到端过程的不稳定性；
- 数据扩散在各个系统中，通常须要保留多份，往往导致审计十分艰难；
- 泛滥工具链所带来的运维工作既有危险，老本也低廉。
2. AIO（All In One）平台
DevOps 性能都集中在一个平台，工程师只须要在一个平台上实现整个软件开发生命周期。
这种形式的益处是：
- 花更少的工夫保护工具，投入更多的工夫研发软件产品；
- 通过繁多的用户数据库和审核，保障工作的可跟踪性、可追溯性和可审核性；
- 自动化反复的工作工作，提供更高的工作吞吐量和效率；
- 确保整个软件的开发和运维过程是平安、统一且防篡改。
极狐 GitLab 即是这样的一体化平安 DevOps 平台，并通过了数百万开发者的利用测验。
2 种仓库设计
「Multi-Repo」和「Mono-Repo」是两种代码仓库的治理格调：
- Multi-Repo：多仓库，每个我的项目都用一个 Git 仓库托管。
- Mono-Repo：单体仓库，对立用一个 Git 仓库治理所有的我的项目。
这两种模式，各有利弊，须要依据理论状况来抉择：
Multi-Repo 模式把一个大问题分成几个小问题来解决，通过问题的细化，缩小复杂度，从而让工作更加棘手，更加有保障 ；但其也有不可漠视的问题：为了保障一个性能的残缺运行，即便再小的改变，也可能 须要对所有的 Repo 进行更新，这是一个沉重的工作。
在 Mono-Repo 模式下，所有设计文档、源代码等都放在一个 Repo 外面，一次提交能够解决所有的问题 ；其最大的问题是随着程序规模一直减少，代码量、文档等随之减少， 整个 Repo 会越来越大。
分支策略
分支策略能够了解为当一个团队须要就同一个我的项目进行协同时，如何借助 Git 这样的代码管理工具或软件协同管理工具来实现协同效应的管理机制。
分支策略次要分为 单分支策略 和多分支策略，二者的外围区别在于：
- 单分支更多强调的是长期分支，存在于整个我的项目生命周期中。
- 多分支更多强调的是短期分支，为长期目标而创立，一旦它们实现了职责并且代码被集成到主线（或另一个长期分支)中，就会被删除。
如果问 10 个不同团队是如何应用 Git 分支的，可能会失去 10 个不同答案。没有所谓的“最佳”分支策略，应该综合剖析我的项目状况，找到最适宜团队的策略。
GitOps 规模化
企业实现 GitOps 规模化，须要外围关注 4 个点：
➤ 实际复用
如果无奈进步复用性，管理员须要投入大量工夫精力在权限开明 / 敞开、加减成员等繁琐事务上，而高质量的复用能力，能够节约大量的人力和老本。
➤ 服务可用
无论 100、1000 还是 10000 用户规模，都须要确保服务可用。
➤ 集成拓展
须要确保可能随时拓展多种利用或产品集成。
➤ 变更审批
变更审批是必要的，尤其是在平安审批上，一点疏漏，可能造成全盘解体。
极狐 GitLab GitOps 最佳实际
极狐 GitLab GitOps 组件
极狐 GitLab 推出 极狐 GitLab Kubernetes Agent Server（KAS），是用平安和云原生形式实现极狐 GitLab 与 Kubernetes 集成的组件，实现以下性能：
- GitOps Workflow：在我的项目仓库里编写任意 K8s 对象的形容文件 (.yaml 或者 .json 格局)，都能实时部署到 K8s 集群中，无需执行 CI/CD；
- CI/CD Workflow：执行 CI/CD Pipeline 时，容器内注入了 KubeConfig 等 K8s 集群连贯信息；能够在容器内执行 KubeCtl、Helm 等命令连贯 K8s 集群再执行部署。
图：极狐 GitLab GitOps 组件概览
极狐 GitLab GitOps 工作流程
极狐 GitLab GitOps Workflow 应用 Pull 模型：极狐 GitLab 作为繁多可信源，当可信源侧的文件清单产生变更时，集群侧可能及时捕捉到此变更，从而实现变更清单部署。
极狐 GitLab Kubernetes Agent 由两局部组成：位于集群侧的极狐 GitLab Kubernetes Agent（agentk）和位于极狐 GitLab 侧的极狐 GitLab Kubernetes Agent Server (GitLab KAS)，可能很好的实现上述的 GitOps Workflow。
图：极狐 GitLab GitOps 工作流程
极狐 GitLab GitOps 最大劣势
极狐 GitLab GitOps 配置简略，疾速上手，仅需几行代码，即可取得开箱即用的 GitOps。
➤ Step 1：配置
在指定目录下建设文件 .gitlab/agents/agent-name/config.yaml，指定我的项目 ID、哪些文件须要同步，即可自动识别，并且无需装置任何组件，主动进行容器扫描。
➤ Step 2：连贯集群
在极狐 GitLab 中，点击连贯 Kubernetes 集群，只需将关上页面的命令复制终端，通过 Helm 间接装置。
➤ Step 3：主动同步
装置后，指定目录文件即可主动同步到集群中，并启动容器平安扫描。
摸索 GitOps 更多可能
极狐 GitLab as Code
如果多个团队应用一个 Git 仓库作为所有基础设施和利用部署代码的繁多事实起源时，这是一个良好的流程标准。
基础设施团队能够应用 Terraform 进行自动化合作，并将代码部署到多个云服务中，实现 Infrastructure as Code。而极狐 GitLab 对 Terraform 进行良好的集成，提供优质体验。
极狐 GitLab 除了提供 KAS 性能，同样反对其余所有的 GitOps 工具，您能够抉择任何您想应用的工具，进一步实现 Everything as Code，也能够说极狐 GitLab as Code。
AI in GitOps
现在 AI 大行其道，AI in GitOps 中可能擦出什么火花呢？这里咱们也做了一些畅想：
兴许将来真的会呈现电影《漂泊地球》系列中的智能量子计算机 MOSS，可能实现自组织、自适应、自感知、自编程的产品，所有皆有可能！