Argo CD 是用于 Kubernetes 的声明式 GitOps 持续交付工具。
什么是 GitOps？
文章开始我们先了解一下GitOps
GitOps 允许由 Git 控制整个代码交付过程，包括基础设施和应用程序定义为代码以及自动更新和回滚。简单来说就是在Git存储库中存储和管理部署的应用。
ArgoCD 是一个 GitOps 代理，它将 Git 存储库中描述的应用程序的状态与 Kubernetes 集群中的部署同步。
在上图示例中，我们讲学习如何使用Tekton Pipeline、Argo CD、Helm来构建GitOps工作流。使用以下组件：
- Tekton Pipeline
- 使用Helm Chart的Kubernetes模板
- 使用Argo CD进行持续部署
先决条件
Argo CD是用在Kubernetes上的工具。所以在这之前，我们需要启动一个Kubernetes集群。
安装Argo CD
我们可通过helm来进行安装，也可通过官方提供的yaml文件来进行安装，两种方式都在下面贴出
$ kubectl create namespace argocd
$ helm repo add argo https://argoproj.github.io/argo-helm
$ kubectl create namespace argocd
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
这将创建一个新的命名空间 ，argocdArgo CD 服务和应用程序资源将在其中存在。
这里需要注意一个地方，安装清单中ClusterRoleBinding绑定argocd命名空间得资源。如果将argocd 安装到别的命名空间下需注意修改。如遇到kubernetes cluster访问不成功，权限问题，那就是这的情况。
访问服务器UI
1>端口转发
Kubectl 端口转发也可用于连接到 API 服务器而不暴露服务。
kubectl port-forward svc/argocd-server -n argocd 8080:443
然后可以使用 https://localhost:8080 访问 API 服务器
2>路由转发
按照ingress 文档了解如何使用 ingress 配置 Argo CD。
ArgoCD CLI
创建CD部署有两种选择，一种是通过CLI，一种是通过UI。我们这里使用CLI,因为它更具有声明性
CLI安装 https://argoproj.github.io/argo-cd/cli_installation/
该admin帐户的初始密码是自动生成的，并以明文形式存储 在您的 Argo CD 安装命名空间中命名password的密码字段中。argocd-initial-admin-secret您可以使用以下方法简单地检索此密码kubectl：
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
使用上面的用户名密码，登录Argo CD，也可通过webUI账号密码登录访问。
[root@master ~]# argocd login 10.10.10.1:31005 --insecure --username admin --grpc-web
Password:
'admin:login' logged in successfully
Context '10.10.10.1:31005' updated
- –insecure 跳过服务器证书和域验证
- –grpc-web 启用grpc-web协议
Create Application
使用 CLI 创建 Argo 应用程序
argocd app create web-service \
--repo http://10.10.10.1:31002/ycloud/project.git \
--path webservice \
--dest-server https://kubernetes.default.svc \
--dest-namespace webservice
我们创建了指向源repo和path清单文件存储的位置，定义了在集群部署应用程序的位置。
ArgoCD 还支持各种类型的模板工具，例如 Kustomize 和 Helm。这里我们使用 Helm，它定义了模板或 K8s 资源的集合。使用可配置的值文件可以灵活地表示不同类型的应用程序或部署阶段。
Helm chaim
为了进行设置，我们通过运行以下命令创建名为webservice的helm chart: helm create webservice该项目的结构如下
[root@sztcyl-177-9-244 ~]# cd project/webservice/
[root@sztcyl-177-9-244 webservice]# ls
charts Chart.yaml templates values.yaml
[root@sztcyl-177-9-244 webservice]#
如果对Helm不熟悉，可通过官网学习了解Helm。
查看**Chart.yaml**文件，它描述了图表信息以及应用程序版本。此**appVersion**参数是推送新版本时 CI 将更新的位置。接下来，**values.yaml**文件是要传递给模板的声明变量。例如，您可以看到**deployment.yaml** 模板如何使用来自repository和appVersion定义容器图像的值。
[root@sztcyl-177-9-244 webservice]# cat values.yaml
# Default values for webservice.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
image:
repository: hub.17usoft.com/gstrain/web-service
pullPolicy: IfNotPresent
# Overrides the image tag whose default is the chart appVersion.
tag: "master-e428d31"
imagePullSecrets: [{ name: first-registry}]
nameOverride: "webservice"
fullnameOverride: "webservice"
serviceAccount:
# Specifies whether a service account should be created
create: true
# Annotations to add to the service account
annotations: {}
# The name of the service account to use.
# If not set and create is true, a name is generated using the fullname template
name: ""
podAnnotations: {}
podSecurityContext: {}
# fsGroup: 2000
securityContext: {}
# capabilities:
# drop:
# - ALL
# readOnlyRootFilesystem: true
# runAsNonRoot: true
# runAsUser: 1000
service:
type: NodePort
port: 9090
ingress:
enabled: false
className: ""
annotations: {}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
hosts:
- host: chart-example.local
paths:
- path: /
pathType: ImplementationSpecific
tls: []
# - secretName: chart-example-tls
# hosts:
# - chart-example.local
resources: {}
# We usually recommend not to specify default resources and to leave this as a conscious
# choice for the user. This also increases chances charts run on environments with little
# resources, such as Minikube. If you do want to specify resources, uncomment the following
# lines, adjust them as necessary, and remove the curly braces after 'resources:'.
limits:
cpu: 100m
memory: 128Mi
requests:
cpu: 100m
memory: 128Mi
autoscaling:
enabled: false
minReplicas: 1
maxReplicas: 100
targetCPUUtilizationPercentage: 80
# targetMemoryUtilizationPercentage: 80
nodeSelector: {}
tolerations: []
affinity: {}
You have new mail in /var/spool/mail/root
使用Helm创建APP，参数会参照value.yaml文件补齐，然后create
持续交付
上篇文章tekton构建CI/CD流水线(二)新增了一个名为Modify listing的task，它的作用就是帮我们去修改清单内容，修改成功之后Argo CD检测sync进行同步发布操作。上篇我们使用的是yaml清单来对我们的应用进行部署，修改的是containers[0].image部分，现在我们是用helm进行部署，和之前类似，只不过只用修改values.yaml中的镜像tag即可。
对Helm不太熟悉的同学可以了解下这片文章
task内容修改如下：
- name: IMAGE_URL_TAG
type: string
description: |
The latest build image tag
default: "$(tasks.fetch-repo.results.short-branch-name)-$(tasks.fetch-repo.results.commit)"
- name: GIT_SCRIPT
description: The git script to run.
type: string
default: |
ls -l
echo $subdirectory
cd $subdirectory
git clone --branch master --depth 1 http://ycloud:zz52130++@10.10.10.1:31002/ycloud/project.git manifests
cd manifests/$subdirectory
ls -la
echo old value:
cat values.yaml | yq r - 'image.tag'
echo replacing with new value:
yq w -i values.yaml 'image.tag' "$IMAGE_URL_TAG"
echo verifying new value :
yq r values.yaml image.tag
if ! git diff-index --quiet HEAD --; then
git status
git add .
git commit -m "auto updated yaml by tekton pipeline"
git push
else
echo "no changes, git repository is up to date"
fi
结合前面tekton的内容，我们的发布流程到这里就结束了，了解GitOps， GitOps 也是 CI/CD 的扩展，而 CI/CD 是 GitOps 的核心。为什么要用也呢？我想大家最早都听过DevOps，和GitOps都是一种理念，如果没有 CI/CD 自动化工具和流程，GitOps 就毫无意义。
参考文献
https://argo-cd.readthedocs.io/en/stable/
扫一扫
2135
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
