OpenShift 向け GitOps の紹介

本日は、GitOpsの原則とモデル、そしてこれらのモデルがOpenShiftプラットフォーム上でどのように実装されているかについて解説します。このトピックに関するインタラクティブガイドはこちらをご覧ください。 リンク.

簡単に言うと、GitOpsとは、Gitプルリクエストを用いてインフラストラクチャとアプリケーションの構成を管理するための一連のプラクティスです。GitOpsは、Gitリポジトリをシステムの状態に関する単一の情報源として扱い、その状態へのあらゆる変更を完全に追跡・監査可能にします。

GitOpsにおける変更追跡の考え方は新しいものではなく、アプリケーションのソースコードを扱う際に、このアプローチは長年にわたりほぼ普遍的に使用されてきました。GitOpsは、インフラストラクチャとアプリケーションの構成を管理する際に、ソースコード管理と同様の機能（レビューチェック、プルリクエスト、タグなど）を実装するだけで、ソースコード管理と同様のメリットを提供します。

GitOps には学術的な定義やルールセットはなく、実践を導く一連の原則のみがあります。

• システムの宣言的な説明は Git リポジトリ (構成、監視など) に保存されます。
• 状態の変更はプル リクエストを通じて行われます。
• 実行中のシステムの状態は、Git プッシュ リクエストを使用してリポジトリ内のデータと一致されます。

GitOpsの原則

• システム定義はソースコードとして記述されます。

システム構成はコードとして扱われるため、Gitリポジトリに保存され、自動的にバージョン管理されます。Gitリポジトリは、信頼できる唯一の情報源として機能します。このアプローチにより、システムへの変更のロールアウトとロールバックが容易になります。

• システムの望ましい状態と構成はGitで定義され、バージョン管理されます。

システムの望ましい状態をGitに保存し、バージョン管理することで、システムやアプリケーションへの変更を簡単にロールバックしたりロールバックしたりできます。また、Gitのセキュリティメカニズムを使用して、コードの所有権を管理し、その信頼性を検証することもできます。

• プルリクエストを使用して構成の変更を自動的に適用できます

Gitのプルリクエストを使用すると、リポジトリ内の設定への変更の適用方法を簡単に制御できます。例えば、他のチームメンバーによるレビューやCIテストの実行などが可能です。

管理者権限をあれこれと与える必要もありません。設定の変更をコミットするには、設定が保存されているGitリポジトリに対する適切な権限があれば十分です。

• 制御不能な構成ドリフトの問題を修正

システムの望ましい状態がGitリポジトリに保存されたら、あとはシステムの現在の状態が望ましい状態と一致しているかどうかを監視するソフトウェアを見つけるだけです。もし一致していない場合、このソフトウェアは設定に応じて、矛盾を自動的に修正するか、構成のずれについて通知するはずです。

OpenShift 向け GitOps モデル

クラスタ内リソース調整ツール

このモデルでは、クラスタにはGitリポジトリ内のKubernetesリソース（YAMLファイル）と実際のクラスタリソースを比較するコントローラが存在します。不一致が検出されると、コントローラは通知を送信し、場合によっては不一致を解決するためのアクションを実行します。このGitOpsモデルは、Anthos Config ManagementとWeaveworks Fluxで使用されています。

外部リソースリコンサイラ（プッシュ）

このモデルは、GitリポジトリとKubernetesクラスターのペアでリソース同期を担当する8つ以上のコントローラーを持つ、前述のモデルのバリエーションと考えることができます。ここでの違いは、各マネージドクラスターが必ずしも個別のコントローラーを持つ必要がないことです。GitとKubernetesクラスターのペアは、多くの場合CRD（カスタムリソース定義）として定義され、コントローラーがどのように同期を実行するかを記述できます。このモデルでは、コントローラーはCRDで指定されたGitリポジトリと、同じくCRDで指定されたKubernetesクラスターリソースを比較し、比較結果に基づいて適切なアクションを実行します。特に、このようなGitOpsモデルはArgoCDで使用されています。

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. 複数のクラスター – XNUMXつのリポジトリ

管理者は、複数の異なる OpenShift クラスターの構成を単一の Git リポジトリに保存し、必要に応じて選択的に適用できます。

8. クラスタ構成の階層（継承）

管理者はリポジトリ内でクラスター設定の階層（ステージ、本番、アプリポートフォリオなど、継承を含む）を定義できます。つまり、設定をどのように適用するか（1つまたは複数のクラスター）を決定できます。

たとえば、管理者が Git リポジトリに階層を定義した場合、「本番クラスター (prod) → システム X のクラスター → システム X の本番クラスター」、システム X の本番クラスターに対して次の構成が結合されます。

• すべての本番環境クラスターに共通の構成。
• X システム クラスターの構成。
• X システムの運用クラスターの構成。

9. テンプレートとオーバーライド構成

管理者は、継承された構成とその値のセットをオーバーライドして、たとえば、それらが適用される特定のクラスターの構成を微調整できます。

10. 構成、アプリケーション構成の選択的な包含と除外

管理者は、特定の特性を持つクラスターに特定の構成を適用するか適用しないかの条件を設定できます。

11. テンプレートのサポート

開発者は、アプリケーション リソースの定義方法 (Helm Chart、プレーン Kubernetes yaml など) を選択して、特定のアプリケーションごとに最も適切な形式を使用できるというメリットが得られます。

OpenShift 上の GitOps ツール

アルゴCD

ArgoCDは外部リソース調整モデルを実装し、クラスターとGitリポジトリ間の1対多関係をオーケストレーションするための集中型UIを提供します。このプログラムの欠点は、ArgoCDが動作していないときはアプリケーションを管理できないことです。

公式サイト

Flux

Flux は On-Cluster Resource Reconcile モデルを実装しているため、定義リポジトリの集中管理が実現されていません。これが弱点です。一方で、集中管理されていないからこそ、1 つのクラスターに障害が発生してもアプリケーション管理能力が維持されます。

公式サイト

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 Server を 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オブジェクトの管理と保守においてまさにこのような状況を生み出すことがよくあります。しかし、機会は常に完全に逃してしまうのでしょうか？

シリーズの続き GitOps今日は、手作業で作成したアプリケーションとそのリソースを、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が提供するラベルがないため、アプリケーションのステータスは「Out of Sync（同期していない）」になります。
このため、後で同期を実行しても、オブジェクトは再デプロイされません。

それでは、ファイルにエラーがないことを確認するためにテスト実行をしてみましょう。

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