エッジでのGitOps
ここ数年、GitOpsを採用する企業が増えています。GitOpsは、Gitをリポジトリーとして使用するDevOpsパラダイムです。
GitOpsが登場してから数年たちますが、コンテナとコンテナ・ランタイム環境の一貫した展開と管理を取り巻く複雑さのため、最近注目を集めています。
GitOpsが解決しようとしている問題は何でしょうか。GitOpsはソフトウェア操作を自動化するので、企業はソフトウェア・エンジニアリングを改善することができます。その結果、アプリケーション・チームはより頻繁にリリースし、クラウドネイティブ・アプリケーションをより効率的に運用できるようになります。
このブログでは、GitOpsをエッジ・トポロジーに適用できるかどうか、特に遠隔エッジ・デバイスにアプリケーションを導入できる CI/CD パイプラインの作成について説明します。繰り返しますが、エッジはクラウドに至るまでの遠隔エッジ・デバイスを包含し、その間にエンタープライズ・エッジとネットワーク・エッジが存在します。
GitOpsは、必要な構成状態が保存される唯一の信頼できる情報源としてGitを使用するDevOpsプラクティスであり、Gitリポジトリーが駆動する運用の自動化に重点を置いています。タイトルにありますが、使用できるリポジトリーはGitだけではありません。運用を自動化するのは、Gitが提供するインターフェースです。GitOpsは、特定のコード変更によってトリガーされるビルド対象パッケージを決定するために、ビルド・メタデータから抽出された情報を使用します。
GitOpsモデルの中心では、コントローラー・パターンを使用します。これはKubernetesやOpenShiftの観点から見ると、オペレーター・パターンによってさらに促進されます。この場合、オペレーターとは、カスタム・リソースを使用して、アプリケーションとそのコンポーネントを管理するソフトウェア拡張機能です。
GitOpsワークフローを支援するGitOpsツールであるArgoCDを取り上げないわけにはいきません。Argo CDは、アプリケーションの継続的インテグレーションと継続的デプロイメント（CI/CD）のためのオープンソースの宣言型ツールです。Kubernetesコントローラーとして実装されたArgo CDは、実行中のアプリケーションの定義と構成を継続的に監視し、クラスター上の現在のライブ状態と、Gitリポジトリーで定義された望ましい状態を比較します。
ただし、GitOpsは単一の製品、プラグイン、またはプラットフォームではありません。GitOpsワークフローは、アプリケーション開発ですでに使用しているプロセスを通じてチームがITインフラストラクチャーを管理できるよう支援します。GitLabのブログから引用すると、GitOpsには、GitOps = IaC+ PRs、またはMR + CI/CDという3つのコア・コンポーネントが必要です。
- IaC：コード型インフラストラクチャー（IaC：Infrastructure as Code）は、すべてのインフラストラクチャー構成をコードとして保存する手法です。GitOpsは、インフラストラクチャー定義の信頼できる唯一の情報源としてGitリポジトリーを使用します。Gitは、すべてのコード管理の変更を追跡します。
- PRまたはMR：GitOpsでは、すべてのインフラ更新の変更メカニズムとしてプル・リクエスト（PR）またはマージ・リクエスト（MR）を使用します。ここでチームはレビューとコメントを通じて共同作業を行い、正式な承認が行われます。
- CI/CD： GitOpsは、継続的インテグレーション（CI）と継続的デリバリー（CD）を備えたGitワークフローを使用してインフラストラクチャーの更新を自動化します。新しいコードがマージされると、CI/CDパイプラインによって環境の変更が行われます。手動による変更やエラーなどの構成ドリフトは、GitOps自動化によって上書きされるため、環境はGitで定義された望ましい状態に収束し、継続的オペレーション（CO）が実現します。
Red Hat OpenShift Operator（オペレーター）は、複雑なワークロードのインストールと自動オーケストレーションを簡素化します。この機能により、Kubernetesネイティブ・アプリケーションとして実行されるサービスを管理するための人間の運用ロジッがエンコードされ、2日目からの運用が容易になります。Operatorは、クラスター上のPodで実行され、Kubernetes APIサーバーと対話するソフトウェアです。OpenShift Operatorは本質的にカスタム・コントローラーであり、事実上アプリケーション固有のコントローラーにすることができます。
Red Hat OpenShiftは、必要なオペレーターを提供することで、GitOpsを利用したい開発者を支援します。導入後、OpenShift Consoleの「Installed Operators」セクションでオペレーターを確認できます。Red Hat OpenShift GitOps OperatorはArgoCDの上流オペレーターであり、同じくt展開されるRed Hat OpenShift Pipelines OperatorはTektonの上流オペレーターです。図3を参照してください。
その後、オペレーターと関連APIを使用して、1つ以上のGitOpsパイプラインを開始し、Gitから必要な構成の結果を引き出してさまざまな環境に展開できます。環境は通常の開発、テスト、本番環境だけでなく、エンタープライズ・クラウド、通信ネットワーク、エッジ・コンピューティング・ノードなどの地理的に分散した環境にも対応可能です。
導入リソースは、インフラストラクチャー、サービス、アプリケーションの3つの領域に分類されます。これらの領域により、関連リソースの導入の分離と管理が容易になります。
- インフラストラクチャーには、必要な名前空間とストレージ・ユニットが定義されます。
- サービスには、インスタンスの設定に必要な各種オペレーターが記述されます。
- アプリケーションには、展開するアプリケーションが列挙されます。
以前のブログでは、エッジコンピューティング分野におけるDevOpsについて説明しました。ここでは、エッジコンピューティングにおけるGitOpsの応用方法について説明します。エッジコンピューティングにおける３つのエッジについて触れました。
- エンタープライズ・エッジ
- ネットワーク・エッジ
- デバイス・エッジ（または遠隔エッジ）
クラウドやエンタープライズ・データセンターもあります。ここではその分野について詳しく説明していきます。図4には、エッジ環境だけでなく、インフラストラクチャー、サービス、アプリケーションという3つのGitOps領域も示されています。
クラウド/エンタープライズ・データセンター
エッジコンピューティングでは、ほとんどのITセンターでOpenShiftまたはKubernetesクラスターが急増しています。顧客ごとに数百から数千の導入という大きな規模に達する可能性があります。その結果、企業のIT部門は、オンプレミスやパブリッククラウド上で稼働する複数の独立した、あるいは協調的なコンテナ・ランタイム・クラスターを管理する必要が出てきます。
クラスターを同じ望ましい状態に確実に維持できること（複数のクラウドで変更をロールアウトし、変更をロールバックすること）は、GitOpsがエッジベースやIoTベースの企業にもたらす大きなメリットです。
ネットワーク・エッジ
通信サービスプロバイダー（CSP）が直面する主要な課題の1つは、ネットワークのオーケストレーション、自動化、および管理を実現することであるため、GitOpsパラダイムはネットワーク・エッジに適用可能です。5Gは消費者にとって恩恵となる一方で、ソフトウェア定義型ネットワーク（SDN）、異なる帯域幅でのネットワーク・スライシング、より迅速な導入は、通信事業者にとって課題を生み出しています。
自動化された導入パイプラインは、CSPが顧客にサービスをより迅速に提供できる方法の1つです。中央リポジトリーと宣言型アプローチを使用して、コンテナ・インフラストラクチャーのプロビジョニングを行うことで、新しい機能と変更要求の市場投入までの時間が短縮されます。このようなパラダイムは、ネットワーク・エッジにおけるVNF（仮想ネットワーク機能）とCNF（クラウドネイティブ・ネットワーク機能）のプロビジョニングを支援します。ネットワーク・コンポーネントのコンテナ化により、このような機能の管理が実現します。最後に、すべての構成アクティビティはログに記録され、 Gitに保管されるため、コンプライアンスと監査の目的で変更を追跡する機能は非常に重要です。参考資料には、WeaveWorksの関連ブログがいくつかあります。
エンタープライズ・エッジ
GitOpsにより、組織は複数のターゲットへの同時展開を行うことができます。その結果、きめ細かい展開のロールアウトが可能になります。これは、形状やフォームファクターが異なり、さまざまな通信プロトコルを使用する数千から数万のエッジ・ノードにアプリケーションを展開する場合に極めて有用です。特に、Intel NUCやNVIDIA Jetsonを使用した小規模なエッジ・クラスターがエッジ・ノードとして使用される場合に効果を発揮します。
GitOpsフレームワークは、アプリケーションを展開し、Gitリポジトリーを信頼できる唯一の情報源として使用する場合に有益です。ITOpsチームは、Red Hat OpenShift Operatorの使用によって促進される、エッジ・ノードの自律的なアプリケーション展開、管理、運用を求めています。
デバイス・エッジ（または遠隔エッジ）
GitOpsのメリットは、ネットワーク・エッジやエンタープライズ・エッジで明らかです。遠隔エッジ・デバイスには、これらのデバイスの一部のストレージ容量とコンピューティング容量がGitOpsサービスをホストしてアプリケーションを実行するのに十分な大きさではないため、別の課題が生じます。
K3やK0sなどの軽量Kubernetesディストリビューションのリリースは、IoTおよびエッジのユースケースを対象としています。エッジ・デバイスに軽量のKubernetesディストリビューションを展開できるため、Argo CDのようなGitOpsツールを実行できます。その後、デバイスは、望ましい状態を得るためにGitリポジトリーをポーリングし、それをクラスターのライブ状態に同期するプル・モデルを採用できるようになります。
GitOpsを使用することで、インフラストラクチャーとアプリケーション構成の無秩序なスプロール現象の問題を解決できます。Red Hat OpenShiftに標準装備GitOps Operatorを使用すると、Argo CD主導のパイプラインを容易に実装できます。IBM Cloud Pak for Network Automationを含むIBM Cloud Paksのお客様は、Red Hat Operatorを利用してリソースをインストールし、GitOpsフレームワークを使用して導入プロセスを自動化および制御できます。
IBM Cloud Native Toolkitは、非常に良い出発点となります。このツールキットは、アプリケーション開発と運用の導入を実現するアセットのオープンソース・コレクションです。
記事をレビューしてくださったHollis Chui氏とKavitha Bade氏に感謝します。