CNCFのWebinarからKubernetesのデプロイメントに冪等性を実現するwerfを紹介

クラウドネイティブなシステムを推進する団体であるCloud Native Computing Foundation（CNCF）が配信したWebinarから、werfを紹介する。この動画は「Why werf for CI/CD in Kubernetes ?」と題された解説だが、理解するためにはそもそも「werfとは何か？」を知っておく必要があるだろう。

そのために、Weaveworksが2020年に開催したGITOPS DAY 2020のセッションを最初に紹介しよう。

●参考：GITOPS DAY 2020の動画：Dmitry Stolyarov (Flant) on Introduction to werf: Another view on GitOps

werfのイントロダクション。GitOpsの別の視点という副題が付いている

この動画はwerfの開発元であるFlantのCTOであるDmitry Stolyarov氏が2020年に行ったもので、非常に緊張した面持ちのStolyarov氏が母国語ではない英語での初めてのプレゼンテーションに苦労しながらwerfを解説しているのがわかる。このプレゼンテーションではwerfのイントロダクションとして、GitOpsのプロセスの中でコードがビルドされてユニットテストを経てステージングやプロダクション環境にプッシュされる際の問題点に注目している。

GitOpsの基本を解説。ソースコードからインフラ構成まですべてGitの中で管理

ソースコードやインフラストラクチャー構成のための情報を一元化し、「Single Source of Truth（唯一の真実の在処）」として扱い、コードの開発とビルド、テストまでをデベロッパーが行い、Gitを媒介にして本番環境への実装は運用担当が行うことで、責任を分解しながらも一連のフローが滞らないようにするのがGitOpsの要点だ。Stolyarov氏はそのプロセスの中で、コードが生成されてインフラストラクチャー上にデプロイされる際に発生する問題点を指摘している。ここではCIの延長として本番環境にデプロイするまでの処理に多くの問題点が存在すると指摘している。

アンチパターンとしてCIOpsを紹介

ここでStolyarov氏はIT業界ではあまり使わない用語を使っていることに注目したい。それはDeterminismとIdempotenceだ。それぞれ日本語では「決定論」「冪等性」（べきとうせい）という意味だ。冪等性は日本のインフラストラクチャーエンジニアではお馴染みの用語かもしれないが、英語のスライドで目にすることは珍しい。

もう一つの決定論は哲学の世界で「あらゆるできごとはそれに先行するできごとによって決定される」という意味で、ITの世界ではあまり見かけない単語だ。冪等性は数学の世界の用語だが、ITの観点からは同じ命令／処理を何度繰り返しても同じ結果が出ること、アプリケーションのレプリカを5つ実行するという命令を与えた時に何もアプリケーションが実行されていない場合は5個を起動するが、すでに1つ起動されているのであれば、4つだけを起動、5つ起動済みであれば何も起動しないということになる。

このチャートでは前半の部分に問題があり後半は問題がないと説明

このスライドでは前半のビルド～テスト～プッシュの部分に問題があることを指摘している。それはDeterminism（決定論）とIdempotence（冪等性）の観点から言えば、ある処理の後には必ず決められた処理が実行されるべきであり、その結果は冪等であるべきという意味だろう。この意味はこの後の例を見れば理解できるが、この時点では非常に概念的だ。

GitOps PipelineとCIOpsの双方に同じ問題点が含まれていることを指摘

次のスライドで概念的ではあるが少しは具体的に何が問題なのかを2点指摘している。最初の問題点はビルドとタグ付けに関するものだ。ここではビルドにおいて決定論的に何がビルドされるのか、同じ手順で必ず同じArtifactが生成されること、冪等性を持つこと、どのマシン、環境であっても同じ結果が生成されることを挙げている。タグについても同様だ。

ビルドとタグ付けに関する問題点の概念的な整理

2つ目の問題点については、Kubernetesのライフサイクル管理のツールであるHelmを例に挙げて説明。

デプロイの問題点をHelmについて解説

ここでも概念的にHelmの持つ問題点を解説している。ここではHelmがチャートに従ってデプロイを行なうが、実際のリソースの監視とそれに対応した処理が行われないために利用者にとっては問題が発生するということを示している。しかしこの説明は具体性に欠け、説明も練られていないために理解は困難だろう。

GitOpsの中核にwerfを使うことで問題点が解決される？

この部分に関してはCNCFの動画でより詳しく解説が行われているので、ここからはCNCFの動画からのスライドを使って解説したい。この動画はPalarkというFlantとは別の企業のエンジニアが行っていることにも注目して欲しい。

「werfとは何か？」を説明するGitHubページの引用

ここではそもそも「werfとは何か？」についてGitHubを引用して紹介したい。werfはCIシステムに導入することですでに利用しているDockerやBuildah、Helmなどを糊付けするCLIツールというのが要約となる。特にDockerfileとHelmを使っているのであれば、そのコードを再利用できるという点がポイントだ。

werfはDockerとHelmをラップする単一のCLIツール

そしてCIパイプラインの中でビルド～テスト～デプロイを担当すると説明されている。

ここではwerfがCI/CDパイプラインの中でビルド～テスト～デプロイを担当

しかし実体はDockerもしくはBuildahによるビルド、Helmによるデプロイをラップして単一のコマンドで実行できる機能をwerfが担当するという意味になる。その役割は次のスライドでより具体的に説明されている。

CIとCD（デリバリーとデプロイメント）の段階とwerfの担当するエリア

そしてこの動画ではDocker、Helmとの比較を強調することでwerfの利点を解説しているが、レイヤーのキャッシング等について説明を行っている。しかしGitOpsの中核にwerfを使う利点としては弱く、次のApplication Deployment Trackingという部分の説明が一番わかりやすい。

Helmを使ってデプロイする際の問題点を解決する仕組み

これはHelmを使ってアプリケーションをデプロイする際の問題点を解説している。Helmはリソースの状態を監視した上でPodのデプロイを行うわけではないので、まだPodがレディ状態にならないためにエラーが発生すること、エラーの内容を監視できないことなどを挙げて、冪等性が低いという問題点が発生することを示している。興味深いのはDeterminismやIdempotentというFlantのStolyarov氏が強調していた単語は使われずに、Deterministic、Immutableという単語が使われていることだろうか。

HelmはKubernetesのリソースの状態を常に監視して実行されるわけではない

ちなみにこのKubernetesの状態を監視して何が起こっているのかを検知する仕組みには、Flantが開発したKubedogが利用されている。

●参考：https://github.com/werf/kubedog

その上でHelmとwerfを使ってKubernetes上にリソースをデプロイするデモを見せ、実際にエラーが起こった時の動作の違いを解説している。

Helm（左）とwerf（右）によるデプロイの違いを解説

この部分のまとめとして使われたのが次のスライドだ。

アプリケーションデプロイメントトラッキングの概要

ここではリソースが準備できるまで待つ機能、失敗したデプロイメントはタイマーに頼らずに即座に終了させる機能、進行状況の可視化などが挙げられている。つまりDockerやBuildahを使ってビルド～テストを実行し、Helmを使ってデプロイを行う部分に前段はラッパーとしてwerfコマンドで抽象化し、後段はHelmの実行をKubedogで監視しながら冪等性を担保することがwerfというツールの実体だろう。

この理解を得るまでに何度も2つの動画を見返す必要があった。今回公開されたCNCFの動画ではKubernetesのCI/CDの中核ツールとして使うことにフォーカスして解説しているのは、2020年のFlantのStolyarov氏の動画が余りにもわかりにくかったからであろうか。ちなみにwerfがCNCFのサンドボックスプロジェクトとして採用されたのは2022年12月、動画が公開されたのが2023年6月だ。

またwerfという名前の由来については、Stolyarov氏の動画で解説されている。

シップヤード（造船所）のロシア語の発音がオランダのwerfから来ていることに由来

ここでは造船所（Shipyard）のロシア語がverfと発音されることとそれがオランダ語の「werf」に由来していることから命名されたと説明。Stolyarov氏の出身がロシアという部分にも関係しているのだろう。別の動画ではwerfはDockerとHelmのラッパーでしかなく、モノレポ環境以外では使い道がないなどと酷評されていたが、Docker以外にBuildahへの対応、Helmの弱点をKubedogで補うという部分にCNCFはサンドボックスプロジェクトとして採用する価値を見出したということだろう。

Kubernetesが宣言的にインフラストラクチャーを抽象化したことで、常に変化を求められるクラウドネイティブなシステムにおいて大きな役割を果たしていることは疑問の余地はない。その周辺を固めるエコシステムのツールについても弱点を見い出し、それらを継続して改善する努力が行われていることが、werfを見ていることで感じられた。

●参考：CNCFの動画：Why werf for CI/CD in Kubernetes?