コマンドラインツールを用いずにCI/CDを行うGitOpsとは？

KubeCon＋CloudNativeConではKubeflowやIstioなどの多くのプロジェクトが紹介され、まるでKubernetesのエコシステム展覧会と言ってもいいほどだ。その中から今回は、WeaveworksのCEO、Alexis Richardson氏が提唱するGitOpsについて紹介したい。Richardson氏は、Cloud Native Computing Foundation（以下、CNCF）のTechnical Oversight Committeeのチェアも務めている人物だ。

プレゼンテーションを行うWeaveworksのAlexis Richardson氏

Richardson氏は、クラウドによってDevOpsへの流れが生じたと語り、その先にあるのは「Push Code, Not Container」とあるように開発者が「コードを変更したら、コンテナーにそれを入れることを優先するのではなく、運用はプルリクエストで実行されるべき」というのがGitOpsの本質ということだろう。

そこでこのセッションではデモを交えてIstioによるサービスメッシュを例に取り、カナリアリリース（試験的に少量のトラフィックを新しいイメージに流して、上手くいくかどうかを確認する）の運用をistioctlやkubectlという管理用のコマンドインタフェースを使わずに実施できることを紹介した。

GitOpsの要点。構成はバージョンコントロールすべき

ここでのポイントは、「KubernetesやIstioの運用に、コマンドラインを用いない」という部分だろう。つまり、全ての変更はGit上のコードとして履歴管理がなされるべきであるという力強い宣言だ。これは特に大規模な運用が必要となるエンタープライズにおいては非常に重要で「誰がいつ、何を変更したのか？」という部分が全てGit上のコードとして記録される。そのために何か不具合があった場合はただちに原因の追求が行えるし、何よりも復旧することが可能になる。そのためにはデベロッパーや運用担当者が、kubectlなどのコマンドラインツールを使わないことが重要なのだ。

そしてIstioをサービスメッシュとして使う場合にも、全ての構成情報がYAMLファイルとして利用されることから、Git上でソースコードとして管理することで履歴管理が可能になる。

Richardson氏曰く「履歴が残らない変更は有害」

そして開発から運用までのパイプラインを紹介する。ここでは上流がデベロッパー、下流が運用担当者という位置付けだ。デベロッパーがコードを変更すると自動的にコンテナーがビルドされ、コンテナーリポジトリーにUpload、それがステージングサーバーへの構成変更としてトリガーされ、運用担当者による構成情報変更のマージがGit上で承認されることで、本番環境のサーバーにプッシュされる。このようにKubernetesの環境が変更されるという流れだ。ここでは一度もkubectlは姿を現していない。

GitOpsのパイプラインを参考として紹介するRichardson氏

特に強調されていたのはDeclarative（宣言的）に構成情報を位置付けて、その状態を常に保つようにKubernetesとIstioが動作するという部分だろう。「宣言的」という意味は「アプリケーションを稼働させる環境が必要とする状態を定義する」ことで、常にそれを維持しようとするように全てのソフトウェアが動くという意味だ。Kubernetesの特性をうまく利用しているとも言える。

あるべき姿と現状との差を常に検知して維持しようとすることが要点

ここからデモを使って紹介するフェーズとなった。「GitOps for Istio」というデモでは、ルーティングの設定をカナリアリリースに対して行う場合に、あるユーザー名から来たトラフィックに限り新しいサービスに振り分けるというルールをIstioで設定。それをGit上で変更し、Prometheusのモニター上で実際に確認するというものだ。

ここでも、Git上でのコード変更から自動的にCIが起動されて本番環境までプッシュされて変更が有効になるまでのデモを行った。

カナリアリリースを行うためのIstioの構成情報

最後のデモは、Kubernetesのネームスペースをコマンドからマニュアルで削除し、それが自動的に復帰されるというもので、ここでもあるべき姿を常にシステムが維持しようとする機能を示したものとなった。

カナリアリリースのCDのためのシステム構成図

このGitOps for Istioについては、以下の動画に全て記録されているので参照されたい。

GitOps for Istio - Manage Istio Config like Code

またRichardson氏に別途インタビューを行ったところ、「CI/CDがCNCFとしても重要なのは理解しているが、特別にひとつのプロジェクトとしてホストする予定はない」とのことだった。その理由として、商用ソフトウェアも含めてすでに多くのCI/CDツールがあること、多くのソフトウェアがある程度成熟しており、CNCFとしてサポートする必要を感じないから、というコメントをもらった。

ただ、感触としてはCNCFのホストプロジェクトではなく、推奨されるツールとしてトレイルマップ上で紹介されることはあると感じられた。