chroju.dev/blog

the world as code

Rails環境構築（5）Capistranoによるデプロイ ※未完

だいぶ間が空いてしまった……。Rails環境構築シリーズ、あとサーバーにはDB（postgresql）、unicorn、Railsを入れれば終わりなのだが、いずれもアプリ側のGemfileを使ってローカルにインストールするつもりなので、まずはアプリのデプロイが必要となる。そしてRailsのデプロイといえばCapistranoだ！と、いきたいところだったのだが。

Capistrano 3.0を試しているのだが、どうにもハマっている。ハマっているというのはのめり込んで楽しくなっちゃった的な意味ではなく、上手くいかずにっちもさっちもいかない的な意味である。とりあえず頭からやり方おさらいしつつ、ハマった箇所をまとめてみたい。

3.0についてはまだ登場してから時間も経ってないためか、日本語で有益な記事は少ない。が、まずは本家をよく読むこと推奨。一応これに則れば出来るようになっているはずではある。他に個人の方がまとめたハウツーで参考になったのは以下の記事。すでに2.0を使っている人ならよりわかりやすいのだろうが、これがCapistrano初体験となる自分にはちょっとわかりにくかったりも、した。特に3番目の記事は完全に2.0からの移行組に向けて書かれた内容。

Capistranoとは？

そもそも論。開発完了したアプリをサーバーにデプロイするときの手順をRubyで書いて自動化しておくためのもの。デプロイ先はステージング環境とか本番環境とか何種類か存在する場合もあるが、環境ごとにデプロイ手順は別々に設定したりできる。なお、Rails用のツールだと思われがちだが、3.0からRails以外でも使える汎用的なツールになったらしい。自分の場合はRailsで使っているのであしからず。あと、SCMはGitを使っている必要がある。

インストール

インストールはGemで行う。デプロイ予定のRailsアプリで、Gemfileに以下追記してbundle install。

group :development do
  gem 'capistrano', '~> 3.1.0'
  gem 'capistrano-rails', '~> 1.0.0'
  gem 'capistrano-bundler', '~> 1.1.2'
end

capistranoが本体。先の本家によれば、Railsで使う場合はcapistrano-railsも必要になるとのこと。他にもいろいろ便利なプラギンがあったりするっぽいけど、わかんないので今はここまで。

初期作業

$ bundle exec cap install

初期ファイルの生成。手元の本にはcapify .コマンドだと載っていたのだが、capistrano 3.0から変わったらしい。ほあ。これによりCapfileと、config配下にdeploy.rb、さらにconfig/deploy配下にproduction.rbとstaging.rbが作成される。それぞれの役割は次の通り。

  • Capfile : 他のGem（capistrano-railsとか）の読み込みなどを記述
  • config/deploy.rb : デプロイタスクを記述
  • config/deploy/hoge.rb : 各サーバー情報を記述

Capfile編集

capistrano-railsと同bundlerを読み込むため、Capfileを開いて以下追記。

require 'capistrano/rails'
require 'capistrano/bundler'

config/deploy.rb編集

いろいろコメントアウトしてあってどれを使えばいいかよくわかんなかったりもするのだが、最低限以下は必要っぽい。

set <span class="synConstant">:application</span>, <span class="synSpecial">'</span><span class="synConstant">hoge</span><span class="synSpecial">'</span>
set <span class="synConstant">:repo_url</span>, <span class="synSpecial">'</span><span class="synConstant">git@github.com:chroju/hoge</span><span class="synSpecial">'</span>
set <span class="synConstant">:deploy_to</span>, <span class="synSpecial">'</span><span class="synConstant">/var/www/hoge</span><span class="synSpecial">'</span>
set <span class="synConstant">:scm</span>, <span class="synConstant">:git</span>

上から。1行目はアプリケーション名。これはどこかで使われる設定ではないようなので、適当に入れておけばよさそう。2行目はGithubのリポジトリURL。3行目はデプロイ先となるサーバー上のディレクトリパス指定。ここではApacheの設定にならってみた。4行目は使用しているSCMの指定。とはいえ、現状Gitしか対応していないのでこれ以外の書き方は不可。

ファイル後半にはデプロイタスクのデフォルト設定が書かれている。一応、ここはそのままでも動くみたい。自分で何か特別なことをやらせたい場合は当然ながら編集する必要があるが、まだその域に至ってないです。

config/deploy/hoge.rb編集

ここではステージング環境としてvagrantを使うものと仮定。WebサーバーやDBサーバーを分けたりはせず、1台のサーバーですべてをまかなうこととする。よってstaging.rbを編集する。このファイルもデフォルトでいろいろ書かれてはいるのだが、とりあえず次の4行があればOK。

server <span class="synSpecial">'</span><span class="synConstant">127.0.0.1</span><span class="synSpecial">'</span>, port: <span class="synConstant">2222</span>, user: <span class="synSpecial">'</span><span class="synConstant">vagrant</span><span class="synSpecial">'</span>, roles: <span class="synSpecial">%w{</span><span class="synConstant">web, app, db</span><span class="synSpecial">}</span>, ssh_options: {
  user: <span class="synSpecial">'</span><span class="synConstant">vagrant</span><span class="synSpecial">'</span>,
  keys: <span class="synSpecial">%w(</span><span class="synConstant">~/.vagrant.d/insecure_private_key</span><span class="synSpecial">)</span>,
  auth_methods: <span class="synSpecial">%w(</span><span class="synConstant">publickey</span><span class="synSpecial">)</span>
}

server〜で1台のサーバーの設定を一括で書ける。言わずもがな、まず対象IP。portがポート番号、userがSSHログインするユーザー名。roleはこのサーバーの役割を書く。web、app、dbの中から当てはまるものを書けばいいようだが、allという指定もできるとかできないとか。ssh_options:でさらに詳しい内容を記述。userはさっきのと被ってるので不要な気がするのだが、他のサイトを見てたら書いている設定があったので取りあえず入れてる。keysは認証に使うキーのパス。auth_methods:で認証方法を指定しているが、通例publickey認証とする。 ここに書いた設定の大半はvagrant ssh-configコマンドで拾えるので、自分の環境に合った設定に書き換えて下さい。

デプロイ実行

で、あとはデプロイでいけちゃうみたいです。

bundle exec staging deploy

stagingをproductionに換えればproduction.rbの設定に則ります。あと、末尾に:checkを付けるとコマンドが通るかコールドでチェックしてくれるので、まずは:checkをした方がいい。あと、cap -Tで実行可能なコマンドがずらずら出てくる。デプロイのロールバックしたり、rake db:migrateを走らせたり、結構いろんなことができるので一度見ておくと吉。

ハマった点

自分の場合は以上の手順で上手くいきませんでした。何点かハマったポイントをば。

デプロイ先ディレクトリのパーミッション

大変アホみたいな話だが最初これでmkdirが上手くいかなかった。公式ドキュメントのココに書いてあるけど、SSHユーザーはsudoなしでデプロイ先ディレクトリを操作できる権限がなきゃダメです。vagrantユーザーは~/var配下の操作権限なかったので弾かれた次第。。。

対応としてはさっきのリンク先に書いてある手順通りsgidの設定とかしてあげたらなんとかなりました。あるいはパスワードなしでsudo実行可能にしてやっても動くみたいだけど、当然ながらサーバーセキュリティ的にはNGなので。まぁvagrantであればどうでもいいかもしんないけど。

SQLiteのエラー

deploy中にsqlite3.hが存在しないよというエラーが発生。このページに書いてあるのとまったく同じ症例だったので、同様の対策をしてあげて解決。これは俺のvagrant環境の準備に不備があったってことでいいんだろうか。根本原因がイマイチ謎。

rake db:migrateのエラー

そして現在進行形で未解決なのがこのエラー。デフォルトのデプロイタスクでは途中でデプロイ先サーバー上でRAILS_ENV=staging bundle exec rake db:migrateを叩くんだけど、これが次のエラーで停まってしまう。

DEBUG [4be84d91]        rake aborted!
DEBUG [4be84d91]        database configuration does not specify adapter

いくつか思い当たった原因に取り組んではみたのだが、なおエラーが起きている。

  • RAILS_ENV=hogeを追加した場合、Gemfileのgroup :hogeを見に行くのだが、stagingグループを用意していなかった（参考）。
  • database.ymlにstagingの設定を用意していなかった。

たぶんRAILS_ENV周りの設定が何かおかしいと思うのだが、わからないので取りあえず保留にしている。というか、これに行き当たるまでRAILS_ENVのことを全然知らなかった自分にも問題大有りなので、一度Railsの勉強に立ち返ってみている次第。知識がないと、連鎖的に他のこともできなくなってくるなぁというのを痛感している。