ビルドからリリースまでを抽象化するツールWaypointをHashiCorpがリリース

VagrantやTerraform、Nomad、Consulなどのツールを開発するHashiCorpは、開発プロセスを抽象化するツールWaypointをオープンソースソフトウェアとしてリリースし、HashiCorpのプライベートイベントHashiConf Digitalのキーノートセッションでその詳細を明らかにした。

Waypointの公式サイト：https://www.waypointproject.io/

この記事ではWaypointを紹介するキーノートセッションからWaypointの概要を解説する。より深い解説となったDeep Diveセッションについては、別の記事で紹介する予定だ。Waypointのアーキテクチャー、ServerとClient、Runnerなどのコンポーネント、そしてキーとなるコンセプトであるEntrypointの詳細、プラグインの概要などについてはそちらの記事を参考にして欲しい。

まずは概要として、HashiCorpのCTOで共同創業者であるMitchell Hashimoto氏が登壇したキーノートセッションの動画を参照して欲しい。

動画：HashiConf Digital Keynote: HashiCorp Waypoint Introduction and Demo

Waypointを紹介するCTOのMitchell Hashimoto氏

Hashimoto氏は、デベロッパーのワークフローの中で最初のコードを書く部分、そして最後の運用の部分についてはかなり完成されたツーリングとプラットフォームが揃っているとし、実際のツールを示す。しかしコードを書いてビルドする部分からコードをインフラストラクチャーにデプロイする部分、そしてアップデートなどをリリースする部分に大きな問題があると語った。

フローの最初と最後は、かなり完成されたツールとプラットフォームがある

特にVisual Studio Codeでコードを書き、GitHubでソースコードをコントロールする部分からCIの部分は多くのツールがあり、ある程度完成されたワークフローができていると語った。また最後の運用する部分とそれを監視／観測する部分についても、クラウドネイティブなシステムの代表的なプラットフォームとなったKubernetesやHashiCorp製のTerraformやNomadなどのツールがあり、監視・観測についてもGrafanaやDataDogといった商用ツールが揃っていると解説した。

問題はBuild→Deploy→Releaseの部分

しかしビルドから実装（デプロイ）そしてコードをリリースする部分についてはツールが多数存在し、それぞれがプラットフォームに依存した形になっており、分断化されていると語った。

この問題はコードを実装するプラットフォームが原因なのではなく、ビルド→デプロイ→リリースのワークフローに問題があるというのがHashiCorpの視点である。

問題はプラットフォームそのものではなくワークフロー

例として仮想マシンベースのワークロード、コンテナベースのワークロード、サーバーレスのワークロードを挙げて説明を行った。ここではAWSでビルドする場合はPackerを使い、コンテナベースであればDockerでコードをビルドしコンテナ化、そしてGCP上のサーバーレスであれば、CloudRunを使うというように、実装の形式とプラットフォームに依存して、それぞれ使うツールが異なるということを紹介した。

ビルドの場合はPacker、Docker、CloudRunが使われる

これはデプロイでも同様で、仮想マシンベースであればTerraform、コンテナベースであればHelmやKubernetesのコマンドラインツールであるkubectlを使うというのが現実の方法である。

デプロイの際もツールはバラバラ

つまりコードを書く部分や運用する部分はかなり洗練されてきたが、ビルド→デプロイ→リリースの部分については、デベロッパーが思うように洗練されていないと語った。

アプリケーションを本番環境に実装するのは相変わらず難しい

そして組織によってはmakefileを使って統一したり、CI/CDパイプラインを使ってビルドから実装までを自動化していると解説した。しかしこの方法ではスケーラビリティに限界があり、どうしても本番環境ではプラットフォームに特化したツールを使う必要があると解説した。またWaypointがよく比較されるPaaSに関しても「コードを書いてそれを実装するまでを簡単にするという部分では似ているが、PaaSの外側にあるシステムとの連携が非常に難しい」ことを解説した。

これはHerokuから始まったPaaSがプラットフォームの中で閉じた状況にいることを暗示しているのだろう。HerokuからCloudFoundryに至るPaaSの進化の中で、いち早くKubernetesに移行したOpenShiftを擁するRed Hatだけは、その閉塞感に早くから気付いていたのかもしれない。

make、CI/CD、そしてPaaSを使った場合の問題点を解説。

そしてデベロッパーが求める「ビルド→デプロイ→リリースのワークフローをどうやって実現するのか？」という問題については、HashiCorpが開発するVagrantを例に挙げて「vagrant up」というコマンドで開発環境を作成できる体験こそがあるべきワークフローであることを解説した。

Waypointが参考にしたのはVagrant

「vagrant up」だけで開発環境が作成できる

そしてここから、Waypointの公開前にアルファユーザーとしてツールを利用しているユーザーの声を紹介した。特に3人目のBrendan Burns氏は、Kubernetesの初期の開発に携わった7人のエンジニアの一人で、今はMicrosoftのAzureに関わっており、クラウドネイティブなシステムにおいては、大きな影響力を持つ人材として知られている。そのBurns氏からのエンドースメントをビデオでのコメントとは言え、紹介できたのは大きい。

MicrosoftのBrendan Burns氏もWaypointを使っている

ここからやっとWaypointの紹介というステージになったが、ポイントは「ビルド→デプロイ→リリースのワークフローをどのプラットフォームでも同様の操作で行えることを目指して作られた」であると紹介された。

目的は「ビルド→デプロイ→リリース」のワークフローをスムーズにすること

ここから詳細な解説が始まった。次に示したスライドで言いたいことはビルド、デプロイ、リリースの定義が分かれているという部分ではなく、それぞれが同じ構成ファイルにおいて記述できるという部分だろう。

一つの構成ファイルの中にビルド、デプロイ、リリースが定義できる

この次のスライドでそれははっきりと書かれているが、プラットフォームが変わっても同じ構成ファイルで定義しているというのが理解できる。

一つの構成ファイルでビルド、デプロイ、リリースまでが定義されている

次のスライドでは実際に「waypoint up」コマンドを実行した時のメッセージが確認できる。ここではReactのコードをローカルでビルドして、ローカル環境にデプロイ、リリースも同様にローカルのKubernetesに配置しているという内容だ。そして特徴的なのは、リリースされたコードへのURL、デプロイされたイメージへのURLが用意されているという部分だろう。

「waypoint up」を実行した際のログを紹介

そしてプログラミング言語＆フレームワークからプラットフォームまで、デベロッパーに選択の自由があることを強調した。

さまざまな言語で書かれたコードをどこへでもデプロイできる

またデベロッパーにフレンドリーなツールであることを紹介する中で、Webユーザーインターフェースにダークモードがあることを紹介。ここはリアルなイベントであれば会場が大いに沸く部分だろう。

ダークモードも用意された管理用のWebインターフェース

またコードをデプロイした後に開発現場で重宝される機能としてwaypoint execを紹介。これはそのコードが実行されているシェルへのアクセスを行うための入口とも呼べるもので、シェルコマンドを打つこともアプリケーションに対するコマンドを実行することも可能となる。

「waypoint exec」でアプリケーションのコードとのやり取りが可能に

同様にアプリケーションが正しく実行されているのかを簡易的に確認するためのlogsの機能も紹介された。ここではlogsがアプリケーションを検証するための機能であり、本格的なログ管理機能を置き換えるものではないということが強調された。

「waypoint logs」でアプリケーションのログを確認できる

またGitHubユーザーが多く使い始めているGitHub Actionsとの連携もすでに完成しており、GitHubのCI/CDをマルチプラットフォームに展開する際のきっかけを提供していることも紹介された。

GitHub ActionsからもWaypointを利用できる

次に拡張性についても解説を行った。これはビルド→デプロイ→リリースの各ステージにおいて、デベロッパーが利用するツールやプラットフォームに対応できるように、プラグインによる拡張を行えることを解説するものだ。実際、すでに利用可能となっているDockerビルドなどもプラグインとして実装されていることからもわかるが、プラグインが後付けでないことを見せた形になった。

ビルド→デプロイ→リリースのツールの組み込みはプラグインとして実装される

この後は、実際にターミナルを使ってローカルのアプリケーションからパブリッククラウドまで構成ファイルの一部を書き換えるだけで、ほぼ修正なしでコードがデプロイされるデモを見せた。

最後にWaypointの特徴をまとめたスライドを見せて、セッションを終えた。

Waypointの特徴を一枚のスライドで紹介

0.1のリリースですでにDocker、Kubernetes、AWS、Azure、GCP、Heroku、Netlifyなどの多数のプラットフォームに対応していることからも、多くのデベロッパーに向けてちゃんと準備をしてきたことがわかる内容だ。この記事ではビルド→デプロイ→リリースのワークフローをVagrantのようにしたいという思いを実現したWaypointの表層をなぞった内容となったが、Deep DiveではWaypointのアーキテクチャーやコンポーネント、そして重要なEntrypointの解説を行う予定だ。

詳細を知りたいエンジニアはぜひ、ドキュメントサイトで内容を確認して欲しい。

公式ドキュメントサイト：https://www.waypointproject.io/docs/intro

Waypoint 0.1のリリースを発表