heroku で Sinatra のアプリを動かす
heroku toolbelt をインストールする
インストール後 heroku コマンドが使えるようになる
$ heroku --version heroku-toolbelt/3.2.1 (x86_64-darwin10.8.0) ruby/1.9.3
sinatra のアプリを書く
Gemfile を準備する。モジュールをインストールする
$ cat Gemfile source 'https://rubygems.org' gem 'sinatra' $ bundle install --path vendor/bundle
vendor
、.bundle
は gitignore する。Gemfile.lock はバージョン管理する。プロジェクトのルートに app.rb などを作ってアプリを書く。テンプレートは views 以下におく。今回は erb を使う。
# app.rb require 'sinatra' get '/' do @text = 'hi' erb :index end
# views/index.erb <!DOCTYPE html> <html> <body> <%= @text %> </body> </html>
bundle exec ruby app.rb
で手元で動作確認できるconfig.ru ファイルを準備。よく理解していないけど、config.ru は rack アプリ起動時のエンドポイントみたいなものかな?
require 'bundler' Bundler.require require './app' run Sinatra::Application
heroku のアプリとして初期化する。プロジェクトのルートで以下を実行。初回は id/pass や公開鍵の設置などの入力をプロンプトで求められるはず
$ heroku create APP_NAME
- こうすると git remote heroku が追加されている
heroku にデプロイする。push するだけ。
$ git push heroku master
アプリを開く
$ heroku open
ログを見る
$ heroku logs
雑感
paas 全般に言えることなんだけど、そのサービス固有の知識が求められたり特有の制限にひっかかったりするとやる気が萎えてしまう。90 % の時間は快適に使わせてもらっていても、ちょっとそういうことがあると実際以上にマイナスイメージをいだいてしまうような気がする。(無料でつかわせてもらっているのにせこい話だけど…)。AWS なり VPS を契約しているのなら、はじめからそっちを使って自分でやったほうが最終的にはやかったりするということもあると再確認することになった。
今回はでかいクッキーを食わせた場合のブラウザの挙動をしらべていて、単に任意の Set-Cookie ヘッダを発行するだけのアプリをインターネットから見えるところにおいておきたいというだけの要件だった。多くの web サーバはヘッダサイズのリミットを持っているが、当然ながらそんな設定値を触らせてくれるわけがないので、そもそも最初から自分の選択がおかしいという話だった。
ちなみにリクエストヘッダのサイズは heroku の場合 8KB くらいが限界のようだ。