介绍
虽然许多企业已在生产环境中采用 Kubernetes，但他们常常困惑于如何实现持续部署、高安全性、权限隔离和审计，同时还要确保业务敏捷性，尤其是在多个 Kubernetes 集群同时运行于不同阶段的情况下。使用 GitOps 可以实现基于 Kubernetes 集群的持续部署，同时满足企业级的安全性和权限隔离等要求。.
在本博客中，我们将使用 AWS CodeCommit、AWS CodePipeline 和 Flux 在 Amazon EKS 环境中实现 GitOps。我们将详细介绍如何在 Amazon EKS 环境中设置满足生产需求的 GitOps 工作流，并演示微服务应用程序如何在 GitOps 式 CI/CD 流水线中实现持续集成和持续交付。.
先决条件
- AWS 体验
- AWS账户
什么是 GitOps？
GitOps 是一种为云应用程序实现持续部署的方法。它以开发人员为中心，同时利用开发人员已经熟悉的工具（包括 Git 和持续部署工具）来充分利用基础设施。.
GitOps 的基本理念是维护一个 Git 仓库，其中始终包含生产环境基础设施的详细描述，并配备一套自动化流程，使生产环境与仓库中描述的状态保持一致。如果需要部署新应用或更新现有应用，只需更新仓库即可。自动化流程会自动处理所有操作。这就像为生产环境中的应用管理配备了巡航控制系统。.
为什么要使用 GitOps？
Git 是系统唯一真正的状态来源。它支持可重复的自动化部署、集群管理和监控。开发人员可以复用组织内已成熟的 Git 工作流，用于构建、测试、扫描和其他持续集成步骤。一旦最新的系统状态提交到主 Git 仓库分支，GitOps 工具链就会用于验证部署、查看告警和修复操作。基于 GitOps 的核心原则，我们认为 GitOps 是持续部署 Kubernetes 集群的最佳方式。流程如下：
基于 Amazon EKS 的 GitOps 最佳实践
根据最佳实践，整个 CI/CD 流水线如下图所示。.
AWS CodeCommit 代码库下有三个代码库。 flux-repo 是配置存储库 通量 CD用于定义与以下方面相关的资源 通量 另一个是微服务仓库（microservices-repo），用于存储微服务应用程序的配置和部署文件。第三个是业务服务的源代码仓库应用程序。本文以一个前端项目为例。我们在流水线中使用 AWS CodePipeline 进行持续集成。 CI/CD 我们在 Docker 镜像中使用了 亚马逊 ECR 我们不断节省成本，并将 Flux CD 引擎作为 pod 部署到 Amazon EKS 环境中。.
基本工作流程如下：
- 编码工程师编写代码并将最终代码推送到应用程序仓库。.
- 应用仓库中的代码更改会触发 AWS CodePipeline。.
- AWS CodePipeline 编辑和打包代码，生成容器镜像，并将它们推送到容器镜像存储库/Amazon ECR。.
- 在 EKS 环境中运行的 Flux CD 引擎会定期扫描 ECR 容器镜像仓库，并提取应用程序的容器镜像元数据。.
- 当检测到容器镜像的新版本时，新的容器镜像 URL 会通过 git commit/push 自动与存储在 microservices-repo 中的应用程序部署文件同步。.
- Flux 会定期从 Flux 仓库拉取应用程序配置和部署文件。由于 Flux 仓库引用了微服务仓库，Flux 会检查集群工作负载的执行状态是否与微服务仓库文件中描述的预期一致。如果存在任何差异，Flux 会自动使 EKS 集群同步这些差异，以确保工作负载以预期状态运行。.
既然我们已经解释了 GitOps 的概念和 CI/CD 流水线架构，我们将通过一个案例来完成这项练习，回顾以下四个模块：
- 使用基础设施即代码 (IaC) 部署云基础设施
- 在 AWS EKS 集群上部署 Flux CD
- 使用 Flux CD 实现 GitOps 工作流
- 基于镜像的GitOps工作流自动化部署
1- 使用 IaC 部署云基础设施
DevOps 的一个基本原则是基础设施等同于代码。基础设施即代码 (IaC) 使用代码来实现云基础设施部署和云环境管理。编码工程师使用配置文件或代码来定义基础设施，并用代码构建它，以确保一致性和可重复性。借助 IaC，编码工程师还可以管理资源生命周期，例如将基础设施定义托管在版本控制仓库中，并使用与编程一致的持续集成/持续交付 (CI/CD) 来更改 IaC 定义，协调不同环境（例如，开发、测试、生产）与 IaC 代码变更。此外，在发生故障时可以自动回滚，而漂移检测有助于识别与预期状态的偏差。.
在云端，软件工程师可以使用 AWS 云开发工具包 (CDK)，通过 Python、Java 和 TypeScript 构建基础设施模型。CDK 提供名为“构造”的高级组件，这些组件预先配置了云资源并设置了有效的默认值。它还允许工程师编写和共享自定义构造，以满足其组织的特定需求。所有这些都有助于加快项目进度。.
1.1 使用 CDK CLI 创建项目
一个带有 TypeScript CDK 的项目 cdk 初始化 创建，它会创建文件夹结构并安装 TypeScript CDK 项目所需的模块。.
cdk init -- language typescript
1.2 使用 EKS 蓝图创建 EKS 集群
EKS 蓝图可帮助您构建完整的 EKS 集群，这些集群已预先配置好部署和运行工作负载所需的全部运维软件。借助 EKS 蓝图，您可以将 EKS 环境所需状态的配置（例如控制面板、工作节点和 Kubernetes 插件）描述为 IaC 蓝图。配置好蓝图后，您可以使用它通过持续自动化在多个 AWS 账户和区域部署一致的环境。.
您可以使用 EKS Blueprints 轻松搭建包含 Amazon EKS 插件以及各种常用开源插件的 EKS 集群，这些插件包括 Prometheus、Karpenter、Nginx、Traefik、AWS Load Balancer Controller、Fluent Bit、Keda、ArgoCD 等。EKS Blueprints 还可以帮助您实施在集群上运行来自多个团队的工作负载所需的相应安全控制措施。.
目录 快速入门 创建并运行以下代码以安装项目依赖项。.
mkdir quickstart cd quickstart npm install @aws-quickstart/eks-blueprints
lib/quickstart-stack.ts 打开并输入验证码。 EKS蓝图 添加以下内容。.
import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as blueprints from '@aws-quickstart/eks-blueprints'; import { KubernetesVersion } from 'aws-cdk-lib/aws-eks'; export class QuickstartStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const account = props?.env?.account!; const region = props?.env?.region!; const clusterProvider = new blueprints.GenericClusterProvider({ version: KubernetesVersion.V1_23, managedNodeGroups: [ { id: "default-ng", desiredSize: 2, minSize: 1, maxSize: 2, } ] }); const cluster = blueprints.EksBlueprint.builder() .clusterProvider(clusterProvider) .account(account) .region(region) .addOns( new blueprints.AwsLoadBalancerControllerAddOn, ) .teams(); } }
在上一步中，我们创建了一个 EKS 集群，定义了它的 NodeGroup，并添加了 AwsLoadBalancerController 插件。.
虽然使用 CDK 命令行工具部署堆栈很方便，但我们建议您设置自动化流水线来部署和更新 EKS 基础架构。这样可以更轻松地跨区域部署开发、测试和生产环境。.
CodePipelineStack 是一个用于持续交付 AWS CDK 应用程序的框架。当 AWS CDK 应用程序的源代码上传到 Git 时，该框架会自动构建、测试并运行新版本。随着应用程序的每个阶段或堆栈的添加，它会自动重新配置自身以部署这些新阶段或堆栈。.
接下来，我们运行 cdk deploy 命令来部署堆栈。.
最后，我们使用命令验证了应用程序负载均衡器是否已成功安装。.
$ kubectl get pod -n kube-system NAME READY STATUS RESTARTS AGE aws-load-balancer-controller-6bd49cfb7-2cvlk 1/1 Running 0 5m31s aws-load-balancer-controller-6bd49cfb7-7lcwd 1/1 Running 0 5m31s aws-node-9hsvz 1/1 Running 0 99m coredns-66cb55d4f4-gdcqg 1/1 Running 0 106m coredns-66cb55d4f4-gmzjt 1/1 Running 0 106m kube-proxy-wr5jn 1/1 Running 0 99m
1.3 总结
在本节中，我们介绍了基础设施即代码 (IaC) 的概念，并使用 CDK 创建了一个自定义 EKS 集群，同时安装了 AWS 应用程序负载均衡器插件。这为将来访问微服务网页奠定了基础。以下是本节的总结：
- 使用 cdk init 启动 CDK 项目。.
- 通过添加 AWS Application Load Balancer 插件，使用 EKS Blueprint 快速定义了一个 EKS 集群。.
2. 在 Amazon EKS 集群上部署 Fluxcd
Flux CD 是由 Weaveworks 开发并开源给 CNCF 的持续交付工具。由于其易于设置且能够理解 Kubernetes 的变更，它如今被广泛使用。其重要特性之一是允许团队以声明式的方式管理 Kubernetes 部署。Flux CD 通过定期轮询源代码仓库，将存储在其中的 Kubernetes 清单文件与 Kubernetes 集群同步。Flux CD 确保 Kubernetes 集群始终与源代码仓库中定义的配置保持同步，而无需担心 kube ctl 的运行状态或使用其他工具和服务来监控工作负载。那么，让我们来安装 Flux 吧。.
2.1 安装 Flux CLI
Flux CLI 是一个适用于所有平台的二进制可执行文件，您可以从 GitHub 发布页面下载。.
curl -s https://fluxcd.io/install.sh | sudo bash
2.2 准备 AWS CodeCommit 凭证
我们需要创建一个用户，并使用 CodeCommit 作为 Git 源，以及通过 HTTPS Git 凭证获取 AWS CodeCommit 所需的访问权限。.
2.3 在集群上安装 Flux
克隆已准备好的 GitOps 代码。项目结构如下：
. ├── apps // 定义应用程序 │ ├── base // 应用程序基础架构层 │ └── overlays // 应用程序覆盖层 ├── clusters // 集群配置门户 │ └── dev-cluster ├── infrastructure // 基础架构共享组件 │ ├── base // 基础架构层 │ └── overlays // 基础架构覆盖层 └── README.md
在 Kubernetes 集群上安装 Flux，并配置其通过 Git 仓库进行管理，同时启用 Flux 引导。如果集群中已存在 Flux 组件，引导命令将根据需要执行升级。此引导过程不具备任何控制权限，因此可以安全地多次运行该命令。请将以下命令中的用户名和密码替换为您的 AWS CodeCommit HTTPS Git 凭证。.
flux bootstrap git \ --url=https://git-codecommit.us-west-2.amazonaws.com/v1/repos/gitops \ --username=__replace_with_your_Git_credential_username__ \ --password=__replace_with_your_Git_credential_password__ \ --token-auth=true \ --path="./clusters/dev-cluster" \ --components-extra=image-reflector-controller,image-automation-controller
使用 git pull 命令检查引导程序所做的更新。Git 仓库的 clusters/dev-cluster/flux-system 目录中将出现三个新文件：
- gotk-components.yaml：定义了六个 Flux 控制器：helm、Kustomize、source、notification、image automation 和 image reflector。.
- gotk-sync.yaml：Git Flux 源，源控制器监控 GitOps 存储库中集群代码的更改，并提交相应的更改。.
- kustomization.yaml：多集群配置。.
使用命令 `flux get kustomizations --watch` 检查 Flux 是否已成功安装。输出结果类似于：
$ flux get kustomizations --watch NAME REVISION SUSPENDED READY MESSAGE flux-system master/83b7e66 False True Applied revision: master/83b7e66 infrastructure master/83b7e66 False True Applied revision: master/83b7e66
使用 kubectl -n flux-system get pod,services 命令检查 flux-system 部署的组件。输出结果如下：
$ kubectl -n flux-system get pod,services NAME READY STATUS RESTARTS AGE pod/helm-controller-88f6889c6-sblvd 1/1 Running 0 11m pod/image-automation-controller-6c5f7bbbd9-8xskk 1/1 Running 0 11m pod/image-reflector-controller-78949bb4b4-bqn4m 1/1 Running 0 11m pod/kustomize-controller-784bd54978-s82dq 1/1 Running 0 11m pod/notification-controller-648bbb9db7-627zs 1/1 Running 0 11m pod/source-controller-79f7866bc7-gdt95 1/1 Running 0 11m名称 类型 集群 IP 外部 IP 端口 年龄 服务/通知控制器 集群 IP 172.20.60.72 80/TCP 11m 服务/源控制器 集群IP 172.20.133.44 80/TCP 11m 服务/webhook接收器 集群IP 172.20.196.178 80/TCP 11米
2.4 总结
在本节中，我们使用 flux bootstrap 命令在 Kubernetes 集群上安装了 Flux，并介绍了三个重要的配置文件：gotk-components.yaml、gotk-sync.yaml 和 kustomization.yaml。以下是本节的总结：
- 安装 Flux 客户端
- 创建 IAM 用户和 CodeCommit 凭据
- 在 Amazon EKS 集群上安装 Flux 并启用自动镜像更新功能
3. 使用 Flux CD 实现 GitOps 工作流
对于 GitOps CI/CD 流水线，EKS 集群及其上运行的工作负载的配置和状态变更均由 Git 中的代码变更驱动（由 git push 或 pull request 生成。GitOps 推荐使用 pull request）。传统的 CI/CD 流水线与 CI 引擎协同工作，触发 kubectl 的 create/apply 或 install/upgrade 命令来部署集群。因此，GitOps 创建了一个更高效、更简洁的 CI/CD 流水线。.
我们将演示一个具体的应用程序——“袜子商店”——并通过实践练习来演示如何在 GitOps CI/CD 管道中实现持续集成和交付。.
3.1 关于袜子店
我们将以一家在线袜子商店的用户界面部分为例。它使用 Spring Boot、Go Kit 和 Node 构建，并打包在 Docker 容器中。正如“微服务标准演示”所示：
- 部署微服务的最佳实践（包括错误示例）
- 跨平台部署能力
- 持续集成/部署的优势
- DevOps 和微服务的互补性
- 适用于不同编排平台的可测试“真实”应用程序
Socks Store 项目由 8 个前端和后端微服务组成，前端是一个使用 NodeJS 构建的网页，项目名称为：front-end。它通过 HTTP 请求访问多个后端服务，包括：订单处理、支付、用户管理、产品管理和购物车等。后端服务的数据存储在 MongoDB 和 MySQL 数据库中。.
参考架构如下：
3.2 关于 Kustomize
除了搭建 GitOps 工作流之外，我们还需要了解如何配置 Kubernetes。随着系统和环境复杂性的增加，传统的基于资源清单（YAML）的管理方式变得越来越难以维护。复杂的业务用例、多环境（开发、测试、预发布、生产）以及大量的 YAML 资源清单都需要维护和管理。虽然 Helm 可以解决一些问题，例如统一管理分散的资源文件、应用程序分发、升级、回滚等，但它在处理环境间的细微差异时却更加困难。此外，它还要求掌握复杂的 DSL（模板语法）语法，这构成了较高的入门门槛。因此，声明式配置管理工具 Kustomize 应运而生。Kustomize 帮助团队跨不同环境和团队管理大量的 YAML Kubernetes 资源。它能够以轻量级的方式管理环境间的细微差异，使资源配置可重用，减少复制和修改工作量，并大幅降低配置错误。整个应用程序配置过程无需额外学习模板语法。.
Kustomize 通过以下方式解决上述问题：
- Kustomize 通过 Base 和 Overlays 来维护不同环境下的应用程序配置。.
- Kustomize 使用 Patch 来重用基本配置和实现，并通过 Overlay 描述和基本应用程序配置之间的差异部分来实现源代码重用。.
- Kustomize 管理原生 Kubernetes YAML 文件，无需学习 DSL 语法。.
根据官网介绍，Kustomize 已成为 Kubernetes 的原生配置管理工具，允许用户无需模板即可自定义应用程序设置。Kustomize 利用 Kubernetes 的原生概念来创建和重用源配置（YAML），允许用户使用应用程序描述文件（YAML）作为基础（基础 YAML），然后通过 Overlay 为最终部署的应用程序生成所需的描述文件。.
3.3 多集群配置
了解 Kustomize 配置管理工具后，我们使用 Kustomization（基础、覆盖）来实现多集群部署转型。.
我们在微服务项目中创建了两个目录：基本目录用于存储完整的源配置文件（YAML），覆盖目录用于存储不同的环境或差异集群配置。.
例如，在本例中，微服务的完整配置文件为 full-demo.yaml，我们将其复制到主文件夹。.
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
对于开发环境，如果存在差异性要求，例如更改服务端口和副本的数量，只需在 overlays/development/kustomization.yaml 文件中配置差异性设置，而无需复制和更改现有的 full-demo.yaml 文件。.
3.4 使用 GitOps 工作流部署微服务
在完成对微服务的多集群支持后，Flux 需要知道微服务配置已更改，因此我们在 Flux 存储库 (flux-repo) 中注册微服务存储库 (microservices-repo) 的 CodeCommit URL。.
3.4.1 添加微服务存储库地址
我们返回到应用程序层/applications 文件夹下的 Flux 代码库：
.。 根据打开 apps/base/sock-shop/ 中的 tenant.yaml 文件，并将 MICRO_SERVICES_REPO 替换为微服务 URL：https://git-codecommit.xxx.amazonaws.com/v1/repos/microservices-repo。.
apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository metadata: name: sock-shop-tenant namespace: sock-shop spec: interval: 1m url: __MICRO_SERVICES_REPO__ ref: branch: main secretRef: name: microservices-basic-access-auth ......
3.4.2 添加 CodeCommit 凭据
找到«准备 AWS CodeCommit 凭证»的账户和密码。在运行命令之前，将数据值转换为 base64 编码。.
然后打开 base/sock-shop/basic-access-auth.yaml 文件，并将 BASE64_USERNAME 和 BASE64_PASSWORD 替换为生成的 base64 编码：
--- apiVersion: v1 kind: Secret metadata: name: microservices-basic-access-auth namespace: sock-shop type: Opaque data: username: __BASE64_USERNAME__ password: __BASE64_PASSWORD__3.4.3 部署
通过将微服务的 Git URL 添加到 Flux 配置仓库，Flux 会自动扫描其配置更改。代码提交后，Flux 会检查集群中是否已部署任何微服务，并判断它们是否与 Git 仓库中的定义匹配；否则，Flux 会自动将微服务部署到集群。.
代码执行完毕后，运行命令 `flux get kustomizations -watch` 并等待 Flux 更新。当所有自定义项的 READY 状态均为 True 时，部署即完成。.
在如下所示的 sock store 命名空间中搜索 pod 和服务：
$ kubectl get pod,service -n sock-shop NAME READY STATUS RESTARTS AGE pod/carts-b4d4ffb5c-z4jrj 1/1 Running 0 5m28s pod/carts-db-6c6c68b747-jl5pd 1/1 Running 0 5m28s pod/catalogue-759cc6b86-qdmvc 1/1 Running 0 5m28s pod/catalogue-db-96f6f6b4c-zgp5z 1/1 Running 0 5m28s pod/front-end-5c89db9f57-cvbdl 1/1 Running 0 5m28s pod/orders-7664c64d75-lqwbm 1/1 Running 0 5分28秒 pod/orders-db-659949975f-qv7pl 1/1 运行中 0 5分28秒 pod/payment-7bcdbf45c9-szrfq 1/1 运行中 0 5分28秒 pod/queue-master-5f6d6d4796-nkktx 1/1 运行中 0 5分28秒 pod/rabbitmq-5bcbb547d7-gzhn4 2/2 运行中 0 5分28秒 pod/session-db-7cf97f8d4f-9mz6v 1/1 运行中 0 5分28秒 pod/shipping-7f7999ffb7-95rlc 1/1 运行中 0 5分27秒 pod/user-68df64db9c-kh247 1/1 运行中 0 5分27秒pod/user-db-6df7444fc-jlkp9 1/1 运行中 0 5分27秒 名称 类型 集群IP 外部IP 端口 运行时间 service/carts 集群IP 172.20.33.124 80/TCP 5分29秒 service/carts-db ClusterIP 172.20.75.163 27017/TCP 5分29秒 service/catalogue ClusterIP 172.20.92.254 80/TCP 5分29秒 service/catalogue-db ClusterIP 172.20.242.255 3306/TCP 5分29秒 service/front-end LoadBalancer 172.20.55.188 k8s-sockshop-frontend-12345678910-012345678910abc.elb.us-east-1.amazonaws.com 80:30001/TCP 5分29秒 service/orders ClusterIP 172.20.8.252 80/TCP 5分29秒 service/orders-db ClusterIP 172.20.40.212 27017/TCP 5分29秒 服务/支付 集群IP 172.20.6.218 80/TCP 5分29秒 service/queue-master ClusterIP 172.20.153.80 80/TCP 5分29秒 service/rabbitmq 集群IP 172.20.99.37 5672/TCP,9090/TCP 5分29秒 service/session-db ClusterIP 172.20.37.111 6379/TCP 5分29秒 服务/发货 集群IP 172.20.43.252 80/TCP 5分29秒 服务/用户 集群IP 172.20.220.174 80/TCP 5分29秒 service/user-db ClusterIP 172.20.70.57 27017/TCP 5分29秒访问 AWS 负载均衡器的 DNS 名称。.
3.5 总结
本节介绍了一个微服务业务应用——Sock Shop 在线商店，并完成了其多集群配置。我们还创建了一个基于 Flux 的标准 GitOps 工作流，该工作流能够自动将目标集群与配置文件变更同步，从而完成微服务在 EKS 集群上的部署。同时，我们也介绍了实用的配置管理工具 K8s-Kustomize 以及如何管理应用资源文件。以下是本节内容的总结：
- 袜子店开业啦！
- 学习配置管理工具 Kustomize（基础版、覆盖版）以及如何更改多集群微服务部署。.
- 构建 GitOps 工作流并部署微服务
4. 基于镜像的自动化部署与 GitOps 工作流
我们选择 Sock Shop 前端微服务作为示例，来演示使用 GitOps 工作流进行代码更改、镜像构建和自定义发布的详细过程。.
4.1 CodePipeline CI 的定义
前端是一个纯 Node.js 前端服务，用于支持 Docker 镜像打包（详情请参阅第 3.1 章中的 Sock Shop 架构）。要定义在 CodePipeline 中执行的 CI 流程，请将 buildspec.yml 文件添加到前端项目源代码中：
版本：0.2 阶段：pre_build：命令：- echo 登录到 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当前端代码发生更改时，此 CI 流程会自动构建镜像并将其上传到 ECR weaveworksdemos/front-end 存储库。镜像标签格式为 [branch]-[commit]-[build number]。.
4.2 自动图像更新
在采用持续集成的敏捷开发环境中，例如在测试开发时，更新 GitOps 仓库或使用脚本管理新的服务镜像可能非常麻烦。幸运的是，Flux 提供了一个强大的自动镜像更新功能，可以帮你轻松解决这个问题。要使用它，你只需在配置中启用镜像更新组件即可。如果你还没有启用，也不用担心，只需在 Flux 引导程序迭代时添加参数 `--components-extra=image-reflector-controller,image-automation-controller` 即可启用它。.
为了实现基于图像的自动更新，我们需要执行以下步骤：
- 注册前端微服务镜像仓库，以便 Flux 定期扫描前端项目中的 ECR 镜像仓库报告器。.
- 配置访问镜像仓库的凭据。Flux 需要凭据才能访问 ECR 镜像仓库并读取镜像信息。.
- 设置镜像更新策略。大多数情况下，我们不希望每次镜像版本变更都触发持续交付 (CD)。相反，我们只希望指定分支（根）代码触发 CD。为此，需要特殊的更新策略。.
接下来，我们将逐一完成上述操作。.
4.2.1 向 Git 仓库前端添加镜像策略
在 microservices-repo 项目中，我们将在开发环境中使用 Kustomization overlays 来替换微服务前端，使其拥有自定义和更新的版本。请修改 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"}4.2.2 在 Flux-repo 下注册微服务的前端
在 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
4.2.3 配置 Amazon ECR 的访问凭证
Flux 中有两种 Amazon ECR 凭证处理方法。.
- 自动身份验证机制（图像反射器控制器自行检索凭据，仅适用于：Amazon ECR、GCP GCR、Azure ACR）
- 使用 CronJob 定期检索凭据（通过 Secret 存储在集群中）。
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
4.2.4 设置图像更新策略
添加文件 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' 策略：数值：顺序：升序
添加文件 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: [email protected] 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
4.3 公布和批准
我们通过修改前端源代码来验证整个自动图像更新过程。.
4.3.1 更新前端代码
更改前端页脚并修改文件：front-end/public/footer.html。.
4.3.2 检查代码管道
前端代码更改会自动触发 CodePipeline 执行。.
4.3.3 确认 ECR 映像版本变更
CodePipeline 完成后，登录 Amazon ECR 控制台检查 weaveworksdemos/front-end 镜像版本：
4.3.4 检查通量图像信息
通过 Flux CLI 检查 ImageRepository 和 ImagePolicy 是否已成功检索到最新版本。.
$ flux get images all --all-namespaces NAMESPACE NAME LAST SCAN SUSPENDED READY MESSAGE sock-shop imagerepository/sock-shop-front-end 2022-09-18T14:46:45Z False True successful scan, found 20 tags NAMESPACE NAME LATEST IMAGE READY MESSAGE sock-shop imagepolicy/sock-shop-front-end 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24 True Latest image tag for '267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end' resolved to: master-1f49071-24命名空间名称 上次运行 已暂停 就绪 消息 sock-shop imageupdateautomation/sock-shop-front-end 2022-09-18T14:43:51Z False True 未进行任何更新；上次提交 1ff6d91 于 2022-09-18T14:34:40Z
4.3.5 微服务源代码自动更新
Flux 已自动更新前端镜像版本。最后一次提交由 fluxcdbot 完成，镜像标签已成功修改为最新版本：master-1f49071-24。.
4.3.6 验证 Pod 镜像版本
使用 `kubectl get pod -n sock-shop | grep front-end` 验证 pod 名称。使用 `kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep` 检查 pod 详细信息。镜像：验证镜像版本更新。结果将显示如下：
$ kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image: Image: 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-244.3.7 验证静态页面是否为最新版本
4.4 总结
本节详细描述了基于镜像的整个自动化部署流程。简而言之，我们利用 Flux 的持续监控功能来管理镜像仓库。当检测到镜像版本发生变更时，它会自动更新 Git 仓库中的镜像配置，并通过与上一节中介绍的标准 GitOps 工作流连接来完成自动化部署。本节总结如下：
- 通过 CodePipeline 运行 CI 流程，实现前端代码的持续集成。.
- 找到并修改带有 Flux 注解的业务配置文件。.
- 配置 Flux 镜像更新策略，使 Flux 能够监控特定版本的镜像并实现部署的完全自动化。.
结果
本文重点介绍如何使用 FluxCD 将微服务自动化部署到云端的 Amazon EKS 集群，以及 GitOps 流水线的最佳实践。GitOps 是一种持续交付方法，包含一系列最佳实践。只要遵循 GitOps 的基本原则，构建 CI/CD 工具就没有硬性限制。.
