Deploy to Heroku / Webアプリケーションのポータビリティ再び

Heroku の新機能で Heroku Button が出た。

見るよりも、触る方が早い。以下のボタンを押すと md2inao をあなたの Heroku アカウントにデプロイして、動かすことができる。

ボタンを押すと以下のような画面が出て、Deploy to Free を押すと直ちにデプロイが始まる。

GitHub からソースコードが Heroku にデプロイされて、Web アプリケーションが動く。

ご満悦。

このボタンを README.md に置いておけば、Webアプリケーションを自分で動かしたいなと思ったユーザーが、自分自身の環境で好きな時にそれをデプロイして使うことができる。

すなわち、Heroku Button で、URI を介した Web アプリケーションの交換が可能になった。

Heroku Button

Heroku Button を有効にするための前提は割とシンプルで

• GitHub にソースを置く
• Heroku にデプロイできる形式で構成しておく ( Ruby なら Gemfile とか Rack とか Procfile とかそういう話 )
• app.json を書く
• デプロイボタンを設置

というもの。app.json は

{
  "name": "md2inao",
  "env": {
    "BUILDPACK_URL": "https://github.com/naoya/heroku-buildpack-perl.git#cpanm-with-psgi"
  }
}

こういう JSON ファイル。app.json Schema を見るといろいろパラメータを指定できるけれども、シンプルなアプリならほとんど記述は要らない。md2inao は Perl 製で、buildpack が必要なのでそれだけ環境変数で指定した。

Deploy to Heroku ボタンのリンク先は https://heroku.com/deploy だが、このエンドポイントを叩くとリファラ (もしくはクエリパラメタの template に指定された URL) にある app.json を読み取り、ソースコードをデプロイする。

Pull Request と Heroku Button

Heroku Button が面白いのは、ソースコードのレポジトリを GitHub を前提にしている点。

app.json に明示的にレポジトリURL を書かない場合、app.json の URL はリファラから動的に決定される。GitHub の場合は Pull Request やコミットハッシュ毎に URL が付く。なので README.md にデプロイボタンを置いて app.json のレポジトリURLを空にしておけば、それだけで第三者が (master だけでなく) 任意のブランチの任意のコミットを選んで Heroku にデプロイできるようになる。

以下は、サンプルアプリケーションのあるコミットをデプロイした例。ハッシュ値が付いてるのがわかる。

よって Pull Request ベースで Web 開発をしてるときに、ちょっとこの Pull Request の動作確認をしたいなと思ったら、その Pull Request のブランチの Heroku Button をおしてデプロイして動作させるということが可能になっている。

app.json があったら、Pull Request のスレッドに自動的に Heroku Button が表示されるとかそういう改修を、GitHub (やどっかのサービス) がやってくれることを期待したい。

Immutable Infrastructure / Webアプリケーションのポータビリティ

半年ほど前に ポータブルなWebアプリケーション - naoyaのはてなダイアリー に、Immutable / Disposable Infrastructure の概念によって Web アプリケーションがポータブルになり、結果的に、Web アプリケーションが交換できるようになるのではないかという話を書いた。

Heroku Button を見て、そういえばそんなことを書いたな、ということを思い出した。

ご存知の通り、Heroku のバックエンドはコンテナベースの仮想化環境よって設計されていて、コードを push するたびに古いコンテナは廃棄されて新しいコンテナにアプリケーションがデプロイされる。Immutable Infrastructure そのものである。

常に廃棄されることを前提に Web アプリケーションを構成するには、Web アプリケーションに含まれる外部ライブラリなどの各種依存関係なが宣言的に明記されていなければならない。そのために Gemfile や Procfile などがある。この辺りのプラクティスは The Tweleve-Factor App などにまとまっている。

結果的に、Immutable であるという制約が Web アプリケーションの実行環境にポータビリティを与える･･･というのが先のエントリで書いたこと。この辺の話は Immutable Infrastructureが開発プロセスに与える影響 というカンファレンス発表でも話した。

Heroku Button は、その典型的なユースケースだと言える。

Docker や Docker Hub などの普及が進むと、次は Heroku という特定ベンダのインフラ環境に縛られない、同様のユースケースが実現されていくのは間違いない。

というわけで Heroku Button はとってもクール、である。