Contenu connexe
Similaire à 特盛!Heroku (20)
Plus de Shunji Konishi (20)
特盛!Heroku
- 3. 各種言語で構築したWebアプリケーションを実行するプラット
フォーム
標準サポート言語
◦ Ruby
◦ Node.js
◦ Clojure
◦ Python
◦ JVM(Java, Gradle, Grails, Scala, Play)
標準サポートではない言語もカスタムbuildpackを使用するこ
とで利用可能
◦ PHPは標準サポートではないがFacebook連携のデフォルトとなって
いるため山ほど使われている
プラットフォーム全体がEC2上にある
◦ 現在はUS-EASTとEUリージョンがある
◦ Tokyoにはいつ来るんだー
- 4. Git
◦ ソースコードのやり取りはすべてgit経由
Dyno
◦ Herokuがユーザーアプリケーションを実行する環境のこと
◦ 役割によってWebDyno, WorkerDynoのように呼ばれることもある
◦ 課金の単位でもある
Slug
◦ Dynoに転送されるアプリケーションの塊(最大300MB)
◦ これが大きければ大きいほどDynoの起動に時間がかかる
Stack
◦ DynoのベースとなるOS環境
◦ 過去にはStackの違いを意識する場面もあったが、Cedar(Ubuntu)
がデフォルトになって以降、それ以外を使用することはまずない
Buildpack
◦ RubyやJavaなどの各種言語毎の実行環境を構築するモジュール
実際のところHeroku固有の用語や独自の技術はほとんどない。
トリッキーなことはせずに標準技術のみで実装されている。
- 5. http://www.heroku.com/
◦ まずはアカウント作成
◦ 必要な情報はメールアドレスだけ
https://toolbelt.heroku.com/
◦ herokuクライアントのインストール
◦ 現行のインストーラではgitも一緒にインストールしてくれるらしい。
◦ Gettinng Started(https://devcenter.heroku.com/articles/quickstart)
を見るとSSHの鍵の生成とherokuへのアップロードまで半自動で
やってくれるっぽい
- 6. Playアプリケーションを新規作成してHeroku上で動
作確認するまでの全コマンド
$ play new test
$ cd test
$ git init
$ git add .
$ git commit -m "Initial put"
$ heroku create
$ git push heroku master
$ heroku open
たったこれだけでまたひとつインターネットにゴミが増える。。。(--
(実際のところHeroku上で動いているアプリの半分はこんなんだと思う)
あとはコードを書いてはgit pushの繰り返し
• Gitでソースコードを管理する上では「.gitignore」
は常に作成した方が良いがここでは省略
• PlayのbuildpackではProcfileが存在しない場合
は自動生成されるのでなくても良い
- 9. Dyno起動時に実行するコマンドが定義されたファイル
web: play run --%web --http.port=$PORT $PLAY_OPTS
hoge: play run --%hoge --http.port=$PORT $PLAY_OPTS
fuga: play run --%fuga --http.port=$PORT $PLAY_OPTS
[名前]: に続けて実行コマンドを記述
上の例では引数だけ変えてすべてPlayを起動している
$PORTはHttpRequestを受け付けるポートを定義した環境
変数(web以外ではここにリクエストが来ることはない)
名前が「web」の定義だけは特別扱いされており、これだけが
Routerからのhttpリクエスト転送を受ける(WebDyno)
それ以外の定義行はすべてWorkerDynoと呼ばれバックエンド
での処理を構築する際に使用する
メールやキューをポーリングして処理を実行する、など
- 12. Dynoが起動している時間をDyno時間と呼ぶ
◦ 1Dyno時間は1台のDynoが1時間起動していたことを表す
1Dyno時間の料金=0.05$
ただし750Dyno時間までは無料
◦ つまりWebDyno1台をまる一ヶ月動かしたとしても
1 × 24 × 31 = 744Dyno時間にしかならないため料金はかからな
い
WebDynoがアイドル状態であったとしてもDyno時間を消費す
る
スケジューラやheroku runコマンドの実行もDyno時間を消費
する
2XDynoは1時間の起動で2Dyno時間を消費すると考える
これ以外にアドオンの料金がかかる
- 14. SSLのアドオンを追加(20$/month)
heroku certsコマンドで証明書と秘密鍵を追加
◦ 中間証明書がある場合は証明書に追加しておく
証明書がインストールされると新しいホスト名
「xxx.herokussl.com」が生成されるのでDNSでそのホ
ストを設定
◦ ちなみにxxx.herokussl.comの実体はELB
◦ なのでSSLではhttpの転送が1段増えていると思う
herokuapp.comには「*.herokuapp.com」の証明書が
入っているのでSSLアドオンを使用しなくてもSSL通信自体
は可能
$ heroku addons:add ssl:endpoint
$ heroku certs:add <PEM> <KEY>
- 15. 例えば開発環境をコピーしてステージング環境を作成
したい場合は開発環境のディレクトリで。。。
heroku createで新しいアプリを作成
作成後にgitのURIが表示されるので適当な名前で
git remoteに登録
その名前でgit push
$ heroku create staging-xxxx
$ git remote add staging git@heroku.com:staging-xxxx.git
$ git push staging master
heroku createコマンドはそこにあるリポジトリに
「heroku」というremote名が登録されていない
場合は自動的に登録する。
そのため、最初にアプリを作成した直後はgit
remote addを実行する必要はない
heroku forkというアプリをコピーするコマンドもあるが
課金アドオンが元と同じプランで作成されるためあまり使わない
- 16. herokuコマンドはgit remoteに登録されたエイリア
スからアプリを判断する
◦ 「git@heroku.com」で始まるリモートリポジトリの「:」以降が
Herokuアプリケーション名
◦ Herokuのリモートリポジトリが一つだけの場合はherokuコ
マンド実行時にアプリケーション名を省略可
◦ 複数ある場合はコマンド実行時に「-a <アプリケーション名
>」を明示的に指定する必要がある
$ git remote –v
heroku git@heroku.com:prod-myapp.git (fetch)
heroku git@heroku.com:prod-myapp.git (push)
stg git@heroku.com:staging-myapp.git (fetch)
stg git@heroku.com:staging-myapp.git (push)
$ heroku logs –a staging-myapp
- 20. Dynoは以下のタイミングで再起動する
◦ Git push
◦ heroku configの変更
◦ おおむね1日1度の頻度で自動的に再起動
ここで再起動と言っているのは実際にはインスタンス
が切り替わる
◦ Herokuはマルチテナントなので一つのEC2インスタンス上に
複数のDynoが同居
◦ このためHerokuのIPはころころ変わる
WebDynoはともかくWorkerDynoが毎日再起動するのは
とても困る(--
- 21. 最初にルーティングを止めて、
全てのDynoをシャットダウン
◦ シャットダウンの前に実行中のリクエストのレスポンスを待っている?
その後再起動
◦ つまりコードや環境変数の異なるDynoが同時に起動しているという状態はない
その後ルーティングを再開
◦ その間のリクエストはRouterのキューに入ると思われる
再起動中にブラウザでF5を連打した場合レスポンスは遅いがエラーとはならない
もちろんリクエストが多くてキューがあふれた場合はエラーになると思われる
Preboot(現在ベータ
扱い)を使用すると
DownTimeも短くなるDown
Time
- 23. HerokuAPIとは
◦ herokuコマンド相当のことをプログラムから実行するための
WebAPI
24時間未満で自動再起動がかかることはない(多分)ので
その前でWorkerプロセスの中から自力で再起動してしまう
HerokuAPI api = new HerokuAPI(“xxxx”);//引数のAPIKeyはWebConsoleで取得
api.restartProcessByType(“yyyy”,”worker”);//heroku ps:restart worker
api.scaleProcess(“yyyy”, “worker”, 0);//heroku ps:scale worker=0
Workerが常時動いている必要がない場合は
scaleProcessメソッドでWorkerを停止するのもアリ
◦ この場合どうやってWorkerを起動するかは別途検討が必要
- 24. https://devcenter.heroku.com/articles/labs-
preboot
Heroku labsは正規リリース前の機能を実験的にユーザー
に使用できるようにしたもの
Prebootを使用すると再起動時の動作が
新Dyno起動 > ルーティングスイッチ > 旧Dyno停止
の順になり、ダウンタイムを短縮できる
◦ WebDynoにのみ適用
◦ WebDynoが2台以上起動している場合のみ適用
Prebootを使用するとSlugサイズやアプリの起動時の重たい
処理のダウンタイムへの影響もなくなる
Dynoの再起動問題/Prebootについて別スライドあり
http://www.slideshare.net/shunjikonishi/heroku-dyno
- 26. Dyno上で任意のコマンドを実行するHerokuコマンド
◦ viがないなどコマンドはかなり制限されている
◦ アプリのルートに「.profile」を作成しておくと起動時にそれが実
行される(WebDynoやWorkerDynoでも実行される)
heroku runコマンドでも新しいDynoが作成される
◦ 既存のWebDynoやWorkerDynoに接続できるわけではない
◦ もちろんDyno時間を消費する
「heroku run bash」とたたくと。。。
◦ telnet的な操作が可能
◦ スケジューラでどういうコマンドが実行できるかを確認するのに
便利
◦ つなぎっぱなしで放置してはいけない(Dyno時間を消費する)
- 27. Herokuはgit pushや環境変数の変更毎にそのリビ
ジョンを保存している
$ heroku releases
v35 Add hoge config k-shunji@flect.co.jp 2013/09/03 13:28:53
v34 Deploy 8740ef9 k-shunji@flect.co.jp 2013/08/29 12:27:29
v33 Deploy 2469798 k-shunji@flect.co.jp 2013/08/23 20:25:13
「heroku releases:rollback <リビジョン番号>」を叩くこ
とで、任意のバージョンにロールバックすることが可能
ロールバックはS3に保存されている各リビジョンのコン
パイル済みSlugと差し替えることで実現
ロールバック後に再度git pushするとpushされた再
度最新のソースからSlugが作成される。(git内で
revert等のロールバック操作は一切行われてない)
- 29. クラウド上にあるというだけでごく普通のPostgreSQL
制限事項
◦ パラメータを変更できない
◦ Userを作れない
◦ 接続を制限できない(URLを知っていればどこからでもアクセス可
能)
複数のHerokuアプリから同じDBを使用しても良い
◦ この場合heroku configのDATABSE_URLをコピーする
◦ Heroku以外からも使用できるがUS-EASTなので日本からの接続
は遅い
価格毎に土台となるEC2のインスタンスが異なる
◦ メモリ(キャッシュサイズ)の差異よりもCPUパワーの差が大きい
- 30. pgbackups
◦ アドオンの一つ
◦ 毎日自動でバックアップを取ってくれる
◦ 無料なので必ず使うべき
◦ ただしバックアップを取る時間帯は指定できない(アクセスの少
ない夜間に、という設定はできない)
◦ heroku pgbackupsコマンドで手動でのバックアップ/リスト
ア/ダウンロードが可能
Fork
◦ 既存のDBをコピーして新しいDBを作成
Follow
◦ 既存のDBのレプリケーションDBを作成
◦ 本番DBの障害時に切り替えて使用することが可能(手動)
- 31. https://dataclips.heroku.com/
SELECT文を登録しておいてその結果をいつでも参照でき
る
◦ ExcelやCSV形式でダウンロード
◦ GoogleDocsへのExport
GoogleSpreadsheetのURLが生成されてそこにアクセスするといつで
も最新のデータを参照できる
グラフもそこで作れたりする
色々と惜しい
◦ セキュリティのデフォルト設定が「URLを知っている人は誰でも使え
る」のは危険
◦ パラメータが使えない
◦ 登録したSELECT文を整理できない
不便なので代替ツールを自分で作ってみた
https://github.com/shunjikonishi/sqltool
http://www.slideshare.net/shunjikonishi/furoku-sqltool
- 32. Localeが「en_US.UTF-8」固定
◦ このためCREATE TABLE時に「COLLATE “C”」を設定しない
と日本語列のソートがおかしくなる
◦ 何故か日本語Localeは指定できない
実行に2秒以上かかる遅いSQLはデータ込みでログ
出力される
◦ データがログに残ることが一切NGな場合は注意が必要。
◦ 原則はそんな遅いSQLは実行しないこと(だがデータ量や負
荷によってはいかんともしがたい場合もあるので。。。(--)
◦ 別アプリでDBを作ってDATABASE_URLをコピーする運用に
したこともある。(Papertrailにログを流さないようにするため)
- 36. メール送信Addon
機能
◦ SMTP/WebAPIでのメール送信
◦ Webコンソールでの送信/不達メール確認
◦ メール中のURLのクリック数カウント
メール中のURLをSendGridが自動的にリダイレクトURLに書き換えて、
そのリクエスト数を数える
◦ メールの開封確認
HTMLメールのみ(メール中に非表示の画像URLを埋め込むことでその
画像URLのリクエスト数を数える)
価格体系
◦ 200通/日まで無料
◦ 有償版は40000通/月で9.95$から
- 39. HerokuAPI
◦ herokuコマンドが裏で実行しているREST API
◦ Heroku APIのJavaラッパー
https://github.com/heroku/heroku.jar
認証にはHEROKU_API_KEYを使用
PlatformAPI
◦ Oauth経由でHerokuを操作するREST API
◦ 現在ベータ版のため、APIの変更はあと数ヶ月はかなりある
見込み
◦ APIのJavaラッパーは今のところない
Heroku社内で優先して作っているのはRubyとNode.jsらしい