🥇OpenShift 的 GitOps 简介

今天我们来谈谈GitOps的原理和模型，以及这些模型如何在OpenShift平台上实现。提供了有关此主题的交互式指南链接.

简而言之，GitOps 是一组使用 Git Pull 请求来管理基础设施和应用程序配置的实践。 GitOps 中的 Git 存储库被视为有关系统状态的单一信息源，并且此状态的任何更改都是完全可跟踪和可审计的。

GitOps 中的更改跟踪的想法绝不是新的；这种方法长期以来在处理应用程序源代码时几乎普遍使用。 GitOps 只是在基础设施和应用程序配置管理中实现类似的功能（评论、拉取请求、标签等），并提供与源代码管理类似的好处。

GitOps 没有学术定义或批准的一套规则，只有一套构建此实践的原则：

系统的声明性描述存储在 Git 存储库中（配置、监控等）。
状态更改是通过拉取请求进行的。
使用 Git 推送请求使正在运行的系统的状态与存储库中的数据保持一致。

GitOps 原则

系统定义被描述为源代码

系统配置被视为代码，因此可以在 Git 存储库中存储并自动进行版本控制，从而充当单一事实来源。这种方法可以轻松地在系统中推出和回滚更改。

系统所需的状态和配置在 Git 中设置和版本控制

通过在 Git 中存储所需的系统状态并对其进行版本控制，我们能够轻松地推出和回滚对系统和应用程序的更改。我们还可以利用Git的安全机制来控制代码所有权并验证其真实性。

配置更改可以通过拉取请求自动应用

使用 Git 拉取请求，我们可以轻松控制如何将更改应用于存储库中的配置。例如，可以将它们提供给其他团队成员进行审查或运行 CI 测试等。

同时，无需左右分配管理权限。要提交配置更改，用户只需要存储这些配置的 Git 存储库中的适当权限。

修复配置不受控制漂移的问题

一旦系统的所需状态存储在 Git 存储库中，我们所要做的就是找到能够确保系统当前状态与其所需状态相匹配的软件。如果情况并非如此，那么该软件应该 - 根据设置 - 自行消除差异，或者通知我们有关配置漂移的信息。

OpenShift 的 GitOps 模型

集群内资源协调器

根据这个模型，集群有一个控制器，负责将 Git 存储库中的 Kubernetes 资源（YAML 文件）与集群的真实资源进行比较。如果检测到差异，控制器会发送通知，并可能采取措施纠正差异。此 GitOps 模型用于 Anthos Config Management 和 Weaveworks Flux。

外部资源协调器（推送）

当我们有一个或多个控制器负责同步“Git 存储库 - Kubernetes 集群”对中的资源时，该模型可以被视为前一个模型的变体。这里的区别在于每个托管集群不一定有自己单独的控制器。 Git - k8s集群对通常被定义为CRD（自定义资源定义），它可以描述控制器应该如何执行同步。在此模型中，控制器将 CRD 中指定的 Git 存储库与 CRD 中指定的 Kubernetes 集群资源进行比较，并根据比较结果执行适当的操作。特别是，ArgoCD 中使用了这个 GitOps 模型。

OpenShift 平台上的 GitOps

多集群 Kubernetes 基础设施的管理

随着 Kubernetes 的普及以及多云策略和边缘计算的日益普及，每个客户的平均 OpenShift 集群数量也在增加。

例如，在使用边缘计算时，一个客户的集群可以部署成百上千个。因此，他被迫在公共云和本地管理多个独立或协调的 OpenShift 集群。

在这种情况下，需要解决很多问题，特别是：

控制集群处于相同的状态（配置、监控、存储等）
根据已知状态重新创建（或恢复）集群。
根据已知状态创建新集群。
将更改推广到多个 OpenShift 集群。
跨多个 OpenShift 集群回滚更改。
将模板化配置链接到不同的环境。

应用程序配置

在其生命周期中，应用程序在最终进入生产集群之前通常会经过一系列集群（开发、阶段等）。此外，由于可用性和可扩展性要求，客户通常跨多个本地集群或公共云平台的多个区域部署应用程序。

在这种情况下，必须解决以下任务：

确保应用程序（二进制文件、配置等）在集群（开发、阶段等）之间移动。
在多个 OpenShift 集群中推出对应用程序（二进制文件、配置等）的更改。
将应用程序的更改回滚到之前的已知状态。

OpenShift GitOps 用例

1. 应用 Git 存储库中的更改

集群管理员可以将 OpenShift 集群配置存储在 Git 存储库中，并自动应用它们来轻松创建新集群，并使它们进入与 Git 存储库中存储的已知状态相同的状态。

2. 与 Secret Manager 同步

管理员还将受益于将 OpenShift 秘密对象与 Vault 等适当软件同步的能力，以便使用专门为此创建的工具来管理它们。

3. 漂移配置的控制

只有当 OpenShift GitOps 本身识别并警告实际配置与存储库中指定的配置之间的差异时，管理员才会赞成，以便他们能够快速响应偏差。

4.有关配置漂移的通知

当管理员想要快速了解配置漂移的情况以便快速自行采取适当的措施时，它们非常有用。

5.漂移时手动同步配置

允许管理员在配置发生偏差时将 OpenShift 集群与 Git 存储库同步，以将集群快速返回到之前的已知状态。

6.漂移时自动同步配置

管理员还可以将 OpenShift 集群配置为在检测到偏差时自动与存储库同步，以便集群配置始终与 Git 中的配置匹配。

7. 多个集群 - 一个存储库

管理员可以将多个不同 OpenShift 集群的配置存储在一个 Git 存储库中，并根据需要有选择地应用它们。

8. 集群配置的层次结构（继承）

管理员可以在存储库中设置集群配置的层次结构（阶段、产品、应用程序组合等，具有继承性）。换句话说，它可以确定是否应将配置应用于一个或多个集群。

例如，如果管理员在 Git 存储库中设置层次结构“生产集群（prod）→系统 X 集群→系统 X 的生产集群”，则以下配置的组合将应用于系统 X 的生产集群：

所有生产集群通用的配置。
System X 集群的配置。
X 系统生产集群的配置。

9. 模板和配置覆盖

管理员可以覆盖一组继承的配置及其值，例如，微调将应用它们的特定集群的配置。

10. 配置、应用程序配置的选择性包含和排除

管理员可以设置对具有某些特性的集群应用或不应用某些配置的条件。

11. 模板支持

开发人员将受益于选择如何定义应用程序资源（Helm Chart、纯 Kubernetes yaml 等）的能力，以便为每个特定应用程序使用最合适的格式。

OpenShift 平台上的 GitOps 工具

阿尔戈CD

ArgoCD 实现了外部资源协调模型，并提供了一个集中式 UI，用于协调集群和 Git 存储库之间的一对多关系。该程序的缺点包括当 ArgoCD 不工作时无法管理应用程序。

官方网站

流

Flux 实现了集群内资源协调模型，因此没有对定义存储库进行集中管理，这是一个弱点。另一方面，正是由于缺乏集中化，即使一个集群发生故障，管理应用程序的能力仍然存在。

官方网站

在 OpenShift 上安装 ArgoCD

ArgoCD 提供了出色的命令行界面和 Web 控制台，因此我们不会在这里介绍 Flux 和其他替代方案。

要在 OpenShift 4 平台上部署 ArgoCD，请以集群管理员身份执行以下步骤：

在OpenShift平台上部署ArgoCD组件

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

改进 ArgoCD 服务器，使其可以被 OpenShift Route 看到

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

部署ArgoCD CLI工具

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

更改ArgoCD服务器管理员密码

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

完成这些步骤后，您可以通过 ArgoCD WebUI Web 控制台或 ArgoCD Cli 命令行工具使用 ArgoCD Server。
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - 永远不会太晚

“火车已经开走了”——这是他们在错过做某事的机会时所说的情况。就 OpenShift 而言，想要立即开始使用这个很酷的新平台的愿望常常会在管理和维护路由、部署和其他 OpenShift 对象时造成这种情况。但机会总是完全丧失吗？

继续有关的系列文章 Git 操作，今天我们将向您展示如何将手工制作的应用程序及其资源转变为一切都由 GitOps 工具管理的流程。为此，我们首先手动部署 httpd 应用程序。下面的屏幕截图显示了我们如何创建命名空间、部署和服务，然后公开该服务以创建路由。

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

所以我们有一个手工制作的应用程序。现在它需要在 GitOps 管理下转移，而不损失可用性。简而言之，它是这样做的：

为代码创建一个 Git 存储库。
我们导出当前对象并将它们上传到 Git 存储库。
选择和部署 GitOps 工具。
我们将存储库添加到该工具包中。
我们在 GitOps 工具包中定义应用程序。
我们使用 GitOps 工具包对应用程序进行测试运行。
我们使用 GitOps 工具包同步对象。
启用对象的修剪和自动同步。

如前所述文章，在 GitOps 中，有关 Kubernetes 集群中所有对象的信息只有一个来源 - Git 存储库。接下来，我们的前提是您的组织已经使用 Git 存储库。它可以是公共的或私有的，但必须可供 Kubernetes 集群访问。这可以是与应用程序代码相同的存储库，也可以是专门为部署创建的单独存储库。建议在存储库中拥有严格的权限，因为秘密、路由和其他安全敏感的内容将存储在那里。

在我们的示例中，我们将在 GitHub 上创建一个新的公共存储库。您可以随意称呼它，我们使用名称 blogpost。

如果 YAML 对象文件未存储在本地或 Git 中，则必须使用 oc 或 kubectl 二进制文件。在下面的屏幕截图中，我们为命名空间、部署、服务和路由请求 YAML。在此之前，我们克隆了新创建的存储库并 cd 到其中。

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

现在让我们编辑deployment.yaml文件以删除Argo CD无法同步的字段。

sed -i '/sgeneration: .*/d' deployment.yaml

另外，路线也需要改变。我们首先设置一个多行变量，然后用该变量的内容替换 ingress: null 。

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

至此，我们已经整理好了文件，剩下的就是将它们保存到 Git 仓库了。此后，该存储库成为唯一的信息源，并且严格禁止对对象进行任何手动更改。

git commit -am ‘initial commit of objects’
git push origin master

此外，我们从您已经部署 ArgoCD 的事实出发（如何执行此操作 - 请参阅前面的内容）邮寄）。因此，我们将向 Argo CD 添加我们创建的存储库，其中包含示例中的应用程序代码。只需确保指定您之前创建的确切存储库即可。

argocd repo add https://github.com/cooktheryan/blogpost

现在让我们创建应用程序。应用程序设置值，以便 GitOps 工具包了解要使用哪个存储库和路径、需要哪个 OpenShift 来管理对象、需要存储库的哪个特定分支以及资源是否应该自动同步。

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

一旦在 Argo CD 中指定了应用程序，工具包就会开始根据存储库中的定义检查已部署的对象。在我们的示例中，自动同步和清理已禁用，因此元素尚未更改。请注意，在 Argo CD 界面中，我们的应用程序将处于“不同步”状态，因为 ArgoCD 没有提供标签。
这就是为什么当我们稍后开始同步时，对象将不会被重新部署。

现在让我们进行测试运行以确保我们的文件中没有错误。

argocd app sync simple-app --dry-run

如果没有错误，则可以继续同步。

argocd app sync simple-app

在我们的应用程序上运行 argocd get 命令后，我们应该看到应用程序状态已更改为 Healthy 或 Synced。这意味着 Git 存储库中的所有资源现在都与已部署的资源相对应。

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

现在，您可以启用自动同步和清理，以确保不会手动创建任何内容，并且每次创建对象或将对象更新到存储库时都会进行部署。

argocd app set simple-app --sync-policy automated --auto-prune

因此，我们成功地将一个应用程序置于 GitOps 控制之下，该应用程序最初并未以任何方式使用 GitOps。

来源： habr.com

OpenShift 的 GitOps 简介