"GitOps": WeaveworksがCI/CD実践に使用する開発者モデルを公開

この1年間、Weaveworksの開発チームは、開発用ツールを運用と継続的デリバリの実現に使う、“GitOps”と名付けた彼らのプラクティスに対して、そのアイデアを洗練する作業を続けてきた。

GitOpsは、分散バージョン管理システム(DVCS)であるGitを、宣言的インフラストラクチャとアプリケーションの“唯一の情報源(single source of truth)”とすることで実現されている。チーム内の開発者はすべて、そのGitリポジトリに対してプルリクエストを発行することができる。マージが発生した場合は、“差分と同期”ツールでシステムの意図した状態と実際の状態の差異を確認した後、インフラストラクチャを意図した状態に同期させるツーリングが起動される。

Weaveworksの創設者でCEOのAlexis Richardson氏と、同社コミュニティエンジニアのIlya Dmitrichenko氏は、GitOpsの概念を説明する一連の記事を自社のブログに書いている。GitOpsプラクティスを使用する場合、自動化されたビルド/デリバリーパイプラインでは、Gitに加えられた変更からインフラストラクチャの更新を検出してロールアウトする、いわゆる“プルモデル”を採用する。このプラクティスでは、専用のツールや製品の使用を求められることはなく、選択したツールが特定の機能(“差分と同期”など)を提供可能であればよい。

Weaveworksチームは、GitOpsを使用することで、開発チームの開発速度の向上、並びにシステムの信頼性向上が可能になる、と主張している。記事の中では、同社がGitOpsを社内のプロダクト提供において実践していること、同社のSaaSプロダクトであるWeave Cloudがこのアプローチのビルディングブロックを提供していること、などが論じられている。Weave Cloudは、“コンテナとマイクロサービスの展開、監視、管理”を提供し、Gitクラスタ同期(Git-cluster synchronization)をサポートするサービスである。

Weaveworksの作成したGitOps実践ガイドラインでは、現時点ではデプロイにコンテナとKubernetesを使用する。その内容は次のようなものだ。

1. ソフトウェアシステム内でコードとして記述できるものは、すべてGitに保存しなければならない。Gitを真実の情報源(source of truth)として使用することにより、クラスタを監視し、目標とする状態と比較することが可能になる。目標は、ポリシ、コード、コンフィギュレーション、さらには監視対象イベントやダッシュボード定義まで、すべての記述をバージョン管理の対象にすることである。
2. KubernetesのCLIツールである“kubectl”を直接使用しないこと。一般的なルールとして、kubectlを使ってクラスタに直接デプロイするのはよいプラクティスではない。CIツールにデプロイメントを任せているチームは多いが、この方法では、“関心の分離”を適切に行えないと同時に、“潜在的なハッキング可能性の高さで知られるこのツールの、生産ラインへの関与を可能にする”ことになる、とWeaveworksチームは主張する。
3. “オペレータパターン(operator pattern)”に従ってKubernetesコントローラを使用すること。オペレータパターンに準拠した独自のコントローラを使用して、Kubernetesの提供する機能を拡張することにより、Gitベースの“真実の情報源”と常に同期するようにクラスタを設定することが可能になる。Weaveworksチームでは、意図された状態と実際の状態を比較する"diff"および"sync"ツールとして、オープンソースのkubediffの他、"terradiff"や “ansiblediff”(それぞれTerraformおよびAnsible用)などの社内ツールを使用している。

インフラストラクチャとアプリケーションの両方の現在の状態を比較し、管理することにより、Gitログにカプセル化された完全な監査証跡を使ったテスト、展開、ロールバックが可能になる。それ自体、“GitOpsの哲学とそのベストプラクティス”そのものだ。現代的なプラットフォームコンポーネントでは、例えばKubernetesは宣言的なconfigによってほぼ完全に管理されており、コンテナを変更不能に構築することも(比較的)簡単なので、旧来のテクノロジに比べると、このアプローチをはるかに実践しやすくなっている。

Weave Cloud SaaSプラットフォームを使用した場合、ソフトウェアアプリケーション内に新たな機能を開発ないし更新する一般的な開発ワークフローは、次のようなものになる。

1. 要求された新機能を新たなGitブランチ上で開発し、コードレビューの準備が整ったならば、GitHub上などでプルリクエストを生成する。
2. コードがレビューされ、コメントが付けられるか、あるいは変更がメンバによって承認される。必要な修正が行われた後、プルリクエストが承認され、トランクまたはメインラインブランチにマージされる。
3. Gitマージの実施が継続的インテグレーション(CI)とビルドパイプラインを起動し、一連のテストが実施される。これらのテストが正常に完了すると、新たなコンテナイメージが作成され、イメージレジストリにアップロードされる。
4. イメージレジストリを監視しているWeave Cloudの“Deployment Automator”が新たなイメージを検出すると、これをレジストリから取り出して、設定が記述されたリポジトリ内のYAMLファイルを更新する。
5. Weave Cloudの“Deployment Synchronizer”(クラスタにインストールされている)が、クラスタの状態が“古くなった”ことを検出すると、更新されたマニフェストをconfigリポジトリから取得して、新しい機能を運用向けにデプロイする。

WeitworksチームはGitOpsについて、運用と機能の両方を実装し管理するための“リリース指向モデル”である、と述べている。可観測性に優れたプラクティスとツールを追加して仮説駆動型(hypothesis-driven)開発におけるフィードバックループを完全なものにすることで、顧客に対していかに速く新機能を提供することができるようになるかは、一部においては、OODAループにインスパイアされたソフトウェア提供ライフサイクルの各ステージまでいかに早く到達できるかに依存している。

GitOpsについて詳しく知りたい読者には、WeaveworkのWebサイトで公開されている一連のブログ記事がある。最初の記事では、“プルリクエストによる運用”モデルについて説明した上で、コンセプトの動機と概要が示されている。２番目の記事は、GitOpsデリバリパイプラインの中核的なステージについて論じる。シリーズのパート３では、このプラクティスにおける可観測性の役割について検討する。ソフトウェアデリバリコミュニティからの反応は概ね良好で、Kelsey Hightowerなど業界の著名企業もこのアプローチを肯定的に評価している。

GitOpsと“CIOps”を独自に比較検討した記事もある。その中では、ソフトウェアを継続的に提供するというデプロイメント面をオーケストレートする上で、CIツーリングの使用は必ずしも最善策ではないかも知れない、と論じている。すべての人々がこのネーミング選択を歓迎している訳ではない。例えば、Conflux Digitalのコンサルタント部門を統括するMatthew Skelton氏は、“CIOps”という用語が一部の開発者に対して、GitOpsが優れたCIの実現に対する代替策であるという誤った結論を招く可能性を示唆している。

GitOpsに関する詳細な情報は、Weaveworksのブログで見ることができる。