CNDT2020シリーズ：オススメのGitOpsツールをCAのインフラエンジニアが解説

今回は、サイバーエージェントのインフラストラクチャーエンジニアである長谷川誠氏によるGitOpsのためのCDツールを比較検討するセッションを紹介する。長谷川氏は青山氏と同じくインフラストラクチャーチームに所属し、サイバーエージェントのOpenStackとKubernetesのインフラストラクチャーを担当するリードエンジニアだ。過去のCloudNative Days Tokyoでも講演を行い、高い評価を得たコンテナランタイムのセッションなども行っている。

今回は、CI/CDの解説とツールの比較検討を行うセッションを担当した。CI/CDはCNCFのクラウドネイティブなシステムのトレイルマップにおいても、コンテナ化の次にやるべきこととして挙げられている。

ちなみにCNCFのトレイルマップは、クラウドネイティブなシステムを実装する際に「どこから手を付けるべきか？」を教えてくれるものだ。これによれば、アプリケーションのコンテナ化の次にCI/CDが挙げられており、ソースコードの修正から本番環境への実装までを自動化することを推奨している。クラウドネイティブなシステムの基盤として使われるKubernetesが登場するのはその次の段階となっており、「コンテナ化」→「CI/CD」→「コンテナオーケストレーション」→「オブザーバビリティ」という流れがベストプラクティスであることを知っておくべきだろう。トレイルマップは以下のリンクから参照可能だ。

参考：CNCFトレイルマップ

セッションを行うサイバーエージェントの長谷川氏

セッションのタイトルは「GitOpsツール徹底比較！あなたにぴったりなGitOpsツールがきっと見つかる」というもので、CI/CDをより進めたGitOpsを解説する内容ともなっている。

GitOpsツールの比較を行うセッションとなった

そもそもGitOpsとは？

まず長谷川氏は「GitOpsとは何か？」の解説からセッションを始めた。ここではWeaveworksが2017年に公開したブログ記事から「GitOps」という単語が使われ始めたことを紹介。「簡単に言うと」というまとめで「Kubernetesのリソース構成情報をGit上で管理する」ことで、属人化しがちなインフラストラクチャーを宣言的に処理しようという試みであることを解説した。

GitOpsの定義は？

より運用担当者の立場で分かりやすく言えば、「kubectl」コマンドを使わないことだと説明した。

GitへのPushがそのままインフラストラクチャーへの構成指示になる

次にGitOpsを成立させるためのルールの一例として、「Kubernetesのリソース情報はすべてGitに置く」「内容の変更はPull Requestのみで行う」「リソースの変更は自動でKubernetesクラスターに反映する」「クラスターとGitの内容に違いが生じた場合は、それを修正する」などを紹介した。ただ「この辺りの定義は組織やデベロッパーによって異なる」という認識も示しており、違いはあるだろうとのことだ。

GitOpsのルールの例

またGitOpsを実施するメリットとして「履歴が残るために変更が分かりやすくなる」「変更の承認などの組織のガバナンスが適用できる」「自動化によって人的コストが削減できる」などを挙げた。

GitOpsのメリット

そしてCI/CDの処理の流れのうちで長谷川氏が考えるGitOpsの領域について、後半のCDの部分がGitOpsの適用領域であると説明した。ここでも「諸説ある」としてインフラストラクチャーエンジニアの中でも認識にはズレがあることを語った。

長谷川氏の認識ではCI/CDの後半部分がGitOpsの領域

Pull or Push？

続いて、GitOpsの手法にはPush型とPull型の2つが考えられるとした。PushはGitリポジトリーからのWebhookによってKubernetesへのDeployが始まる仕組みであり、PullはKubernetesからGitへの定期的なポーリングを行うことで変更を検知して、自身の構成の変更をキックする仕組みだ。

Push型とPull型のGitOpsの実施方法

長谷川氏はPush型の欠点として、クラスターを変更するための特権を持つユーザーの認証情報をKubernetesの外側に持つ必要があり、APIを外部から操作できるように公開する必要もあるとして、セキュリティ上のマイナスポイントになるだろうと解説した。

Push型の欠点

一方のPull型はKubernetesの中で閉じた構成が可能となり、またAPIを公開する必要もないため、Push型のセキュリティ上のマイナスポイントがないことを語った。

Pull型の特徴

ただマニフェストの中で暗号化されたクレデンシャルを複合して適用するような手法はやりづらいとして、External Secretのようなツールを使うなどの工夫が必要だと解説した。External SecretはGoDaddyが作ったツールで、詳細についてはGoDaddyの以下のブログを参照されたい。

参考：GoDaddyブログ：Kubernetes External Secrets

日本語の資料で参考になるのは、以下のPlaidのエンジニアが書いたブログだろう。

参考：悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由

以上を踏まえて長谷川氏は、実際に選択するとすれば、セキュリティの観点からPull型を採用すべきと語った。

Pull型を推奨

GitOpsツールの比較

そしてここからこのセッションの本題であるGitOpsツールの比較となった。

GitOpsツールの比較はFlux、ArgoそしてJenkinsX

ここで紹介されたツールはすべてオープンソースソフトウェアであり、FluxはWeaveworks、ArgoはIntuit、そしてJenkinsXはCloudBeesが開発をリードしている。前述のとおり、WeaveworksはそもそもGitOpsという単語を生み出したベンチャー企業だ。

まずはGoogle Trendでそれぞれのソフトウェアの人気の遷移を紹介した。

Google TrendによるFlux、Argo、JenkinsXの比較

ツールの開発状況の比較としてGitHubでのStar、Commit、Contributorの数などを示したのが次のスライドだ。

GitHubでの開発状況を比較

ここではFluxとArgoがCNCFにそれぞれサンドボックス、インキュベーションとしてホストされている一方、JenkinsXは同じくCNCF配下ではあるが、別の組織となるContinuous Delivery Foundationの中でホストされているという違いがあることが分かる。

Flux

Fluxの特徴

Fluxはシンプルな構成をもつソフトウェアで、1リポジトリーに一つのAgentが必要となる。シンプルであるゆえに、複数のGitとKubernetesクラスターという組み合わせでは構成＆運用するのにコツが必要と言えるようだ。またGitだけではなくアプリケーションのイメージが更新されたらCDが動き出すという特徴を備えており、長谷川氏はこれを指して「ImageOpsと呼んでも良い」とコメントした。この点はGitの中の変更ではなく、その生成物であるArtifactを中心にフローが動き出すという意味であろう。

イメージを中心としたImageOpsがFluxの特徴

Argo CD

次に紹介するのはArgo CDだ。「Argo」はプロジェクトの名称であり、その下にArgo CD、Argo Workflow、Argo Events、Argo Rollout、GitOps Engineなどのサブプロジェクトが存在する形になっている。正確に言えばCNCFにインキュベーションされているのはArgo Workflowで、KubernetesのCRDとして実装されるソフトウェアだ。Argo CDはその意味ではCNCFのプロジェクトではないと言える。長谷川氏はArgo CDの特徴を「何と言ってもGUIだ」と解説し、すべての操作がGUIから実行できることを強調した。

Argo CDの特徴はGUI

またArgo CDではGitリポジトリーやクラスターなどをApplicationという名称で定義し、マルチテナントも無理なく構成できるという。また複数のApplicationを使うことで、メインのクラスターに実装されたArgo CDが複数存在するサブのクラスターを運用できるとして、柔軟な構成が取れる部分がシンプルなFluxとの違いであると解説した。

複数のクラスターを1つのArgo CDで運用できる

JenkinsX

最後に紹介されたのは、CloudBeesが開発するJenkinsXだ。JenkinsXはJenkinsとはまったく異なるソフトウェアであり、複数のオープンソースソフトウェアによって構成されていると説明した。

多くのOSSで構成されるJenkinsXの概要

JenkinsXのコマンドラインツールであるjxコマンドは非常に強力で、JenkinsXの設定だけではなくKubernetesクラスターの作成まで可能であるとして、他のツールとの違いを解説した。

複数のOSSで構成されることで複雑なのがJenkinsXの残念な点

ここではステップに沿ってPreview～Staging～Productionと開発からステージング、本番環境に至るまでをJenkinsXで運用する部分を解説した。

jxコマンドで操作し、本番環境までDeployされるようすを説明

GitOpsツールはどれを選ぶ？

ここまでで3つのツールについてインストール、マルチテナンシー、GUI、ImageOpsの項目で評価をしたのが次のスライドだ。

Flux、Argo CD、JenkinsXの比較表

最後にWeaveworksのFluxとIntuitのArgo CDが「GitOps Engine」として統合されるというニュースを紹介。

FluxとArgo CDが統合される？

しかし実際にはFluxとArgo CDの統合は上手くいかなかったとして、FluxはGitOps Toolkitの開発に移行し、IntuitのArgo CDはArgo CDと並行にGitOps Engineを開発するということになったと説明した。

FluxとArgo CDの統合は失敗に終わった

そしてFlux、Argo CD、JenkinsXに追加する形でGitOps Toolkitについても簡単に評価を行い、多くの要素がKubernetesのCustom Resourceに移行したことで、よりKubernetes-Nativeになったことを解説した。しかしながら、長谷川氏がImageOpsと呼んだイメージを検知してCDを実行するImageOpsの機能はまだ実装されておらず、またGUIも予定にないと説明した。

ImageOpsもGUIもないことを説明

GitOps Toolkitを加えて4つのツールを比較した表は以下の通りだ。

Flux、Argo CD、JenkinsX、GitOps Toolkitの比較表

最後にそれぞれの特徴によって選択すべきツールを紹介してセッションを終えた。

手軽に体験するならFluxかArgo CD

GitOps Toolkit/GitOps Engineの項でも説明されていたように、CI/CDのツールに関して言えば戦国時代という様相で、Netflixが開発し2015年に公開したSpinnaker、HashiCorpが2020年10月に公開したWaypointなどまだまだ新しいツール、プロジェクトがさまざまなベンダー、ユーザーから出てくるレッドオーシャンと言える。

エンドユーザーから見れば、選択は非常に困難と言えるだろう。そのためにもこのような比較のセッションは価値がある。細かい領域では、CI/CDで利用されるクレデンシャルの扱いや管理ツールの比較にも期待したい。今後もCI/CDの領域は要注目だ。