大人でもわかるGitOps初心者ガイド

GitOpsの概念は、Kubernetes管理会社であるWeaveworksによって2017年に初めて提案されました。今では5年が経過しています。誰もがこの概念について聞いたことがあると思いますが、それが何なのか、DevOps とどのような関係があるのか​​は知らないかもしれません。この記事は、これらの疑問を一つずつ解決するのに役立ちます。

インフラストラクチャ・アズ・コード

GitOps を理解する前に、Infrastructure as Code とは何かを理解する必要があります。

Infrastructure as Code (IaC) は、その名前が示すように、コード (手動プロセスではなく) を使用してインフラストラクチャを定義することを意味し、開発者はインフラストラクチャをアプリケーション ソフトウェアのように扱うことができます。次に例を示します。

• インフラストラクチャの仕様を含む宣言型構成ファイルを作成できるため、構成の編集と配布が容易になります。
• これにより、構成するたびに環境がまったく同じになることが保証されます。
• バージョン管理を実行でき、すべての変更が記録されるため、追跡が容易になります。
• インフラストラクチャは複数のモジュール コンポーネントに分割でき、自動化によってさまざまな方法で組み合わせることができます。

もちろん、広義の IaC はインフラストラクチャだけでなく、ネットワーク、セキュリティ、構成なども含まれるため、広義の IaC は X as Code とも呼ばれます。

たとえば、サーバーを作成し、ネットワークを構成し、Kubernetes クラスターとさまざまなワークロードを AWS にデプロイする場合は、Terraform または Ansible の宣言型構成と Kubernetes の構成リストを定義するだけで済み、複雑な手動操作がすべて排除されます。

GitOpsとは

GitOps = IaC + Git + CI/CD、つまり IaC に基づくバージョン管理された CI/CD。その中核は、Git リポジトリを使用してインフラストラクチャとアプリケーションの構成を管理し、Git リポジトリをインフラストラクチャとアプリケーションの唯一の信頼できるソースとして使用することです。他の場所から構成を変更する試み（オンライン構成を手動で変更するなど）は許可されません。

Git リポジトリ内の宣言型構成は、ターゲット環境に現在必要なインフラストラクチャの望ましい状態を記述します。 GitOps では、クラスターの実際の状態が Git リポジトリで定義された目的の状態と一致しない場合、Kubernetes リコンサイラーが目的の状態に応じて現在の状態を調整し、最終的に実際の状態と目的の状態を一致させます。

一方、現代のアプリケーション開発では、反復速度と規模に重点が置かれています。成熟した DevOps 文化を持つ組織では、コードを 1 日に何百回も本番環境にデプロイできます。 DevOps チームは、バージョン管理、コードレビュー、自動テストとデプロイメントのための CI/CD パイプラインなどのベストプラクティスを通じてこの目標を達成できます。これが GitOps が行うことです。

GitOps と DevOps

広い意味では、GitOps と DevOps は互いに矛盾しません。 GitOps は技術的な手段ですが、DevOps は文化です。 GitOps は、DevOps 文化をサポートする継続的デリバリー、継続的デプロイメント、およびインフラストラクチャ アズ コード (IaC) を実装するためのツールおよびフレームワークです。

狭義では、GitOps と DevOps には次のような違いがあります。

まず、GitOps は目標指向です。 Git を使用して目的の状態を維持し、実際の状態を継続的に調整して、最終的に目的の状態に一致させます。一方、DevOps は、企業内のすべてのプロセスに普遍的に適用できるベストプラクティスに重点を置いています。

第二に、GitOps は宣言型の操作方法を採用していますが、DevOps は宣言型と命令型の両方の方法を受け入れるため、コンテナ環境に加えて、仮想マシンやベアメタル環境にも DevOps を適用できます。

最後に、GitOps は、継続的なデプロイメントを加速するために Git を中心的な不変の状態宣言として使用し、クラウド ネイティブ シナリオで CI/CD を再定義します。

GitOpsの設計哲学

GitOps を使用してインフラストラクチャとアプリケーションを管理するには、次の原則を実践する必要があります。

1. 宣言的

システムの望ましい状態は宣言的に記述する必要があります。たとえば、Kubernetes は、宣言型の最新のクラウドネイティブ ツールの 1 つにすぎません。

2. バージョン管理/不変性

すべてのステータス ステートメントは Git リポジトリに保存され、Git リポジトリは唯一の真実のソースとして使用されるため、すべての操作は Git リポジトリから実行され、完全なバージョン履歴が保持され、簡単にロールバックできます。 Git の優れたセキュリティにより、SSH キーを使用してコミットに署名し、コードの作成者とソースに対して強力なセキュリティ保護を実装することもできます。

3. 変更を自動的に適用する

Git リポジトリで宣言された目的の状態への変更は、追加のツール (kubectl など) をインストールして構成したり、Kubernetes の認証と承認を構成したりすることなく、すぐにシステムに適用できます。

4. 継続的な和解

調整は実際には Kubernetes で初めて導入されたもので、システムの実際の状態が予想される状態と一致していることを確認するプロセスを指します。具体的な実装方法は、対象環境にエージェントをインストールすることです。実際の状態が予想される状態と一致しない場合、エージェントは自動的に修復します。ここでの修復は、Kubernetes の自己修復よりも高度です。クラスターのオーケストレーション マニフェストが手動で変更された場合でも、クラスターは Git リポジトリのマニフェストで記述された状態に復元されます。

上記の設計哲学を踏まえて、GitOps ワークフローを見てみましょう。

• まず、チームのどのメンバーでもリポジトリをフォークし、構成に変更を加えて、プル リクエストを送信できます。
• 次に、CI パイプラインが実行されます。これは通常、構成ファイルの検証、自動テストの実行、コードの複雑さの検出、OCI イメージのビルド、イメージ リポジトリへのイメージのプッシュなどを行います。
• CI パイプラインが完了したら、コードをマージする権限を持つチームのメンバーがプル リクエストをメイン ブランチにマージします。通常、この権限を持つのは、研究開発担当者、セキュリティ専門家、または上級運用保守エンジニアです。
• 最後に、CD パイプラインが実行され、変更がターゲット システム (Kubernetes クラスターや AWS など) に適用されます。

プロセス全体は完全に自動化され、透明性が高く、複数人のコラボレーションと自動テストを通じてインフラストラクチャの宣言的構成の堅牢性が保証されます。従来のモデルでは、1 人のエンジニアが自分のコンピューターでこれらすべてを操作し、他のエンジニアは何が起こっているのか分からず、操作を確認することもできません。

プッシュ対プル

CD パイプラインには、プッシュとプルの 2 つのモードがあります。

プッシュモード

現在、ほとんどの CI/CD ツールは、Jenkins、CircleCI などのプッシュベースのデプロイメント モデルを使用しています。このモードでは通常、CI パイプラインが完了した後にコマンド (kubectl など) を実行して、アプリケーションをターゲット環境にデプロイします。

この CD モデルの欠点は明らかです。

• 追加のツール (kubectl など) をインストールして構成する必要があります。
• Kubernetes はそれを承認する必要があります。
• クラウド プラットフォームの承認が必要です。
• 展開ステータスを検知できません。また、期待される状態と実際の状態の間の偏差を認識することは不可能であり、一貫性を確保するために追加のソリューションが必要になります。

Kubernetes クラスターまたはクラウド プラットフォームから CI システムへの認証資格情報は、クラスターまたはクラウド プラットフォームの信頼ドメイン外にあり、クラスターまたはクラウド プラットフォームのセキュリティ ポリシーによって保護されていません。したがって、CI システムは簡単に違法攻撃の媒体として利用される可能性があります。

プルモード

プル モードでは、ターゲット環境にエージェントがインストールされます。たとえば、Kubernetes クラスターでは、オペレーターがエージェントとして機能します。 Operator は、ターゲット環境の実際の状態を定期的に監視し、それを Git リポジトリ内の目的の状態と比較します。実際の状態が目的の状態と一致しない場合、オペレーターはインフラストラクチャの実際の状態を目的の状態に一致するように更新します。

望ましい状態の唯一のソースとして機能できるのは、Git の変更のみです。これ以外では、誰もクラスターに変更を加えることはできません。変更を加えた場合でも、オペレーターが希望の状態に復元します。これは伝説的な不変のインフラストラクチャです。

現在、プルモードに基づくCDツールには、Argo CD[1]、Flux CD[2]、ks-devops[3]などがあります。

GitOpsの利点

一般的に、GitOps ではプルベースのデプロイメント モードが好まれます。このモードにはかけがえのない利点が多数あるためです。

より強力なセキュリティ

前述のように、GitOps を使用する場合、デプロイメントを実行するために Kubernetes またはクラウド プラットフォームの資格情報は必要ありません。 Kubernetes クラスター内の Argo CD または Flux CD は、Git リポジトリにアクセスし、プル モードで更新するだけで済みます。

一方、Git は、コードの変更を追跡および管理するための強力な暗号化技術を備えており、変更に署名して作成者と出所を証明する機能も備えているため、クラスターのセキュリティ保護に重要です。

真実の唯一の情報源としての Git

インフラストラクチャの宣言的構成を含むすべてのアプリケーションが Git に保存され、Git がアプリケーション システムの唯一の信頼できるソースとして使用されるため、kubectl などのツールを使用せずに、Git の強力な機能を使用して、バージョン管理、履歴、監査、ロールバックなど、すべてを操作できます。

生産性の向上

Git も開発者にとって非常に馴染みのあるツールです。 Git の継続的な反復により、生産性が向上し、開発と展開が加速され、新製品のリリースが早まり、システムの安定性と信頼性が向上します。

コンプライアンス監査の簡素化

GitOps を使用するインフラストラクチャは、他のソフトウェア プロジェクトと同様に Git を使用して管理できるため、品質の監査も行えます。インフラストラクチャに変更を加える必要がある場合は、プル リクエストが作成され、関係者がコードをレビューした後にのみ変更をシステムに適用できます。

要約する

GitOps は既存の DevOps 文化を補完するものです。 Git などのバージョン管理システムを使用してインフラストラクチャを自動的にデプロイします。展開プロセスは明確に可視化され、システムに加えられた変更を表示および追跡できるため、生産性、セキュリティ、コンプライアンスが向上します。さらに、GitOps はより優れた可観測性を提供し、デプロイメント ステータスをリアルタイムで監視し、実際のステータスを予想されるステータスと一致させるためのアクションを実行できます。

さらに、GitOps ではシステム全体が宣言的に記述されますが、Kubernetes がこのように設計されているため、クラウド ネイティブ環境に自然に適しています。

参考文献

• GitOpsとは何か？そしてそれについて何を知るべきか？[4]
• DevOps vs GitOps: 方法論をマスターするために知っておくべき4つの利点[5]
• GitOpsガイド[6]

参考リンク

[1]アルゴCD: https://github.com/argoproj/argo-cd/

[2]フラックスCD: https://github.com/fluxcd/flux

[3]ks-devops: https://github.com/kubesphere/ks-devops

[4]GitOpsとは何か、そしてそれについて何を知るべきか？: https://devs-group.medium.com/what-is-gitops-and-what-should-you-know-about-it-fcaa3e3c1dd5

[5]DevOps vs GitOps: 方法論をマスターするために知っておくべき 4 つの利点: https://www.tynybay.com/our-thinking/devops-vs-gitops-4-benefits-you-must-know-to-master-the-methodologies

[6]GitOpsガイド: https://www.weave.works/technologies/gitops/