GitOpsアーキテクチャーの説明

この記事では、GitOpsを可能にする基本的なアーキテクチャーについて説明し、必要なツールと、開始するためのアドバイスを紹介します。

GitOpsのベストプラクティスを採用するということは、ソフトウェア開発プロセスを管理し、Gitを信頼できる唯一の情報源として使用してインフラストラクチャーを自動化することを意味します。アプリケーションをデプロイすると、それをサポートするために、継続的デリバリー（CD）ツールが必要なクラスターを自動的にデプロイ、ロールバック、またはロールフォワードします。GitOpsの実践が高度になればなるほど、実際にはより多くのことが自動的に行われます。GitOpsは、最高のインフラ管理と自動化をDevOpsのベストプラクティスと組み合わせて、継続的なデプロイを実現します。

GitOpsの最終的な形は、手動のインフラに関わる作業が不要になることを意味し、リリースの加速につながります。これは、機械学習を使用して障害を検出し、必要に応じてクラスターを含むデプロイ全体をロールバックして、ブルーグリーン、およびカナリアデプロイを行うことを意味します。

しかし、それをサポートするには何が必要で、どこから始めればよいのでしょうか？この記事では、GitOpsを可能にする基礎的なアーキテクチャーについて説明し、必要なツールと、開始するためのアドバイスをご紹介します。

GitOps とは何か?

では、GitOpsはどのように機能するのでしょうか?GitOpsの原則は、最新の継続的デプロイに不可欠です。GitOpsは、クラウドネイティブアプリケーションのデプロイを簡素化しようとする企業向けのアプローチであり、開発者によるアプリケーションの配信に対して、さらなる自律性を提供します。ファイアウォールルールの追加、VPCの定義、UIバグの修正など、全てソースコントロールの中央面から行われる必要があります。

GitOpsは全てのアプリケーションのコンポーネントが宣言的に記述されている「方法」ではなく、「それが何か」に焦点を充てています。そして、それらの構築方法の指示ではありません。宣言型パラダイムでは、開発者はコードで望ましい状態を記述します。そしてそれらと対話しているシステムは、記述した要件を満たす方法でアプリケーションをいつ、どのように、どこに配置するかを決定し、この望ましい状態と実際のクラスターの状態を自動的に一致させます。

宣言型インフラと宣言型構成の主な利点は、ソフトウェア開発チームが展開とランタイムのロジスティクスではなく、アプリケーションにまず集中できることです。言い換えれば、手動プロセスの代わりにGitOpsを使用すると、開発者はインフラの自動化、つまりInfrastructure as Codeを使い、デプロイプロセス全体で摩擦や承認のボトルネックを減らせるのです。

クラウドインフラのGitOpsベストプラクティスのガイドラインも、併せてぜひご確認ください。

GitOpsと継続的デプロイの関係は? 

GitOpsワークフローをインフラ管理に実装する練習をするには、次の５つが必要です。

1. ソース管理システム
2. 継続的インテグレーション（CI）ツール
3. Dockerのようなコンテナ化ツール
4. Kubernetesのようなコンテナオーケストレーション ツール
5. Argo CDやFluのようなコンテナエージェント／コントローラー

それぞれ詳しく見ていきましょう。

１.Gitのようなバージョン管理システム

インフラをコードとして定義すると、Gitリポジトリーに保存されます。それがあなたの情報源になります。CDエージェントはそれを監視し、実際のクラスター構成と比較します。これらの構成ファイルはコードとして保存されるため、毎回同じインフラ環境がデプロイされます。

２.継続的インテグレーション（CI）ツール

CIツールを介してプルリクエストを実行すると、構成ファイルを使用して、宣言的に定義されたGitOpsインフラのデプロイにテストを組み込むことができます。これはインフラ管理の重要な部分です。コミットする前にバグを修正できるよう、テストの自動化はGitOpsワークフローに不可欠です。

３.Dockerのようなコンテナ化ツール

GitOpsの機能を使うには、マイクロサービスのコンテナ化を使用して、ソフトウェア開発中にコード、依存関係、構成、プロセスなどをパッケージ化する必要があります。

４.Kubernetesのようなコンテナオーケストレーションツール

コンテナのデプロイを調整するには、Kubernetesのようなツールが必要です。CDツールのエージェントをインストールするときは、それをKubernetesクラスターにインストールします。

５.Argo CDやFluxのようなコンテナエージェント／コントローラー

GitOpsを機能させるのは、Argo CDのようなコントローラーです。そのエージェントをKubernetesクラスターにインストールすると、それがソース管理システム内のGitで定義されたインフラと実際の運用環境との違いを監視し、同期が維持されます。

合わせて、これらのツールによって、Gitでインフラの定義し、人々がアプリケーションにコードをコミットする時に、自動的に実装する構成のために必要なツールがほとんど提供されるのです。これらの各ステップを詳しく見ていきましょう。

GitOpsアーキテクチャーの実装

まず、GitOps アーキテクチャーをコンテナ化する

言うまでもありませんが、最初のステップは、Dockerなどのコンテナツールを使用してアプリケーションをコンテナ化することです。そして一般的にはKubernetes（そしておそらくTerraformも）を使ってインフラを宣言的に管理し、コードとして存在させ、変更をオーケストレーションするようなツールを使用します

次に、Gitリポジトリーを使いインフラを定義する

Gitでインフラを定義する必要があります。これはつまり、インフラをコードに変換する方法が必要になります。多くの人にとって、それはKubernetesの使用を意味します。なぜなら宣言型コードは、全ての構成ファイルのバージョン管理を実装できるため、操作が簡単だからです。また、Helmチャートを使用してパケットを管理したり、Kustomizeを使用して構成とYAMLテンプレートをより簡単に管理したりすることも意味します。

Gitリポジトリーで定義・保存されたインフラは、インフラの真実の唯一のソースになります。現在実稼働中のクラスターのものを含む、他の全てのバージョンまたは説明は、その真実と同期しているか、同期していないと見なされます。

[引用：Gitリポジトリーで定義・保存されたインフラは、インフラの真実の唯一のソースになります。]

Git内では、そのインフラを格納する方法がいくつか考えられます。

オプション１：１つのGitリポジトリーを維持する

そのリポジトリー内に、少なくとも２つのブランチを作成します。１つはアプリケーション用、もう１つは環境（インフラ）用です。これは、管理するリポジトリーが１つ少なくなり、アプリケーションブランチに全てのマイクロサービスを含めることができるため、より簡単な方法です。唯一の欠点は、常に許可をしたいわけではないのに、インフラへのアクセスを提供してしまう部分です。

オプション２：２つ以上のGitリポジトリーを維持する

少なくとも、アプリケーション用に１つ、環境用に１つのリポジトリーを作成します。これにより、本番環境にアクセスできるユーザーをより詳細に制御でき、開発者と運用チームが必要に応じて別々のリポジトリーで作業できるようになります。しかし、その管理は大変になります。

3つ目に、GitOpsインフラスの望ましい状態と実際の状態をバージョン管理システムと同期する

次に、CIツールを構成して、Gitでの目的のクラスター状態と実稼働環境での実際の状態との違いを自動的に解決できるようにします。大まかに、これには２つのアプローチがあります。

1.設定の変更をプッシュする

より伝統的なセットアップでは、トリガーをパイプラインに組み込み、コマンドを実行して目的のインフラの状態を本番環境にプッシュするコマンドを実行できます。（通常、JenkinsまたはCI/CDツールを使用します。）これにより、クラスターが新しく定義された状態に更新されますが、問題はそれが一方通行で、受動的であることです。２つの状態が乖離した場合、自動的な強制力はありません。クラスターがエラーループに陥っている可能性があっても、Jenkinsはそれを検出や解決しません。そのように構築されていないからです。自分でエラーを検出して更新をプッシュする必要がありますが、アプリケーションも更新する必要があるため、煩わしさを感じるでしょう。

2.設定の変更をプルする

より新しく、回復力のあるクラスターの更新方法は、Argo CDのようなエージェントをインストールして、Gitの望ましい状態と実際のクラスターの状態との違いを積極的に監視し、解決することです。この利点は、エージェントが２つの状態が同期していることを常にチェックしていることです。それらが同期しなくなると、アクションが実行されます。そして、それは両方向で機能します。本番環境が同期しなくなった場合、それをキャッチして解決できます。

4つ目に、GitOpsを使ってデプロイするようにチームに教える

インフラチームがGitでプルリクエストとマージを使い始めたり、開発者が独自のインフラを選択したりするには、少し文化を変える必要があります。しかし全体として、これは手作業によるインフラ展開作業を大幅に削減するための道です。

アーキテクチャーがセットアップされると、実際の動作は次のようになります。

1. インフラチームは、Gitリポジトリーで宣言的に必要なインフラを事前に定義します。
2. アプリケーションへのプルリクエストの一部として、開発者はデプロイ先の環境を参照します。
3. インフラ、セキュリティー、またはその他のチームがそのプルリクエストをレビューします。
4. プルリクエストがマージされます。
5. GitOpsエージェント（Argo CDなど）は、更新されたコンテナイメージを検出し、そのクラスターの状態を最新の更新されたコミットと同期します。
6. GitOpsエージェントは、同期の完了を確認します。

GitOps による高度な継続的デリバリー

クラウドネイティブアプリケーションの開発においてGitOpsを使用すると、手動タスクに費やす時間と労力を大幅に節約できます。インフラを手動でプロビジョニングするのではなく、デプロイの一部としてYAMLファイルを使用してインフラをデプロイできます。また、Gitで定義された実際のインフラの状態を監視し、解決できる適切なアーキテクチャーとツールを使用すれば、迅速なリリースに対する大きな障害を排除できます。

Harness CDとGitOps as a Serviceを無料で始めましょう！

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。