了解了GitOps 的概念以及 CI/CD 流水线的架构，完结了构建 GitOps 风格的 CI/CD 流水线的前两部分，恭喜开发者们！咱们一同在 GitOps 最佳实践的道路上现已完结了多半。接下来，咱们一同看看构建 CI/CD 流水线最佳实践的后两个部分：

1. 经过 IaC 布置云基础架构
2. 在 Amazon EKS 集群上布置 Flux CD
3. 利用 Flux CD 布置 GitOps 作业流
4. 利用 GitOps 作业流完结依据镜像的主动布置

利用 Flux CD 布置 GitOps 作业流

对于 GitOps CI/CD 实践下的 EKS 和运转其上的作业负载来说，EKS 集群和作业负载的装备修正和状况改变是源自于 Git 中代码的改变（经过 git push 或许 pull request 触发并完结终究交付，GitOps 引荐运用 pull request），而不再是传统的 CI/CD 流水线中由 CI 引擎所发起的运用 kubectl create/apply 或 helm install/upgrade 直接操作集群完结终究交付。因而咱们经过 GitOps 的方法，去简化传统的 CI/CD 流水线，构建更为高效和简洁的 GitOps 方法的 CI/CD 流水线。

最佳实践

Flux 周期性拉取代码库中的运用装备和布置文件，比较集群当前的运用负载运转状况是否和代码库中的文件所描绘的期望共同，当发现二者有差异时，Flux 会主动将差异同步至 EKS 集群，确保作业负载一直按照期望状况运转。

咱们经过具体的实践演示，来展现一个具体运用 sock shop 如安在以 GitOps 方法构建的 CI/CD 流水线上完结运用的继续集成和继续交付。

1 Sock Shop 运用介绍

咱们运用 sock shop 的在线商店面向用户的部分作为案例的举例运用。它旨在协助演示和测验微服务和云原生技能。它运用 Spring Boot、Go kit 和 Node 构建，并打包在 Docker 容器中。作为”微服务规范演示”，将供给：

• 微服务最佳实践 (包括错误示例)
• 供给跨渠道布置才能
• 展现继续集成/布置的优势
• 展现 DevOps 与微服务的互补
• 为各种编排渠道供给“实在”的可测验运用程序

参考架构如下：

2 装备办理东西 Kustomize

除了 GitOps 作业流的建立，咱们还需求了解 K8s 中运用的办理方法，传统的依据资源清单（yaml）的办理随着体系杂乱度和环境杂乱度的提升越来约难以保护。多个事务运用，多个环境（开发，测验，预发，出产），很多的 yaml 资源清单需求保护和办理。尽管 Helm 能够解决部分痛点，比方：统一办理涣散的资源文件，运用分发、晋级、回滚等。可是 Helm 面临不同环境之间细小的差异处理比较杂乱，需求学习杂乱的 DSL（模板语法）语法，上手本钱较高。所以依据声明式的装备办理东西 Kustomize 应运而生。Kustomize 协助团队办理不同环境或不同团队的运用的很多 Kubernetes YAML 资源，协助团队以轻量化的方法办理不同环境的细小差异，使得资源装备能够复用，削减 copy and change 的作业量，一同也很大程度上降低了装备出错率。整个运用装备过程不需求额外学习模板语法。

Kustomize 经过以下几种方法解决了上述问题：

• kustomize 经过 Base & Overlays 方法方法保护不同环境的运用装备
• kustomize 运用 patch 方法复用 Base 装备，并在 Overlay 描绘与 Base 运用装备的差异部分来完结资源复用
• kustomize 办理的都是 Kubernetes 原生 YAML 文件，不需求学习额外的 DSL 语法

  

  依据官网的描绘：

kustomize 成为 kubernetes 原生的装备办理，以无模板方法来定制运用的装备。

kustomize 运用 k8s 原生概念协助创建并复用资源装备(YAML)，答运用户以一个运用描绘文件 （YAML 文件）为基础（Base YAML），然后经过 Overlay 的方法生成终究布置运用所需的描绘文件。

3 微服务多集群装备

了解装备办理东西 Kustomize 后，咱们经过 Kustomization（base、overlays）完结多集群布置改造。

在微服务项目中创建两个目录，base 目录寄存完好的资源装备 (YAML) 文件，overlays 目录中寄存不同环境或许集群的差异装备：

cp deploy/kubernetes/complete-demo.yaml deploy/kubernetes/base/complete-demo.yaml

左滑检查更多

然后经过 kustomization.yaml 引证该文件：

# deploy/kubernetes/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ./complete-demo.yaml

左滑检查更多

对于开发环境 development，如果有差异化的需求，比方服务端口、副本数等需求修正，只需求把差异装备到 overlays/development/kustomization.yaml 文件，而不用仿制并修正原有的 complete-demo.yaml。

最佳实践

flux 在服务布置时会主动依据环境把 base 装备与 overlays 装备合并。咱们引荐在 overlays 下一同界说 development，test，prod 多套环境的差异装备。对多环境集群的支持并没有选用多库房/多分支的战略，而是用的运用不同途径来办理不同的集群。 这也是 Flux 引荐的战略，能够削减代码保护和合并的难度。

4 利用 GitOps 作业流布置微服务

完结微服务的多集群支持后，咱们需求让 flux 感知到微服务的装备改变，所以需求把微服务库房（microservices-repo）所在的 CodeCommit 地址注册到 flux 的库房（flux-repo）中。

增加微服务库房地址

咱们回到 flux-repo 项目，在运用层 /apps 目录下：

增加 CodeCommit 凭据

找到 “2.3.2 预备 Amazon CodeCommit 凭据” 的账号和暗码。履行命令，请先将数据的值转化为 base64 编码：

开始布置

由于咱们把微服务的 Git 地址增加到了 flux 的装备库房，所以 flux 会主动扫描微服务的装备改变。当咱们提交代码后，flux 发现集群中没有布置微服务，与 Git 库房界说不共同，所以 flux 会主动把微服务布置到集群。

提交代码后，履行命令 flux get kustomizations -watch，等待 flux 更新，当所有 kustomizations 的 READY 状况都为 True 时说明布置完结：

查询命名空间 sock-shop 的 pod 和 service，显现如下：

5 小结

在这儿咱们具体介绍了一个微服务事务运用：sock shop 在线商店，而且完结了该服务的多集群装备。咱们还依据 Flux 建立了规范的 GitOps 作业流，当装备文件发生改变时，会主动把改变同步到目标集群，以此完结了微服务布置到 EKS 集群。一同，咱们介绍了一个有用的 K8s 装备办理东西 Kustomize，咱们运用它的特性完结了运用的资源文件办理：

• 微服务事务运用介绍
• 装备办理东西 Kustomize 介绍，并经过 Kustomize（base、overlays）完结微服务多集群布置改造
• 建立 GitOps 作业流，并布置微服务

利用 GitOps 作业流完结依据镜像的主动布置

咱们挑选 sock shop 的其间一个前端微服务 front-end 作为例子，演示 GitOps 作业流完结的代码改变-镜像构建-自界说发布的具体过程。

1 界说 CodePipeline 的 CI 流程

front-end 是一个 Node.js 的纯前端服务，支持 Docker 镜像打包。在前端项意图源码中增加 buildspec.yml 文件，来界说 CodePipeline 中履行的 CI 流程：

version: 0.2
phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws --version
      - AWS_ACCOUNT_ID=`echo $REPOSITORY_URI|cut -d"." -f1`
      - AWS_DEFAULT_REGION=`echo $REPOSITORY_URI|cut -d"." -f4`
      - echo $AWS_ACCOUNT_ID $AWS_DEFAULT_REGION
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_HOST
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=main-$COMMIT_HASH-$CODEBUILD_BUILD_NUMBER
      - echo $IMAGE_TAG
  build:
    commands:
      - echo Build started on `date`
      - echo Building the Docker image...
      - docker build -t $REPOSITORY_URI:latest .
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker images...
      - docker push $REPOSITORY_URI:latest
      - docker push $REPOSITORY_URI:$IMAGE_TAG

左滑检查更多

最佳实践

咱们在 CodePipeline 中运用了 CodeBuild 履行 CI 步骤，buildspec.yml 文是 CodeBuild 这一步需求的文件。

该 CI 流程会在 front-end 代码改变时，主动构建镜像，并上传到 ECR 的库房 weaveworksdemos/front-end。其间镜像的 tag 格式为—[branch]-[commit]-[build number]：

2 镜像主动更新

在开发测验等可继续集成的灵敏环境中，在构建新服务镜像且发布后，经过人工或脚本更新 GitOps 代码库房显得过于繁琐。Flux 本身供给了完善且强大的 Git 库房镜像主动晋级功用。镜像主动更新需求确保 Flux 在装置装备时已启用镜像主动更新组件。如未启用，可重复 Flux bootstrap 时加上 –components-extra=image-reflector-controller,image-automation-controller 参数来启用。

要想到达依据镜像的主动更新，咱们需求做以下操作：

• 注册 front-end 微服务的镜像库房，该步骤的意图是让 Flux 定期扫描前端项目对应的 ECR 镜像库房。
• 装备镜像库房拜访凭据，需求给 Flux 拜访 ECR 镜像库房的凭据，它才干有权限读取镜像信息。
• 设置镜像更新战略，大多数情况咱们不期望所有版别的镜像改变都触发一次 CD，咱们的期望是指定分支（main）的代码改变才触发 CD。这时候需求特殊的更新战略来完结该需求。

接下来咱们逐个完结以上的操作。

Flux 定位镜像

在项目 microservices-repo 中，咱们在 DEV 环境将运用 Kustomization overlays 将 front-end 微服务替换为定制化更新的版别。修正文件 deploy/kubernetes/overlays/development/kustomization.yaml。（注意替换__ACCOUNT_ID__成自己的 ACCOUNT_ID）：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
images:
  - name: weaveworksdemos/front-end
    newName: __ACCOUNT_ID__.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end # {"$imagepolicy": "sock-shop:sock-shop-front-end:name"}
    newTag: latest # {"$imagepolicy": "sock-shop:sock-shop-front-end:tag"}

左滑检查更多

注意：其间的注释 $imagepolicy 是必须的，它们的作用是用来定位的。Flux 发现镜像的版别改变后，需求依据该注释定位并修正文件内容。

注册 front-end 微服务的镜像库房

在项目 flux-repo 中，新建文件 apps/overlays/development/sock-shop/registry.yaml，注意替换__ACCOUNT_ID__成自己的 ACCOUNT_ID：

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
  name: sock-shop-front-end
  namespace: sock-shop
spec:
  image: __ACCOUNT_ID__.dkr.ecr.xxxx.amazonaws.com/weaveworksdemos/front-end
  interval: 1m0s

左滑检查更多

装备镜像库房拜访凭据

有两种方法可用于 Flux 中的镜像库房凭据 ：

• 主动身份验证机制（image-reflector-controller 自己检索凭据，仅适用于三大云供给商：Amazon ECR、GCP GCR、Azure ACR）
• 经过 CronJob 定期改写凭据（经过 Secret 存储在集群）

最佳实践

咱们运用的 Amazon ECR，挑选主动身份验证机制，修正 clusters/dev-cluster/flux-system/kustomization.yaml，经过 patch 机制增加–aws-autologin-for-ecr 参数。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - gotk-components.yaml
  - gotk-sync.yaml
patches:
  - patch: |-
      - op: add
        path: /spec/template/spec/containers/0/args/-
        value: --aws-autologin-for-ecr
    target:
      version: v1
      group: apps
      kind: Deployment
      name: image-reflector-controller
      namespace: flux-system

左滑检查更多

设置镜像更新战略

新增文件 gitops/apps/overlays/development/sock-shop/policy.yaml。如下规则将匹配 master-d480788-1, master-d480788-2, master-d480788-3 等镜像版别：

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
  name: sock-shop-front-end
spec:
  imageRepositoryRef:
    name: sock-shop-front-end
  filterTags:
    pattern: '^main-[a-fA-F0-9]+-(?P<buidnumber>.*)'
    extract: '$buidnumber'
  policy:
    numerical:
      order: asc

左滑检查更多

新增文件 gitops/apps/overlays/development/sock-shop/image-automation.yaml。Flux 主动镜像装备会指定运用装备的 Git 库房，包括分支、途径等信息：

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
  name: sock-shop-front-end
spec:
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        email: fluxcdbot@users.noreply.github.com
        name: fluxcdbot
      messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
    push:
      branch: main
  interval: 5m0s
  sourceRef:
    kind: GitRepository
    name: sock-shop-tenant
    namespace: sock-shop
  update:
    path: ./deploy/kubernetes/overlays/development
    strategy: Setters

左滑检查更多

3 发布并验证

咱们经过修正 front-end 源码，来验证镜像主动更新的全流程。

更新微服务 front-end 代码

修正前端页面的页脚，修正文件—front-end/public/footer.html：

检查 CodePipeline

front-end 的代码改变会主动触发 CodePipeline 运转：

承认 ECR 镜像版别更新

等待 CodePipeline 成功完结后，登录 Amazon ECR 控制台，查询 weaveworksdemos/front-end 镜像版别：

验证 Flux 镜像信息

经过 flux 查询，ImageRepository 和 ImagePolicy 是否成功检索到最新版别。返回结果应该能够看到现已最新版别 master-1f49071-24：

微服务源码主动更新

flux 主动更新 front-end 的镜像版别。能够看到最新一次 commit 提交人是 fluxcdbot，而且成功修正镜像 tag 为最新版别—master-1f49071-24：

查询 pod 镜像的版别

用命令 kubectl get pod -n sock-shop | grep front-end 查询 pod 称号，经过以下代码查询 pod 详情，承认镜像版别现已更新：

kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image
仿制代码

左滑检查更多

更新显现如下：

承认静态页面现已是最新版别

4 小结

以上是咱们对依据镜像的主动布置全过程的具体介绍。简单来说，咱们利用了 Flux 对镜像库房的继续监听才能，当发现镜像版别改变时主动修正 Git 库房中的镜像装备，衔接上一末节的规范的 GitOps 作业流完结主动布置：

• 经过 CodePipeline 完结 CI 流程，完结前端代码的继续集成
• 经过注释 Flux 定位并修正事务装备文件内容
• 装备 Flux 镜像更新战略，让 Flux 监听指定版别的镜像，完结主动布置

在 GitOps 系列内容中，咱们介绍运用 GitOps 东西 FluxCD 完结了办理云环境下的 Amazon EKS 集群的微服务主动发布，实践了 GitOps 流水线的最佳实践。

GitOps 是一种继续交付的方法，包含了一系列的最佳实践，在构建 CI/CD 的东西层面并没有严格约束，只要契合 GitOps 的一些基本原则（Principles of GitOps）即可， 期望大家从中获得了一些启发去构建自己的 GitOps 技能仓库。

一同，面临杂乱的企业场景，还有一些方面还能够继续的优化，例如：

1. 面临要害的线上出产体系，怎么安全增量的灰度发布？
2. Sealed Secrets 引入了额外的私钥办理需求，在云计算环境怎么改进 GitOps 密钥的办理？
3. 怎么将云渠道的资源 IaC 同 Kubernetes 内资源 GitOps 协同办理？
4. 怎么愈加高效的开发 Kubernetes manifests(YAML)？

请继续重视 Build On Cloud 微信公众号，了解更多面向开发者的技能共享和云开发动态！欢迎开发者与咱们一同探讨这些问题，能够经过微信留言与咱们共享你的经历或观点。

往期引荐

Generative AI 新国际

机器学习洞悉

开发者生态

文章作者

郑予彬

亚马逊云科技资深开发者布道师

20 年 ICT 职业和数字化转型实践积累，专注于亚马逊云科技云原生、云安全技能领域。18 年架构师经历，致力于为金融、教育、制作以及国际 500 强企业用户供给数据中心建造以及软件界说数据中心等解决方案的咨询及技能落地。

阙铭飞

亚马逊云科技大中华区解决方案研制中心解决方案架构师

任职亚马逊云科技大中华区解决方案研制中心-解决方案架构师，担任解决方案研制作业。到目前为止有 10 年的作业经历，主要触及大数据、DevOps、容器化等相关作业。

文章来历：dev.amazoncloud.cn/column/arti…