より良いソフトウェアワークフローのためのOpenGitOps原則の理解

GitOpsは、Gitバージョン管理システムに基づく方法論を用いてソフトウェアを運営・管理する方法を説明しています。GitOpsベースのワークフローを使用することで、システムの特性をGitリポジトリ内のファイルとして定義することを要求するため、ソフトウェアの開発、デプロイ、保守、およびコラボレーションが容易になります。

Gitの役割は単一の真実のソースであることが用語から暗示されています。しかし、GitOps駆動のプロセスの実際の実装は歴史的に解釈の余地がありました。この曖昧さは、再現可能なGitOpsシステムに導く原則を定義するためのCNCF支援の試みであるOpenGitOps基準によって解決されました。

この記事では、原則とは何か、なぜそれが重要なのか、そしてそれを使ってスケーラブルでメンテナブルなソフトウェアを構築する方法について見ていきます。この基準は、90以上の主要企業やGitOpsワーキンググループの利害関係者からの洞察を基に開発されました。

1. 単文状態

第一の原則は、すべてのGitOps管理システムの状態が宣言的に表現されている必要があるということです。理想的な状態が現在の時点でどのようなものかを定義すべきであり、その状態を組み立てるための具体的な指示を提供するべきではありません。

宣言型構成は、システムの望ましい状態を、その状態への移行に使用される手順から分離します。これは、より保守的で、時間が経つにつれて考慮しやすくなります。貢献者は、システムが現在どのように見えるべきかを説明する必要があるだけで、状態の変更に影響を与えるマイグレーションを書く必要がなくなります。

正確なステップを定義しないことで、開発時間を節約し、デプロイの柔軟性を高めることができます。リポジトリから最新の状態定義を適用することで、新しい環境でアプリケーションのインスタンスを簡単に開始できます。

宣言型構成は、AnsibleやTerraformなどのInfrastructure-as-Codeツールで一般的に使用されます。あなたは、利用可能にしたいインフラストラクチャのコンポーネントを定義する構成ファイルを書きます。ツールは、あなたの宣言をAPI呼び出しや必要なリソースを供給するコマンドに変換します。Kubernetesコンテナオーケストレーションプラットフォームも宣言型システムの一例です。

2. バージョン管理され、不変

第二のOpenGitOpsの原則は、システムの状態はそのライフサイクルを通じて完全にバージョン管理されなければならないということです。ここでGitの利点が発揮され、設定ファイルをコミットし、他の共同作業者からの変更をマージし、時間をかけて状態を進化させることができます。

宣言的な状態定義と組み合わせることで、バージョン管理は、物事がうまくいかない場合にシステムを元に戻すための確実な方法を提供します。古いコミットをチェックアウトし、設定ファイルを再適用することで、その時点でのシステムの状態に戻すことができます。

このように状態を保持することは、不変性を強化するのにも役立ちます。インフラストラクチャに変更を適用する唯一の方法は、リポジトリ内のファイルの修正によるべきです。この原則に従うことで、システムの状態が実際にソースの宣言を反映していることを確信できます。インフラストラクチャコンポーネントを直接変更して状態を変更することは避けるべきです。なぜなら、それはシステムの実際の状態と管理リポジトリにおける「望ましい」状態との間に不一致を生じさせるからです。

3. プルベースエージェント

GitOpsの最終的な目的は、システム管理を可能な限り自動化することです。変更を適用するためにプルベースのアプローチを使用することは、これを促進するのに役立ちます。インフラ内で実行されているエージェントは、定期的にGitリポジトリから現在の状態を取得し、変更を適用する必要があります。

従来のプッシュベースのデプロイメントモデルは、CI/CDパイプラインスクリプトの一部としてインフラストラクチャに変更を送信することで機能します。これが自動化されているように感じられても、これはソースリポジトリとインフラストラクチャの間に結合点を作る余分なステップです。プルベースモデルでは、環境内のエージェントがソースリポジトリをポーリングして自動的に変更を検出します。

このモデルは、状態の「ドリフト」に対してより耐性のある自立的なインフラストラクチャを作成します。ドリフトとは、環境内での変化がリポジトリによって宣言された状態と比較して不一致を引き起こすことを指します。プッシュベースのデプロイメントモデルでは、次のスクリプト実行が別のプッシュを開始するまでドリフトは解決されません。プルベースの手法は、定期的にポーリングして最新の状態を再適用することでドリフトを最小限に抑えます。

プルエージェントを使用することはセキュリティの利点にもなります。プッシュベースのアプローチでは、インフラストラクチャを何らかの形で公開する必要があります。これは、ソースコントロールサーバーが更新された状態を送信し、それを適用するコマンドを実行できるようにするためです。インフラストラクチャ内でエージェントを実行することにより、そこへのアクセス経路を提供する必要がなくなります。すべての外部アクセスを環境に許可するようにファイアウォールの制御を強化できます。

同様に、インフラストラクチャにアクセスするための認証情報を生成する必要はなくなりました。プッシュベースのモデルで使用されるCIサーバーの侵害は、ライブ環境を保護するキーを漏洩する可能性があります。外部アクセスに環境を開放するよりも、プルエージェントにGitホスティングプラットフォームへのアクセストークンを与えることでこの流れを逆転させる方がリスクが低いです。

4. 継続的な調整

最終的なOpenGitOpsの原則は、継続的な調整に関するものです。これは、プルベースのエージェントと宣言的状態定義を組み合わせて使用することで実現されます。

あなたのエージェントは、常にシステムの状態を監視しています。彼らは、変更がコミットされるか自然なドリフトが発生する際に、環境を宣言された状態に戻すために行動を起こします。これは、デプロイメントが線形プロセスであり、開始、コマンドのシーケンスを実行し、終了してインフラが自立するのを残す従来のモデルとは対照的です。

継続的な調整は、GitOpsワークフローをリアルタイムで変化する条件に適応する動的なプロセスとして特定します。「設定して忘れる」単純なデプロイメントとはかけ離れたもので、GitOpsエージェントは常に望ましい状態を維持するために働くアクティブなコンポーネントです。これにより、デプロイメントが意図した通りに作動していることを確信して一日を終えることができます。

結論

OpenGitOpsの原則は、GitOpsベースのワークフローを使用して効果的に管理されるシステムの4つの共通の特徴を説明します。これらは、成功した実装の主要な特性を公式化し、DevOpsチームが自分たちのシステムと比較するための基準点を提供します。

これらの原則が示すように、GitOpsは単なるGitリポジトリ内の設定ファイル以上のものです。それは、システムを定義し、実装し、維持するための統一的な方法論です。Gitリポジトリはバージョン管理にとって重要ですが、プルベースのソフトウェアエージェントなどの他のコンポーネントがこの戦略の全潜在能力を引き出します。

OpenGitOpsの原則を取り入れたGitOpsワークフローの効果的な導入は、スループットを向上させ、デプロイメントの健全性を改善し、インフラの運用と保守にかかる時間を最小限に抑えることができます。このアプローチにより、システムの状態を簡単に検査し、Gitとお気に入りのコードエディタを使用して変更を加えたりロールバックしたりすることができます。その後は、インフラのエージェント統合が変更を検出して適用する役割を果たし、デプロイメントへの人間の関与とそれに伴うリスクを排除します。