capistranoは便利ですね。
ただ、巷の情報はrailsが前提となっているケースが殆どですので、 そうでないものでも使ってみよう、というものです。
実は、version2.xの頃にそれなりに使用していましたが、昨今は3.x系になっており、 かなり勝手が違っています(こういうのなんとかならないんでしょうかね…)。
従いまして、今回は3.4.0となります。
$ cd project_dir $ bundle init $ echo "gem 'capistrano'" >> Gemfile $ echo "gem 'capistrano-rbenv'" >> Gemfile $ echo "gem 'capistrano-bundler'" >> Gemfile $ bundle install --path=vendor/bundle $ bundle exec cap install
このような感じで、一気にインストール出来ました。
インストール後は、以下のようなファイル・ディレクトリができています。
Capfile
config/deploy.rb
config/deploy/production.rb
config/deploy/staging.rb
Capfileの設定
最初はCapfileを編集します。 この目的は、rbenvをデプロイ対象で使用できるようにするためです。
capistrano/rbenv と capistrano/bundler のコメントを除去します。
Capfile
# require 'capistrano/rvm' require 'capistrano/rbenv' # require 'capistrano/chruby' require 'capistrano/bundler' # require 'capistrano/rails/assets' # require 'capistrano/rails/migrations' # require 'capistrano/passenger'
staging.rbの設定
staging.rb / production.rb は、それぞれ環境用の設定になっています。 今回はstaging.rbを使用します。
config/deploy/staging.rb
server 'target-server', user: 'username', roles: %w{app} role :app, %w{username@target-server}
コメントをすべて除去しました。 実際は参考になる記述なので、残しておいたほうがよいでしょう。
deploy.rbの設定
最後にdeploy.rbですが、これは実際のデプロイ詳細を記述しています。
config/deploy.rb
# config valid only for current version of Capistrano lock '3.4.0' set :application, 'my-app-name' set :repo_url, 'git@github.org:[github username]/[github repo].git' set :deploy_to, '/path/to/target_dir' set :scm, :git set :log_level, :debug set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp/pids', 'vendor/bundle') set :keep_releases, 5 set :rbenv_path, "/usr/local/rbenv" set :rbenv_ruby, '2.2.3' set :bundle_path, "vendor/bundle" namespace :deploy do task :restart do on roles(:app) do execute "touch #{fetch(:deploy_to)}/current/abc" end end after :published, :restart end
ここでもコメントは除去しています。 一応わかりやすいように、デフォルトで有効になる設定もあえて書いているところがあります(git等)。
以下のコマンドでこの設定でのデプロイを実行します。
$ bundle exec cap staging deploy
基本的には、gitリポジトリにmasterブランチを対象サーバの対象ディレクトリに展開します。
今回はrubyでbundlerを使用したプログラムを想定しており、rbenvの設定やbundleディレクトリの設定も記述しています。
他の言語のプログラムをデプロイする場合は、これらは不要です。
本来ならば、最後の’namespace’の部分で、配置後の作業を記述しますが、今回はabcというファイルをtouchしているだけです。
通常はデーモンプログラムを再起動したり、リリースバージョンを書き換えたりと、自由に設定可能です。
上記設定では、対象ディレクトリは /path/to/target_dir ですが、実行後にこの中を覗くと、以下のような構成になっています。
├── current -> /path/to/target_dir/releases/20151207163431
├── releases
│ └── 20151207163431
│ ├── abc
│ ├── Gemfile
│ ├── Gemfile.lock
│ ├── log -> /path/to/target_dir/shared/log
│ ├── REVISION
│ ├── tmp
│ └── vendor
├── repo
│ ├── branches
│ ├── config
│ ├── description
│ ├── FETCH_HEAD
│ ├── HEAD
│ ├── hooks
│ ├── info
│ ├── objects
│ ├── packed-refs
│ └── refs
├── revisions.log
└── shared
├── bundle
│ └── ruby
├── log
├── tmp
│ └── pids
└── vendor
└── bundle
配置したプログラムファイルはreleasesディレクトリ下に置かれますが、
デプロイを実行するたびにサブディレクトリを作成します。
実体はこちらで、current シンボリックリンクによってパスが変わらないようにしているわけですね。
sharedディレクトリには、デプロイしても固定にしたいファイル・ディレクトリを設置します。
データベースの接続情報やリポジトリに含まない設定ファイル等はここに設置すればよいでしょう。