🥇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。

來源： www.habr.com

OpenShift 的 GitOps 簡介