gitops

gitOps 持续化集成部署/交付流程解释

一、gitOps整个过程拓扑图

手绘gitOps.pdf

二、每个系统在GitOps流程中占据的角色和作用

2.1 gitlab

功能1

首先，gitlab作为公司自建的代码仓，原本的定位是仅作为代码仓使用，现在经过改良，决定将gitlab作为 持续化集成部署/发布的重要角色。

日常开发人员pull/push代码，最后由分支合并到/master中。

开发人员在各自的代码块区工作，对于代码区的每次提交和推送，都会出发阶段迭代。

将代码更改并合并到/master时，会触发整个gitlab代码项目。

功能2

gitlab中存有完整的应用代码部署配置文件(frontend、backend、applicationset、template等)yaml文件，环境变量，配置与nacos配置中心衔接等。

随机一个应用.yaml文件

~/someApp
├── base
│ ├── deployment.yaml
│ ├── kustomization.yaml
│ └── service.yaml
└── overlays
├── development
│ ├── cpu_count.yaml
│ ├── kustomization.yaml
│ └── replica_count.yaml
└── production
├── cpu_count.yaml
├── kustomization.yaml
└── replica_count.yaml

在gitlab中都能将应用要求写清楚。

2.2 jenkins

该系统通过各类支持插件，调用各系统；组成流水线。流水线一般包含以下内容

gitlab项目
参数化构建过程
名称：ServiceName
hm-app-admin
hm-sso
hm-app-basic
hm-app-config
…

名称：TargetEnv
sit-month
sit-week
uat

高级项目选项
pipeline script from SCM
git 代码库拉取信息
xxxx.git
认证密钥
…

branches to build
*/master

脚本路径
${JOB_BASE_NAME}/Jenkinsfile

通过以上的配置信息，可以让应用在k8s构建的时候，按照配置进行。

在使用pipeline语句；引用前面定义的各类参数值；然后按照步骤走（检查、拉取代码、打包、构建images、打标、推送到harbor、推送到K8S集群中）

jenkins 与gitlab衔接的细节，此文件在gitlab 各应用yaml文件中

jenkinsfile

#!groovy
@Library(‘hm-jenkins-sharedlibrary’) _

def map = [:]
map.put(‘agent’,‘java’)
// 定义项目名称，这里的项目名称与jenkins流水线中的可选应用名称相呼应，对吧。
map.put(‘serviceList’,“hm-base-gateway-open,hm-base-gateway-document,hm-base-gateway,hm-base-gateway-doc”)
// 定义项目git地址
map.put(‘GIT_URL’,‘https://gitlab.huamengtech.com/root/Public_Gateway.git’)
map.put(‘GIT_TOKEN’,‘a063b84a-83bb-4cfd-ae90-39590877d36e’) //拉取代码的验证交换
map.put(‘TargetEnv’,‘dev\ndevm’) // 这里不懂
map.put(‘systemName’,‘taxsaas’) //对应服务的环境变量
map.put(‘pomPath’,‘/hm-gateway’)
shineUATPipeline(map)

2.3 harbor

内部镜像库；存储新构建的应用images (该镜像包含新的应用tag,根据代码人员提交的更新时间，重新打包构建成的images文件)
镜像仓库中默认有 配置信息、代码块等
镜像项目分为：公开/私有
仓库管理：链接外部 镜像库(可以连接到各种云服务商的镜像库中)

2.4 argoCD
该系统与gitlab集成之后，argoCD中由于配置了gitlab代码项目源，并且argoCD会自动监听，代码项目的变化。当代码项目发生了更新变化，argoCD会定期扫描，发现变化后argoCD会自动同步最新的应用版本。

2.5 nacos
所谓配置管理中心，即代码项目中启动时需要加载的所使用到的一些固定衔接数据，例如：[spring cloud 、spring boot、MySQL数据库连接、代码上下层、rabbitmq连接、redis基础配置]。
这样做的好处，让代码项目中的配置统一，防止每次代码更新打包带来的基础配置不一致，导致应用莫名崩溃。
nacos——配置管理
默认配置存储在public，当有新增配置列表时，会生成一个<列表串>，在代码构建时需要填写进去，好让应用启动时正确读取。
配置文件三个重点
Data ID：
Group：
配置内容：

nacos——服务管理
与配置管理相似，只不过该模块是用来对外暴露的，目的让应用启动时顺利通过该IP:80进入到系统中。
服务名:
分组:
元数据:
服务路由类型:

2.6 rabbit-mq

这个系统在微服务架构中往往被定位为消息队列处理平台，所谓消息队列，即应用的请求方与接收方，数据来往过程会产生巨量<建立连接的消息队列>的结果 。那么这些队列包含着<请求方>反复多次的请求，以及<接收方>解析请求消息。就需要一个 消息存储容器了。在生产环境中使用<延迟队列>可以保障用户请求消息得到处理，同时保证消息不堵塞，及时释放。该系统也广泛应用于分布式系统之间的通信
分布式系统通信：借助第三方完成通信
发送方为生产者、消息接收者为消费者、中间则为消息队列容器系统。

消息队列能保证生产者和消费者之间消息正常传递的机制是：通过<延迟队列>机制，生产者只管生产并推送消息到 消息队列，而消费者只管从消息队列中获取消息。由于两方对消息的生产和获取都是异步的，只关系消息的发送和接收，没有业务逻辑的侵入，这样就能避免生产者与消费者之间的消息延迟、丢失。实现两者的解耦。

运维日常使用功能：
overview主页：
消息队列预览(已读取得消息/消息总数)；
消息得预设值及读取值；
ports and contexts (rabbitMQ端口及连接信息)
connections 消息连接状态
消息从哪儿来，存在哪个消息服务器上，被哪个应用消费。
channels 连接通道
exchange 消息交换机
amq.direct
amq.fanout
amq.headers
amq.match
amq.rabbitmq.trace
amq.topic
//以上为rabbit自带得的
queues 消息队列
使用量/限制量

2.7 redis-cluster

该系统可以理解为一个 高速缓存 平台,为什么会选择这个工具？
1.和常规数据库不同，redis数据存储在内存中，所以读取速度非常快，每秒可以处理抄10万次读写操作，该系统广泛用于缓存。
2.redis支持高效的数据结构(SDS简单动态字符串、哈希值、跳跃表、压缩列表ziplist)。
3.使用合理的数据编码(string、list、hash、set、Zset)让数据被查询起来变得更快。
4.合理的线程模型，redis支持多种数据类型，每种类型可能对应多种数据结构，在什么情况下，什么样的数据结构用什么样的编码(单线程模型：避免上下文切换；I/O多路复用)
5.虚拟内存机制。通过VM功能实现冷热数据分离，将内存空间用于被访问次数多的数据，将不经常访问的数据由内存交换回磁盘中。防止因内存不足而造成范围跟速度下降的问题。

redis运维日常使用

2.8 bytebase/archery
bytebase和archery作为应用程序开发期间管理数据库的工具平台，首先bytebase具备以下特征。
1.SQL审查(分析SQL的变化，让SQL更改更规范化)，整个过程跟代码审查一样，bytebase简化了数据库数据更改的过程。
2.SQL编辑器(web界面，更方便查询SQL)
3.有完整的历史更改记录，集成VCS系统，可以再VCS中管理SQL迁移脚本。支持回滚和灾难恢复。

bytebase运维日常使用（archery差不多）

2.9 kubernetes/rancher
kubernetes作为最主流的容器编排工具，生产环境中为 多master多worker 的集群，多用于解决资源调度的问题。k8s集群包含以下组件构成
1.master
当应用发布请求时，master节点会分析当前集群的资源状况，将应用合理的分配到集群中的某个worker 节点上，同时时刻监控整个集群；管理集群中的网络，保证pod之间和与外部的网络访问。
具体实现这一功能，由以下几个组件完成：etcd k8s集群中的数据库，api-server 是k8s集群的唯一可以访问和操作etcd的组件，它是k8s的接口和组件。
scheduler 掌握集群资源情况，有需求时根据特定算法计算，将Pod 均匀分布在到空闲节点。
controller-manager 监控集群状态，负责最终调度策略，主要管理pod的新建、更新，保证pod的一致性。
2.worker
当pod建立的指令下发到某个节点后，该节点的kubelet会接收到来自master节点 controller-manager的指令，接着转发指令给节点中的docker，由它来完成容器的创建、更新、销毁等具体操作。kube-proxy则提供集群内部的服务发现和负载均衡。

下面，以部署一个nginx服务来说明kubernetes系统各个组件调用关系：

首先要明确，一旦kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中
一个nginx服务的安装请求会首先被发送到master节点的apiServer组件
apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上
在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer
apiServer调用controller-manager去调度Node节点安装nginx服务
kubelet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod
pod是kubernetes的最小操作单元，容器必须跑在pod中至此，
一个nginx服务就运行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理
这样，外界用户就可以访问集群中的nginx服务了

2.10 prometheus/zabbix/grafana

Prometheus就是为了解决微服务监控诞生的。可以监控到k8s整个集群组件的状态，而对于时常变化的应用 pod在创建之初，底层都有promethues。
zabbix负责基础监控，比如常见的网络设备以及哑终端设备、还有各种系统终端。相对Prometheus而言，zabbix对基础监控更全面专业一些。
grafana可视化界面，可接入主流的诸多数据源，通过它将数据通过web界面展示，方便统计趋势。

三、简述GitOps流程运行的整个过程，自我理解

1.开发组的人员在自己代码区工作，对于代码的每次提交和推送，都会触发代码阶段迭代。代码项目默认有两种分片一种 master 即代码的汇总。另一种是各开发人员所属的代码分段。代码合格后，由代码项目负责人将代码更改合并到./master时会触发整个gitlab代码项目。开发推送代码到gitlab<私有代码仓>.
2.在实际的gitOPS流程中，会直接在gitlab项目中写好配置详情。
2.1 前端、后端(配置地图、应用镜像拉趣、label、tag、挂载目录、服务端口、资源使用限额)
2.2 applicationset(指定argocd在gitops中拉取代码项目、外网k8s集群地址、预设值等信息）
2.3 hack(各种脚本sh 使用dockerfile重新打包）这是干啥的？
2.4 template 模板（定义了各服务的模板）
2.5middleware （各类中间件应用配置文件：中间的副本数、镜像拉取、版本号、资源使用限额、）
3.jenkins流水线手动建立（ 发布的应用名称、环境变量、脚本路径、从哪些代码项目发布、从check-clone-build打包-容器tag-deploy）Jenkins仅作为调用各系统API，组成流水线。
3.1与gitlab配置免认证key，在流水线中预设定应用名、运行环境、代码项目地址等。
3.2在使用pipeline语句，引用前面定义的参数值，从check到部署，每个步骤都对应着之前设置的预设值。
4.流水线是个过程，整个过程会涉及到nacos配置清单读取使用、harbor镜像库Pull/push、kubernetespod建立、argoCD同步。那么接下来细细拆解。
当代码从gitlab中通过dockerfile重新构建打jar包之时，会从nacos配置管理中读取该应用的配置文件(包含预连接的数据库、spring上层关系、数据库源)
当包打完后，会生成打包完成时的系统时间，这个时间即为tag ，具备动态性。包会封装成Image推送到harbor镜像库中。
通过流水线中的脚本命令，删除旧镜像，将新镜像存储在应用镜像位置中。
5.当镜像完成后，接下来要进行发布操作，发布一般为（测试环境、生产环境、灰度环境）。内网有k8s集群，多为测试环境和灰度环境。通过内部测试，检查项目是否有bug，当测试失败存在bug，接着退回。让开发人员重新修改代码。接着进行1-4过程。
若测试符合标准，直接在流水线中发布到生产环境的k8s集群中。
6.生产环境的k8s接收来自jenkins流水线pipeline的指令，通过读取gitlab 应用配置信息(副本、标签、镜像、版本、资源限额等)，在k8s集群中启动相应的 pod 应用。此时 微服务完整的发布过程就出来了。这是目前主流的微服务迭代流程之一。
7.当应用正常运行后，用户可通过k8s集群公布出来的应用节点IP+端口，访问到引用。由于应用打包之初默认与中间件redis进行了对接和设置。当应用接收到数量级的请求时，redis 缓存的优势就体现出来了。而且通过rabbitMQ查看消息队列的详情。
8.Prometheus天生为k8s诞生，在每个应用启动时默认都会加入到Prometheus中接收监控。当应用建立时自动在Prometheus生成被监控，当应用被销毁和到期，会随着pod变动而消失。
9.为防止数据泄露，可采用jumpserver堡垒机方式，远程连接到服务器进行编辑。