GitOps实践，基于Gitlab CI、Kustomize 与Argo CD

GitOps总结与实践

GitOps

什么是GitOps

GitOps是Weaveworks公司于2017年首创的一种进行Kubernetes集群管理和应用交付的方式。GitOps通过使用Git作为声明性基础设施和应用程序的单一事实来源进行工作。 GitOps的核心是将应用的声明性基础架构描述、应用源码与自动化流程存放在Git Repository中，将Git作为交付流水线的核心。GitOps会Diff Repository中声明信息与Kubernetes集群中实际运行的内容之间的差异，其实现的GitOps Kubernetes Operator会根据情况进行自动更新或回滚集群；通过将Git作为交付流水线的核心，开发人员可以使用push、pull request等Git操作，以加速和简化Kubernetes集群应用程序的部署和操作任务。

GitOps是用于构建云原生应用程序的操作模型

GitOps为Kubernetes或其他云原生技术的操作模型，提供了一组最佳实践，统一容器化集群和应用程序基于Git部署、管理和监控。
优化开发人员管理应用程序的方式，包括应用 CI/CD pipeline 和 Git Flow 的操作和开发。

使用GitOps的前置条件

声明式描述整个应用系统，并使用Git进行版本化控制

任何能够被描述的内容都必须存储于Git仓库中，如Kubernetes资源对象描述；声明性意味着配置由一组事实而不是一组指令来保证，基于Git对应用程序的声明。描述进行版本控制后，就有了单一的事实来源，应用程序可以轻松部署到Kubernetes，并进行升级、回滚，而且当容灾处理时也可以快速、可靠地复制基础设施。

Git Approved Changes后自动更新

允许对声明信息的变更，自动化更新于集群中，并且不需要集群凭证来更改系统，在隔离的环境中使用GitOps，将状态定义位于外部，使得可以将"所做的事情"和"将要如何做的事情"分开。

通过GitOps确保正确性以及分歧报警

一旦系统状态被声明并受版本控制，可以通过GitOps提供的工具对真实的系统状态与版本控制中声明的系统状态进行Diff，在真实的系统状态与版本控制中声明的系统状态不一致时进行通知；以及通过GitOps工具支持系统在故障、人为错误时进行自我修复。

不可变基础设施、IaC与GitOps

不可变基础设施（Immutable Infrastructure）：不可变基础设施是由Chad Fowler于 2013 年提出的一个构想：在这种模式中任何基础设施的实例一旦创建之后便成为一种只读状态，不可对其进行任何更改。如果需要修改或升级某些实例，唯一的方式就是创建一批新的实例以替换。传统可变基础设施是将应用打包好部署在不同的机器上，需要确保环境的统一，并通过修改、补丁的方式持续更新应用，随着时间的推移很难再确保所有的机器处于相同的状态；而不可变基础架构，是将整个机器环境打包成一个单一的不可变单元，这个单元包含了整个环境和应用本身，以解决传统可变基础架构的问题。

基础架构即代码（IaC）是通过代码（而非手动流程）来管理和置备基础架构的方法。

通过使用容器技术可以实现基础设施的不变性，而Kubernetes的声明性容器编排可以实现基础架构即代码。GitOps基于不可变基础设施和IaC，结合Git进行应用系统整个配置文件集版本控制。

GitOps的工作模式

Git对环境配置进行版本控制

GitOps以Git为核心进行工作，除了应用程序的仓库外，还需要对环境配置的仓库进行版本控制；其中应用程序仓库含应用程序的源码与部署相关的manifests，环境配置仓库包含应用所需基础架构与部署相关的manifests。

GitOps基于pull的工作模式

GitOps大都基于Pull模式去工作，开发人员推送应用代码到应用仓库后，经过Pull Request合并到目标分支后，触发CI Pipeline，构建推送应用容器镜像与推送更新环境配置仓库；在CD阶段，通过引入Operator，不断观察环境配置库的声明信息并与当前集群的应用环境进行Diff，当存在差异时进行集群应用环境的部署、更新或者还原。

GitOps基于push的工作模式

GitOps也可以基于Push模式去工作，对比基于Pull的工作模式，Push模式在CI Pipeline完成阶段会去通知Operator进行环境配置信息的拉取与部署、更新。Push模式有着传统CI/CD流程的直观性，对比Pull模式有着更好的实时性与性能，但却缺少了对端（环境配置信息）到端（集群应用信息）一致性的保证。

GitOps的优势

通过GitOps，当我们对Git Repository进行更改时，GitOps的自动化交付流水线会自动将变更部署到基础架构中。而且，GitOps还会使用工具将应用程序的实际状态与Git Repository中的声明状态进行比较，以通知集群Git Repository中声明状态与实际环境的Diff。

通过应用GitOps，基础设施和应用程序代码都有一个“真实来源”，提高了开发团队速度并提高系统可靠性。

将GitOps理论应用在持续交付流水线上有着深远的好处：

提高生产力：具有集成反馈控制回路的自动化持续部署可以显著加快部署时间。
增加开发体验：开发人员可以使用熟悉的版本控制工具（Git）更快速、方便地管理Kubernetes的更新和功能。
更加稳定与可靠：可以使用Git Flow来管理集群应用，而且可以方便地获得审计日志，记录集群应用的更改；借助Git的revert/rollback，可以稳定且可重现地进行回滚、恢复操作。
一致性和标准化：GitOps提供了标准化的模型以进行基础设施、应用程序与Kubernetes的附加更改，可以保持组织中端到端工作流的已执行状态。

Argo CD

Argo CD是一个用于Kubernetes的声明式GitOps持续交付工具；Argo CD遵循GitOps模式，使用Git存储库作为定义所需应用程序状态的真实来源, Argo CD支持多种Kubernetes manifests 如kustomize、helm charts、jsonnet files…。Argo CD可以在指定的目标环境中自动部署所需的应用程序状态，应用程序部署可以跟踪分支、标签的更新或在Git提交时固定到特定版本的清单。

Argo CD特性

将应用程序自动部署到指定的目标环境
支持多种配置管理/模板工具（Kustomize、Helm、Jsonnet、plain-YAML）
支持管理和部署到多个集群
SSO 集成（OIDC、OAuth2、LDAP、SAML 2.0、GitHub、GitLab、Microsoft、LinkedIn）
用于授权的多租户和 RBAC 策略
基于Git版本控制，支持回滚到Git存储库中提交的任何应用程序状态
持续监控与分析应用资源的健康状况
支持自动或手动（基于Pull/Push模式）触发应用程序同步到所需状态
提供可视化的Web UI与用于自动化与CI集成的CLI
Webhook 集成（GitHub、BitBucket、GitLab），以及提供用于自动化的访问令牌
PreSync、Sync、PostSync hooks 以支持复杂的应用程序的部署策略（如blue/green 、canary upgrades）
应用程序事件和API调用的审计跟踪
Prometheus指标

Argo CD架构

Argo CD 通过kubernetes控制器实现，通过持续监控集群中正在运行的应用程序并将当前的状态信息与所需的目标状态（环境配置仓库）进行比较。通过Diff实时状态与目标状态，如果存在差异则应用进入OutOfSync状态；Argo CD会报告和可视化差异，同时提供工具自动或手动的方式将实时状态同步回所需目标状态。在 Git 存储库中对所需目标状态所做的任何修改都可以自动应用并反映在指定的目标环境中。

Argo CD主要由API Server、Repository Server、Application Controller组成。

API Server Argo CD的 API Server是一个gRPC/REST服务，它公开了Argo CD的Web UI、CLI API 与CI/CD系统使用的API，主要职责为：

应用程序管理和状态报告
调用应用程序进行相关的操作，如同步、回滚、自定义操作等
存储库和集群凭证管理(使用K8s secrets进行存储)
对外部身份提供者的身份验证和授权
基于RBAC的角色访问权限控制
Git Webhook 事件的listener/forwarder

Repository Server 存储库服务器是一个内部服务，维护保存应用程序Git存储库的本地缓存，当应用设置如下输入信息时，它负责生成和返回 Kubernetes manifests：

存储库URL
git revision（commit, tag, branch）
应用程序设置的路径
模板配置：parameters、helm values.yaml

Application Controller 应用程序控制器是一个Kubernetes Controller，它持续监控正在运行的应用程序并将当前的状态信息与所需的目标状态（环境配置仓库）进行比较，对检测到的OutOfSync状态的应用程序选择对应的纠正措施进行纠正。它还负责调用任何用户定义的生命周期事件（PreSync、Sync、PostSync）对应的hooks。

Argo CD部署

Argo CD支持两种部署方式：多租户（multi-tenant）、核心（core）。

多租户（multi-tenant）多租户模式是安装Argo CD最常见的方式，通常用于为公司内多个开发团队提供服务，并由平台团队进行维护；用户可以使用Web UI或CLI 通过 API Server访问 Argo CD；支持HA与非HA方式进行部署。
核心（core）核心模式适合独立使用Argo CD且不需要多租户特性的集群管理员；核显模式包含更少的组件并且更易于设置，bundle不包含API Server或Web UI，并只安装每个组件的轻量级（非 HA）版本；用户需要 Kubernetes 访问权限来管理 Argo CD。

具体的部署方式可以参考：https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/

使用Kustomize定制/管理Kubernetes资源

关于Kustomize

Kustomize是一个通过kustomization文件定制Kubernetes对象的工具；kustomize允许您自定义原始的、无模板的Kubernetes YAML文件以用于多种用途，而原始Kubernetes YAML保持不变且可按原样使用。

Kustomize可以解析并修补Kubernetes API对象，如同make在一个文件中进行声明，如同sed可以发出解析并修补完成的YAML文本。

可以通过kustomize build命令生成自定义YAML，从1.14版本开始kubectl也支持使用kustomization文件来管理Kubernetes对象，可以直接通过kubectl kustomize命令生成自定义YAML。

使用Kustomize定制/管理Kubernetes资源

kustomize提供以下功能特性定制/管理Kubernetes应用配置文件

从其他来源生成资源

Kustomize提供secretGenerator和configMapGenerator，可以基于文件或字面值来生成Secret和ConfigMap。如下，从.env文件生成ConfigMap。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
configMapGenerator:
- envs:
  - .env
  name: echo-config

为资源设置贯穿性（Cross-Cutting）字段如同模板中的变量，为在项目中所有的Kubernetes对象设置贯穿性字段，如为所有资源设置相同的名字空间；为所有对象添加相同的前缀后缀、标签、注解等。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
namespace: dev
namePrefix: dev-
nameSuffix: "-test"
commonLabels:
  app: echo
commonAnnotations:
  sidecar: monitoring
resources:
- deployment.yaml
- service.yaml

组织和定制资源集合在项目中构造资源集合并将其放到同一个文件或目录中管理。Kustomize提供基于不同文件来组织资源并向其应用补丁或者其他定制的能力。

kustomization.yaml文件的resources字段定义配置中要包含的资源列表，达到资源的组织。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml

补丁文件（Patches）可以用来对资源执行不同的定制。Kustomize通过patchesStrategicMerge和patchesJson6902支持不同的打补丁机制。 patchesStrategicMerge的内容是一个文件路径的列表，其中每个文件都应可解析为策略性合并补丁（Strategic Merge Patch）。

# deployment replace patch file 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo
spec:
  replicas: 3

# deployment memory patch file
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo
spec:
  template:
    spec:
      containers:
      - name: echo
        resources:
          limits:
            memory: 512Mi

# kustomization file
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
patchesStrategicMerge:
- deployment_replicas_patch.yaml
- deployment_memory_patch.yaml

也可以通过patchesJson6902来使用JSON补丁的能力，对比patchesStrategicMerge的合并机制，patchesJson6902支持对任何资源的任何字段进行修改。

# deployment replace patch file 
- op: replace
  path: /spec/replicas
  value: 3

# kustomization file
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
patchesJson6902:
- target:
    group: apps
    version: v1
    kind: Deployment
    name: echo
  path: deployment_replicas_patch.yaml

kustomize也提供了对象字段值注入的功能，例如通过images字段设置新的镜像。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
images:
- name: echo
  newName: my.image.registry/echo
  newTag: 1.1.0

基准（Bases）与覆盖（Overlays）

Kustomize中有基准（bases）和覆盖（overlays）的概念，基准是包含kustomization.yaml文件的本地目录或者远程仓库目录，包含一组资源及其相关的定制；覆盖也是一个目录，其中包含将其他kustomization目录当做bases来引用的kustomization.yaml文件。基准与覆盖是多对多的关系，覆盖可以引用多个基准，基准也可以被多个覆盖引用，提高了kustomize的高度定制性。

├── 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

kustomize的详细用法可以参考：

Kustomize Vs Helm

Kustomize对比Helm，可以通过如下表格来对比两者的特性：

特征	Helm	Kustomize
模板支持	√	×
覆盖支持	×	√
打包支持	√	×
验证hooks	√	×
回滚支持	√	×
原生 K8s 集成	×	√
声明性	√	√
可见性和透明度	弱	强

对比两者，比较显著的差别是Helm的流程主要基于模板，类似于瀑布式的 [模板定义->模板填充->生成资源文件]；Kustomize的流程基于覆盖，类似于迭代式的Base和Overlay独立迭代变更。相比之下，选择使用更契合GitOps 版本化控制思想的Kustomize进行实践。

基于Gitlab CI、Kustomize、 Argo CD的GitOps实践

前置条件

Docker：使用镜像构建，打包实现基础设施的不变性；实现对不可变基础设施（Immutable Infrastructure）的支持。
Kubernetes：声明性容器编排，实现基础架构即代码（IaC）的支持。
Gitlab：Merge Request与Approval 作为所有基础架构更新的更改机制（MRs），Git Repository实现对源码版本控制支持，- - Gitlab CI作为对GitOps CI阶段的支持。
Kustomize：对Kubernetes资源对象的定制。
Argo CD：声明式GitOps CD支持。

GitOps流程

这里我们选择基于pull的工作模式去实现GitOps，具体流程如下所示：

项目结构

├── .backup
│   ├── ci-base
│   │   ├── Dockerfile
│   │   └── Makefile
│   └── gitlab
│       └── note.md
├── Dockerfile
├── .gitignore
├── .gitlab-ci.yml
├── go.mod
├── go.sum
├── .kubernetes
│   ├── base
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays
│       ├── production
│       │   ├── deployment_patch.yaml
│       │   ├── .env
│       │   └── kustomization.yaml
│       └── staging
│           ├── deployment_patch.yaml
│           ├── .env
│           └── kustomization.yaml
├── main.go
├── Makefile
└── README.md

这里我们为了更简单直观的展示流程，将应用仓库与环境配置仓库合并为一个，使用Golang、Gin简单实现了一个应用服务；其中.backup目录为基础CI镜像的manifests，.kubernetesm目录是基于Kustomize的manifests。

GitOps流程实践

应用Docker镜像构建

使用makefile定义了三个phony target ，配合Dockerfile实现Docker镜像构建、镜像远程仓库登录与上传镜像

.PHONY: build-release-image
build-release-image:
	docker build . \
		--no-cache \
		--force-rm \
		-t $(release-image) \
		-f Dockerfile

.PHONY: login-docker-registry
login-docker-registry:
	docker login -u $(registry-user) -p $(registry-password) $(registry-host)

.PHONY: push-release-image
push-release-image:
	docker push $(release-image)

FROM golang:1.18 as build

ENV GO111MODULE=on
ENV GOPROXY=https://goproxy.cn,direct

WORKDIR /go/release

ADD . .

RUN GOOS=linux CGO_ENABLED=0 GOARCH=amd64 go build -ldflags="-s -w" -installsuffix cgo -o app main.go

FROM scratch as prod

COPY --from=build /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
COPY --from=build /go/release/app /

CMD ["/app"]

Kustomize定制声明式Kubernetes资源对象

这里使用Kustomize Base/Overlay来管理Kubernetes多环境资源配置与使用Patches特性来进行迭代更新;

│   ├── base
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays
│       ├── production
│       │   ├── deployment_patch.yaml
│       │   ├── .env
│       │   └── kustomization.yaml
│       └── staging
│           ├── deployment_patch.yaml
│           ├── .env
│           └── kustomization.yaml

# base kustomization.yaml 定制应用的基础kubernetes资源
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
commonLabels:
  app: saken
namespace: default
resources:
- deployment.yaml
- service.yaml
# overlay kustomization.yaml 定制应用不同环境（staging/production/...）特定kubernetes资源属性，
# 基于configMapGenerator从不同环境的env文件生成不同资源的configMap
# 基于patchesStrategicMerge对不同环境的deployment-pod资源进行控制
# 基于Cross-Cutting对不同环境的namespace、name-prefix进行定制
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
namePrefix: production-
namespace: production
configMapGenerator:
- envs:
  - .env
  name: saken-config
patchesStrategicMerge:
- deployment_patch.yaml
images:
- name: my-registry.com/shovel/shovel-gitops
  newTag: 940638fd88cf1c030e3c02b21f2df738db8544f3

通过kustomize edit 命令，支持我们在CI阶段对基础配置仓库的kustomization文件进行命令式的编辑。

Gitlab CI流程

首先需要配置好CI流程所需要的环境变量，通过Gitlab settings->CI/CD->Variables进行配置如下变量

DOCKER_REGISTRY_HOST
DOCKER_REGISTRY_IMAGE
DOCKER_REGISTRY_PWD
DOCKER_REGISTRY_USER
GITLAB_EMAIL
GITLAB_ID_RSA
GITLAB_REMOTE_URL
GITLAB_USERNAME

如下所示，Gitlab-CI流程，定义了两个stage:

build-publish-image：Docker镜像构建并推送到远程仓库
update-kustomize：更新对应分支的kustomize overlay下kustomization文件，并推送到环境配置仓库

stages:
  - build-publish-image
  - update-kustomize

build-publish-image:
  image: ccr.ccs.tencentyun.com/shovel/ci-base:0.0.7
  stage: build-publish-image
  tags:
    - docker-runner
  only:
    - staging
    - main
  services:
    - name: docker:20-dind
  before_script:
    - make login-docker-registry registry-user=$DOCKER_REGISTRY_USER registry-password=$DOCKER_REGISTRY_PWD registry-host=$DOCKER_REGISTRY_HOST
  script:
    - make build-release-image release-image=$DOCKER_REGISTRY_HOST/$DOCKER_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - make push-release-image release-image=$DOCKER_REGISTRY_HOST/$DOCKER_REGISTRY_IMAGE:$CI_COMMIT_SHA

update-kustomize:
  image: ccr.ccs.tencentyun.com/shovel/ci-base:0.0.7
  stage: update-kustomize
  tags:
    - docker-runner
  only:
    - staging
    - main
  services:
    - name: docker:20-dind
  before_script:
    - eval $(ssh-agent -s)
    - echo "${GITLAB_ID_RSA}" | tr -d '\r' | ssh-add - > /dev/null
    - mkdir -p ~/.ssh
    - ssh-keyscan gitlab.com >> ~/.ssh/known_hosts
    - git remote set-url origin $GITLAB_REMOTE_URL
    - git config --global user.email $GITLAB_EMAIL
    - git config --global user.name $GITLAB_USERNAME
    - if [ "$CI_COMMIT_BRANCH" == "main" ]; then KUSTOMIZE_OVERLAY="production"; fi
    - if [ "$CI_COMMIT_BRANCH" == "staging" ]; then KUSTOMIZE_OVERLAY="staging"; fi
  script:
    - git checkout -B ${CI_COMMIT_BRANCH}
    - cd .kubernetes/overlays/${KUSTOMIZE_OVERLAY}
    - kustomize edit set image $DOCKER_REGISTRY_HOST/$DOCKER_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - kustomize build .
    - git commit -am '[skip ci] staging kustomize update'
    - git push origin ${CI_COMMIT_BRANCH}

进行到这里就完成了GitOps CI阶段的流程。

Argo CD流程

安装

由于是实验环境，我们这里直接使用轻量级（非 HA）版本进行安装。

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

安装完成后Deployment状态如下：

$kubectl get deploy --namespace argocd
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
argocd-redis                       1/1     1            1           1h
argocd-server                      1/1     1            1           1h
argocd-notifications-controller    1/1     1            1           1h
argocd-applicationset-controller   1/1     1            1           1h
argocd-dex-server                  1/1     1            1           1h
argocd-repo-server                 1/1     1            1           1h

web服务配置：可以通过配置Ingress路由映射到argocd-server443/80端口；或者简单通过port-forward实现。

获取admin password：第一次安装完成后，需要获取argocd命名空间下secret-argocd-initial-admin-secret获取到初始化的admin password进行登录；完成密码修改后即可删除该secret。

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

使用CLI进行操作：

# 安装CLI
VERSION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/')
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64
chmod +x /usr/local/bin/argocd

# 使用CLI登录
argocd login my.argocd.k8s.com
# argocd -h 查看argocd的一些基本操作帮助

配置Kubernetes Cluster

通过CLI添加本地kube config中的cluster到argo cd：

argocd cluster add production-cluster

创建Projects

Projects提供了应用程序的逻辑分组，一般为公司内部的多个团队、多个项目组做区分与提供资源限制。Projects对应的CRD是appprojects.argoproj.io ,对应的spec规范了资源限制条件，定义项目角色以提供应用程序RBAC，如下是默认default projects；

spec:
# 限制可以部署的Git源存储库
  sourceRepos:
  - '*'
  destinations:
  # 制应用程序可以部署的目标集群和命名空间
  - namespce: '*'
    # 如果应用程序清单于私有存储库中，则必须配置存储库凭据。Argo CD 支持 HTTPS 和 SSH Git 凭证。
    server: '*'
  # 限制可以部署或不可以部署的Kubernetes资源类型(Deployment,DaemonSets...)
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'

通过CLI配置Projects可以使用如下命令

argocd proj create --help
Create a project

Usage:
  argocd proj create PROJECT [flags]

通过Web UI配置Projects:通过在settings->projects下创建并编辑使用。

配置Repository

如果应用程序位于私有存储库中，则必须配置存储库凭据。Argo CD支持HTTPS/SSH Git凭证。通过CLI配置Repositories可以使用如下命令

argocd repo add --help
Add git repository connection parameters

Usage:
  argocd repo add REPOURL [flags]

Examples:
  # Add a Git repository via SSH using a private key for authentication, ignoring the server's host key:
  argocd repo add git@git.example.com:repos/repo --insecure-ignore-host-key --ssh-private-key-path ~/id_rsa

通过Web UI配置Repositories:通过在Settings/Repositories下CONNECT REPO进行连接测试与创建。

配置Application

接下来就可以创建Application，创建后即创建了对应的Application Kubernetes CRD资源applications.argoproj.io，Argo CD实现的GitOps Controller会自动将Application Git仓库里的配置清单部署到指定的Kubernetes集群上。

通过CLI配置Application如下所示：

 argocd app create --help
Create an application

Usage:
  argocd app create APPNAME [flags]

Examples:
        # Create a Kustomize app
        argocd app create kustomize-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path kustomize-guestbook --dest-namespace default --dest-server https://kubernetes.default.svc --kustomize-image gcr.io/heptio-images/ks-guestbook-demo:0.1

其中一些参数…

–repo 指定部署应用对应的Git仓库地址
–path 部署应用对应的 manifest 位置
–dest-server 目标 Kubernetes 集群地址

通过Web UI创建Application可以通过NEW APP进行创建，如下所示：

创建完成后，如果选择的同步策略为automated，Argo CD会自动同步项目的manifest部署到对应的集群中，也可以在WEB UI通过SYNC或者CLI通过argocd app sync shovel-gitops-production进步手动同步。

同步完成后可以在WEB UI上看到对应应用的同步状态，如下所示：

自动同步策略（SYNC POLICY）

Argo CD能够在检测到 Git 中所需的清单与集群中的实时状态之间存在差异时自动同步应用程序。自动同步是GitOps Pull模式的核心，好处是 CI/CD Pipeline 不再需要直接访问Argo CD API服务器来执行部署，可以通过在WEB UI的Application-SYNC POLICY中启用AUTOMATED或CLIargocd app set <APPNAME> --sync-policy automated 进行配置。

自动修剪（Automatic Pruning）

自动修剪作为一种安全机制，当Argo CD检测到资源不再存在于Git中的环境配置定义时，自动同步不会删除资源。可以通过手动同步（检查修剪）或者通过WEB UI的Application-SYNC POLICY中启用PRUNE RESOURCES或CLIargocd app set <APPNAME> --auto-prune进行配置。

自动修复（Automatic Self-Healing）

自动修复作为一种安全机制，当我们直接对集群进行操作导致实时集群的状态偏离Git中的环境配置定义的状态时，Argo CD会自动进行修复，保持集群的状态与Git manifest的一致性。可以通过WEB UI的Application-SYNC POLICY中启用SELF HEAL或CLIargocd app set <APPNAME> --self-heal进行配置。

更多Argo CD的配置可以参考：https://argo-cd.readthedocs.io/en/stable/user-guide/

项目源码

可以在Github上获取到此项目的源码：https://github.com/ChinaLHR/shovel-kustomize-argocd-gitops