ビルドからリリースまでを抽象化するWaypointにディープダイブ

HashiCorpは、自社のイベントHashiConf Digital 2020で発表したWaypointのより詳細な解説を、Deep Diveセッションとして公開した。この記事ではWaypointのアーキテクチャーなどを紹介する。

Deep DiveセッションでWaypointを深く解説

Waypointの概要はHashiConfのキーノートセッションとしてCTOのMitchell Hashimoto氏が紹介した動画で知ることができる。また、より詳細な内部の構造などについてはHashiCorpのPrincipal EngineerであるEvan Phoenix氏によるセッションで解説された。動画は以下のURLから参照可能だ。

動画：HashiCorp Waypoint Deep-Dive

ここではWaypointの構成ファイル、クライアントサーバーアーキテクチャー、Entrypoint、そしてプラグインの4つについて、約20分かけて解説した。

4つのトピックに絞って解説

Waypointの構成ファイルにはYAMLではなく、HashiCorpが開発したHashiCorp Configuration Language（以下、HCL）を使っている。HCLは、JSONとYAMLの欠点を補うように開発された言語フォーマットと言える。HCLそのものについては、GitHubのリポジトリーで表示されるREADME.mdを参照されたい。HCLはGitHubが自社のCI/CDソリューションであるGitHub Actionsを発表した時に校正用の言語として採用されたが、その後GitHub ActionsがYAMLに変更したという経緯もあり、今ではHashiCorpのみが積極的に利用する言語という状態になってしまっているようだ。

https://github.com/hashicorp/hcl

HCLで書かれたWaypointの構成ファイル

HCLはJSONと互換性があるため、JSONで書かれたデータもサポートしている。サーバーや環境依存ではなく、プロジェクトベースで構成ファイルを作り、利用するというのが基本スタンスだ。そしてFunctionを書けるというのもHCLの利点であるという。これがJSONやYAMLではできないということだろう。

ビルド→デプロイ→リリースまでを一つのファイルで表現できるのが利点

そして何よりも重要視したと思われるのは、ビルド→デプロイ→リリースまでのプロセスを一つの構成ファイルで表現できるという点だろう。これはビルド→デプロイ→リリースの各プロセスに個別のツール、個別の構成ファイルが必要であることを、HashiCorpが「分断されている」問題と考えていることの表れと言える。そしてオンプレミスからパブリッククラウドまで、どのプラットフォームであってもほぼ同じ定義で構成が記述できることを利点として挙げている。

ここでもプラットフォームが異なることで違うツールを使う必要があるという現状の問題点を解決する工夫がなされている。

Waypointのアーキテクチャーはクライアントサーバーモデル

Waypointのアーキテクチャーはシンプルなクライアントサーバーモデルだ。ここでの「クライアント」はサーバーに対して命令を出す役割という位置付けで、主にコマンドラインインターフェースまたはWebUIを指すようだ。サーバーからの指示を受けてビルドなどを実行するのは「Runner」と呼ばれるソフトウェアで、それぞれのプロジェクトに実装される。サーバーは多数のプロジェクトから利用することが可能であるということから、システムに一つ実装され、複数のプロジェクトから利用することを前提にしている。

サーバーの機能

クライアントの機能

Runnerの機能

ここではサーバー、クライアント、Runnerの機能を解説しているが、すべての動作のハブとして機能するサーバーと起点となるクライアント、そして実際にビルド→デプロイ→リリースの機能を実行するRunnerの解説が行われている。ここでは、Waypointの最も特徴的な点であるEntrypointに注目したい。

WaypointのキーとなるのがEntrypoint

次のスライドでは「Runtime Functionality」と記述されているように、実行するアプリケーションを起動するという意味でのランタイムがEntrypointの仕事の一つだ。そして、アプリケーションのコードとともに実行されるプログラムであり、現時点ではBuildpackおよびDockerのコンテナの中にインジェクションされるというのがポイントだ。これによって、この後に説明されるExecやLogsといった機能が実現できるというわけだ。

ランタイムの機能を果たすEntrypoint

そしてこのEntrypointはWaypointのサーバーとのみ通信を行い、外部に露出されることはないという。この仕組はセキュリティ上の観点でも際立っている。

必要最低限の機能だけを実装したシム（クサビ）的なプログラムであるEntrypoint

コンテナイメージに注入されるEntrypoint

KubernetesにおけるサイドカーProxyのように通信を仲介するのではなく、アプリケーションの起動とアプリケーションへのコマンドや状態の収集などに使われるのが用途である。その用途は二つの機能として実装されている。一つ目がアプリケーションへのコマンドであるExecで、二つ目がアプリケーションの状態をstdoutやstderrから取得するLogsだ。

他にもURLを生成するサービスが実装されており、すべてのデプロイ→リリースにおいて個別のURLが生成される。このためにリリースごとのアプリケーションの動作確認などが容易に行えるようになる。このサービスについては、現状ではHTTPでのアクセスのみのサポートのようだ。

URLを生成するサービスをHashiCorpが提供

HashiCorpのサービスを使わずにオンプレミスに実装することも可能

ここからEntrypointが提供するExecとLogsの機能をダイアグラムを使って解説を行った。

Waypoint Execの解説

この例ではDateというコマンドをクライアントからgRPCを使ってサーバー経由でEntrypointに通信し、Entrypointがそれをアプリケーションに渡すという形になっている。

またLogsについても同様の通信を行って簡易的なログを収集することが可能になっている。

LogsもEntrypointによって実装されている

Entrypointは運用担当者が構成するログ収集／管理システムを置き換えるものではなく、自ら書いたコードが「意図した通りに動いているのか？」をデベロッパーが確認するための仕組みであることが強調されていた。実際にはこのEntrypointを入れずにワークフローを回すことも可能であるため、正常な実行を確認した後に、本番環境において外してデプロイすることも可能だ。ちなみにURLを生成するサービスもEntrypointが必要なので、デフォルトで有効にするというのがWaypointを開発したHashiCorpの想定している使われ方だろう。

ラストのパートはプラグインによる拡張の解説だ。

Waypointの機能はプラグインとして実装される

次のスライドではビルドステージの例を挙げてプラグインを解説している。0.1のバージョンではDockerおよびHerokuのBuildpackが利用可能と記述されているが、ドキュメントにはAWS、Azureなども書かれており、今後この部分は拡張されていくだろうということが理解できる。

最後にビルド→デプロイ→リリースが一つの構成ファイルで定義できることの利点として、前のステージで生成された値を使ってワークフローを定義できることを解説したのが、次のスライドだ。

各ステージで値を渡すことでインテグレーションが可能になる

またMapperという値をマップする機能を使うことで、ワークフローを柔軟に定義できることを解説した。

Mapperを使うことでワークフローを柔軟に定義できる

まとめとして使われたスライドでは、構成ファイルを一つにまとめることでアプリケーションのビルドからリリースまでをシンプルにできることなどがあらためて紹介された。

Waypointの重要なコンセプトは、デベロッパーに対してビルド→デプロイ→リリースというプロセスに統一的なインターフェースを提供するという部分だ。対象は運用担当者ではなくデベロッパーであり、EntrypointによるExecやLogsなども、Ops目線ではなくDev目線であるということだろう。

またHashiCorpは、WaypointがPaaSなどと比較されることにについても意識しているようで、HerokuなどのPaaSとの比較だけではなく、KubernetesのパッケージマネージャーであるHelmにも言及している。

参考：Waypoint vs. Other Software

ここまでのWaypointの解説を見ると、デベロッパーが直面するプラットフォームごとに異なるツールでビルド→デプロイ→リリースを行う苦痛に対する解決策として、シンプルなツールで必要十分なことだけを実装したソフトウェアであることが理解できる

すでに存在し使われている多数のツールとプラットフォームの組み合わせをプラグインの形で組み込める発想は、いかにもHashiCorpならではというところだろう。「Waypointの構成ファイルであるHCLが支持されるのか？」については多少疑問はあるものの、ツール自体の今後の進化とコミュニティの成長に注目したい。