Capistranoを試してみた

Capistrano

こんにちわ、でらぽんです。弊社プロダクトでデプロイツールの導入を検討しているネタが前回ありましたが、私はCapistranoを調べています。「かぴすとらーの」と読むそうでヨーロッパの方々が作っているそうです。

平尾さんのFablicを試している記事はこちらになります。 tech.sanwasystem.com

対象

デプロイツールを使用した事がなく、体験してみようという記事になっています。同じような境遇の方に読んでいただければと思います。

今回やること

Capistranoの環境構築とGitHubからソースコードを取得してデプロイするという内容をCapistranoの基本機能で行います。

環境

デプロイサーバ
Webサーバ
  • AmazonLinux

f:id:Derabon:20150625095454p:plain

Capistranoのインストール

まずは、適当な箇所にCapistrano用のディレクトリを用意し、以下の内容のGemfileを作成して、bundle install を実行します。

Gemfileの内容
gem 'capistrano', '~> 3.4.0'

# bundle install の実行
[vagrant@localhost myfirst-cap]$ ls .
Gemfile
[vagrant@localhost myfirst-cap]$ bundle install
Resolving dependencies...
Using rake 10.4.2
・
・省略
・
Using bundler 1.10.4
Bundle complete! 1 Gemfile dependency, 8 gems now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
[vagrant@localhost myfirst-cap]$ ls .
Gemfile  Gemfile.lock

テンプレートの出力

cap install というコマンドを実行するとテンプレートを出力します。構造は以下の通りです。config/deploy/ の下に production.rb と staging.rb という2つのファイルが作成されています。これはCapistrano3から、ProductionとStagingの複数環境へのデプロイ設定がデフォルトで作成されるようになったそうです。また、これはinstallコマンドの引数で設定できるそうです。また、capコマンドはCapfileがあるディレクトリで実行してください（重要）

# テンプレート出力
[vagrant@localhost myfirst-cap]$ bundle exec cap install
# 出力されたファイル
myfirst-cap
|-- Capfile                         #使用するライブラリなどを記述
|-- Gemfile
|-- Gemfile.lock
|-- config
|    |-- deploy.rb                  #デプロイ処理を記述
|    |-- deploy
|    |    |-- production.rb         #本番用サーバの設定やタスクを記述
|    |    |-- staging.rb            #ステージングサーバの設定やタスクを記述
|-- lib
|    |-- capistrano
|    |    |-- tasks

まず、deploy.rb を開きすべて以下の内容に書き換えます。

# deploy.rb

# Capistranoのバージョン
lock '3.4.0'
# アプリケーション名
set :application, 'cap_sample'
# Gitリポジトリ
set :repo_url, '[Gitのリポジトリを差すURL]'
# deployをするブランチ
set :branch, 'master'
# デプロイ先
set :deploy_to, '/var/www/html'
# ログレベル
set :log_level, :debug
# タスク内でsudoするにはこれが必要
set :pty, true
# 何世代残しておくか
set :keep_releases, 3

desc "デプロイの実行"
task :deploy do
    # ここにデプロイ時に行う処理を記述いくのですが
    # 今回は何も実行させません
end

次に、production.rbとstaging.rbをそれぞれの接続先に書き換えます。

# production.rb or staging.rb

# デプロイ先のサーバへのアクセス情報
server '[ホスト名]', user: '[ユーザ名]',  roles: %w{app}

# SSHログインキーの情報
# 事前にデプロイ先のサーバにアクセスできるキーを作成しておきそれを指定する
set :ssh_options, {
keys: %w(/home/vagrant/.ssh/deploy_key),
forward_agent: false,
}

desc "Production(Staging)タスクの実行"
task :deploy do
    #　ここにデプロイ時に行う処理を記述していきますが、
    # 今回は何も実行させません
end

bundle exec cap staging deploy を実行すると実行されているログが表示され処理が開始されます。

[vagrant@localhost capistrano]$ bundle exec cap staging deploy
INFO [e2ac0003] Running /usr/bin/env mkdir -p /tmp/capistrano_sample/ as ec2-user@52.69.13.213
・
・ 省略
・
DEBUG [b6e3a648] Command: echo "Branch master (at a7741ab) deployed as release 20150624093643 by vagrant" >> /var/www/html/revisions.log
INFO [b6e3a648] Finished in 0.069 seconds with exit status 0 (successful).

デプロイされた内容を見てみましょう。使うまで勘違いしていましたが、Capistranoは世代管理を基本機能で行ってくれて、デプロイ先が以下のような状態になります。currentをDocumentRootにするなどの方法もありますが、実際の運用では何かしらの工夫が必要かと思います。

# コマンドの実行
/var/www/html
   |-- current -> /var/www/html/releases/20150624093643   #releaseの最新版にシンボリックリンクされている
   |-- releases                     #リリース内容が世代管理され保存される
   |    |-- 20150624093523          #gitから取得したソースはここに世代管理されます
   |    |    |-- index.html
   |    |    |-- README.md
   |    |    |-- REVISION
   |-- repo
   |    |-- branches
   |    |-- config
   |    |-- description
   |    |-- FETCH_HEAD
   |    |-- HEAD
   |    |-- hooks
   |    |-- info
   |    |    |-- exclude
   |    |-- objects
   |    |-- packed-refs
   |    |-- refs
   |    |    |-- heads
   |    |    |    |-- master
   |    |    |-- tags
   |-- revisions.log
   |-- shared

まとめ

デプロイ先とデプロイするGitのリポジトリを指定するだけでここまでの事が実現できました。ここまで使っての感想ですが、複数サーバへのデプロイ(今回は触れていないがサーバごとのロール分けもできる)、世代管理、処理をタスクという単位に分けて実行できるなど、機能が充実していますね。ですが、実際の処理を行う部分が隠ぺいされ簡単に出来る事が多い反面、Fablicなどの小規模なツールに比べ学習コストも多くかかりそうだと思いました。

参考サイト

Capistranoの本家サイト：A remote server automation and deployment tool written in Ruby. CapistranoのGitHub：GitHub - capistrano/capistrano: Remote multi-server automation tool