komagataのブログ

bashの脆弱性、怖話でも気になったけどEngine Yard Cloudで簡単に対応できました。

CVE-2014-6271からの一連の脆弱性対策がボタン一個で勝手に対応できて楽ですね。

全部の詳細を抑えておくのは大変ですが、こうやって表記してくれると安心感がありました。

お客さんの案件だったらドヤ顔で「調査して対応しました。」とか言えますな。

いきなり更新は怖いので例によって一回cloneした環境で動くこと確認してからアップデートしました。

EngineYardCloudが価格改定したのでそれにともなって怖話ではちょっと古いc1.mediumというEC2のインスタンスを使ってたので@yandoさんおすすめのm3.mediumに変えてみました。

vCPUが減る代わりにメモリはほぼ倍増、起動ディスクはSSDになる上に価格がかなり抑えられるということでこれで賄えれば万々歳ですね。夏でアクセス増えてる怖話の経費削減に大きく影響しそうです。

そもそも新しい種類のインスタンスということで見えないところもだいぶ新しくなってそうですし、期待です。

EngineYardCloudのEnvironmentをのぞいてみたらruby2.1.2に対応してたので怖話をアップデートしました。

stackのversionが上がる時ほど警戒は必要無いとは思いますが、clone environmentしてそちらをアップデートしてみて動作確認してから本アップデートをかけるのが正義。

ruby2.0.0-p247からのアップデートだったんですが、何の問題も無く完了しました。最新は気持ちいい。

Early AccessにはWebサーバーのpumaも来てるのでrails4.1系にしてpumaが正式版になったらこっちも変えたらかなり速くなるんじゃないかなと期待しております！

Engine Yard Cloudを使っててrailsのproduction.logをちょっとしたフィルターかけてサッと見たい。（productionでのバグの原因究明などで）

production.logを探るのってEYCに限らず、機会が多いわりに面倒臭い。

$ scp deploy@app.kowabana.jp:/data/kowabana/shared/log/production* .
$ gzip -d production.log-*.gz
$ grep -r 'foo' .

とか。productionサーバーへのアクセス権がある人しか見れないのも手軽じゃない。

次からはこんなことしたくないのでEYCのlogentries addonを使ってみた。logentriesは無料でも使える範囲が大きいし、以前使ったことがあるので慣れているのでちょうどいい。

Getting started with Logentriesの通りに進めていき、下記のようにproduction.logを追加した。

diff --git a/cookbooks/le/recipes/configure.rb b/cookbooks/le/recipes/configure.rb
index 8a4432d..8225077 100644
--- a/cookbooks/le/recipes/configure.rb
+++ b/cookbooks/le/recipes/configure.rb
@@ -16,6 +16,7 @@ follow_paths = [
 ]
 (node[:applications] || []).each do |app_name, app_info|
   follow_paths << "/var/log/nginx/#{app_name}.access.log"
+  follow_paths << "/data/#{app_name}/shared/log/production.log"
 end

upload, applyしてからLogentriesのDashboardにアクセス。

自前でログサーバー作ってアレコレすると大変なので手軽で重宝しそうです。

第二世代？のエラートラッキングサービスrollbarを設定してて気付いたんですが、EngineYardCloudのAddonsのページが新しくなってて、新しい方にはrollbarが入ってる。

Instructionsのページの設定だけだとデプロイ通知はやってくれないっぽいのでdeploy hooksで送るように追記してみました。

# deploy/after_restart.rb:
require 'rubygems'
require 'bundler/setup'
require 'net/https'

on_app_master do
  rollbar_token = 'xxxxxxxxxxxxxxxxxxxxxxxxxx'
  uri           = URI('https://api.rollbar.com/api/1/deploy/')

  Net::HTTP.post_form(uri, 'access_token'   => rollbar_token,
                           'environment'    => config.framework_env,
                           'revision'       => config.revision,
                           'local_username' => 'deploy')
end

OK。

EngineYardCloudのdeploy hooksを使ってLingrに通知してますが、怖話っぽくしてみました。

Engine Yard Cloudでデプロイした時Lingrに通知する - komagata

サーバー台よりS3+CloudFront代の方が高いという自体になっているので、どーせAppサーバー１台だから怖話の画像ファイルをそのままストレージにおいてみた。

capistranoでおなじみの安心構成なのでS3のファイルをscpするだけで完了。

stop and bootするぐらいでは別のストレージになってるなどはなかったけど、柔軟に構成を変えられるのが売りだとおもうのでそういう場合に「あれ、あの画像どこいった？」とならないように注意が必要。

しかし、EYC外のアプリを1台インスタンスにポコっと持ってきてもとりあえず動くのでそこからS3化考えるってのも入り方としては良さそうに思いました。

cronでrails実行するのにstack v2ベースで下記みたいなエントリーが多いけど、

0 5 * * * cd /data/app_name/current/; BUNDLE_GEMFILE=/data/app_name/current/Gemfile bundle exec /data/app_name/current/script/rails runner 'App.run!' -e production

stack v4ではbundleコマンドがcronでpathの通ってるところにないから下記のようにフルパスにしないとそのまま移行しても動かない。注意。

0 5 * * * cd /data/app_name/current/; BUNDLE_GEMFILE=/data/app_name/current/Gemfile /usr/local/bin/bundle exec /data/app_name/current/script/rails runner 'App.run!' -e production

以前、Engine Yard Cloudでデプロイした時Lingrに通知するというのをやりましたが、デプロイフック内の変数の書き方がdeprecatedになってた。

WARNING: Use of `app` (via method_missing) is deprecated in favor of `config.app` for improved error messages and compatibility.
in /data/kowabana/releases/20130826040633/deploy/after_restart.rb
               
WARNING: Use of `environment_name` (via method_missing) is deprecated in favor of `config.environment_name` for improved error messages and compatibility.
in /data/kowabana/releases/20130826040633/deploy/after_restart.rb

configをつければ良いらしい。

require 'rubygems'
require 'bundler/setup'
require 'lingman'

Lingman::Updater.update(
  "fjord_assistant",
  "takoroom",
  "ASQYUefG1XLx3Mwut7wU44oJh2m",
  "#{config.app} を #{config.environment_name} にデプロイしました。"
)

@yandoさんから下記を教えてもらったのでやってみた。

@komagata timezoneクックブックでJapanに合わせると幸せになれますよ。UTCだと朝10時にバックアップが走ってマズーかも

— Yusuke Ando (@yando) August 2, 2013

Engine Yard Cloudでカスタムレシピを使う

本家に日本語の記事があります。

Chef レシピによる環境のカスタマイズ : Engine Yard Developer Center

最初全体像がつかめなかったんですが、要は環境毎にrecipeを保存してるサーバーがどこかにあって、アプリのコードとは別に、カスタマイズしたrecipesをey recipesコマンドでそこにアップできるそうです。

timezoneの変更

EYCのinstanceに入ってtimezoneを確認してみるとUTCになっています。

$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 25 May 17 19:13 /etc/localtime -> ../usr/share/zoneinfo/UTC
$ date
Sun Aug  4 02:54:45 UTC 2013

timezoneのrecipeはengineyardが用意してるrecipeに元々あるので、それを読み込んで変数を変更してやればいい。（recipeはforkして使う）

% git clone git@github.com:fjordllc/ey-cloud-recipes.git
% cd ey-cloud-recipes

% git diff -U0
diff --git a/cookbooks/main/recipes/default.rb b/cookbooks/main/recipes/default.rb
index 5bbd736..f9d39b0 100644
--- a/cookbooks/main/recipes/default.rb
+++ b/cookbooks/main/recipes/default.rb
@@ -148,0 +149,2 @@
+
+include_recipe "timezone"
diff --git a/cookbooks/timezone/recipes/default.rb b/cookbooks/timezone/recipes/default.rb
index e62ec33..b0de8de 100644
--- a/cookbooks/timezone/recipes/default.rb
+++ b/cookbooks/timezone/recipes/default.rb
@@ -4 +4 @@
-timezone = "UTC"
+timezone = "Asia/Tokyo"

僕はsunzi派ですがchefも触っておいて良かった。

ey recipesでupload, applyする。

% ey recipes upload -e jp_production    
Loading application data from Engine Yard Cloud...
Recipes in cookbooks/ uploaded successfully for jp_production
% ey recipes apply -e jp_production 
Loading application data from Engine Yard Cloud...
Uploaded recipes started for jp_production

ちゃんとtimezoneが変わってるかどうか確かめる。

$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 30 Aug  4 12:06 /etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo
$ date
Sun Aug  4 12:08:20 JST 2013

うん。変わってる。DBサーバーの方もちゃんと変わってました。appサーバーだけ変更する場合にはroleを指定するとか何かあるんでしょう。多分。

これってTokyoリージョン使う場合は必須の作業ですね。