capistrano-extとcapistrano-unicornを使ってRailsアプリをデプロイする
capistrano-extとcapistrano-unicornを使ってRailsアプリをデプロイした時にハマったので、メモがわりに。 参考にしたのは下記サイト
- dan.thoughts » Blog Archive » Using capistrano-unicorn with multistage environment
- Capistranoとcapistrano-ext - 祈れ、そして働け ~ Ora et labora
- github sosedoff/capistrano-unicorn
やりたかったこと
- Rails3.2xで開発しているアプリをnginx+unicornで動かす
- 本番環境としてデプロイされていたアプリをステージング環境としてデプロイし直す
前提条件
以下、作業内容と起きたこと
- capistrano-extとcapistrano-unicornをインストール
Gemfileに下記を追記して(developmentグループに入れておくと良い)bundle installコマンド実行
gem 'capistrano-ext' gem 'capistrano-unicorn'
- /conf/deploy.rbに本番環境とステージング環境の共通のデプロイ設定を記述
- /conf/deploy/staging.rbと/conf/deploy.production.rbにそれぞれ環境個別のデプロイ設定を記述
- /conf/unicorn/staging.rbと/conf/unicorn/production.rbに環境個別のunicornの設定を記述
- Capfileに下記を追加
load 'config/deploy'
- 下記コマンドを実行
bundle exec cap staging deploy
- capistrano-unicornをインストールしてるのでunicornの起動も自動的にコントロールされるのだが、unicorn:stop, unicorn:startタスクが実行されるのではなくunicorn:reloadタスクが実行されるので、psコマンドでunicornのプロセスを確認すると下記のようになっている。
unicorn master -c /path/to/current/config/unicorn/staging.rb -E production -D
- staging環境用の設定ファイル読んでるけどコマンドラインオプション-Eでproductionを指定しているのでRAILS_ENV=production でRailsアプリが動いていることに。。。ブラウザで動作確認したら本番環境のDB見に行ってるじゃないですかー!やだー!!
- /conf/deploy/staging.rbに下記を追加
set :deploy_env, 'staging' set :unicorn_env, 'staging' set :rails_env, 'staging' set :app_env, 'staging'
- bundle exec cap staging deploy 実行後、確実にunicornを再起動させるため、下記を実行。
bundle exec cap unicorn:stop bundle exec cap unicorn:start
- psコマンドでunicornのプロセスを確認すると
unicorn master -c /path/to/current/config/unicorn/staging.rb -E staging -D
- ブラウザで動作確認するとちゃんとステージング環境のDB見に行ってるね!メデタシメデタシ!!
デイリーポータルZの編集部に潜入!
デイリーポータルZさんが渋谷ヒカリエの8Fで公開編集部というのをやっておりまして、そこに見学というかちょっと立ち寄っただけなんですけどね。
ガラス張りのスペースで作業風景が覗けるだけでなくデイリーポータルZの更新作業に使っているPCのディスプレイ画面をプロジェクターに投影してたりと、ペアプロミング以外でコーディング中の画面を堂々と拝見できるという恐ろしいまでの情報公開っぷりです。 同業者の方がエディタ何使ってるかとか何故か気になる時があるんですよね。 ※ちなみに僕が拝見したときはDreamweaverを使ってました。
デイリーポータルZさん、単純に編集部を公開してるだけじゃありません。(それだけでも十分すごいですけどね。コーディング中の画面) いらないものを持って行くと、他の人が持ち寄ったいらないものが入っている「いらないものガチャガチャ」 とか缶バッジ作りとかができたり、デイリーポータルZオリジナルのステッカーなどをもらえたりするんです。 ちなみに僕はいらないものガチャガチャで、大戸屋の割引券を持って行ってミスドのポイントカードを当てました。 ミスドのポイントカードは有効期限が切れてるものと切れてないものの両方があるそうですが、運良く有効期限が切れてないものを当てました。190ポイントくらい貯まってたので何か景品と引換に行こうっと。
渋谷ヒカリエの8FのCreative Lounge Movの入口辺りでふらふらしてると編集部の皆様が気さくに声を掛けてもらえるので、渋谷にお立ち寄りの際はぜひ渋谷ヒカリエの8Fへ!!
平日の昼間にCreative Lounge Movの中で、デイリーポータルZのステッカーとマラドーナのステッカー貼ってるMac Book Airで何かやってるメガネかけた男性がいたら、多分それ僕です。適当に声かけるなり放置するなりしてください。
Coda2買っちゃった
ミサコタロウさんから勧められてCodaを使ってもう3年くらい。今回初めてメジャーバージョンアップし、「Coda2」として今日リリースされました。
僕はiCloudを利用していないのでApp Storeで購入しましたが、iCloudを利用したい場合はPanic社のサイトからダウンロードしてください。 で、早速使ってみた印象ですが、GUIが旧バージョンから結構変わっていますが、基本的な機能はあまり変わりません。 が、コードの折りたたみ機能が追加され、コードの階層がグラフィカルに分かるようになっており、Rspecでテストコードを書く場合などかなり便利です。
他にも追加・改良された機能としては
- gitに対応
- タブバーの改良
- MySQLクライアント機能の追加
- その他いろいろ
MySQLクライアント機能ですが、UIはSequel Proに似ています。
旧バージョンにあったGUIでCSSを編集できる機能ですが、どうも無くなったようです。利用してた方は残念ですね。 すみません、僕はテキストエディタで書いてる、というか基本的にデザイナさんからcssもらったものをPGに埋め込むだけなので。。。
今のところメニューなど全部英語ですがそのうち日本語化されるようです。
capybaraを使ってhelperメソッドのテストを行う
今回はRuby on Railsのhelperメソッドの単体テストをどうしましょうね、というお話です。 model, controller, viewのテストについてはWeb上に情報が色々と出ているのですが、helperについてはあまり情報が上がってないようなので(自分の検索の仕方が悪いだけかもしれませんが。。。)ここで簡単にまとめとこうと思います。
テスト環境は下記の通りです。
- Ruby 1.9.3
- Ruby on Rails 3.2.3
- RSpec 2.10
- capybara 1.1.2
テストする内容としては、helperメソッドを実行した時にちゃんと思った通りのタグや文字列が出力されてるかどうかという点になるかと思いますが、テストコードでhelperメソッドの返り値を正規表現でゴリゴリとチェックするのは大変面倒です。 helperメソッドの仕様が変わったらテストコードも修正する必要がありますが、正規表現でゴリゴリとチェックするようにしてたらメンテナンスも大変です。やってられません。
そこでcapybaraの出番です。 capybaraではhas_css?メソッドやfindメソッド等、cssセレクタを利用して文字列を解析できるメソッドが提供されています。
capybaraのインストールはGemfileに下記行を追加して、bundle updateコマンドでインストールできます。
gem 'capybara'
bundleコマンド実行後にspec/spec_helper.rbの上の方でrequireしてる部分に下記2行を追加してください。
require 'capybara/rails' require 'capybara/rspec'
ここまで出来たら、テストコードを実装して行きましょう。
RSpecのspecファイル内でhelperメソッド「hoge_tag」を実行するには下記のようにします。
result = helper.hoge_tag(fuga)
helper変数のインスタンスメソッドとしてhelperメソッド「hoge_tag」を実行します。 返り値は普通の文字列ですので、別の変数に代入することもできます。
このままではcapybaraの機能を利用してcssセレクタでhoge_tagの実行結果を検証できないので、
node = Capybara.string(helper.hoge_tag(fuga))
上記のようにしてCapybara::Node::Simpleクラスのインスタンスを生成します。 その後にCapybara::Node::Matchersモジュールで実装されているhas_css?メソッドやfindメソッド等を駆使してhelperメソッドの実行結果を検証していきます。 helperメソッド「hoge_tag」の実行結果がこんな感じだとします。
helper.hoge_tag(fuga)
<!-- hoge_tag(fuga)の実行結果 --> <input class="fuga" type="text" name="hoge">fuga</div>
テストコードはこんな感じになります。
node = Capybara.string(helper.hoge_tag(fuga)) node.tag_name.should == 'input' # inputタグが出力されてるかどうか node.has_css?('.fuga').should be_true # cssでfugaクラスが指定されているかどうか node[:type].should == 'text' # inputタグのtype属性がtextかどうか
詳細は公式ドキュメントをご覧ください。
ubuntu 12.04 LTSに今流行のmoshをいれてみた
最近話題のmoshをubuntu 12.04LTSに入れてみました。moshについては公式サイトやこちらのサイトを御覧ください。 で、インストール手順ですが、ubuntuの場合はインストールパッケージが用意されているので
sudo aptitude install mosh
でインストールできます。上記コマンドでサーバプログラムとクライアントプログラムの両方がインストールできます。
クライアントプログラムですが、Macの場合は公式サイトでパッケージをダウンロードしてインストールするか、MacPortsもしくはhomebrewでインストールできます。 私はhomebrewでインストールしました。ターミナルで下記コマンドを実行してインストールします。
sudo brew install mobile-shell
moshではUDP 60000〜61000番ポートを使用するので、iptables等のファイアウォールを使用している場合はポートを開放しておきましょう。 ubuntuでufwを利用している場合は下記コマンドで開放できます。
sudo ufw allow 60000:61000/udp
さくらのVPSでubuntu12.04にアップデートしたら、resolv.confの中身が空っぽになった件
Ubuntu12.04LTS がリリースされたのですが、さくらインターネットのVPSでインストールできるのは未だ(2012/5/1現在)10.04LTSなので、一旦Ubuntu 10.04をインストールしてUbuntu 12.04へアップグレードしました。
アップグレード自体は単純なもので、下記コマンドを実行して
$ sudo do-release-update
画面の指示に従えばアップグレードできます。
問題はその後。
- resolv.confの中身が空っぽになって名前解決ができない!
- resolv.conf書きなおす
- 名前解決できた
- サーバ再起動
- 1に戻る
色々と調べてみたところ、 どうもUbuntu 12.04って起動時にresolv.confを自動生成してるらしく、そのせいでこの現象が出るようです。詳細はマニュアル(http://manpages.ubuntu.com/manpages/precise/man8/resolvconf.8.html)に書かれているのですが、とりあえず要点だけ。
/etc/resolvconf/resolv.conf.d/base に下記行を追加して、
search sakura.ne.jp nameserver 210.188.224.10 nameserver 210.188.224.11
下記コマンドを実行
$ sudo resolvconf -u
これで、/etc/resolvconf/resolv.conf.d/base の内容がresolv.confに転記されます。サーバを再起動しても大丈夫です。