手动部署不容易出错。此外，它们由一堆重复且复杂的任务组成。开发团队担心部署新版本应用程序的复杂性及其带来的麻烦。有时，部署应用程序需要高级平台技能。调试部署问题是一个乏味的过程。   可帮助您减少手动和重复性任务的工作量。它还最大限度地减少了部署错误和人机交互。它提供了使用声明性文件跟踪和更新部署状态的工具，使开发团队的部署和调试过程更加轻松。 FluxCD 本文探讨了部署流程的自动化，以使用  、  和 将其转换为持续部署流程。 FluxCD Flagger Grafana 查看第一篇文章，了解有关持续交付应用程序的更多信息：    。 CI/CD 实践：简单但实用的持续集成工作流程 [第 1 部分]  GitHub 示例：  https://github.com/joan-mido-qa/continious-deployment-example 介绍 使用 和 设置 Kubernetes 集群。首先，创建集群并导出 Kubernetes 配置以设置 Kubernetes 提供程序： KinD Terraform   $ kind create cluster --name develop $ kind export kubeconfig --name develop --kubeconfig kubeconfig 创建一个新的 GitHub 存储库和具有存储库权限的开发人员令牌，Terrafom 需要它来设置 FluxCD。初始化 Terraform 并应用更改：   $ terraform init $ terraform apply -var="github_owner=owner_name" -var="github_repository=repo_name" # Introduce your GitHub token  Terraform 完成安装过程后，您应该在 KinD 集群中运行 FluxCD，并在存储库中创建一个名为 的新文件夹。 cluster 地形 在幕后，Terraform 安装 并配置 IP 范围。您可以在 中阅读有关 MetalLB 配置的更多信息： MetalLB 文章的第一部分   resource "helm_release" "metallb" { name = "metallb" repository = "https://metallb.github.io/metallb" chart = "metallb" } data "docker_network" "kind" { name = "kind" } resource "kubectl_manifest" "kind-address-pool" { yaml_body = yamlencode({ "apiVersion" : "metallb.io/v1beta1", "kind" : "IPAddressPool", "metadata" : { "name" : "kind-address-pool" }, "spec" : { "addresses" : [replace(tolist(data.docker_network.kind.ipam_config)[0].subnet, ".0.0/16", ".255.0/24")] } }) depends_on = [helm_release.metallb] } resource "kubectl_manifest" "kind-advertisement" { yaml_body = <<YAML apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: kind-advertisement YAML depends_on = [helm_release.metallb] } 然后，它安装 FLuxCD Helm Chart 并配置 GitHub 存储库以使用 FluxCD：   resource "helm_release" "flux" { repository = "https://fluxcd-community.github.io/helm-charts" chart = "flux2" name = "flux2" namespace = "flux-system" create_namespace = true version = "2.9.2" } resource "tls_private_key" "flux" { depends_on = [helm_release.flux] algorithm = "ECDSA" ecdsa_curve = "P256" } resource "github_repository_deploy_key" "flux" { depends_on = [tls_private_key.flux] title = "Flux" repository = var.github_repository key = tls_private_key.flux.public_key_openssh read_only = "false" } resource "flux_bootstrap_git" "this" { depends_on = [github_repository_deploy_key.flux] path = "clusters/develop" } 预提交挂钩建议：    （   ）： Terraform https://github.com/antonbabenko/pre-commit-terraform  TFSec：Terraform 的静态分析以发现潜在的错误配置 TFLint：Terraform 的静态格式检查器 （   ）：防止新的秘密进入代码库。 检测秘密 https://github.com/Yelp/detect-secrets 助焊剂CD   是一个 GitOps 工具，用于使 Kubernetes 集群保持最新的源代码控制更改（如 Git 存储库）。 Flux 自动部署新代码。 FluxCD  Flux 在集群中运行后，让我们看看它是如何工作的。我们将部署 ingress-nginx 作为入口提供程序。 Flux 不强制执行项目文件夹结构。您可以根据需要进行配置或遵循您的首选标准。 在名为 的文件夹内创建名为 的文件夹。基本文件夹包含所有集群的基本基础架构配置。接下来，创建一个名为 的文件夹。使用命名空间名称作为文件夹名称。 基础设施 base ingress-nginx   --- apiVersion: v1 kind: Namespace metadata: name: ingress-ngnix --- apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: HelmRepository metadata: name: ingress-nginx spec: interval: 2h url: https://kubernetes.github.io/ingress-nginx --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: ingress-nginx spec: interval: 15m chart: spec: chart: ingress-nginx version: 4.7.1 sourceRef: kind: HelmRepository name: ingress-nginx interval: 15m --- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: ingress-ngnix resources: - namespace.yaml - helmrepository.yaml - helmrelease.yaml 使用多个文件来定义对象：   、   、   、  等。 helmrelease.yaml helmrepository.yaml namespace.yaml kustomization.yaml   读取并处理资源以应用它们。最后但并非最不重要的一点是，您需要创建一个 Kustomization 对象来同步集群配置。在 文件夹中创建一个名为 的 YAML 文件： Kustomization cluster/cluster_name 基础设施.yaml   --- apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization metadata: name: infra-base namespace: flux-system spec: interval: 1h retryInterval: 1m timeout: 5m sourceRef: kind: GitRepository name: flux-system path: ./infrastructure/base prune: true wait: true 提交更改并将其推送到存储库后，Flux 将协调集群状态以安装 ingress-nginx Helm Chart。 弗拉格 是一个 Kubernetes 操作员，它使用蓝/绿部署、金丝雀发布或 A/B 测试逐步交付您的应用程序。 Flagger 您可以使用 文件夹将堆栈安装到所有集群中，或使用不同的文件夹根据集群自定义安装。例如，我们只想将 Flagger 安装到开发集群中。 基本 使用您的集群名称在 文件夹中创建一个新文件夹。然后，在 中创建一个名为 i  的文件： 基础架构 cluster/cluster_name nfrastruct.yaml   --- apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization metadata: name: infra-cluster-name namespace: flux-system spec: dependsOn: - name: infra-base interval: 1h retryInterval: 1m timeout: 5m sourceRef: kind: GitRepository name: flux-system path: ./infrastructure/cluster_name prune: true  FluxCD 将在应用基础设施 Kustomization 后同步集群状态。安装 Flagger，在 文件夹中创建以下 YAML 文件： 基础设施/cluster_name/flaagger-system   --- apiVersion: v1 kind: Namespace metadata: name: flagger-system --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: flagger spec: interval: 1h url: https://flagger.app --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: flagger spec: interval: 1h install: crds: CreateReplace upgrade: crds: CreateReplace chart: spec: chart: flagger version: 1.xx interval: 6h sourceRef: kind: HelmRepository name: flagger --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: flagger-loadtester spec: interval: 1h chart: spec: chart: loadtester version: 0.xx interval: 6h sourceRef: kind: HelmRepository name: flagger --- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: flagger-system resources: - namespace.yaml - helmrepository.yaml - helmrelease.yaml 持续部署 要构建 应用程序持续部署管道，请在  *:* 中创建安装 YAML 文件 Podinfo apps/cluster_name/podinfo --- apiVersion: v1 kind: Namespace metadata: name: podinfo --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: podinfo spec: interval: 5m url: https://stefanprodan.github.io/podinfo --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: podinfo spec: releaseName: podinfo chart: spec: chart: podinfo version: 6.5.0 sourceRef: kind: HelmRepository name: podinfo interval: 50m install: remediation: retries: 3 values: ingress: enabled: true className: nginx hpa: enabled: true --- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: podinfo resources: - namespace.yaml - helmrepository.yaml - helmrelease.yaml 您可以使用更新主机 Python 脚本来更新本地环境主机，如 中所述。 本文第一部分 然后，在 文件夹中创建 Kustomization 文件以同步您的应用程序： cluster/cluster_name   --- apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization metadata: name: apps namespace: flux-system spec: interval: 10m0s dependsOn: - name: infra-cluster-name sourceRef: kind: GitRepository name: flux-system path: ./apps/cluster_name prune: true wait: true timeout: 5m0s 接下来，我们可以配置 FluxCD 自动更新 Podinfo 镜像 Helm Chart 版本。要配置映像自动更新，我们需要创建一个映像存储库来扫描新的映像标签，一个映像更新策略来定义要更新的版本模式，以及一个映像自动更新来配置存储库以推送更改。   --- apiVersion: image.toolkit.fluxcd.io/v1beta2 kind: ImageRepository metadata: name: podinfo-chart spec: image: ghcr.io/stefanprodan/charts/podinfo interval: 5m --- apiVersion: image.toolkit.fluxcd.io/v1beta2 kind: ImagePolicy metadata: name: podinfo-chart spec: imageRepositoryRef: name: podinfo-chart policy: semver: range: 6.xx --- apiVersion: image.toolkit.fluxcd.io/v1beta1 kind: ImageUpdateAutomation metadata: name: podinfo-chart spec: interval: 30m sourceRef: kind: GitRepository name: flux-system namespace: flux-system git: checkout: ref: branch: main commit: author: email: fluxcdbot@users.noreply.github.com name: fluxcdbot messageTemplate: 'chore(develop): update podinfo chart to {{range .Updated.Images}}{{println .}}{{end}}' push: branch: main update: path: ./apps/cluster_name/podinfo strategy: Setters --- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: podinfo resources: [...] - imagepolicy.yaml - imagerepository.yaml - imageautoupdate.yaml 最后，将图像更新策略应用到要更新的图像或标签：   apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: podinfo spec: releaseName: podinfo chart: spec: chart: podinfo version: 6.5.0 # {"$imagepolicy": "podinfo:podinfo-chart:tag"} sourceRef: kind: HelmRepository name: podinfo interval: 50m install: remediation: retries: 3 每当 Podinfo Chart 有 6.xx 范围内的新版本时，FluxCD 都会将提交推送到存储库，用较新的版本更新当前版本。  金丝雀发布 向一小部分用户发布新的应用程序版本，以确保应用程序的功能、性能和安全性达到预期。 FluxCD 自动更新 Chart 版本并将其提供给用户。如果出现故障，FluxCD 会自动将映像版本回滚到之前的版本。  Flagger 逐步将新的应用程序版本交付给一部分用户并监控应用程序状态。它为新的应用程序版本创建新的部署，并逐步将传入流量重定向到新的部署。成功分析指标后，它将促进金丝雀部署。如果发生故障，Flagger 会删除新部署并重新建立到旧部署的流量。此过程假装在将应用程序交付给所有用户之前检测到缺陷、问题和错误。  首先，创建一个指标模板，让 Flagger 知道哪个是应用程序状态。我们使用Prometheus来衡量请求成功率：   --- apiVersion: flagger.app/v1beta1 kind: MetricTemplate metadata: name: podinfo-request-success-rate spec: provider: type: prometheus address: http://loki-stack-prometheus-server.loki-stack:80 query: | 100 - sum( rate( http_requests_total{ app_kubernetes_io_name="podinfo", namespace="{{ namespace }}", status!~"5.*" }[{{ interval }}] ) ) / sum( rate( http_requests_total{ app_kubernetes_io_name="podinfo", namespace="{{ namespace }}", }[{{ interval }}] ) ) * 100 --- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: podinfo resources: [...] - metrictemplate.yaml 然后，定义金丝雀发布流程。我们使用 nginx 作为提供者来调整传入流量。 Flagger 提供了多种方法和工具来配置您的版本。   --- apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: podinfo spec: provider: nginx targetRef: apiVersion: apps/v1 kind: Deployment name: podinfo ingressRef: apiVersion: networking.k8s.io/v1 kind: Ingress name: podinfo autoscalerRef: apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler name: podinfo progressDeadlineSeconds: 60 service: port: 9898 targetPort: 9898 analysis: interval: 10s threshold: 10 maxWeight: 50 stepWeight: 5 metrics: - name: podinfo-request-success-rate thresholdRange: min: 99 interval: 1m webhooks: - name: acceptance-test type: pre-rollout url: http://flagger-loadtester.flagger-system/ timeout: 30s metadata: type: bash cmd: curl -sd 'test' http://podinfo-canary.podinfo:9898/token | grep token - name: load-test url: http://flagger-loadtester.flagger-system/ timeout: 5s metadata: cmd: hey -z 1m -q 10 -c 2 http://podinfo-canary.podinfo:9898/healthz --- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: podinfo resources: [...] - canary.yaml  Flagger 需要对您的部署、入口和 Pod 自动扩展器的引用。每当Flagger检测到新版本时，它就会扩大部署，创建主服务和辅服务，并配置nginx将传入流量发送到相应的服务。使用 maxWeight 和 stepWeight 属性来配置最大流量重定向百分比和增量步长百分比。 使用 Flagger hook 对您的应用程序进行负载测试。它有多个挂钩。验收挂钩检查金丝雀部署准备情况，负载测试挂钩生成持续的传入流量。  Flagger 将使用预定义的成功率指标来监控金丝雀发布状态，以决定金丝雀部署升级案例。 Flagger 预计请求成功率将达到 99%，以促进金丝雀部署。使用阈值属性配置回滚之前失败指标检查的最大数量。 监控 使用Loki堆栈使用Grafana + Loki + Prometheus监控集群资源的状态。通过在 文件夹中创建以下 YAML 文件来安装 Loki 堆栈： 基础设施/cluster_name/loki-stack   --- apiVersion: v1 kind: Namespace metadata: name: loki-stack --- apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: HelmRepository metadata: name: grafana spec: interval: 2h url: https://grafana.github.io/helm-charts --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: loki-stack spec: interval: 1h chart: spec: chart: loki-stack version: v2.9.11 sourceRef: kind: HelmRepository name: grafana interval: 1h values: grafana: enabled: true ingress: enabled: true annotations: kubernetes.io/ingress.class: nginx hosts: - grafana.local prometheus: enabled: true nodeExporter: enabled: true --- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: loki-stack resources: - namespace.yaml - helmrepository.yaml - helmrelease.yaml  Loki 堆栈安装使 Grafana Ingress 能够访问 Grafana，Prometheus 能够收集您的环境指标，Node Exporter 能够导出您的节点指标。 您可以使用更新主机 Python 脚本来更新本地环境主机，如 中所述 本文第一部分 使用管理员用户名和密码登录 Grafana。您可以使用安装值定义管理员密码。默认情况下，Chart 创建一个 Kubernetes 密钥来存储随机密码。描述秘密以获取 Base64 密码值并对其进行解码。 您可以使用 ID 或复制原始 JSON 导入您最喜欢的仪表板：    ：https:  K8s //github.com/dotdc/grafana-dashboards-kubernetes    ：    FluxCD https://grafana.com/grafana/dashboards/16714-flux2/ 结论 第一篇文章探讨了如何交付经过充分测试的应用程序。本文探讨如何持续部署可交付成果并监控部署的状态。  FluxCD 和 Flagger 提供多种功能来持续测试、部署和监控您的应用程序状态。本文使用了其中的一些，但我们没有看到 webhooks 和通知功能。使用通知功能了解部署何时失败，或使用 Web 挂钩功能将部署提升到新环境或针对新版本启动测试。将 FluxCD 与其他工具集成以丰富您的部署管道。 避免手动部署。它们很复杂并且不易出错。鼓励开发团队维护他们的应用程序，使部署过程更加容易。自动部署减少了交付时间、反馈循环和总体成本。开发人员可以专注于真正重要的事情。

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Read My Stories

該音頻是用故事的原始語言製作的！

CI/CD 实践：简单但实用的持续部署工作流程 [第 2 部分]

About Author

註釋

標籤

这篇文章刊登在

Related Stories

Telegram：加密岛通往大陆的桥梁

比特币 UTXO 模型，为独特的生态系统提供动力

加密货币增长：创建有效的用户角色

看不见的层面：为什么用户访谈是不可替代的资产

Telegram：加密岛通往大陆的桥梁

比特币 UTXO 模型，为独特的生态系统提供动力

加密货币增长：创建有效的用户角色

看不见的层面：为什么用户访谈是不可替代的资产

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps