エージェントベースのGitOpsとは何ですか、そしてそれはCI/CDとどのように異なりますか？

GitOpsは、インフラストラクチャを定義し管理するために、ソースコントロールリポジトリ内のバージョン管理されたファイルを使用することを推奨する開発手法です。アーキテクチャを宣言的ファイルとして表現することで、システムの現在の構成を検査し、複数の寄稿者からの変更を統合し、以前の状態にロールバックする方法が提供されます。

これまでのところ、このアプローチはコードとしてのインフラストラクチャ（IaC）に似ています。ただし、GitOpsは単なるIaC以上のものです。成功した実装には、設定ファイルをライブインフラストラクチャコンポーネントに適用するための自動化メカニズムが含まれる必要があります。変更をマージすると、インフラストラクチャの状態は改訂されたリポジトリの内容によって説明された状態に移行するべきです。

これは、ソース管理プラットフォームとインフラストラクチャプロバイダーとの間にブリッジを必要とし、現在の状態が両者間で通信されることを可能にします。このブリッジが実装される方法は異なり、それぞれが関与するプラットフォームに特有の責任のセットを置きます。この記事では、エージェントベース（またはプルベース）デプロイメントモデルを見てから、それをプッシュベースのアプローチと比較します。

エージェントとは何ですか？

エージェントベースのGitOpsは、あなたのインフラストラクチャ内でプロセスを実行して、デプロイメントを容易にすることを指します。このプロセスは、IaCファイルをホストするソースコントロールプラットフォームとの通信を維持する責任があります。

エージェントはあなたのインフラストラクチャの積極的な部分です。エージェントは定期的にあなたのGitリポジトリに接続し、変更を確認し、新しいコミットをデプロイメント環境にプルします。その後、エージェントは取得した変更を周囲に適用するためのアクションを取り、適切な状態遷移をトリガーします。

エージェントは、組み込みのデプロイメントモニタリング、ロギング、アラートなどの追加機能を提供できます。これにより、インフラ内での活動について常に情報を得ることができます。エージェントは既存のツールとの統合を処理し、関連情報を適切な場所で表示します。

エージェントモデルは、トリガーに依存するパイプラインの概念を排除することによって、従来の継続的インテグレーションおよび継続的デプロイメント（CI/CD）の見方と異なります。その代わりに、利用可能になった変更を取得する自動的な調整ループがあります。新しいコミットやマージは、インフラストラクチャの変更を直接的に促すことはありません。エージェントが新しいデータを取得するまでに時間がかかることがあります。

いくつかのベンダーがGitOpsのワークフローを実装するために使用できるエージェントを提供しています。GitLabは現在、このアプローチをKubernetesにデプロイするための推奨方法として提唱しています。これは、Kubernetes用のGitLabエージェントを介して行われます。このエージェントは、クラスター内からGitLabインスタンスに接続し、変更を展開するための双方向の通信を促進し、リポジトリに情報を送信します。

WeaveworksのFluxは、どのGitリポジトリにも対応し、アラート機能を含むもう一つのオプションです。Fluxは現在、Cloud Native Computing Foundation（CNCF）のインキュベータープロジェクトです。これはKubernetesオペレーターとして実行され、接続されたGitリポジトリに加えられた変更を取得します。

エージェントの利点

エージェントベースのGitOpsは、さまざまな利害関係者にとって魅力的になる複数の利点があります。まず、責任の明確な区分があります。ソースコード管理プラットフォームは変更されず、インフラストラクチャとの接続を気にする必要はありません。エージェントにはリポジトリの認証情報が提供される必要がありますが、それ以外は自給自足です。一度稼働すると、エージェントは変更の検出と適用に特化しています。

この関心の分離は、問題を特定し、デプロイメントの失敗について理論を立てるのに役立ちます。一般的に、ソース管理プラットフォームはすぐに捨てることができます。プラットフォームが稼働していて、メインブランチに正しい変更が含まれている場合、インフラの実際の状態の不一致は、エージェントの同期の問題によるものであるに違いありません。

エージェントは、プッシュベースのGitOpsよりも高い自動化の度合いを提供します。プッシュベースのフローを成功裏に採用するには、インフラストラクチャのための認証情報を持つレポジトリを設定し、変更を送信するための正しいスクリプトを実行するCIパイプラインを作成する必要があります。これらのスクリプトはすべてのプロジェクトにコピーされ、時間と共に維持され、敏感な認証情報を保護するために慎重に取り扱う必要があります。

エージェントベースのシステムは、これらの懸念がありません。エージェントがインストールされると、変更に対して脆弱性が少ない堅牢な展開モデルの恩恵を受けることができます。Kubernetesクラスターのような本番環境への成功したアクセスよりも、Gitリポジトリへの接続に関する変数ははるかに少なくなります。したがって、シンプルなシステムから複雑なシステムに変更を引き込むことは理にかなっています。

もう一つの利点は、エージェントのポジティブなセキュリティ効果です。彼らはあなたのインフラ内で動作するため、外部アクセスを開放する必要がなくなります。Gitリポジトリを公開する必要がありますが、これは本番環境へのアクセスを提供するのと比べて、はるかにリスクが少ないです。GitHubプロジェクトトークンの漏洩は、ソースコードやIaCファイルを漏らす可能性が高いですが、それは深刻な事態であるものの、本番のKubernetesアカウントトークンを失うことを考えると比較になりません。データの盗難、続く恐喝、そして回復不可能なシステムの侵害につながる可能性があります。

プッシュベースのGitOpsはどうですか？

代替戦略はプッシュベースのモデルで、変更はソース管理プラットフォームまたは中間システムによってインフラストラクチャに送信されます。コミュニケーションはデプロイメント環境の外部で実行されている何かによって開始されます。プッシュによってインフラストラクチャは制御サーバーから新しい状態を受け取ることを強制されます。

プッシュベースのGitOpsは通常、CIパイプライン内で実装されます。Kubernetesクラスタ接続で構成されたパイプラインを持ち、使用している場合、このモデルを使用しています。

kubectl apply

デプロイメントを作成するためのもう一つの例は、実行されるパイプラインです。

rsync

リポジトリの内容をリモートホストに同期するために。

このアプローチの限界は、上で説明したエージェントに関連する利点を提供できないことにあります。各リポジトリを適切なインフラ接続で手動で設定し、環境を外部アクセスに開放し、時間の経過とともにデプロイスクリプトを維持する責任を負う必要があります。

プッシュベースのGitOpsには独自の利点もあります。重要な要素の一つは、その本質的な親しみやすさです。開発で既に知っているツールを引き続き使用できることです。例えば、

kubectl

,

helm

、そして

docker

これにより、ローカルとライブデプロイメントの違いを最小限に抑えることができます。

エラーハンドリングはもっとシンプルになることもあります。プッシュベースのアプローチは、失敗に至る一連のイベントを特定するのに役立つため、より同期的に感じられる傾向があります。エージェントは明確な開始点（エージェント自体）を提供しますが、その後はそのエージェントの活動に対応するイベントをフィルタリングしなければなりません。それらのイベントは、数十の異なるプロジェクトや和解サイクルをカバーする場合があります。特定のCIパイプラインの実行から始めることができれば、デバッグ中に即座にフィードバックを提供するのに役立ちます。

最後に、プッシュベースのモデルが実際に将来のインフラの変更に対してより適応可能であるという議論があります。プル方式を採用すると、選択したエージェントの特定の期待にシステムを結びつけることになります。これは、そのエージェントがサポートされていない新しいプラットフォームにデプロイする必要が出てきた場合に、すぐに事態を複雑にする可能性があります。スクリプト化されたプッシュベースのアプローチは、ここでより柔軟です。これは、ターゲットプラットフォームに対して正しいアクションを取るための条件付きロジックを組み込むことによって、複数の異なる環境に対応することを可能にします。

要約

エージェントベースのGitOpsは、インフラストラクチャ内でアクティブなコンポーネントを実行し、それがソースリポジトリにアクセスして変更を取得し適用することを指します。これは、CIパイプライン内でスクリプトを実行してデプロイメントを作成し、状態の変更を適用するプッシュベースのモデルを逆転させます。

プッシュワークフローは一般的で、容易に理解でき、いくつかの重要な魅力を持っています。しかし、エージェント駆動の「プル」がクラウドエコシステム全体でますます注目を集めており、ベンダーや開発者はその利点を認識しつつあります。

プルベースのアプローチを採用することで、時間の経過とともにメンテナンスを減らし、環境のセキュリティを改善し、変更が適用されない場合の障害を特定するのに役立ちます。また、エージェントはアラートやメトリクスの集計などの周辺機能のセットアップを簡素化し、複雑なCIスクリプトを手作業で組み合わせることなく、DevOpsの採用の道筋を加速させることができます。