GitOps落地指南

zll大约 6 分钟

通过GitOps的设计与落地，来满足云原生环境下业务的持续交付，建立标准的开发、测试、生产环境，形成统一的规范，完善自动化，为业务快速交付赋能。

整体架构

蓝色代表-ARM适配

运行环境支持AMD和ARMv8

原则: 集群隔离。一个环境一个集群，互不干扰。

目前已有四套集群，提供给研发、测试、生产以及Hotfix、poc使用。

预估信创适配需3-4套ARM集群环境。

后续共需管理7-8个集群环境

通过流程管理，进行仓库的开通或变更，以产品组进行划分和管理，建立起唯一授信源，为后续Pipeline设计做好基础建设

原则：采用一切皆代码的原则，进行基础服务和业务项目的维护管理。

从代码提交到项目上线全流程

运维工程项目

cicd : 用来做产品的的打包和部署管理, 产线内gitlab-ci直接引用即可，做到研发和运维代码管理上的解耦
gitlab-ci.yaml文件

gitlab规定的固定命名文件，用来触发git pipeline，其内容编写遵循gitlab的编排语法，作用类似jenkinsfile
gitops：用来做运维管理，如基础设施、中间件等
misc：试验性的临时功能。未集成到标准编排中的尝试性功能，均在此处编排和管理
playbook：Ansible剧本编排服务，目前提供基于rke工具拉起Kubernetes集群功能 (未支持arm)
template: git pipeline 通用模板文件，现已弃用，迁移至cicd中
utils：运维工具、程序管理，如mysql备份任务，kubernetes调试工具等

gitlab-ci: 项目的持续集成管理 （ARM环境的制品产出，主要是在这里作适配）

gitlab-runner：ci任务的执行者，负责 ci 编排文件的处理和脚本的执行
template： CI编排文件
1. job：提供通用基础服务，如gradle、maven、golang 、artifacts等pipeline节点服务
2. projects：按产线进行归类，按服务进行单独的编排管理，针对不同的服务，可在此进行模板的引用和特性的扩展

制品构建的所有操作均在此处调整

如新增(XC_TONG_WEB_ENABLED)以区分东方通 jar依赖等，通过逻辑判断和处理，产出不同的制品。

如何产出多环境下的制品？

通过ArgoCD 实现多环境的管理与发布

通过argo应用的创建和声明，来监控编排文件的变化，从而实现产品的CD操作

Argo 下产品应用服务编排 （ARM的部署，在这里作适配）

命名的区分
运行环境指定
- 可区分不同的环境发布到不同的集群内，达到多环境的隔离
编排文件指定
- 可以指定应用的编排文件，后续在编排中通过申请的通配域名，即可实现多环境的访问切换，如
  - https://aaa.example.com/
  - https://bbb.example.com/

编排文件对应的就是ArgoCD声明的仓库路径，从而实现了域名和环境的区分，产品的发布只需要修改这里即可，这样后续在pipeline中就可以实现自动化

common: 公共服务管理，比如SQL审计平台 bytebase，研发文档服务docs 等
infra：基础设施服务，和kubernetes集群相关，如SLB (metallb)，存储服务等
middleware: 中间件服务，产品依赖中间件的编排均在此维护
xxx-charts （项目外单独维护）
1. 按产线归类，所有的产品运行编排服务均在此仓库进行维护和管理
**xxx-apps （项目外单独维护）**
1. 产品运行环境归类，基于业务编排模板，进行差异化修改和管理，之后可由Argo-cd发布到对应的集群环境中