werckerを使ってGAE/GOにデプロイしてFastlyでURLベースのルーティングをする
このブログは hugo
で静的htmlを生成して GAE/GO
にデプロイしています。(http://blog.youyo.info/)
旧ブログも Amazon S3
で同じドメインでホストしています。(http://blog.youyo.info/blog/archives/)
この2つを同じドメインで運用するにあたってURLベースでのルーティングを CloudFront
で実現していて、 Circle CI
を使って git push
をトリガーにしてデプロイ/キャッシュクリアして いました。
先週あたりまでこの構成だったのですが、今は CloudFront
=> Fastly
, CircleCI
=> Wercker
へと変更しました。
何故変更したか?
- CloudFrontのキャッシュクリアが遅い
- CircleCIでデプロイ実行時に都度環境作成するのが遅い
- Fastlyもwerckerもなんとなく興味あって使ってみたかった
3番目の理由が一番大きかったりします。やってみたかっただけ。
Fastly?
VarnishをベースとしたCDNサービスです。高速なキャッシュのクリアが特徴です。今回はここに惹かれたので使ってみることにしました。
詳しくはこちらをお読みください。
次世代CDNのFastlyで即時削除(Instant Purge)を体感した
URLベースのルーティング設定
fastlyのアカウント作成やDomain登録などは省略します。
- Domain登録後、ルーティング先(backend)の追加登録を行う
今回は /blog/
, /stylesheets/
, /javascripts/
の場合にS3に向けたかったので、同じHostですが3つ登録しました。メインはGAEです。
- Backendの
Conditions
を設定する
backendの右側の歯車をクリックすると Conditions
が選択できます。
Apply If...
のところに条件を記述できます。
req.url ~ "^/stylesheets/"
と書くことでURLが /stylesheets/
から始まる場合にルーティングされます。今回は残り2つも同じように設定します。
VCL
をクリックすることでCurrentVersionの設定(VCL)を確認できます。
# default conditions
set req.backend = GAE;
# end default conditions
# Request Condition: blog Prio: 10
if( req.url ~ "^/blog/" ) {
set req.backend = F_S3_blog;
}
#end condition
# Request Condition: stylesheets Prio: 10
if( req.url ~ "^/stylesheets/" ) {
set req.backend = F_S3_CSS;
}
#end condition
# Request Condition: javascripts Prio: 10
if( req.url ~ "^/javascripts/" ) {
set req.backend = F_S3_JS;
}
#end condition
設定を確認して問題なければ Activate
すればokです。
キャッシュPurge
ダッシュボードからもできますが、もちろんAPIでも操作できます。
account
からAPIキーを発行して、それを一緒にpostするよくあるシンプルな形です。
purgeにはいくつか種類がありますが、キャッシュ全体を削除する場合には下記コマンドで良さそうです。
詳細をドキュメントを。
https://docs.fastly.com/api/purge
$ curl -X POST -H "Fastly-Key: ${FASTLY_APIKEY}" https://api.fastly.com/service/${FASTLY_SERVICE_ID}/purge_all
FASTLY_SERVICE_ID
はDomain名の下に書かれているのでそれを。
実際やってみるとわかるのですが、本当にキャッシュのクリアが一瞬でびっくりします..!
Wercker?
werckerはCIにdockerコンテナを使用できます。なので自分に必要な環境の揃ったコンテナをあらかじめ用意しておくことでCIにかかる時間を短縮できるのではないかと思い試してみました。複数(または単一)のフェーズ/複数(または単一)のステップで構成されます。それぞれのフェーズで別のコンテナを使用できます。とりあえずwercker.ymlを見てもらうのが手っ取り早いと思うのでご覧ください。下記が今回作成したものになります。
- build/deploy/cacheの3つのフェーズで構成
- それぞれ専用のコンテナを作成して使用(
google/cloud-sdk:latest
はgoogle提供のを使用) - なんとなくぱっと見でわかると思う
小技
- gcloudコマンドでGAE/GOにデプロイするにあたって、なんらかの形で認証しておく必要があります。今回は認証に使用するサービスアカウントのjsonファイルを、
openssl
コマンドで暗号化して一緒にデプロイします。デプロイの過程で復号化を行い、gcloud auth activate-service-account
コマンドで認証するようにしました - 復号化に使用するパスフレーズはwerckerのProtectedな環境変数で渡すので問題なし。
- 詳細はこちら http://qiita.com/ikuwow/items/1cdb057352c06fd3d727
実際やってみてわかったこと
- CI開始後に環境構築が入らないので早くなるかと思っていたが、毎回コンテナイメージのダウンロードが入るので重いイメージを使用しているとそんなに早くならない
context canceled
というエラーを吐いて失敗する
2番目の理由がわからず悪戦苦闘… いまだ解決せずなので原因をご存知の方がいればご一報ください。。
まとめ
- キャッシュクリア早くなったし満足!
- CIもちょっとだけ早くなったし満足!