关于kubernetes:GitOps-最佳实践下-基于-Amazon-EKS-构建-CICD-流水线

理解了 GitOps 的概念以及 CI/CD 流水线的架构，实现了构建 GitOps 格调的 CI/CD 流水线的前两局部，祝贺开发者们！咱们一起在 GitOps 最佳实际的路线上曾经实现了大半。接下来，咱们一起看看构建 CI/CD 流水线最佳实际的后两个局部：

通过 IaC 部署云基础架构
在 Amazon EKS 集群上部署 Flux CD
利用 Flux CD 部署 GitOps 工作流
利用 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 流水线上实现利用的继续集成和继续交付。

咱们应用 sock shop 的在线商店面向用户的局部作为案例的举例利用。它旨在帮忙演示和测试微服务和云原生技术。它应用 Spring Boot、Go kit 和 Node 构建，并打包在 Docker 容器中。作为 ” 微服务规范演示 ”，将提供：

微服务最佳实际 (包含谬误示例)
提供跨平台部署能力
展现继续集成 / 部署的劣势
展现 DevOps 与微服务的互补
为各种编排平台提供“实在”的可测试应用程序

参考架构如下：

除了 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 的形式生成最终部署利用所需的形容文件。

理解配置管理工具 Kustomize 后，咱们通过 Kustomization（base、overlays）实现多集群部署革新。

在微服务项目中创立两个目录，base 目录寄存残缺的资源配置 (YAML) 文件，overlays 目录中寄存不同环境或者集群的差别配置：

例如，本例中微服务的残缺配置文件是：complete-demo.yaml，咱们把它复制到 base 目录下：

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 举荐的策略，能够缩小代码保护和合并的难度。

实现微服务的多集群反对后，咱们须要让 flux 感知到微服务的配置变更，于是须要把微服务仓库（microservices-repo）所在的 CodeCommit 地址注册到 flux 的仓库（flux-repo）中。

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

关上 apps/base/sock-shop/tenant.yaml 文件，把 MICRO_SERVICES_REPO 替换成微服务的地址：https://git-codecommit.xxx.amazonaws.com/v1/repos/microservic…：

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

而后关上文件 base/sock-shop/basic-access-auth.yaml，用下面生的 base64 编码替换 BASE64_USERNAME 和 BASE64_PASSWORD。

因为咱们把微服务的 Git 地址增加到了 flux 的配置仓库，所以 flux 会主动扫描微服务的配置变更。当咱们提交代码后，flux 发现集群中没有部署微服务，与 Git 仓库定义不统一，于是 flux 会主动把微服务部署到集群。

提交代码后，执行命令 flux get kustomizations -watch，期待 flux 更新，当所有 kustomizations 的 READY 状态都为 True 时阐明部署实现：

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

拜访 Amazon Load Balancer 的 DNS 名称：

在这里咱们具体介绍了一个微服务业务利用：sock shop 在线商店，并且实现了该服务的多集群配置。咱们还基于 Flux 搭建了规范的 GitOps 工作流，当配置文件产生变更时，会主动把变更同步到指标集群，以此实现了微服务部署到 EKS 集群。同时，咱们介绍了一个实用的 K8s 配置管理工具 Kustomize，咱们应用它的个性实现了利用的资源文件治理：

微服务业务利用介绍
配置管理工具 Kustomize 介绍，并通过 Kustomize（base、overlays）实现微服务多集群部署革新
搭建 GitOps 工作流，并部署微服务

咱们抉择 sock shop 的其中一个前端微服务 front-end 作为例子，演示 GitOps 工作流实现的代码变更 - 镜像构建 - 自定义公布的具体过程。

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]：

在开发测试等可继续集成的麻利环境中，在构建新服务镜像且公布后，通过人工或脚本更新 GitOps 代码仓库显得过于繁琐。Flux 本身提供了欠缺且弱小的 Git 仓库镜像主动降级性能。镜像自动更新须要确保 Flux 在装置配置时已启用镜像自动更新组件。如未启用，可反复 Flux bootstrap 时加上 –components-extra=image-reflector-controller,image-automation-controller 参数来启用。

要想达到基于镜像的自动更新，咱们须要做以下操作：

注册 front-end 微服务的镜像仓库，该步骤的目标是让 Flux 定期扫描前端我的项目对应的 ECR 镜像仓库。
配置镜像仓库拜访凭证，须要给 Flux 拜访 ECR 镜像仓库的凭证，它能力有权限读取镜像信息。
设置镜像更新策略，大多数状况咱们不心愿所有版本的镜像变更都触发一次 CD，咱们的冀望是指定分支（main）的代码变更才触发 CD。这时候须要非凡的更新策略来实现该需要。

接下来咱们一一实现以上的操作。

在我的项目 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 发现镜像的版本变更后，须要依据该正文定位并批改文件内容。

在我的项目 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

左滑查看更多

咱们通过批改 front-end 源码，来验证镜像自动更新的全流程。

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

提交变更：

front-end 的代码变更会主动触发 CodePipeline 运行：

期待 CodePipeline 胜利实现后，登录 Amazon ECR 控制台，查问 weaveworksdemos/front-end 镜像版本：

通过 flux 查问，ImageRepository 和 ImagePolicy 是否胜利检索到最新版本。返回后果应该能够看到曾经最新版本 master-1f49071-24：

flux 自动更新 front-end 的镜像版本。能够看到最新一次 commit 提交人是 fluxcdbot，并且胜利批改镜像 tag 为最新版本—master-1f49071-24：

用命令 kubectl get pod -n sock-shop | grep front-end 查问 pod 名称，通过以下代码查问 pod 详情，确认镜像版本曾经更新：

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

左滑查看更多

更新显示如下：

以上是咱们对基于镜像的主动部署全过程的具体介绍。简略来说，咱们利用了 Flux 对镜像仓库的继续监听能力，当发现镜像版本变更时主动批改 Git 仓库中的镜像配置，连接上一大节的规范的 GitOps 工作流实现主动部署：

通过 CodePipeline 实现 CI 流程，实现前端代码的继续集成
通过正文 Flux 定位并批改业务配置文件内容
配置 Flux 镜像更新策略，让 Flux 监听指定版本的镜像，实现主动部署

在 GitOps 系列内容中，咱们介绍应用 GitOps 工具 FluxCD 实现了治理云环境下的 Amazon EKS 集群的微服务主动公布，实际了 GitOps 流水线的最佳实际。

GitOps 是一种继续交付的形式，蕴含了一系列的最佳实际，在构建 CI/CD 的工具层面并没有严格限度，只有合乎 GitOps 的一些根本准则（Principles of GitOps）即可，心愿大家从中取得了一些启发去构建本人的 GitOps 技术堆栈。

同时，面对简单的企业场景，还有一些方面还能够继续的优化，例如：

面对要害的线上生产零碎，如何平安增量的灰度公布？
Sealed Secrets 引入了额定的私钥治理需要，在云计算环境如何改善 GitOps 密钥的治理？
如何将云平台的资源 IaC 同 Kubernetes 内资源 GitOps 协同治理？
如何更加高效的开发 Kubernetes manifests(YAML)？

请继续关注 Build On Cloud 微信公众号，理解更多面向开发者的技术分享和云开发动静！欢送开发者与咱们一起探讨这些问题，能够通过微信留言与咱们分享你的教训或认识。

Generative AI 新世界

机器学习洞察

开发者生态

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

20 年 ICT 行业和数字化转型实际积攒，专一于亚马逊云科技云原生、云平安技术畛域。18 年架构师教训，致力于为金融、教育、制作以及世界 500 强企业用户提供数据中心建设以及软件定义数据核心等解决方案的征询及技术落地。

阙铭飞

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

任职亚马逊云科技大中华区解决方案研发核心 - 解决方案架构师，负责解决方案研发工作。到目前为止有 10 年的工作教训，次要波及大数据、DevOps、容器化等相干工作。

文章起源：https://dev.amazoncloud.cn/column/article/6437f0e7fed6cd33add…

关于kubernetes:GitOps-最佳实践下-基于-Amazon-EKS-构建-CICD-流水线

利用 Flux CD 部署 GitOps 工作流

1 Sock Shop 利用介绍

2 配置管理工具 Kustomize

3 微服务多集群配置

4 利用 GitOps 工作流部署微服务

增加微服务仓库地址

增加 CodeCommit 凭证

开始部署

5 小结

利用 GitOps 工作流实现基于镜像的主动部署

1 定义 CodePipeline 的 CI 流程

2 镜像自动更新

Flux 定位镜像

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

配置镜像仓库拜访凭证

设置镜像更新策略

3 公布并验证

更新微服务 front-end 代码

查看 CodePipeline

确认 ECR 镜像版本更新

验证 Flux 镜像信息

微服务源码自动更新

查问 pod 镜像的版本

确认动态页面曾经是最新版本

4 小结

往期举荐

文章作者

Just My Socks（注册教程内含优惠码）

关于kubernetes:GitOps-最佳实践下-基于-Amazon-EKS-构建-CICD-流水线

利用 Flux CD 部署 GitOps 工作流

1 Sock Shop 利用介绍

2 配置管理工具 Kustomize

3 微服务多集群配置

4 利用 GitOps 工作流部署微服务

增加微服务仓库地址

增加 CodeCommit 凭证

开始部署

5 小结

利用 GitOps 工作流实现基于镜像的主动部署

1 定义 CodePipeline 的 CI 流程

2 镜像自动更新

Flux 定位镜像

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

配置镜像仓库拜访凭证

设置镜像更新策略

3 公布并验证

更新微服务 front-end 代码

查看 CodePipeline

确认 ECR 镜像版本更新

验证 Flux 镜像信息

微服务源码自动更新

查问 pod 镜像的版本

确认动态页面曾经是最新版本

4 小结

往期举荐

文章作者

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）