6 篇博文 含有标签「devops」

Terraform是一种部署技术，适用于希望以代码（IaC）的形式提供和管理其基础设施的任何人。基础设施主要指云基础设施，尽管从技术上讲，任何可以通过应用程序编程接口（API）控制的东西都可以视为基础设施。基础设施即代码是通过机器可读的定义文件来管理和提供基础设施的过程。我们使用IaC来自动化过去需要手动完成的过程。

当我们谈论提供服务时，我们指的是部署基础设施的行为，与配置管理不同，后者主要处理应用程序的交付，特别是在虚拟机（VMs）上。像Ansible、Puppet、SaltStack和Chef这样的配置管理（CM）工具非常受欢迎，并且已经存在了很多年。Terraform并没有完全取代这些工具，因为基础设施提供和配置管理本质上是不同的问题。话虽如此，Terraform确实执行了许多过去由CM工具负责的功能，许多公司发现在采用Terraform后不再需要CM工具。

Terraform的基本原理是，它允许你编写人类可读的配置代码来定义你的IaC。通过配置代码，你可以在公有云、私有云和混合云的供应商中部署可重复、短暂且一致的环境

在本章中，我们首先讨论Terraform的显著特性。我们讨论了Terraform相对于其他IaC技术的优势和劣势，以及什么使Terraform成为明显的赢家。最后，我们通过部署一个单独的服务器到AWS并加入一些Terraform的更多动态特性，来看看Terraform的典型“Hello World!”。

最近关于Terraform的炒作很多，但这些炒作是否有理由呢？Terraform并不是唯一的IaC技术——有很多其他工具也能做同样的事情。那么Terraform，一种在高利润的软件部署市场空间中的技术，如何能与亚马逊、微软和谷歌等公司竞争呢？有六个关键特性使得Terraform独特，并赋予它竞争优势。

• 提供工具 — 部署基础设施，而不仅仅是应用程序。
• 易于使用 — 适合所有非天才人士。
• 免费和开源 — 谁不喜欢免费的？
• 声明式 — 说你想要什么，而不是怎么做。
• 云服务无关 — 使用同一工具部署到任何云服务。
• 富有表现力和可扩展性 — 你并不受语言的限制。

Terraform是一种基础设施提供工具，而不是配置管理（CM）工具。提供工具部署和管理基础设施，而像Ansible、Puppet、SaltStack和Chef这样的CM工具则在现有服务器上部署软件。一些CM工具也可以执行一定程度的基础设施提供，但不如Terraform，因为这并不是它们原本设计要做的任务。

CM和提供工具之间的区别是一种哲学问题。CM工具倾向于支持可变基础设施，而Terraform和其他提供工具则倾向于支持不可变基础设施。

可变基础设施意味着你在现有服务器上进行软件更新。相比之下，不可变基础设施并不关心现有的服务器——它将基础设施视为一种可丢弃的商品。这两种范例之间的区别可以概括为可重用与一次性的思维方式。

即使对于非程序员来说，Terraform的基础也是快速且容易学习的。到第4章的结束时，你将拥有成为中级Terraform用户所需的技能，当你思考这一点时，这是相当震惊的。当然，达到精通是另一回事，但这对大多数技能都是如此。

Terraform如此易用的主要原因是，代码是用一种特定领域的配置语言编写的，称为HashiCorp配置语言（HCL）。这是HashiCorp发明的一种语言，作为更冗长的配置语言（如JSON和XML）的替代品。HCL试图在人类可读性和机器可读性之间取得平衡，受到了该领域早期尝试（如libucl和Nginx配置）的影响。HCL与JSON完全兼容，这意味着HCL可以1:1地转换为JSON，反之亦然。这使得与Terraform之外的系统进行互操作或动态生成配置代码变得容易。

驱动Terraform的引擎叫做Terraform core，这是一个根据Mozilla公共许可证v2.0提供的免费和开源软件。该许可证规定任何人都可以使用、分发或修改软件，无论是用于私人还是商业目的。免费是非常好的，因为你永远不必担心在使用Terraform时产生额外的费用。另外，你可以完全了解产品及其运作方式。

并没有Terraform的高级版本，但是为了在大规模下运行Terraform，有商业和企业解决方案可用：Terraform Cloud和Terraform Enterprise。我们将在第6章中详细介绍这些内容；并且在第12章，我们将开发我们自己的Terraform Enterprise的仿制版本。

Terraform通过Terraform提供程序与不同的云进行集成。提供程序是为Terraform设计的插件，用于与外部API进行接口。每个云供应商都维护自己的Terraform提供程序，使Terraform能够管理该云中的资源。提供程序是用golang编写的，并以二进制形式在Terraform注册表（https://registry.terraform.io）上分发。它们处理所有的认证、API请求、超时和错误处理等程序逻辑。注册表上有数百个已发布的提供程序，它们共同使你能够管理数千种不同的资源。你甚至可以编写自己的Terraform提供程序，我们将在第11章中讨论。

背景​

多年来，Kubernetes 已成为全世界的话题。它彻底改变了容器的编排，并已成为该领域的领导者。许多开发人员喜欢使用 Kubernetes。虽然组织更喜欢在 Kubernetes 上部署应用程序以应对规模和苛刻的资源，但与 Kubernetes 相关的部署正在流行一种新的方法 - GitOps。

是的，GitOps 提供了一种流畅的方法和一组实践来利用 Git 等简单工具来管理基础结构和应用程序部署。通过结合 Kubernetes 和 GitOps，组织可以获得灵活性、敏捷性、规模、性能、效率和更快的功能交付的巨大好处。

在这本 Kubernetes 和 GitOps 指南中，我有一个分步的初学者级教程，用于开始使用 Kubernetes 实现 GitOps。是时候将应用程序部署提升到一个新的水平了。让我们开始吧！

简单的 GitOps 工作流​

GitOps 基本上的工作原理是让 Git 成为事实的来源，包括将所有内容移动到代码中以及在 Git 中存储和维护所有内容。在部署方面，请使用运算符以声明方式部署在 Git 和 Yaml 中配置的内容。由于所有开发人员主要对 Git 友好，因此 GitOps 简化了他们复杂的工作流程。

因此，当涉及到 Kubernetes 时，应用程序代码、容器映像和所有相关清单文件都将存储在 Git 中，任何更改都将通过 Git 作为单一事实来源进行。

今天，我们将在下面的教程中向您展示如何开始使用应用程序的 GitOps 方法。

先决条件​

• 在本教程中，我们将使用持续交付工具（如 Harness）来执行 GitOps。因此，创建一个免费的Harness帐户。它使用Argo CD-as-a-Service。
• GitHub 帐户和要试验的示例存储库。我有一个示例存储库，您可以fork并使用。

教程​

注册到 harness 帐户，验证电子邮件，然后重新登录以设置 GitOps Pipeline 。您将看到以下部署选项 - Kubernetes 和 Kubernetes with GitOps。选择“Kubernetes with GitOps”并继续。

您不必担心任何设置和安装。安全带可以照顾一切。它通过预配托管代理连接到 Harness。 您可以单击“配置”并等待一段时间，以便为您的代理显示绿色复选框。

成功安装代理后，请转到下一个配置，在这里，我们提供简单的详细信息，例如源，身份验证和Git详细信息。

从选项中选择 Git 并拥有源代码。添加我们的 Git 存储库链接 - https://github.com/pavanbelagatti/argocd-example-apps

注意：上面显示的是我的 GitHub 存储库链接，您应该添加您的存储库链接，即您在本教程开头 fork 的链接。

添加这些详细信息后，请确保添加“匿名”以验证您的详细信息。[顺便说一句，这是一个公共存储库，因此不需要用户名和密码进行身份验证]

确保身份验证成功。

接下来，让我们添加其他必需的 Git 详细信息，如下所示。

选择“Target revision”作为“master”，选择“Path”作为“helm-guestbook”

接下来，选择“Harness Hosted”以测试 GitOps 工作流。您也可以选择自我管理。但在本教程中，我们将选择“Harness Hosted”。

单击“Connect to Cluster”按钮并确保连接成功。

接下来，您将看到最后一步，我们将全部准备好部署应用程序。

单击“Create and Sync Application”。

这是您将输入的 GitOps 仪表板，所有 GitOps 详细信息都将在其中显示。

您将看到“Sync”状态正在运行。

在一两分钟内，我们可以看到成功消息。

您可以从“Resource View”开始检查每个选项卡

这些是下面显示的“App Details”选项卡功能。

在同一选项卡中，您可以看到同步策略，它设置为“手动”，将其更改为“自动”。

这意味着，当 GitHub 存储库发生任何更改时，GitOps 代理将自动选择这些更改，并以自动方式进行同步。

下一个选项卡显示应用程序的同步状态。

你可以看到集群实时应用拓扑图。

这是我们来自示例存储库的 values.yaml 文件。

# Default values for helm-guestbook.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 4

image:
  repository: gcr.io/heptio-images/ks-guestbook-demo
  tag: 0.1
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  path: /
  hosts:
    - chart-example.local
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #  cpu: 100m
  #  memory: 128Mi
  # requests:
  #  cpu: 100m
  #  memory: 128Mi

nodeSelector: {}

tolerations: []

affinity: {}

现在，将 replicaCount: 4 从 4 更改为 5。

您应该看到 GitOps 代理将看到此差异并将应用此差异。突然，应用程序配置不同步。需要一些时间来匹配并返回到正常且成功的同步状态。

可以看到第二个部署为“自动化”，因为我们将同步策略更改为自动化。

在上面的资源视图中，您可以看到副本已匹配到 5，因为我们想要 5 个副本。

由于 GitOps 使用 Git 作为事实来源，它会记录谁提交了什么代码，以及是否有人更改了存储库中的某些内容。您可以从我们的 GitOps 仪表板中看到这一点。

这就是使用 Harness CD 通过 GitOps 方式部署应用程序的直观和简单之处。

Kubernetes GitOps 是处理复杂云原生应用程序部署的绝佳方法。由于它使用开发人员已经知道的像 Git 这样的简单工具，因此可以轻松学习和简化应用程序部署方法。使用 Kubernetes GitOps 使您的应用程序更加稳定、敏捷和高效。立即开始使用 GitOps！

“GitOps”和“服务网格”可能不是你立即想到的东西 - 但也许它们应该是！这两种截然不同的技术各自具有巨大的独立能力，并且它们结合起来提供的远远超过它们各部分的总和。在这篇博文中，我将向您介绍在现实世界中同时使用 Flux、Flagger 和 Linkerd 以实现成功的 GitOps 需要了解的内容。

我们为什么在这里？​

不过，首先，让我们谈谈在静态文本博客文章的结构中我们能做什么和不能做什么。这篇文章本身不会让你成为 GitOps 专家。GitOps 很复杂，实践没有实际的替代品。你不能通过阅读博客文章来获得这一点。

不过，我们在这里可以提供的是仔细研究使 GitOps 实际工作的好、坏和丑陋。我们将讨论概念和惯例，讨论哪些有效，哪些无效，我们将使您能够充分利用您以后投入的实践

最后，不要忘记我们有一个现成的演示存储库供您练习！您可以在 https://github.com/BuoyantIO/gitops-linkerd 中找到它 - 查看其 README.md 以获取完整说明。

GitOps 简介​

如果你是 GitOps 的新手，你可能会发现所有关于“持续部署”和“单一不可变事实来源”的定义都令人困惑。出于我们的目的查看 GitOps 的一种简单方法是，这是一种管理集群配置的方法，方法是将我们想要的配置放在 git 存储库中，然后拥有使集群与存储库匹配的软件。

换句话说，您不会通过运行 kubectl apply 来更改集群：使用 Git 提交来进行更改。

这似乎是一种倒退，但这是完成生产中非常重要的两件事的绝佳方式：

• 您始终可以确切地知道您的集群正在运行什么配置。
• 您始终可以知道谁进行了特定更改。

这两件事为许多好东西打开了大门，因为了解集群的状态意味着您可以轻松复制它。知识就是力量。在引擎盖下，我们将使用来自WeaveWorks的Flux和Flagger来完成这项工作。

Flux​

Kubernetes 集群无法与 git 存储库进行本机交互。Flux 是一种弥合差距的工具：Flux 代理在群集中运行，并监视存储库和群集中的更改。每当它注意到更改（在任一位置）时，它都会执行任何需要执行的操作以使群集看起来像存储库。

注意：Flux 只会使集群看起来像存储库。没有规定走另一个方向，因为这将是一个糟糕的主意！GitOps 的全部意义在于 git 存储库包含您想要的状态的真相，因此允许存储库修改它不会是一种反模式。

Flux 相当简单：它可以从 GitHub 或 GitLab 读取 Git 存储库，并将其指向存储库中的目录，该目录包含定义 Flux Kustomization 的 YAML 文件。库造口定义包括三个关键组件：

• 源告诉 Flux 去哪里读取集群中应该存在的基本资源。源可以是 Git 存储库或 Helm 图表中的目录。
• 一组可选的补丁（标准 JSONpatch 定义）告诉 Flux 如何在将基本资源应用于集群之前对其进行修改。
• 一个可选的依赖项列表告诉 Flux 在应用此依赖项之前必须应用哪些其他 Kustomization。

这三者的组合非常强大，同时相对简单（尽管我将是第一个承认JSONpatch并不总是令人愉快的使用）。稍后，我们将深入探讨如何处理 Kustomization，以及典型的 Kustomization 可能是什么样子。

Flagger​

Flagger是Flux的姊妹篇，专门处理渐进式交付。这个想法是，当您部署工作负载的新版本时，您应该慢慢地将流量增加到它以确保新版本能够正常工作，而不是立即将所有流量削减到新的（可能损坏的）版本。

Flagger最初看起来很奇怪的是，您没有明确提供“请立即进行渐进式推出”的资源。相反，您只需编辑一个部署，Flagger 就会从那里获取它：它会注意到对其管理下的对象的任何更改，并自动调整集群中的内容以设置渐进式部署。

这意味着 Flagger 需要一种方法来控制流向新版本的流量。它不会直接执行此操作：相反，它需要更改系统其他部分的配置以实际进行流量转移。Flagger对此有几种不同的选择：

• 对于调用图顶部的工作负载，它可以直接与多个入口控制器一起使用;
• 它可以对调用图中任何位置的流量使用 SMI 流量拆分;或
• 它可以使用Gateway API HTTPRoutes。

（目前，Linkerd依赖于SMI TrafficSplit机制。稍后会详细介绍。

Linkerd​

如果您之前没有运行过 Linkerd，它是一个服务网格：一个在平台级别提供安全性、可靠性和可观测性功能的基础结构层，而无需修改您的应用程序。事实上，它是目前唯一的 CNCF 分级服务网格，可提供出色的安全性、一流的操作简便性和任何生产服务网格中最小的开销。

与大多数其他网格一样，Linkerd 的工作原理是在每个工作负载容器旁边放置一个 sidecar 代理，并允许 sidecar 拦截进出工作负载的所有流量。这种低级访问使 Linkerd 能够对集群中网络通信的情况进行巨大的控制和可见性。

Linkerd 同时支持 SMI TrafficSplit 资源和（从 2.12 开始）网关 API HTTPRoute 资源。但是，在 2.12 和 2.13 中，Linkerd 的 HTTPRoute 支持是有限的，这意味着 Flagger 需要使用 SMI TrafficSplit 接口。

付诸实践：Flux​

与许多事情一样，从基本理论到实际实践的跳跃可能很棘手。一个好的开始方法是使用上面提到的演示存储库，https://github.com/BuoyantIO/gitops-linkerd。它的 README.md 提供了有关如何运行一切的完整说明，但让我们在这里也了解亮点和陷阱。

首先，您需要有一个空集群、一个有效的 kubectl 命令和 flux CLI。查看 https://fluxcd.io/flux/installation/ 以获取完整说明，但在 Mac 和 Linux 上的简单方法是 brew install fluxcd/tap/flux 。

存储库布局和 flux bootstrap​

需要了解的非常重要的一点是，在使用 Flux 时，您通常会设置所有 Kustomization，将 Flux 安装到本地机器上，然后运行 flux bootstrap 告诉 Flux 为您设置集群中的所有内容！任何时候都不需要手动设置群集。

运行 flux bootstrap 时，您告诉 Flux 要使用的 git 存储库，以及该存储库中的分支和路径，以开始在存储库中查找其配置。这就引出了两个非常重要的点：

• Flux 需要访问你的 Git 存储库，这通常意味着它需要访问 GitHub 或 GitLab，这意味着你需要设置一个访问令牌供 Flux 使用。有关此处的完整详细信息，请查看 https://fluxcd.io/flux/installation/#bootstrap - 但问题是 Flux 需要能够写入和读取（例如，使用 GitHub 需要能够创建部署密钥）。请仔细阅读有关设置令牌的权限的信息。
• 如果你想理解一个 Flux 设置，你需要知道给了 flux bootstrap 什么分支和路径，这样你就会知道从哪里开始阅读以了解发生了什么。

在这篇博文中，我们不会包含 gitops-linkerd 的完整 flux bootstrap 命令：我们希望专注于概念和陷阱，而不是设置 Git 权限等的所有细节。查看 gitops-linkerd 存储库中的 README.md ，了解所有引导程序详细信息。

但是，在我们的 gitops-linkerd 存储库配置中非常值得一看。其配置的起点是 main 分支上的 clusters/my-cluster 目录，你将在其中找到群集基础结构所需的所有定义以及对应用程序本身的另一个存储库的引用。如果要将其用于自己的 Flux/Flagger/Linkerd 设置，一个好的开始是保留群集基础结构，但将应用程序定义替换为您自己的定义。

• infrastructure.yaml 告诉 Flux 要设置的集群基础架构;
• apps.yaml 告诉 Flux 我们想要在该基础架构上运行的应用程序;和
• flux-system 是自定义 Flux 本身的目录。在这篇博文中，我们不会进入 flux-system ，但很高兴知道它是什么。

“基础架构”和“应用程序”之间的划分是模糊的，而且在很大程度上是约定俗成的，但如果您想使用 gitops-linkerd 作为您自己的集群定义的基础，您可以先关注 apps.yaml ，而不考虑集群基础设施。

gitops-linkerd 集群基础架构​

infrastructure.yaml 为群集基础结构定义了五个单独的组件。其中每个都由此 YAML 文件中的单独文档表示：

• cert-manager
• Linkerd
• NGINX
• Flagger
• Weave GitOps

（回想一下，Flux本身是我们唯一手动安装的东西。此外，Weave GitOps 是 Flux 的仪表板;在 https://www.cncf.io/blog/2023/04/24/how-to-use-weave-gitops-as-your-flux-ui/ 查看。

重要的是， infrastructure.yaml 还定义了这些组件之间的依赖关系;这是Flux的一个特别强大的方面。我们将在这里快速浏览前两个元素： cert-manager 和 linkerd 。

cert-manager​

infrastructure.yaml 中的第一个文档如下所示：

---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: cert-manager
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  prune: true
  wait: true
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/cert-manager

这里有几件事需要了解：

name: cert-manager sets the name of the Kustomization. This is how we’ll refer to this component when describing dependencies.

namespace: flux-system places the Kustomization itself in the flux-system namespace; this does not mean that cert-manager will live in flux-system, though.

按照惯例， flux-system 是群集基础结构核心元素的主页，其他命名空间用于应用程序。

• 没有 dependsOn 属性，因此此库斯托姆化不依赖于任何东西。
• sourceRef 有点神奇：提到 flux-system GitRepository 实际上意味着“与 Kustomization 本身相同的 Git 存储库”。
• path: ./infrastructure/cert-manager 告诉我们在源中的哪个位置查找此 Kustomization 的更多文件。
• wait: true 表示 Flux 将等待安装的所有内容准备就绪，然后再继续其他库Kustomizations。
• interval: 1h 表示 Flux 将每小时检查一次，以查看是否有需要处理的新更改。

如果我们查看 ./infrastructure/cert-manager ，我们会找到一些文件：

kustomization.yaml
namespace.yaml
release.yaml
repository.yaml

开始阅读的地方始终是 kustomization.yaml ，这在这里很简单：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: cert-manager
resources:
  - namespace.yaml
  - repository.yaml
  - release.yaml

这会告诉 Flux 应用这三个 YAML 文件。我们不会在这里深入探讨它们 - gitops-linkerd 演示更详细 - 但重要的是要知道

• namespace.yaml 创建 cert-manager 命名空间;
• repository.yaml 告诉 Flux 到 helm repo add 一个 Helm 存储库;和
• release.yaml 告诉 Flux 到 helm install 一个由 repository.yaml 添加的存储库中的图表。

请注意，这实际上是一个无序列表： kustomize 会自动对所有这些文件中包含的所有资源进行排序，以确保它正在使用的资源按正确的顺序应用。

我们将在 gitops-linkerd 演示本身中深入研究这些文件，除了一个注意事项：如果您查看 repository.yaml 和 release.yaml ，您会发现它们在 cert-manager 命名空间中定义资源，而不是 flux-system 命名空间。这是您将一次又一次看到的模式：Kustomization 管理的资源应位于适合所管理组件的命名空间中。

因此，要从中获取的三个重要概念是：

• 您不必在 Kustomization 中应用任何补丁，尽管它的名字。
• 您可以在 Kustomization 中应用 Kubernetes 资源和更高级别的 Flux 资源。
• Kustomization 创建和管理的资源属于组件的相应命名空间，而不是 flux-system 。

当您查看 gitops-linkerd 定义时，您会一遍又一遍地看到这些相同的概念。

The linkerd component​

infrastructure.yaml 中的第二个文档定义了 linkerd 个组件：

---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: linkerd
  namespace: flux-system
spec:
  dependsOn:
    - name: cert-manager
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  prune: true
  wait: true
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/linkerd

其中大部分与 cert-manager Kustomization 一致：我们有一个 name ，我们仍然在 flux-system 命名空间中，我们会在 ./infrastructure/linkerd 中找到更多文件，等等。

主要区别在于新的 dependsOn 属性，它表示 linkerd Kustomization取决于 cert-manager Kustomization。（另请注意， dependsOn 采用数组值，因此您可以列出许多依赖项。这是 Flux 最强大的功能之一：定义复杂的开始排序只是解释什么取决于什么，然后让 Flux 完成所有艰苦的工作。

快速浏览一下 ./infrastructure/linkerd 目录，我们会发现比 cert-manager 要阅读的内容要多得多：

README.md
ca.crt
ca.key
kustomization.yaml
kustomizeconfig.yaml
linkerd-certs.yaml
linkerd-control-plane.yaml
linkerd-crds.yaml
linkerd-smi.yaml
linkerd-viz.yaml
namespaces.yaml
repositories.yaml

不过，和以前一样，开始阅读的地方仍然是 kustomization.yaml 。它更复杂，因为我们正在安装四个独立的 Linkerd 组件（它的 CRD、控制平面、SMI 扩展和可视化扩展），我们需要将 Linkerd 配置为使用来自 cert-manager 的自定义机密 - 但您将能够看到它们全部布置在文件中。

同样，我们主要将深入探讨留给 gitops-linkerd 演示，但值得指出的是， cert-manager Kustomization 有一个 repository.yaml 文件， linkerd Kustomization 有 repositories.yaml ，名称是复数的。名称对 Flux 来说根本不重要，因为它必须在 kustomization.yaml 中明确列出：这意味着您可以自由选择名称来帮助后来的读者了解正在发生的事情。

infrastructure.yaml 文件中还有很多内容，但我们将把其余部分留给 gitops-linkerd 演示和您自己的阅读。让我们继续使用该应用程序。

更多​

https://www.cncf.io/blog/2023/05/25/real-world-gitops-with-flux-flagger-and-linkerd/

什么是 Argo CD​

ArgoCD 是使用 Kubernetes 持续交付的流行工具。它通过不断协调 repo 的状态与实时工作负载，自动将应用程序部署到 Kubernetes 集群中。

GitOps模型是Argo设计中不可或缺的一部分。它使 repo 成为应用程序所需状态的单一事实来源。应用所需的所有 Kubernetes 清单、Kustomize 模板、Helm charts 和配置文件都应提交到您的存储库。这些资源“声明”应用的成功部署。

Argo 将声明的状态与集群中实际运行的状态进行比较，然后应用正确的更改来解决任何差异。此过程可以配置为自动运行，防止集群偏离存储库。每当出现差异时，Argo 都会重新同步状态，例如在您手动运行 Kubectl 命令之后。

Argo带有CLI和Web UI。它支持多租户和多集群环境，与 SSO 提供程序集成，生成审计跟踪，并可以实施复杂的 rollout 策略，例如 Canary 部署和蓝/绿升级。它还提供集成的回滚功能，因此您可以快速从部署故障中恢复

从历史上看，大多数 CI/CD 实现都依赖于推送驱动行为。这需要您将集群连接到 CI/CD 平台，然后在管道中使用 Kubectl 和 Helm 等工具来应用 Kubernetes 的更改

Argo是一个基于拉动的CI / CD系统。它运行在您的 Kubernetes 集群中，并从您的存储库中提取源代码。然后，Argo 无需手动配置管道即可为您应用更改。

此模型比基于推送的工作流更安全。您不必公开集群的 API 服务器或在 CI/CD 平台中存储 Kubernetes credentials。破坏源存储库只会使攻击者能够访问您的代码，而不是你的集群。

为什么选择Argo CD？​

应用程序定义、配置和环境应具有声明性和版本控制。应用程序部署和生命周期管理应该是自动化的、可审计的且易于理解的。

快速入门​

前置条件​

• 安装 kubectl 命令行工具
• 有一个 kubeconfig 文件（默认位置是 ~/.kube/config）

安装命令​

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

这将创建一个新的命名空间 argocd ，Argo CD 服务和应用程序资源将驻留在其中。

此默认安装将具有自签名证书，如果不进行一些额外的工作，则无法访问。执行以下操作之一：

• 按照说明配置证书（并确保客户端操作系统信任它）
• 将客户端操作系统配置为信任自签名证书
• 在本指南中的所有 Argo CD CLI 操作上使用 --insecure 标志

Argo的所有组件可能需要几秒钟才能在您的集群中运行。通过使用 Kubectl 列出 argocd 命名空间中的部署来监视进度。

$ kubectl get deployments -n argocd
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
argocd-applicationset-controller   1/1     1            1           67s
argocd-dex-server                  1/1     1            1           67s
argocd-notifications-controller    1/1     1            1           67s
argocd-redis                       1/1     1            1           67s
argocd-repo-server                 1/1     1            1           67s
argocd-server                      1/1     1            1           67s

Kubectl 端口转发也可用于连接到 API 服务器，而无需公开服务

kubectl port-forward svc/argocd-server -n argocd 8080:443

实际示例：使用 Argo CD 部署到 Kubernetes​

让我们使用 Argo 在 Kubernetes 中运行一个基本的 NGINX Web 服务器实例。我们假设您已经可以访问 Kubernetes 集群，并且您的机器上已经拥有可用的 Kubectl 和 Helm CLI。

创建应用的 GitHub 存储库​

首先，前往 GitHub 并为您的应用程序创建一个新的存储库。之后，将您的存储库克隆到您的计算机，准备提交您的 Kubernetes 清单

$ git clone https://github.com/<username>/<repo>.git

复制以下 YAML 并将其另存为 deployment.yaml 在存储库中

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: argo-demo
  labels:
    app.kubernetes.io/name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
          - name: http
            containerPort: 80

它定义了一个运行三个 NGINX 副本的基本 Kubernetes 部署对象

接下来，复制第二个 YAML 文件并将其保存到 service.yaml 。它会设置负载均衡器服务以在群集外部公开部署

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: argo-demo
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: http

最后，添加一个将创建应用程序命名空间的清单：

apiVersion: v1
kind: Namespace
metadata:
  name: argo-demo

将更改提交到存储库，然后将其推送到 GitHub：

$ git add .
$ git commit -m "Added initial Kubernetes YAML files"
$ git push

您已准备好安装 Argo 并开始部署您的应用程序。

获取 Argo 命令行界面​

Argo的CLI允许您从终端与应用程序进行交互。稍后您将需要它来向 Argo 实例注册您的应用程序。

您可以从 GitHub 下载最新的 CLI 版本。为您的平台选择正确的二进制文件，然后使其可执行并将其移动到路径中的某个位置。以下步骤适用于大多数 Linux 系统 - 首先替换最新版本号而不是下面的 2.6.1：

$ wget https://github.com/argoproj/argo-cd/releases/download/v2.6.1/argocd-linux-amd64
$ chmod +x argocd-linux-amd64
$ mv argocd-linux-amd64 /usr/bin/argocd

在登录之前，您需要检索默认管理员用户的密码。这是在Argo的安装过程中自动生成的。可以通过运行以下 argocd 命令来访问它：

使用这些凭据登录到Argo

进入后，直接转到左侧边栏中的“用户信息”项，然后单击屏幕顶部的“更新密码”按钮。按照提示将您的密码更改为唯一的密码

Login to the CLI 登录到命令行界面​

要登录到 Argo CLI，请运行 argocd login 并提供 API 服务器的 URL 作为参数：

$ argocd login localhost:8080

与上面遇到的浏览器警告类似，如果您尚未配置自己的TLS，系统将提示您接受Argo的内置自签名证书：

通过键入 y 并按回车键接受提示。然后，系统会要求您输入用户名和密码。CLI 应成功向您的 Argo 实例进行身份验证：

'admin:login' logged in successfully
Context 'localhost:8080' updated

使用 Argo 部署您的应用程序​

一切准备就绪，可以开始将应用程序部署到 Argo！首先，运行以下 CLI 命令来注册应用：

$ argocd app create argo-demo \
  --repo https://github.com/<username>/<repo>.git \
  --path . \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace argo-demo
application 'argo-demo' created

让我们解释这里发生的事情：

• --repo 标志指定 Git 存储库的 URL。
• --path 标志指示 Argo 在存储库的此路径中搜索 Kubernetes 清单、Helm 图表和其他可部署资产。 此处使用 . 是因为示例清单存储在存储库的根目录中。
• --dest-server 标志指定要部署到的 Kubernetes 群集的 URL。在部署到运行 Argo 的同一群集时，可以使用 kubernetes.default.svc 。
• --dest-namespace 设置应用将部署到的 Kubernetes 命名空间。这应与资源上设置的 metadata.namespace 字段匹配。

您的应用程序现在将在 Argo 中注册。您可以使用 argocd app list 命令检索其详细信息：

NAME              CLUSTER                         NAMESPACE   PROJECT  STATUS     HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                   PATH  TARGET
argocd/argo-demo  https://kubernetes.default.svc  argo-demo   default  OutOfSync  Missing  <none>      <none>      https://github.com/ilmiont/spacelift-argo-cd-demo.git

该应用程序还显示在Argo UI中：

Your First Sync 您的首次同步​

应用显示为“缺失”和“不同步”。创建应用不会自动将其同步到群集中。立即执行同步，让 Argo 应用存储库内容当前定义的目标状态：

$ argocd app sync argo-demo
...
GROUP  KIND        NAMESPACE  NAME       STATUS   HEALTH       HOOK  MESSAGE
       Namespace   argo-demo  argo-demo  Running  Synced             namespace/argo-demo created
       Service     argo-demo  nginx      Synced   Progressing        service/nginx created
apps   Deployment  argo-demo  nginx      Synced   Progressing        deployment.apps/nginx created
       Namespace              argo-demo  Synced                      

同步结果显示在您的终端中。应会看到命名空间、服务和部署对象都同步到群集中，如上面的命令输出所示。所有三个对象的消息都确认它们已成功创建。

重复 apps list 命令以检查应用的新状态

$ argocd app list
NAME              CLUSTER                         NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                   PATH  TARGET
argocd/argo-demo  https://kubernetes.default.svc  argo-demo  default  Synced  Healthy  <none>      <none>      https://github.com/ilmiont/spacelift-argo-cd-demo.git  .   

现在应用程序已同步且健康！它在Argo UI中也是绿色的：

作为最终证明，请使用 Kubectl 检查应用命名空间中的部署。这应确认 nginx 已启动并运行三个副本：

$ kubectl get deployment -n argo-demo
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           7m56s

Syncing App Updates 同步应用更新​

现在，让我们对应用进行更改。修改 deployment.yaml 中的 spec.replicas 字段，以便部署中现在有五个 Pod：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: argo-demo
  labels:
    app.kubernetes.io/name: nginx
spec:
  replicas: 5
  ...

提交并推送更改

$ git add .
$ git commit -m "Run 5 replicas"
$ git push

接下来，重复 argocd app sync 命令以将更改应用于群集。或者，您可以单击用户界面中的“同步”按钮。

Argo 从存储库刷新应用的目标状态，然后执行操作来转换实时状态。部署已重新配置，现在运行五个 Pod：

$ kubectl get deployment -n argo-demo
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   5/5     5            5           12m

启用自动同步​

在重复同步命令之前，对五个副本的更改不适用。不过，Argo 可以自动同步存储库中的更改，无需每次都发出命令。这完全自动化了您的交付工作流程。

您可以通过单击用户界面中的“应用程序详细信息”按钮并向下滚动到“同步策略”部分来激活应用程序的自动同步。单击“启用自动同步”按钮。

还可以通过运行以下命令使用 CLI 启用自动同步：$ argocd app set argo-demo --sync-policy automated

默认情况下，自动同步每三分钟运行一次。如果需要更频繁的部署，您可以通过修改 Argo 的配置映射来更改此值。

总结​

Argo CD 是 Kubernetes 的持续交付工具。它提供基于拉取的 GitOps 工作流，用于自动将源存储库与群集内部署同步。虽然本文只介绍了基础知识，但 Argo 为您提供了一个完整的工具包，用于部署应用程序、检查其运行状况以及快速回滚任何失败的更改。

ps: 友情链接 ： https://spacelift.io/blog/argocd

argo-workflow介绍​

Argo Workflows是一个开源的容器化云原生工作流项目，其主要通过Kubernetes CRD实现的。

特点如下：

• 工作流的每一步都是一个容器
• 将多步骤工作流建模为一系列任务，或者使用有向无环图（DAG）描述任务之间的依赖关系
• 可以在短时间内轻松运行用于机器学习或数据处理的计算密集型作业
• 在Kubernetes上运行CI/CD Pipeline，无需复杂的软件配置

安装​

命令​

要安装 Argo Workflows，请导航至 Release 页面并找到您希望使用的版本（最好是最新的大版本）。

以下是安装命令的示例，请确保替换 ARGO_WORKFLOWS_VERSIO 变量以安装正确的版本号：

kubectl create namespace argo
kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v<<ARGO_WORKFLOWS_VERSION>>/install.yaml

安装好后我们可以使用 kubectl 命令查看 argo 命名空间下的服务，我们可以看到主要是2个服务，argo-server 用来接收前端请求，workflow-controller 用来执行 crd 控制器逻辑。

补丁 argo-server 认证​

argo-server（以及 UI）默认为客户端身份验证，这需要客户端提供其 Kubernetes 承载令牌才能进行身份验证。有关详细信息，请参阅 Argo 服务器身份验证模式文档。我们将身份验证模式切换为 server ，以便我们现在可以绕过 UI 登录：

kubectl patch deployment \
  argo-server \
  --namespace argo \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
  "server",
  "--auth-mode=server"
]}]'

ui界面端口转发​

将ui端口转发到本地

kubectl -n argo port-forward deployment/argo-server 2746:2746 & open https://localhost:2746

我们可以看到argo-workflow的界面啦 ，默认会显示 argo 命名空间下的工作流任务列表。

提交一个最简单的工作流​

提交工作流​

让我们从创建一个非常简单的工作流模板开始，使用来自 Docker Hub 的 docker/whalesay 容器镜像来回应“hello world”

您可以使用简单的 docker 命令直接从 shell 运行它：

$ docker run docker/whalesay cowsay "hello world"
 _____________
< hello world >
 -------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/


Hello from Docker!
This message shows that your installation appears to be working correctly.

我们尝试让argo系统帮助我们运行这个容器，点击argo界面 +SUBMIT NEW WORKFLOW 按钮，将下面的yaml文件，提交到argo系统。

apiVersion: argoproj.io/v1alpha1
kind: Workflow                  # 自定义类型
metadata:
  generateName: hello-world-   
spec:
  entrypoint: whalesay          # 入口
  templates:
    - name: whalesay              # 模版名字
      container:
        image: docker/whalesay
        command: [ cowsay ]
        args: [ "hello world" ]
        resources: # limit the resources
          limits:
            memory: 32Mi
            cpu: 100m

查看工作流​

我们可以看到界面上多了个绿色的任务，点击右下角的Logs按钮，我们能查看容器中的日志，打印出了我们要的鲸鱼。

多步骤工作流​

如果我们想执行多个工作流，如何做呢？试试提交下下面的yaml文件吧！

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: steps-
spec:
  # 程序入口模版名字
  entrypoint: hello-hello-hello

  # 包含两个模版: hello-hello-hello and whalesay
  templates:
  - name: hello-hello-hello
    # 这个模版有好几个步骤，hello1 先执行
    steps:
    - - name: hello1            # hello1 先执行
        template: whalesay
        arguments:
          parameters:
          - name: message
            value: "hello1"
    - - name: hello2a           # 在hello1后执行
        template: whalesay
        arguments:
          parameters:
          - name: message
            value: "hello2a"
      - name: hello2b           # 与hello02a并发执行
        template: whalesay
        arguments:
          parameters:
          - name: message
            value: "hello2b"

  
  - name: whalesay
    inputs:
      parameters:
      - name: message
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["{{inputs.parameters.message}}"]

看图秒懂！我们创建了3个任务，hello2b 和 hello2a 在 hello1 任务之后并发执行。同时这三个任务接受的参数不同，打印的结果也不同哦！

4大模版​

argo-workflow 系统重定义的模版有4种类别，如下：

Container​

也许是最常见的模板类型，它会调度一个容器。模板的规范与 Kubernetes 容器规范相同，因此您可以像在 Kubernetes 中的其他任何地方一样在这里定义容器。

  - name: whalesay
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["hello world"]

Script​

执行脚本，添加了 source: 字段，允许您就地定义脚本。该脚本将保存到一个文件中并为您执行。脚本的结果会自动导出到 变量 {{steps.<NAME>.outputs.result}} 中，你可以在下一阶段使用这个结果。

  - name: gen-random-int
    script:
      image: python:alpine3.6
      command: [python]
      source: |
        import random
        i = random.randint(1, 100)
        print(i)

Resource​

直接对集群资源进行操作。它可用于获取、创建、应用、删除、替换或修补集群上的资源。此示例在集群上创建一个 ConfigMap 资源

  - name: k8s-owner-reference
    resource:
      action: create
      manifest: |
        apiVersion: v1
        kind: ConfigMap
        metadata:
          generateName: owned-eg-
        data:
          some: value

Suspend​

暂停模板将暂停工作流的执行，持续一段时间或直到手动恢复。用户可以使用 cli、API 接口或 UI点击操作来恢复暂停的工作流，让其继续执行。

  - name: delay
    suspend:
      duration: "20s"

2大流程控制​

Steps​

steps 模板允许您在一系列 steps 中定义您的任务。模板的结构是“列表的列表”。外部列表将按顺序运行，内部列表将并行运行。如果要逐一运行内部列表，请使用同步功能。您可以设置各种选项来控制执行，例如 when: 子句以有条件地执行步骤。 在此示例中， step1 首先运行。完成后， step2a 和 step2b 将并行运行：

  - name: hello-hello-hello
    steps:
    - - name: step1
        template: prepare-data
    - - name: step2a
        template: run-data-first-half
      - name: step2b
        template: run-data-second-half

Dag​

dag 模板允许您将任务定义为依赖关系图。在 DAG 中，您列出所有任务并设置在特定任务开始之前必须完成哪些其他任务。没有任何依赖关系的任务将立即运行。在此示例中， A 首先运行。一旦完成， B 和 C 将并行运行，一旦它们都完成， D 将运行：

  - name: diamond
    dag:
      tasks:
      - name: A
        template: echo
      - name: B
        dependencies: [A]
        template: echo
      - name: C
        dependencies: [A]
        template: echo
      - name: D
        dependencies: [B, C]
        template: echo

CI 示例​

一般将代码构建成镜像，有两种方式 ，一种是dind，一种是使用本地构建工具，比如 kaniko，buildkit等工具。这里我们展示如何使用argo-workflow 来构建镜像。

# in a workflow. The resource template type accepts any k8s manifest
# (including CRDs) and can perform any `kubectl` action against it (e.g. create,
# apply, delete, patch).
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: k8s-jobs-
spec:
  serviceAccountName: default
  entrypoint: pi-tmpl
  templates:
  - name: pi-tmpl
    resource:                   # indicates that this is a resource template
      action: create            # can be any kubectl action (e.g. create, delete, apply, patch)
      # The successCondition and failureCondition are optional expressions.
      # If failureCondition is true, the step is considered failed.
      # If successCondition is true, the step is considered successful.
      # They use kubernetes label selection syntax and can be applied against any field
      # of the resource (not just labels). Multiple AND conditions can be represented by comma
      # delimited expressions.
      # For more details: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
      successCondition: status.succeeded > 0
      failureCondition: status.failed > 3
      manifest: |               #put your kubernetes spec here
        apiVersion: v1
        kind: Pod
        metadata:
          generateName: kaniko-pod
        spec:
          containers:
            - name: kaniko
              image: gcr.io/kaniko-project/executor:debug
              args:
                - "--dockerfile=Dockerfile"
                - "--context=git://github.com/mouuii/golang-dockerfile.git#refs/heads/main"
                - "--destination=上传到镜像仓库地址"
              volumeMounts:
                - name: kaniko-secret
                  mountPath: "/kaniko/.docker"
              env:
                - name: GOOGLE_APPLICATION_CREDENTIALS
                  value: /secret/kaniko-secret.json
          restartPolicy: Never
          volumes:
            - name: kaniko-secret
              secret:
                secretName: dockersecret
                items:
                - key: .dockerconfigjson
                  path: config.json

我们使用argo-workflow简单创建一个镜像，传入 dockersecret 和代码仓库地址，执行后，会将我们的代码打包成镜像并上传到我们配置的镜像仓库地址，如果不熟悉，可以去百度下 kaniko。

个人感受​

概念太多，使用姿势太多，很多东西看的出都是功能的堆叠，并没有一个很好的兼容，上手成本比较高。

工作流分类​

1. 工艺产品流水线
2. 团队协作流程
3. 软件开发工作流
4. 应用平台工作流

工艺产品流水线​

马斯克在2017年的一次财报会上说过："最难的产品不是车，而是制造车的工厂，发现像福特流水线那样的造车方式！"。事实上高度自动化的流水线是所有汽车制造工厂的核心引擎，能够大幅度提升造车产能同时降低成本，是企业的核心命脉！

团队协作流程​

在公司内部，我们日常使用的OA系统中，众多精致的工作流程支持着企业每日数万员工的请假、报销、入职等事务。

软件开发工作流​

在软件开发中，工作流是一个描述从项目开始到最终部署的一系列任务和步骤的过程。它涵盖了整个软件开发生命周期（SDLC），包括需求分析、设计、编码、测试和部署等阶段。工作流的目标是提高开发团队的协同效率，确保软件质量并降低错误风险。

CI/CD工作流​

CI/CD 工作流是指持续集成（Continuous Integration, CI）和持续交付/部署（Continuous Delivery/Deployment, CD）的过程。它是一种自动化软件开发实践，旨在加速软件的构建、测试和发布。CI/CD 工作流有助于提高开发团队的协作效率，降低错误风险，并确保软件质量。

CI/CD 工作流通常包括以下几个阶段：

• 代码提交：开发人员将修改后的代码提交到版本控制系统（如 Git）。
• 持续集成：自动检查新提交的代码，合并到主分支，并触发构建过程.
• 构建：编译源代码，生成可执行文件，打包和准备部署。
• 自动化测试：执行单元测试、集成测试和其他自动化测试，确保软件无缺陷。
• 静态代码分析：检查代码质量和编码规范，提高代码可维护性。
• 部署到预发布环境：将软件部署到类似生产环境的预发布环境，进行验证。
• 持续交付：当软件通过所有测试和验证后，将其部署到生产环境的过程。在持续交付模式下，部署需要手动触发。
• 持续部署：自动将通过所有测试和验证的软件部署到生产环境。这种模式下，部署是完全自动化的，无需人工干预。

CI/CD 工作流的实施通常依赖于专用的工具和平台，如 Jenkins、Travis CI、GitLab CI/CD 和 GitHub Actions 等。这些工具可以帮助团队轻松地自动化构建、测试和部署过程，实现快速、可靠的软件交付。

工作流能力​

在工作流系统中，提供一些常见功能以方便用户对工作流的操作和监控。这些功能使得团队可以更好地控制和管理整个工作流程，以应对各种不同的场景和需求。以下是一些常见的工作流能力：

1. 暂停（Pause）：允许用户在需要的时候暂停工作流的执行。暂停功能可以在调试过程中，或者在需要检查或修改某些参数时使用。
2. 恢复（Resume）：在暂停工作流后，恢复功能允许用户继续执行未完成的任务。恢复操作通常在解决了问题或调整了参数后进行。
3. 取消（Cancel）：取消功能允许用户终止正在进行的工作流。这在遇到错误或需要中止整个流程时非常有用。
4. 重试（Retry）：如果工作流中的某个任务失败，重试功能可以让用户尝试重新执行该任务。这在处理短暂的故障或网络问题时很有用。
5. 回滚（Rollback）：回滚功能允许用户将工作流恢复到之前的稳定状态，以便快速解决问题或撤销错误的更改。
6. 通知（Notification）：工作流系统可以向用户发送通知，提醒他们关于任务完成、失败或其他重要事件的信息。这有助于确保团队及时了解工作流状态并采取相应行动。
7. 条件分支（Conditional Branching）：条件分支功能允许工作流根据特定条件执行不同的任务。这使得工作流能够灵活地处理不同场景和需求。
8. 参数化（Parameterization）：通过参数化，用户可以在不修改工作流本身的情况下调整任务的输入和设置。这有助于实现更高程度的自定义和灵活性。

这些常见的工作流能力有助于团队更有效地管理和监控工作流程，提高生产力并降低错误发生的风险。