マルチクラウド GitOps とは

GitOps は、ワークフローをガイドし、クラウドネイティブ・アプリケーションの継続的デプロイメント (CD) の実装を可能にする一連の原則です。以前は手動で行われていたプロセスに自動化を導入することで、クラスタ設定とアプリケーションのデプロイを管理できるようになります。たとえば、GitOps は、マルチクラスタ Kubernetes 環境において Red Hat^® OpenShift^® Container Platform クラスタを管理するために役立ちます。GitOps は、単純なデプロイも複雑なデプロイも自動化し、アプリケーションのワークフローを効率化します。

GitOps は、新規アプリケーションのデプロイや既存のアプリケーションの更新に役立ちます。リポジトリを更新すると、GitOps ワークフローによって他のあらゆるものを自動化できます。 

具体的には、GitOps によって次のことが可能になります。

• パブリッククラウドとプライベートクラウドの両方にまたがるハイブリッドクラウドとマルチクラウドのデプロイの管理
• クラスタ間のガバナンスとアプリケーションのライフサイクル管理
• デプロイ全体におけるシークレットの安全な管理

これらの機能により、パブリッククラウド、プライベートクラウド、さらにはオンプレミス環境間でワークロードを移行する際の一貫性、セキュリティ、コラボレーションの必要性など、マルチクラウド・アプローチに伴う課題を軽減することができます。 

GitOps では、git リポジトリがシステム設定とアプリケーション設定の信頼できる唯一の情報源です。環境のインフラストラクチャの宣言的記述で構成されており、Argo CD などの GitOps ツールが処理する自動プロセスと連携して動作します。この自動化によって、環境の実際の状態が記述された状態に一致します。Git 履歴には変更追跡機能があるため、リポジトリを使用してシステムの状態に対する変更のリストを表示することもできます。 

さらに、インフラストラクチャと設定をコードとして保存すると、スプロールを軽減できます。クラスタとアプリケーションの設定をコードとして git リポジトリ内に保存することができます。 

組織は、オープン・ハイブリッドクラウド上で、安定した、シンプルかつ安全な方法でアプリケーションを開発し、デプロイし、運用する必要があります。そのためには、マルチクラウドのデプロイを含むハイブリッド戦略が必要です。 

マルチクラウドアプローチには大きな課題があります。たとえば、さまざまなクラウドベンダーがさまざまなツールを提供しており、それらが他のベンダーの製品とうまく連携しないことがあります。その結果、ワークロードの移行はコストのかかる困難なものになる可能性があります。可搬性の欠如は、セキュリティリスクの増大やデータプライバシーの懸念にもつながります。 

しかし、Kubernetes はそのような課題の多くに対処しています。Kubernetes によって、異なるクラウド環境 (オンプレミスを含む) で複数のクラスタを実行することができます。ワークロードは、同様の移行やセキュリティの問題を引き起こすことなく、環境間をシームレスに移動できます。 

このようなデプロイメントのワークロードは、複数のクラスタと複数のクラウド (プライベートまたはパブリック) で動作している場合があります。この戦略によってこれまでの課題は軽減されますが、Infrastructure-as-Code (コードとしてのインフラストラクチャ) アプローチも必要になります。つまり、先進的なマルチクラウド戦略には GitOps が必要です。 

前述のとおり、GitOps は、git リポジトリを信頼できる唯一の情報源として使用し、インフラストラクチャをコードとして提供します。提出されたコードはまず継続的インテグレーション (CI) プロセスを通過します。継続的デリバリー (CD) プロセスでは要件がチェックされ、適用されます。コードに対するすべての変更が追跡され、使い慣れたバージョン管理とリビジョン機能が提供されます。 

これにより、GitOps はインフラストラクチャ・チーム間のコラボレーションを可能にし、開発プロセスを加速します。マルチクラウドアプローチに一貫性をもたらし、コストがかかり人的ミスのリスクが生じる可能性がある手動プロセスではなく、自動化されたプロセスを通じてそれを実現します。 

そのため、マルチクラウドアプローチを導入している組織には、環境全体での一貫性とセキュリティが必要です。Red Hat OpenShift GitOps のような GitOps ソリューションが必要になります。

Red Hat OpenShift GitOps は、Argo CD インスタンスのインストールと設定を行う Operator です。インフラストラクチャの設定とアプリケーションのデプロイを管理し、これらの設定リポジトリを中心にデプロイプロセスを編成します。少なくとも 2 つのリポジトリが常にそのプロセスの中核となります。

• ソースコードが含まれるアプリケーション・リポジトリ
• アプリケーションの望ましい状態を定義する環境設定リポジトリ

クラスタリソースを維持するために、Red Hat OpenShift GitOps は、アプリケーションの継続的インテグレーションおよび継続的デプロイメント (CI/CD) の継続的デプロイメントの部分に対応するオープンソースツールである Argo CD を使用します。つまり、Argo CD は、git リポジトリで定義されているように、アプリケーションの状態の記述と設定を監視することにより、Red Hat OpenShift GitOps のコントローラーとして機能します。定義された状態と実際の状態を比較し、指定の記述から逸脱する設定をすべて報告します。 

管理者は、これらの報告に基づいて、設定を定義された状態に再同期することができます。再同期は、手動で行うことも自動化することもできます。自動化の場合、設定は基本的に「自己修復」されます。

したがって、Red Hat OpenShift GitOps とその自動プロセスにより、次のことが可能になります。

• クラスタの設定、監視、ストレージの状態が同様であることを確認する
• 複数のクラスタに設定変更を適用する、または設定変更を元に戻す
• テンプレート化された設定をさまざまな環境に関連付ける
• ステージングからプロダクションまで、クラスタ全体にアプリケーションをデプロイする

OpenShift Container Platform コントロールプレーンでサービスをパッケージ化し、デプロイし、管理するための手法として推奨されるのが Operator です。たとえば、GitOps Primer は Kubernetes オブジェクトをエクスポートし、クラスタ間、チーム間、環境間で共有できるようにする Operator です。GitOps がマルチクラウドアプローチに一貫性、セキュリティ、コラボレーションをもたらすのにも役立ちます。 

Operator は、Kubernetes API およびコマンドライン・インタフェース (CLI) ツールと統合して、アプリケーションの監視、ヘルスチェックの実行、OTA (over-the-air) 更新の管理を実施し、アプリケーションが指定した状態にあることを確認するための手段となります。

OpenShift Container Platform の Operator は、目的に応じて 2 つの異なるシステムによって管理されます。

• クラスタ Operator：これらは Cluster Version Operator (CVO) によって管理され、クラスタ機能を実行するためにデフォルトでインストールされます。
• オプションのアドオン Operator：これらは Operator Lifecycle Manager (OLM) によって管理され、ユーザーがアプリケーションで実行できるようにアクセス可能にすることができます。

Operator を使用すると、クラスタ内で実行中のサービスを監視するアプリケーションを作成できます。インストールや設定の操作だけでなく、自動スケーリングやバックアップの作成などの操作も実装し自動化します。これらのアクティビティはすべて、クラスタ内で実行されているソフトウェアの一部です。

Operator は以下を提供します。

• インストールおよびアップグレードの反復性
• すべてのシステムコンポーネントの継続的なヘルスチェック
• OpenShift コンポーネントの OTA (over-the-air) 更新 
• フィールドエンジニアからの知識をカプセル化して、それを 1 人や 2 人ではなくすべてのユーザーに浸透させるための場所

GitOps Primer は OpenShift クラスタで動作する Operator で、これによって開発者が名前空間内のすべての Kubernetes オブジェクトをエクスポートできるようになります。移植可能な .zip ファイルが生成されるため、次のことが可能です。 

• 別のクラスタへの転送
• チームメンバーとの共有
• Argo CD または Red Hat Advanced Cluster Management for Kubernetes (RHACM) を用いた GitOps ワークフローへのプッシュ 

GitOps Primer は、GitOps がマルチクラウドにもたらす Infrastructure-as-Code アプローチを促進するのに役立ちます。

Git は、インフラストラクチャ設定とアプリケーション設定の信頼できる唯一の情報源として機能します。GitOps ツールがその機能を実行するには、インフラストラクチャ設定とアプリケーション設定の両方で、通常シークレットと呼ばれる機密資産 (認証トークン、秘密鍵など) へのアクセスが必要です。

しかし、git リポジトリにシークレットを保存するとセキュリティ上の脆弱性が生じるため、リポジトリがプライベートとみなされ、対象者を制限するアクセス制御が含まれる場合であっても、許可されるべきではありません。シークレットがクリアテキスト (または簡単に元に戻せる状態) で Git にプッシュされた場合、そのシークレットを侵害されたものとみなし、直ちに破棄する必要があります。

この課題を克服するために、GitOps のシークレット管理には主に 2 つのアーキテクチャ・アプローチがあります。

• 暗号化されたシークレット
  • git リポジトリ内に保存される
  • 自動化されたプロセスが復号し、Kubernetes Secret としてレンダリングする
• シークレットへの参照を git リポジトリに保存
  • 自動化されたプロセスが、これらの参照に基づいてシークレットを取得する
  • 取得されたシークレットが Kubernetes Secret としてレンダリングする 

これら 2 つのアプローチの詳細は、GitOps と Kubernetes によるシークレット管理のためのガイドを参照してください。

マルチクラウド GitOps の概念を理解したところで、次のステップは、以下に示すような GitOps を用いた開発方法について学ぶことです。

• ArgoCD および OpenShift GitOps Operator を使い始める
• SyncWaves とフックを使い始める
• Red Hat Ansible^® Automation Platform と OpenShift 上の Jenkins による CI/CD

また、以下のような OpenShift GitOps に関連する記事を引き続き参照することもできます。

• 検証済みパターンとは
• Argo CD とは
• CI/CD とは