基于Gitlab CI+Argo CD的Gitops實踐，你學會了嗎？

作者：崔亮的博客 2024-08-07 10:14:35

Kustomize強調聲明式管理，配置即代碼。它允許用戶通過層次化的覆蓋和變更來定制Kubernetes資源，而不需要使用模板。

項目簡介

項目說明

本項目構建了一個基于GitOps理念的完整CI/CD管道，旨在實現軟件開發與運維的高度自動化和一致性。通過GitLab、GitLab Runner（部署于Kubernetes）、Maven、Java、SonarQube、Harbor以及Argo CD等工具的緊密協作，實現代碼提交后自動進行編譯打包、單元測試、代碼掃描、構建鏡像、更新資源清單以及滾動更新、藍綠部署、金絲雀發布、多集群發布功能。

CI/CD管道流程

代碼提交：開發人員將Java代碼提交到GitLab倉庫，這一動作將觸發CI/CD流水線的啟動。
編譯與構建：GitLab Runner（基于Kubernetes）自動拉取最新的代碼，并使用Maven和Java工具鏈進行編譯和構建，生成可部署的制品（如Docker鏡像）。
單元測試與源碼掃描：執行單元測試以驗證代碼的功能性，并通過SonarQube進行靜態代碼分析，確保代碼質量和安全性。
制品上傳：將構建好的Docker鏡像推送到Harbor私有鏡像倉庫，作為后續部署的輸入。
GitOps部署：Argo CD監聽Git倉庫中的基礎設施和應用配置更改，自動將更新應用到Kubernetes集群中。這里，Git倉庫成為了基礎設施和應用狀態的唯一真實來源，所有的部署和更新都基于Git中的配置進行。支持滾動更新、藍綠部署、金絲雀發布、多集群多環境批量發布等多種部署方式。
持續監控與反饋：通過GitLab Runner、Argo CD等工具的exporter暴露的指標，團隊可以實時監控CI/CD流水線的狀態和部署結果，

Gitlab CD劣勢

agent權限過大：通常授予GitLab Runner集群管理員權限，無法有效通過更有限的權限來限制訪問。這意味著必須授予對一個相當簡單的功能的完全訪問權限，這可能會成為一種隱患。
部署功能單一：GitLab Runner的部署功能主要依賴kubectl工具執行，在Kubernetes集群的深入管理和部署方面，不如專門為此設計的工具如Argo CD全面，例如自動同步、健康檢查、回滾、多種發布方式。
審計與合規性：Argo CD提供了更加全面的審計日志，并以git作為唯一來源，除此之外，任何人都不可以對集群進行任何更改，也會被 Operator 還原為git倉庫期望狀態。

GitOps優勢

強化安全保障：GitOps模式下，部署無需Kubernetes或云平臺憑證，僅通過Git倉庫更新，減少暴露風險。Git的密碼學支持確保變更的真實性和來源，加固集群安全。
統一真實來源：Git作為唯一事實來源，存儲所有應用及基礎設施配置。利用Git的版控、歷史、審計和回滾等功能，簡化操作，無需額外工具。
提升開發效率：Git的熟悉度促進快速迭代，加快開發與部署速度，加速產品上市，同時提升系統穩定性和可靠性。
簡化合規審計：基礎設施變更如同軟件項目，通過Git管理，支持Pull Request和Code Review流程，確保合規與透明。

更多gitops介紹可參考文檔：GitOps-崔亮的博客 (cuiliangblog.cn)

Kustomize對比Helm

Kustomize強調聲明式管理，配置即代碼。它允許用戶通過層次化的覆蓋和變更來定制Kubernetes資源，而不需要使用模板。

Helm是一個包管理工具，類似于Linux的apt或yum，旨在簡化Kubernetes應用的部署和管理。Helm使用Charts（模板）來定義Kubernetes資源。以下是兩者的差異對比

特征	Helm	Kustomize
模板支持	√	×
覆蓋支持	×	√
打包支持	√	×
驗證hooks	√	×
回滾支持	√	×
原生 K8s 集成	×	√
聲明性	√	√
可見性和透明度	弱	強

相較而言Kustomize使用起來更簡單，雖然不支持打包與回滾，但我們可以依賴ArgoCD完成這部分功能，更契合GitOps 版本化控制思想。

更多Kustomize資料可參考文檔：kustomize多環境管理-崔亮的博客 (cuiliangblog.cn)

項目流程圖

圖片

準備工作

服務部署

需要部署Gitlab、SonarQube、Harbor、buildkitd、Gitlab Runner服務，具體可參考文檔：gitlab+k8s項目實戰-崔亮的博客 (cuiliangblog.cn)

部署完成后根據實際情況對Runner進行優化，具體可參考文檔：kubernetes類型runner優化-崔亮的博客 (cuiliangblog.cn)

部署ArgoCD服務，具體可參考文檔：ArgoCD部署-崔亮的博客 (cuiliangblog.cn)

部署ArgoCD Rollouts服務（可選，如果需要藍綠部署或金絲雀發布時需要部署），具體可參考文檔：ArgoCD Rollouts-崔亮的博客 (cuiliangblog.cn)

Runner鏡像構建

在Gitlab CI流程中，Runner主要的工作包括打包鏡像、使用kustomize修改images信息，因此需要構建一個名為gitlab-runner-agent的鏡像，dockerfile內容如下：

FROM alpine:latest
USER root
RUN apk update && \
    apk add --no-cache git && \
    rm -rf /var/cache/apk/*
COPY kustomize /usr/bin/kustomize
COPY nerdctl /usr/bin/nerdctl
COPY buildctl /usr/bin/buildctl
[root@tiaoban ~]# docker build -t harbor.local.com/cicd/gitlab-agent:v1.1 .

流水線鏡像構建

需要構建maven、sonar-scanner、jmeter鏡像，具體可參考文檔：gitlab+docker項目實戰-崔亮的博客 (cuiliangblog.cn)

項目代碼倉庫地址

gitee：https://gitee.com/cuiliang0302/spring_boot_demo

github：https://github.com/cuiliang0302/spring-boot-demo

gitlab項目權限配置

具體參考文檔：Jenkins+docker項目實戰-崔亮的博客 (cuiliangblog.cn)

配置郵件發送

具體可參考文檔：Gitlab與Email集成-崔亮的博客 (cuiliangblog.cn)

創建ci用戶并添加至devops組

創建一個名為gitlabci的用戶，用于提交kustomize更新后的資源清單文件。將gitlabci用戶角色指定為維護者。

圖片

Argo CD創建project與Repo

創建project，具體可參考文檔：ArgoCD project-崔亮的博客 (cuiliangblog.cn)，project配置如下：

圖片

創建repo，具體可參考文檔：ArgoCD快速體驗-崔亮的博客 (cuiliangblog.cn)，repo配置如下：

圖片

Gitlab CI流程

配置密鑰變量

進入項目——>設置——>CI/CD——>變量新建SONAR_QUBE_TOEKN、HARBOR_PASSWORD、CI_PASSWORD三個變量，取消保護變量，并勾選隱藏變量。變量配置信息內容如下：

圖片

模板庫資源更新

模板庫具體介紹可參考文檔：gitlab+linux項目實戰-崔亮的博客 (cuiliangblog.cn)，本文是在gitlab+k8s項目基礎上補充模板庫內容。完整模板庫鏈接：https://gitee.com/cuiliang0302/gitlabci-template

kustomize.yaml

該job的主要內容是通過kustomize工具，根據不同的分支提交事件，生成不同環境的資源清單，并將鏡像替換為最新的鏡像地址，并將資源清單文件提交至Gitlab倉庫。

# 更新kustomize
variables: # 全局變量
  KUSTOMIZE_OVERLAY: '' # kustomize環境目錄

.update-kustomize:
  stage: update-kustomize
  tags:
    - build
  only:
    - master
    - test
  before_script:
    - git remote set-url origin http://${CI_USER}:${CI_PASSWORD}@gitlab.local.com/devops/spring_boot_demo.git
    - git config --global user.email "${CI_EMAIL}"
    - git config --global user.name "${CI_USER}"
    - if [ "$CI_COMMIT_BRANCH" == "master" ]; then KUSTOMIZE_OVERLAY="prod"; fi
    - if [ "$CI_COMMIT_BRANCH" == "test" ]; then KUSTOMIZE_OVERLAY="test"; fi
  script:
    - git checkout -B ${CI_COMMIT_BRANCH}
    - cd cicd/kustomize/overlays/${KUSTOMIZE_OVERLAY}
    - kustomize edit set image $CONTAINER_NAME=$IMAGE_FULL_NAME
    - kustomize build .
    - git commit -am '[gitlab ci] kustomize update'
    - git push origin ${CI_COMMIT_BRANCH}

流水線配置

在項目根目錄下創建.gitlab-ci.yml文件，流水線內容如下：

include: # 引入模板庫公共文件
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/build.yml'
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/test.yml'
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/sonarqube.yml'
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/harbor.yml'
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/kustomize.yml'
variables: # 全局變量
  SONAR_QUBE_PATH: "$CI_PROJECT_DIR/cicd/sonar-project.properties" # sonarqube配置文件地址
  # 鏡像上傳
  HARBOR_REPO: devops # harbor倉庫名
  HARBOR_USER: admin # harbor用戶名
  DOCKERFILE_PATH: cicd/Dockerfile # Dockerfile文件路徑
  IMAGE_NAME: "$CI_PROJECT_NAME:$CI_COMMIT_BRANCH-$CI_COMMIT_SHORT_SHA" # 鏡像名稱
  # 更新yaml
  CI_USER: gitlabci # gitlab ci用戶名
  CI_EMAIL: gitlabci@qq.com # gitlab ci用戶郵箱
  CONTAINER_NAME: demo # k8s控制器container名稱

default:
  cache: # 全局緩存配置
    paths:
      - target/
      
workflow: # Gitlabci更新不觸發流水線
  rules:
    - if: '$GITLAB_USER_LOGIN == "gitlabci"'
      when: never
    - when: always
stages:
  - build
  - code_scan
  - product
  - update_yaml

mvn: # 編譯打包
  stage: build
  extends: .mvn_build
  image: harbor.local.com/cicd/maven:v3.9.3 # 構建階段使用指定的maven鏡像
  before_script:
    - ls -lh /home/gitlab-runner/cache/
  tags:
    - k8s
unit_test: # 單元測試
  stage: build
  extends: .mvn_unit_test
  image: harbor.local.com/cicd/maven:v3.9.3 # 構建階段使用指定的maven鏡像
  before_script:
    - ls -lh /home/gitlab-runner/cache/
  tags:
    - k8s
code_scan: # SonarQube代碼掃描
  stage: code_scan
  extends: .sonarqube
  image: harbor.local.com/cicd/sonar-scanner-cli:10 # 代碼掃描階段使用sonar-scanner-cli鏡像
  before_script:
    - ls target/
  tags:
    - k8s
  
product: # 打包上傳鏡像到harbor倉庫
  stage: product
  image: harbor.local.com/cicd/gitlab-agent:v1.1
  extends: .container_upload_harbor
  tags:
    - k8s

update_yaml: # 更新資源清單
  stage: update_yaml
  image: harbor.local.com/cicd/gitlab-agent:v1.1
  extends: .update_kustomize
  tags:
    - k8s

Gitlab CI結果驗證

查看update_yaml階段kustomize生成的資源清單文件，已完成image和namespace的更新。

圖片

查看kustomization.yaml文件，已替換并提交最新的鏡像地址。

圖片

同樣的操作，對test分支配置ci流水線，查看test分支kustomization.yaml文件信息。

圖片

至此 CI流程配置完成，CI流程只需要將集成后的文件提交至Gitlab倉庫即可，后續CD流程會根據Gitlab資源清單自動完成服務部署與狀態同步。

Argo CD流程(滾動更新)

創建APP

Argo CD支持通過web UI、CLI命令行工具、yaml文件創建APP，具體可參考文檔Directory APP創建與配置-崔亮的博客 (cuiliangblog.cn)。

此處以yaml文件創建Kustomize類型APP為例，具體可參考文檔：Kustomize App創建-崔亮的博客 (cuiliangblog.cn)，yaml文件內容如下：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-prod
  namespace: argocd
spec:
  destination:
    namespace: 'prod'
    server: 'https://kubernetes.default.svc'
  source:
    path: cicd/kustomize/overlays/prod
    repoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'
    targetRevision: 'master'
  sources: []
  project: devops
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-test
  namespace: argocd
spec:
  destination:
    namespace: 'test'
    server: 'https://kubernetes.default.svc'
  source:
    path: cicd/kustomize/overlays/test
    repoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'
    targetRevision: 'test'
  sources: []
  project: devops
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

此時查看Argo CD頁面，已根據master和test分支分別部署了兩套demo服務。

圖片

結果驗證

查看pod信息

[root@tiaoban ~]# kubectl get pod -n prod
NAME                   READY   STATUS    RESTARTS   AGE
demo-7dd977b57-5qdcx   1/1     Running   0          4m41s
[root@tiaoban ~]# kubectl get pod -n test
NAME                    READY   STATUS    RESTARTS   AGE
demo-6b67766cb5-c9fq9   1/1     Running   0          4m32s

修改host解析，分別訪問測試和生產域名驗證。

[root@tiaoban ~]# curl demo.prod.com
<h1>Hello SpringBoot</h1><p>Version:v1 Env:prod</p> 
[root@tiaoban ~]# curl demo.test.com
<h1>Hello SpringBoot</h1><p>Version:v1 Env:test</p>

修改springboot項目源碼，將version內容從v1升級為v2，等待gitlab CI和Argo CD執行完成。此時查看生產環境pod并訪問服務，已經通過deployment滾動更新到v2版本。

[root@tiaoban ~]# kubectl get pod -n prod
NAME                   READY   STATUS        RESTARTS   AGE
demo-65b44b4d8-58f67   1/1     Running       0          21s
demo-7dd977b57-5qdcx   1/1     Terminating   0          10m
[root@tiaoban ~]# curl demo.prod.com
<h1>Hello SpringBoot</h1><p>Version:v2 Env:prod</p>

Argo CD流程(藍綠部署)

Argo CD藍綠部署和金絲雀發布主要依賴Rollouts組件實現，具體內容可參考文檔：ArgoCD Rollouts-崔亮的博客 (cuiliangblog.cn)。

藍綠部署具體內容可參考文檔：藍綠部署-崔亮的博客 (cuiliangblog.cn)。

模板庫資源配置

rollout.yml

該job的主要內容是將鏡像替換為最新的鏡像地址，并將資源清單文件提交至Gitlab倉庫。

# 更新rollout資源鏡像
.update_rollout:
  stage: update_rollout
  tags:
    - build
  only:
    - master
  before_script:
    - git remote set-url origin http://${CI_USER}:${CI_PASSWORD}@gitlab.local.com/devops/spring_boot_demo.git
    - git config --global user.email "${CI_EMAIL}"
    - git config --global user.name "${CI_USER}"
  script:
    - git checkout -B master
    - sed -i "s|\(image:\s*\).*|\1${IMAGE_FULL_NAME}|" ${ROLLOUT_PATH}
    - git commit -am '[gitlab ci] rollout update'
    - git push origin ${CI_COMMIT_BRANCH}
  after_script:
    - cat ${ROLLOUT_PATH}

流水線配置

在流水線update_yaml階段使用上面定義的更新rollout資源job。

include: # 引入模板庫公共文件
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/build.yml'
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/test.yml'
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/sonarqube.yml'
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/harbor.yml'
  - project: 'devops/gitlabci-template'
    ref: master
    file: 'jobs/rollout.yml'

variables: # 全局變量
  SONAR_QUBE_PATH: "$CI_PROJECT_DIR/cicd/sonar-project.properties" # sonarqube配置文件地址
  # 鏡像上傳
  HARBOR_REPO: devops # harbor倉庫名
  HARBOR_USER: admin # harbor用戶名
  DOCKERFILE_PATH: cicd/Dockerfile # Dockerfile文件路徑
  IMAGE_NAME: "$CI_PROJECT_NAME:$CI_COMMIT_BRANCH-$CI_COMMIT_SHORT_SHA" # 鏡像名稱
  # 更新yaml
  CI_USER: gitlabci # gitlab ci用戶名
  CI_EMAIL: gitlabci@qq.com # gitlab ci用戶郵箱
  ROLLOUT_PATH: cicd/argo-cd/bluegreen/rollout.yaml # rollout文件路徑

workflow: # Gitlabci更新不觸發流水線
  rules:
    - if: '$GITLAB_USER_LOGIN == "gitlabci"'
      when: never
    - when: always
    
default:
  cache: # 全局緩存配置
    paths:
      - target/

stages:
  - build
  - code_scan
  - product
  - update_yaml

mvn: # 編譯打包
  stage: build
  extends: .mvn_build
  image: harbor.local.com/cicd/maven:v3.9.3 # 構建階段使用指定的maven鏡像
  tags:
    - k8s
  
unit_test: # 單元測試
  stage: build
  extends: .mvn_unit_test
  image: harbor.local.com/cicd/maven:v3.9.3 # 構建階段使用指定的maven鏡像
  tags:
    - k8s

code_scan: # SonarQube代碼掃描
  stage: code_scan
  extends: .sonarqube
  image: harbor.local.com/cicd/sonar-scanner-cli:10 # 代碼掃描階段使用sonar-scanner-cli鏡像
  before_script:
    - ls target/
  tags:
    - k8s
  
product: # 打包上傳鏡像到harbor倉庫
  stage: product
  image: harbor.local.com/cicd/gitlab-agent:v1.1
  extends: .container_upload_harbor
  tags:
    - k8s

update_yaml: # 更新資源清單
  stage: update_yaml
  image: harbor.local.com/cicd/gitlab-agent:v1.1
  extends: .update_rollout
  tags:
    - k8s

Gitlab CI結果驗證

查看update_yaml任務信息，已替換為最近的鏡像地址。查看倉庫rollout.yaml文件，已經替換為最新的鏡像地址。

Argo CD創建APP

接下來創建ArgoCD APP，資源清單內容如下：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: blue-green
  namespace: argocd
spec:
  destination:
    namespace: default
    server: 'https://kubernetes.default.svc'
  source:
    path: cicd/argo-cd/bluegreen
    repoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'
    targetRevision: master
  sources: []
  project: devops
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

此時查看Argo CD頁面，已經成功部署了名為blue-green的應用。

藍綠部署驗證

添加hosts域名解析后訪問，由于剛發布第一個版本，因此正式環境和測試環境都是v1版本的鏡像。

[root@tiaoban ~]# kubectl get pod
NAME                                READY   STATUS    RESTARTS       AGE
bluegreen-rollout-7679f8576-bj9lw   1/1     Running   0              4s
bluegreen-rollout-7679f8576-lrt5r   1/1     Running   0              4s
[root@tiaoban ~]# curl demo.prod.com
<h1>Hello SpringBoot</h1><p>Version:v2 Env:prod</p>
[root@tiaoban ~]# curl demo.test.com
<h1>Hello SpringBoot</h1><p>Version:v1 Env:prod</p>

修改springboot項目源碼，將version內容從v2升級為v3，等待gitlab CI和Argo CD執行完成。

圖片

此時訪問應用生產和測試域名，分別返回不同的版本信息。

[root@tiaoban ~]# kubectl get pod
NAME                                 READY   STATUS    RESTARTS       AGE
bluegreen-rollout-6f76ccc55c-gbgsc   1/1     Running   0              7s
bluegreen-rollout-7679f8576-bj9lw    1/1     Running   0              3m49s
bluegreen-rollout-7679f8576-lrt5r    1/1     Running   0              3m49s
[root@tiaoban ~]# curl demo.prod.com
<h1>Hello SpringBoot</h1><p>Version:v2 Env:prod</p>
[root@tiaoban ~]# curl demo.test.com
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>

發布新版本后，此時就需要測試人員訪問測試域名驗證系統功能是否正常，驗證無誤后，將服務切換至生產域名。

[root@tiaoban ~]# kubectl argo rollouts promote bluegreen-rollout
rollout 'bluegreen-rollout' promoted

此時訪問web頁面，生產和測試環境均返回v3版本信息。

[root@tiaoban ~]# kubectl get pod
NAME                                 READY   STATUS    RESTARTS       AGE
bluegreen-rollout-6f76ccc55c-gbgsc   1/1     Running   0              83s
bluegreen-rollout-6f76ccc55c-hcflg   1/1     Running   0              19s
bluegreen-rollout-7679f8576-bj9lw    1/1     Running   0              5m5s
bluegreen-rollout-7679f8576-lrt5r    1/1     Running   0              5m5s
[root@tiaoban ~]# curl demo.prod.com
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
[root@tiaoban ~]# curl demo.test.com
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>

至此整個藍綠發布流程完成。

Argo CD流程(金絲雀發布)

金絲雀發布具體內容可參考文檔：金絲雀發布-崔亮的博客 (cuiliangblog.cn)，此處不再贅述。

模板庫與流水線配置

模板庫與流水線配置與上面的藍綠部署一致，區別在于流水線中ROLLOUT_PATH指定為金絲雀資源路徑

variables: # 全局變量
  ROLLOUT_PATH: cicd/argo-cd/canary/rollout.yaml # rollout文件路徑

Gitlab CI結果驗證

查看流水線update_yaml階段日志，已經替換為最新的鏡像地址。

Argo CD創建APP

接下來創建ArgoCD APP，資源清單內容如下：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: canary
  namespace: argocd
spec:
  destination:
    namespace: default
    server: 'https://kubernetes.default.svc'
  source:
    path: cicd/argo-cd/canary
    repoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'
    targetRevision: master
  sources: []
  project: devops
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

此時查看Argo CD頁面，已經成功部署了名為canary的應用。

金絲雀發布驗證

添加hosts域名解析后訪問，由于剛發布第一個版本，因此所有流量都調度到v3版本的服務。

[root@tiaoban ~]# kubectl get pod
NAME                              READY   STATUS    RESTARTS        AGE
canary-rollout-7d77478fd7-4vdzn   1/1     Running   0               115s
canary-rollout-7d77478fd7-5rbmp   1/1     Running   0               115s
canary-rollout-7d77478fd7-6pm62   1/1     Running   0               115s
canary-rollout-7d77478fd7-98xmk   1/1     Running   0               115s
canary-rollout-7d77478fd7-jv6zk   1/1     Running   0               115s
canary-rollout-7d77478fd7-l22zh   1/1     Running   0               115s
canary-rollout-7d77478fd7-lhxm8   1/1     Running   0               115s
canary-rollout-7d77478fd7-tkfrb   1/1     Running   0               115s
canary-rollout-7d77478fd7-zcgwq   1/1     Running   0               115s
canary-rollout-7d77478fd7-zw4w2   1/1     Running   0               115s
[root@tiaoban ~]# for i in {1..10}; do curl canary.demo.com; done
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>

修改springboot項目源碼，將version內容從v3升級為v4，等待gitlab CI和Argo CD執行完成。查看Rollouts狀態，新增了canary-rollout-6c764844bd，運行v4版本的鏡像。

[root@tiaoban ~]#  kubectl argo rollouts get rollout canary-rollout
Name:            canary-rollout
Namespace:       default
Status:          ? Paused
Message:         CanaryPauseStep
Strategy:        Canary
  Step:          1/7
  SetWeight:     10
  ActualWeight:  10
Images:          harbor.local.com/devops/spring_boot_demo:master-3bccf809 (canary)
                 harbor.local.com/devops/spring_boot_demo:master-e58822da (stable)
Replicas:
  Desired:       10
  Current:       11
  Updated:       1
  Ready:         11
  Available:     11

NAME                                        KIND        STATUS     AGE  INFO
? canary-rollout                            Rollout     ? Paused   12m  
├──# revision:2                                                         
│  └──? canary-rollout-6c764844bd           ReplicaSet  ? Healthy  24s  canary
│     └──□ canary-rollout-6c764844bd-dzc4t  Pod         ? Running  24s  ready:1/1
└──# revision:1                                                         
   └──? canary-rollout-7d77478fd7           ReplicaSet  ? Healthy  12m  stable
      ├──□ canary-rollout-7d77478fd7-4vdzn  Pod         ? Running  12m  ready:1/1
      ├──□ canary-rollout-7d77478fd7-5rbmp  Pod         ? Running  12m  ready:1/1
      ├──□ canary-rollout-7d77478fd7-6pm62  Pod         ? Running  12m  ready:1/1
      ├──□ canary-rollout-7d77478fd7-98xmk  Pod         ? Running  12m  ready:1/1
      ├──□ canary-rollout-7d77478fd7-jv6zk  Pod         ? Running  12m  ready:1/1
      ├──□ canary-rollout-7d77478fd7-l22zh  Pod         ? Running  12m  ready:1/1
      ├──□ canary-rollout-7d77478fd7-lhxm8  Pod         ? Running  12m  ready:1/1
      ├──□ canary-rollout-7d77478fd7-tkfrb  Pod         ? Running  12m  ready:1/1
      ├──□ canary-rollout-7d77478fd7-zcgwq  Pod         ? Running  12m  ready:1/1
      └──□ canary-rollout-7d77478fd7-zw4w2  Pod         ? Running  12m  ready:1/1
[root@tiaoban ~]# kubectl get pod
NAME                              READY   STATUS    RESTARTS        AGE
canary-rollout-6c764844bd-dzc4t   1/1     Running   0               28s
canary-rollout-7d77478fd7-4vdzn   1/1     Running   0               12m
canary-rollout-7d77478fd7-5rbmp   1/1     Running   0               12m
canary-rollout-7d77478fd7-6pm62   1/1     Running   0               12m
canary-rollout-7d77478fd7-98xmk   1/1     Running   0               12m
canary-rollout-7d77478fd7-jv6zk   1/1     Running   0               12m
canary-rollout-7d77478fd7-l22zh   1/1     Running   0               12m
canary-rollout-7d77478fd7-lhxm8   1/1     Running   0               12m
canary-rollout-7d77478fd7-tkfrb   1/1     Running   0               12m
canary-rollout-7d77478fd7-zcgwq   1/1     Running   0               12m
canary-rollout-7d77478fd7-zw4w2   1/1     Running   0               12m
rockylinux                        1/1     Running   21 (140m ago)   52d

循環請求訪問驗證,可以看到，在前5分鐘只有10%的流量請求到了v4版本的服務中。

[root@tiaoban ~]# for i in {1..10}; do curl canary.demo.com; done
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v4 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>
<h1>Hello SpringBoot</h1><p>Version:v3 Env:prod</p>

持續觀察流量v4的占比會逐步增加直到最后達到100%。

Argo CD流程(多集群發布)

我們在實際工作中會存在多個生產、測試集群，通常會將test分支代碼發布至測試環境，master分支代碼發布至生產環境，Argo同樣支持這種多集群模式發布，且配置起來更為簡單。

多集群發布配置具體可參考文檔：多集群應用部署-崔亮的博客 (cuiliangblog.cn)

添加集群

假設現在有兩套集群，已經在k8s-ha集群部署了gitlab和Argocd，現在需要添加k8s-test集群。在添加集群前，先配置config上下文，具體內容可參考文檔：kubectl多集群管理-崔亮的博客 (cuiliangblog.cn)

[root@tiaoban .kube]# kubectl config get-contexts
CURRENT   NAME                  CLUSTER    AUTHINFO     NAMESPACE
*         ha-admin@k8s-ha       k8s-ha     ha-admin     
          test-admin@k8s-test   k8s-test   test-admin 
[root@tiaoban .kube]# kubectl get node
NAME      STATUS   ROLES           AGE    VERSION
master1   Ready    control-plane   285d   v1.27.6
master2   Ready    control-plane   285d   v1.27.6
master3   Ready    control-plane   285d   v1.27.6
work1     Ready    <none>          285d   v1.27.6
work2     Ready    <none>          285d   v1.27.6
work3     Ready    <none>          285d   v1.27.6
[root@tiaoban .kube]# kubectl config use-context test-admin@k8s-test
Switched to context "test-admin@k8s-test".
[root@tiaoban .kube]# kubectl get node
NAME         STATUS   ROLES                  AGE   VERSION
k8s-master   Ready    control-plane,master   21h   v1.23.17
k8s-work1    Ready    <none>                 20h   v1.23.17
k8s-work2    Ready    <none>                 20h   v1.23.17

ArgoCD添加集群。

[root@tiaoban ~]# argocd login argocd.local.com
WARNING: server certificate had error: tls: failed to verify certificate: x509: certificate is valid for de4d64dda4cc17aa063ca24baa2abc22.6d1744aa3a6f00c3129e20bc6d196dd0.traefik.default, not argocd.local.com. Proceed insecurely (y/n)? y
WARN[0002] Failed to invoke grpc call. Use flag --grpc-web in grpc calls. To avoid this warning message, use flag --grpc-web. 
Username: admin
Password: 
'admin:login' logged in successfully
Context 'argocd.local.com' updated
[root@tiaoban ~]# argocd cluster add test-admin@k8s-test --kubecnotallow=/root/.kube/config
WARNING: This will create a service account `argocd-manager` on the cluster referenced by context `test-admin@k8s-test` with full cluster level privileges. Do you want to continue [y/N]? y
INFO[0003] ServiceAccount "argocd-manager" created in namespace "kube-system" 
INFO[0003] ClusterRole "argocd-manager-role" created    
INFO[0003] ClusterRoleBinding "argocd-manager-role-binding" created 
WARN[0004] Failed to invoke grpc call. Use flag --grpc-web in grpc calls. To avoid this warning message, use flag --grpc-web. 
Cluster 'https://192.168.10.10:6443' added

查看集群狀態信息如下：

圖片

更新Project

更新devops項目權限配置，允許對k8s-test集群進行操作。

圖片

創建應用

創建Argo CD app，按照不同的分支同時發布至不同的k8s集群中。

# master分支代碼發布至生產環境
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-prod
  namespace: argocd
spec:
  destination:
    namespace: 'prod'
    server: 'https://kubernetes.default.svc'
  source:
    path: cicd/kustomize/overlays/prod
    repoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'
    targetRevision: 'master'
  sources: []
  project: devops
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
---
# test分支代碼發布至測試環境
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-test
  namespace: argocd
spec:
  destination:
    namespace: 'test'
    server: 'https://192.168.10.10:6443'
  source:
    path: cicd/kustomize/overlays/test
    repoURL: 'http://gitlab.local.com/devops/spring_boot_demo.git'
    targetRevision: 'test'
  sources: []
  project: devops
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

多集群發布驗證

ArgoCD會自動進行發布，查看發布信息如下：

圖片

此時訪問test集群查看資源，已經成功創建myapp2資源。

[root@tiaoban ~]# kubectl config use-context test-admin@k8s-test
Switched to context "test-admin@k8s-test".
[root@tiaoban ~]# kubectl get pod -n test
NAME                    READY   STATUS    RESTARTS   AGE
demo-6c86b77bd6-dpf4m   1/1     Running   0          3m3s
[root@tiaoban ~]# kubectl config use-context ha-admin@k8s-ha
Switched to context "ha-admin@k8s-ha".
[root@tiaoban ~]# kubectl get pod -n prod
NAME                    READY   STATUS    RESTARTS   AGE
demo-77b7f4576b-vlwtc   1/1     Running   0          3m

責任編輯：武曉燕來源：崔亮的博客

成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

基于Gitlab CI+Argo CD的Gitops實踐，你學會了嗎？

項目簡介

項目說明

CI/CD管道流程

Gitlab CD劣勢

GitOps優勢

Kustomize對比Helm

項目流程圖

準備工作

服務部署

Runner鏡像構建

流水線鏡像構建

項目代碼倉庫地址

gitlab項目權限配置

配置郵件發送

創建ci用戶并添加至devops組

Argo CD創建project與Repo

Gitlab CI流程

配置密鑰變量

模板庫資源更新

流水線配置

Gitlab CI結果驗證

Argo CD流程(滾動更新)

創建APP

結果驗證

查看pod信息

Argo CD流程(藍綠部署)

模板庫資源配置

流水線配置

Gitlab CI結果驗證

Argo CD創建APP

藍綠部署驗證

Argo CD流程(金絲雀發布)

模板庫與流水線配置

Gitlab CI結果驗證

Argo CD創建APP

金絲雀發布驗證

Argo CD流程(多集群發布)

添加集群

更新Project

創建應用

多集群發布驗證