はじめに
Capistrano3を使ったデプロイ手順をまとめます。
このまとめは僕がCapistranoの詳細について知りたいと思ってまとめたものになります。
この文献を読めばCapistranoに対する理解は深まると思いますが、使用する際に知らなくても良い情報も多数記載されています。
(使い方だけを知りたい方は「デプロイレシピの書き方」から読んでください。)
はじめはRailsデプロイに特化した記事にしようと思ったのですが、Capistranoに関する仕様が多くこの記事だけでは収まらなかったため本記事はCapistrano全般に関する記事に変更しました。
なので、PHPやJavaなどのデプロイで使う場合にも参考になる記事になってます。
※僕が調べた限りの情報なので間違っている部分やあやふやな部分もありますので怪しいと思ったところに関してはご指摘いただければと思います。
インストール
インストールするディレクトリを適当に作成して以下のファイルを作成します。
(あらかじめRubyのインストールは済ませておいてください。またgem install bundle
の実施も事前に行っておいてください。)
source 'https://rubygems.org'
gem 'capistrano'
Gemfile
を作成したディレクトリで
$ bundle install
を行う。
その後
$ bundle exec cap install
と行う。
特に何も指定しない場合は「staging」と「production」用の設定ファイルが作成される。
あとで追加もできるが、初めに作って欲しい設定ファイルがある場合は以下の様に設定することも可能。
$ bundle exec cap install STAGES=development,staging,production
STAGESパラメータをつけることで初めのファイルを指定できます。
(といっても、ファイルを作成/削除すればいいだけの問題なので無理に覚えておく必要はありません。)
ディレクトリ構成
作成された後のディレクトリは以下の構成になってます。
パス | 説明 |
---|---|
Capfile | capistranoが実行される際に読み込むgemファイルやtaskを記載します。 |
config/deploy.rb | capistranoが実施するレシピを記載します。 |
config/deploy/**.rb | 各環境ごとの設定を記載します。※上記で指定したSTAGES のファイルが作成されます。 |
lib/capistrano/tasks/ | capistranoに実施させたいタスクを定義します。(本記事では扱いません。) |
Capistranoのおおまかな流れ
Capistranoは以下の流れでデプロイを行います。
基底ディレクトリの作成
Capistranoは以下のディレクトリ構成でデプロイを行います。
current・・・releasesに入っている最新のディレクトリに対するシンボリックリンク
releases
∟20151105121212・・・YYYYmmddHHMMSS形式でリリースプログラムが複数配置される。
∟YYYYmmddHHMMSS
shared・・・releasesに依存せず、共通となるファイルが配置される。
Capistranoはデプロイするたびにreleases
のディレクトリの中にデプロイした日時のディレクトリを作成して、その中にSCM(gitやsvn等)
で取得したファイルを配置している。(詳細は後述)
その配置したディレクトリの一番新しい日時のディレクトリに対してcurrent
からシンボリックリンクが張られる。
なのでPassenger
やunicorn
を使う場合はcurrent
に対してパスを通せば動く仕組みである。(unicornの場合はソケット)
なぜこんな構成になっているか?
rsync
などでデプロイをした方なら上記の構成に疑問を持つかもしれない。
rsync
などの手動デプロイをする場合はcurrent
だけ作成して中身のファイルを置き換えていく手順が多い。
その方法だと誤ったファイルをデプロイしてしまうと元に戻すのが大変だったり、場合によっては元に戻せないという悲劇が産まれるかもしれない。
releases
に毎回ディレクトリを切ることでこの状況をある程度回避できる。(DBの変更などがあると回避できない場合がある。)
すなわち、デプロイしたものにバグがあったりして前のバージョンに戻したい場合はcurrent
のシンボリックリンクを一つ前のreleases
に貼り直せば元に戻るという仕組みである。(Capistranoにはこれを行うためにrollback
と言うタスクが用意されている。)
ちなみにこの方法だとreleases
ディレクトリが肥大化するが、keep_releases
と言う設定(デフォルトは5)を記載しておけば指定の個数以上の日時ディレクトリができた場合は古いものから消していってくれる。
デプロイ方法
Capistranoは以下の手順でデプロイを行う。
- 各サーバーに上記の構成ファイルを作成する。
- 各サーバー上でSCMからデータを取得する。(
/tmp/APPLICATION_NAME/*
にgit clone --mirror
でデータを取得する。) - 取得したファイルを各サーバーの
releases
ディレクトリに展開する。 - 各サーバーで
current
のシンボリックリンクをreleases
の最新ディレクトリに張り替える。
おおまかにこの手順でデプロイを行う。
そのため、Railsに関わらずPHPなどの他のプロジェクトにも適用できる。
Railsをデプロイする場合はもう少し複雑な手順が必要。それらに関しては別途記事を書きます。
おまけ
Capistrano2の時代では作業PCにgit clone
してgzip
で固めて各サーバーに配置してた気がするけど、、、最近はそういう方法は使わないんですね。
Capfile(基底タスクの確認)
このままでも使用できますが、Capfileの中身を知らないで使用するのは怖いという方は以下を読んでください。
このファイルにrequire
していくと使えるタスクが増えて行く。
require
したいgemに関しては上記のGemfile
に記載してあらかじめbundle install
をしておく。
require 'capistrano/setup'
Capistranoの基底処理が記載されている。
デプロイするディレクトリなどの作成を行っている。
include Capistrano::DSL
namespace :load do
task :defaults do
load 'capistrano/defaults.rb'
end
end
stages.each do |stage|
Rake::Task.define_task(stage) do
set(:stage, stage.to_sym)
invoke 'load:defaults'
load deploy_config_path
load stage_config_path.join("#{stage}.rb")
load "capistrano/#{fetch(:scm)}.rb"
I18n.locale = fetch(:locale, :en)
configure_backend
end
end
require 'capistrano/dotfile'
この処理はこの後に必要となるRubyファイルを読み込んでいる。
Capistranoを使う上で重要なのはload 'capistrano/defaults.rb'
の部分になる。
set_if_empty :scm, :git
set_if_empty :branch, :master
set_if_empty :deploy_to, -> { "/var/www/#{fetch(:application)}" }
set_if_empty :tmp_dir, "/tmp"
set_if_empty :default_env, {}
set_if_empty :keep_releases, 5
set_if_empty :format, :pretty
set_if_empty :log_level, :debug
set_if_empty :pty, false
set_if_empty :local_user, -> { Etc.getlogin }
このように何も指定してない場合のデフォルトが定義されている。
この後に書かれているコードを見れると、上記のcapistrano/defaults.rb
を読み込んだ後にconfig/deploy.rb
を読み込みその後にconfig/deploy/**.rb
を読み込んでいる事がわかる。
invoke 'load:defaults'
load deploy_config_path
load stage_config_path.join("#{stage}.rb")
すなわちconfig/deploy.rb
とconfig/deploy/**.rb
に定義されていないパラメータは上記が使われるのだ。
また、config/deploy/**.rb
が最後に定義されているのでconfig/deploy/**.rb
に設定した内容が一番強い事がわかる。
これはdeploy.rb
に書いたレシピの設定を各環境(config/deploy/staging.rb
やconfig/deploy/production.rb
)で上書きできる事を指している。
stage
やdeploy_to
などのデフォルト設定をdeploy.rb
に書いておき、各環境ごとで変化する場合は変えれるという事だ。
おまけ
stages.each
はconfig/deploy/**.rb
のファイル全てが対象となる。
すなわちcapistranoはstaging
にデプロイするときにもproduction
のデータも読み込んでいるようだ。(他のstage
のファイルは使われないはずだが・・・)
require 'capistrano/deploy'
Capistranoをデプロイするためのタスクと順番が定義されている。
内部でrequireされている'capistrano/framework'
にタスクの順番が定義されいてる。
namespace :deploy do
task :starting
task :started
task :updating
task :updated
task :reverting
task :reverted
task :publishing
task :published
task :finishing
task :finishing_rollback
task :finished
task :rollback
end
中身のタスクだけ抜き出すとこんな感じだ。
そして肝心のdeploy
タスクは以下のように記載されている。
desc 'Deploy a new release.'
task :deploy do
set(:deploying, true)
%w{ starting started
updating updated
publishing published
finishing finished }.each do |task|
invoke "deploy:#{task}"
end
end
task default: :deploy
この設定で各タスクを順番通り呼び出している。
なお、rollback
には以下のように記載されている。
%w{ starting started
reverting reverted
publishing published
finishing_rollback finished }.each do |task|
invoke "deploy:#{task}"
end
微妙に中身が違う事がわかると思う。
各タスクの説明(../tasks/deploy.rake
)
Capistranoを使う上で重要となるタスクの中身がここに定義されている。
ただ、これらを細かく追うと長くなるので僕が読んで理解した範囲で記載する。
なお、Capistranoのdeploy.rake
は全てのサーバーに対して行われる。
starting(デプロイ、ロールバック共に呼び出される。)
Capistranoで一番初めに呼ばれるタスクだ。
中には以下のように記載されている。
invoke 'deploy:check'
invoke 'deploy:set_previous_revision'
簡単に流れを書くと以下のような感じになる。
-
git ls-remote --heads
で更新を確認. -
execute :mkdir, '-p', shared_path, releases_path
でCapistranoが使用するディレクトリを作成する。 -
execute :mkdir, '-p', linked_dirs(shared_path)
で指定されているディレクトリのリンボリックリンクを作成する。 -
execute :ln, '-s', source, target
で指定されているファイルのシンボリックリンクを作成する。 -
previous_revision
を作成する。(各タスク内でprevious_revision
が使用できるようになる。)
※ロールバックでもこのタスクが呼び出されるという事は、ロールバック時にcheck用としてgit
へのアクセスが発生しているという事である。
started(デプロイ、ロールバック共に呼び出される。)
deploy.rake内では特に処理をしていない。
各レシピ内で必要に応じて初期用のタスクを作成する。
updating(デプロイのみ)
アップデートタスクは以下のように記述されている。
これが実際にファイルを各サーバーに対してアップデートをかけている。
task :updating => :new_release_path do
invoke "#{scm}:create_release"
invoke "deploy:set_current_revision"
invoke 'deploy:symlink:shared'
end
:updating => :new_release_path
の部分はupdating
タスクを行う前にnew_release_path
が行われる事を示してます。
(後述しますがbefore : updating, :new_release_path
と同義です。)
new_release_path
では以下の処理が行われてます。
set(:release_timestamp, timestamp)
set(:release_path, releases_path.join(timestamp))
ここではまだリリースフォルダを作成せずに、リリースする情報を設定してます。
#{scm}:create_release
ここの部分は肝となるので詳細を追っていきます。
gitの場合は以下のようにタスクが定義されています。
namespace :git do
def strategy
@strategy ||= Capistrano::Git.new(self, fetch(:git_strategy, Capistrano::Git::DefaultStrategy))
end
set :git_environmental_variables, ->() {
{
git_askpass: "/bin/echo",
git_ssh: "#{fetch(:tmp_dir)}/#{fetch(:application)}/git-ssh.sh"
}
}
desc 'Upload the git wrapper script, this script guarantees that we can script git without getting an interactive prompt'
task :wrapper do
on release_roles :all do
execute :mkdir, "-p", "#{fetch(:tmp_dir)}/#{fetch(:application)}/"
upload! StringIO.new("#!/bin/sh -e\nexec /usr/bin/ssh -o PasswordAuthentication=no -o StrictHostKeyChecking=no \"$@\"\n"), "#{fetch(:tmp_dir)}/#{fetch(:application)}/git-ssh.sh"
execute :chmod, "+x", "#{fetch(:tmp_dir)}/#{fetch(:application)}/git-ssh.sh"
end
end
desc 'Check that the repository is reachable'
task check: :'git:wrapper' do
fetch(:branch)
on release_roles :all do
with fetch(:git_environmental_variables) do
strategy.check
end
end
end
desc 'Clone the repo to the cache'
task clone: :'git:wrapper' do
on release_roles :all do
if strategy.test
info t(:mirror_exists, at: repo_path)
else
within deploy_path do
with fetch(:git_environmental_variables) do
strategy.clone
end
end
end
end
end
desc 'Update the repo mirror to reflect the origin state'
task update: :'git:clone' do
on release_roles :all do
within repo_path do
with fetch(:git_environmental_variables) do
strategy.update
end
end
end
end
desc 'Copy repo to releases'
task create_release: :'git:update' do
on release_roles :all do
with fetch(:git_environmental_variables) do
within repo_path do
execute :mkdir, '-p', release_path
strategy.release
end
end
end
end
desc 'Determine the revision that will be deployed'
task :set_current_revision do
on release_roles :all do
within repo_path do
with fetch(:git_environmental_variables) do
set :current_revision, strategy.fetch_revision
end
end
end
end
end
release_roles :all
と定義されているので、他と同様で全てのサーバーが対象になります。
タスクの順番を整理すると以下の順番に実行されている事がわかります。
task :wrapper
task :clone
task :update
大まかですが、以下の処理をしている事がわかります。
- テンポラリー領域にGitを実施するためのディレクリや実行ファイルを作成します。
-
git :clone, '--mirror', repo_url, repo_path
を行ってgitからデータを取得します。 -
git :remote, :update
を行う。 -
execute :mkdir, '-p', release_path
でリリースディレクトリを作成します。 -
git :archive, fetch(:branch), '| tar -x -f - -C', release_path
でgitから取得したファイルをリリースディレクトリに展開する。
なお、1番で取得している実行ファイルは以下のようなファイルになります。
#!/bin/sh -e
exec /usr/bin/ssh -o PasswordAuthentication=no -o StrictHostKeyChecking=no "$@"
"#{scm}:set_current_revision"
SCMからデータを取得した後に最新のリビジョンを取得してコンソールに表示します。
context.capture(:git, "rev-list --max-count=1 --abbrev-commit #{fetch(:branch)}")
シンボリックリンク
最後にシンボリックリンクの指定があればshared
へシンボリックリンクを張ります。
updated(デプロイのみ)
deploy.rake内では特に処理をしていない。
各レシピ内で必要に応じて配置後用のタスクを作成する。
(この時点ではまだ本番適用はされていない。)
publishing(デプロイ、ロールバック共に呼び出される。)
current
からrelease
にシンボリックリンクを貼り直します。
実際には一時的にtmp_current_path
を作成して、そこからrelease
へシンボリックリンクを張ってからcurrent
へmv
します。
おまけ
Capistranoでデプロイ中にcurrent
ディレクトリに移動して、デプロイ後にls
などのコマンドを叩くと何もない状況に陥るのはこのためである。
published(デプロイ、ロールバック共に呼び出される。)
deploy.rake内では特に処理をしていない。
各レシピ内で必要に応じてデプロイ後用のタスクを作成する。
(この時点ではすでに本番適用されている。)
finishing(デプロイのみ)
リリースディレクトリの数を数えて指定の数より多い場合は、古いディレクトリを削除します。
finished(デプロイのみ、ロールバック共に呼び出される。)
revision_log_message
を出力して終わります。
以下はロールバック時に発生するタスクです。
reverting(ロールバックのみ)
updatingではreleases_path
に新しい日時のディレクトリ名を設定してましたが、ロールバック時は一つ古いリリースディレクトリ名を設定します。
これにより後続で走るpublishing
でcurrent
の付け替えが古いものになります。
revision_log_message
を設定します。(finishingで出力されます。)
reverted(ロールバックのみ)
deploy.rake内では特に処理をしていない。
各レシピ内で必要に応じてロールバック後用のタスクを作成する。
(この時点ではすでに本番適用されている。)
finishing_rollback(ロールバックのみ)
ロールバックしたため一番新しいリリースディレクトリを使用しなくなりました。
その不要ディレクトリを削除します。
Capistranoの実行手順まとめ
文字だけでは伝わりにくいと思うので、簡単に説明します。
デプロイ時
初めのデプロイで以下の状態が発生します。
current
releases
∟1・・・本来はYYYYmmddHHMMSS型で作成されるが、説明の便宜上1番目にできるディレクトリとする。
shared
シンボリックリンクは以下のようになっています。
(最近のRailsではdatabase.yml
にシンボリックリンクを張る必要はないが、説明上以下のようなシンボリックリンクが張られているとします。)
current -> releases/1
releases
∟1
∟database.yml -> shared/database.yml
shared
∟database.yml
こちらに対して再度デプロイを行うと以下のようになります。
current -> releases/2
releases
∟2
∟database.yml -> shared/database.yml
∟1
∟database.yml -> shared/database.yml
shared
∟database.yml
このようにreleases
配下にデプロイされたモジュールが出来てきます。
ロールバック時
上記の状態に対してロールバックを行うと以下のようになります。
current -> releases/1
releases
∟1
∟database.yml -> shared/database.yml
shared
∟database.yml
見てわかる通り、最後にリリースされたreleases/2
が消えて一回目のデプロイと同じ状況に戻ります。
(この状態でロールバックを行うと途中で処理が停止します。)
デプロイ時エラーの場合
上記の状態に対してデプロイをしている途中の状態は以下のようになります。
current -> releases/1
releases
∟2
∟database.yml -> shared/database.yml
∟1
∟database.yml -> shared/database.yml
shared
∟database.yml
この状態でエラーを感知するとCapistranoはロールバックを発生させます。
(どうやってロールバックを発生させているのかは、コード上からは追いきれなかった・・・。)
current -> releases/1
releases
∟1
∟database.yml -> shared/database.yml
shared
∟database.yml
そのため、デプロイ時に予定外の事が発生してもある程度はカバーされます。
データベースに変更を加えたりした場合はreverting
タスクの前後に対応コードを入れる必要がある。
デプロイレシピの書き方
とりあえず使いたいという方はここから読んでください。
長々書きましたが、使い方はある程度シンプルです。
(デプロイシェルを書くよりは遥かにシンプルになります。)
タスクの作成方法
namespace :test do
task :task1 do
p "call task1"
end
end
基本的な記述は上記のようになります。
上記のコードをconfig/deploy.rb
の最後に追加してください。
そして以下のコマンドを叩いてください。
$ bundle exec cap staging test:task1
これでタスクが実行されてcall task1
と表示されたと思います。
実際はこのような使い方はしませんが、実行されるルールの例として書いてます。
各サーバーで実行する方法
Capistranoはデプロイ対象のサーバー上でコマンドを打つ必要があります。
その対象のサーバーで実行するためには以下のように行います。
まずはサーバーの設定を行います。
(通常はconfig/deploy/**.rb
に記載します。)
例えば本番サーバーの設定を以下のようにしたとします。
server '172.1.1.1', user: 'user', roles: %w{web app batch}
server '172.1.1.2', user: 'user', roles: %w{web app}
ステージングサーバーが2台あったとします。
そのうち一台はバッチサーバーも兼用してたとします。
(本説明ではuser
は割愛しますが、上記で指定しているユーザーはssh
コマンドを実行するユーザーです。)
namespace :test do
task :task1 do
on roles(:app) do
execute 'echo "app server!"'
end
end
task :task2 do
on roles(:batch) do
execute 'echo "batch server!"'
end
end
end
このように記述して実行します。
(config/deploy/production.rb
の内容で実行する場合はcap production **
と記述します。)
$ bundle exec cap production test:task1
$ bundle exec cap production test:task2
test:task1
は両方サーバー上で'echo "app server!"'
のコマンドを実行します。
test:task2
は172.1.1.1
サーバー上で'echo "batch server!"'
のコマンドを実行します。
このようにon roles
という記述を使うと実施させるサーバーを指定させることができます。
絶対に一台のサーバーだけで実施したい場合
上記の設定ファイルが以下のようになっていたらどうなるでしょうか?
server '172.1.1.1', user: 'user', roles: %w{web app batch}
server '172.1.1.2', user: 'user', roles: %w{web app}
server '172.1.1.3', user: 'user', roles: %w{web app batch}
この状態で先ほどのタスクを実施するとroles
がbatch
のサーバーが二つ存在するため二つのサーバーで実施されてしまいます。
通常はこのような設定を行うときは意図的なので問題が出ることはありません。
しかし、念のため対応したいという場合は以下のような記述ができます。
namespace :test do
task :task3 do
on primary(:batch) do
execute 'echo "only one batch server!"'
end
end
end
このように記述した場合は先に見つかったbatch
ロールでのみ実施されます。
設定値を使いたい場合
レシピ内に設定値を記載すると後で変更するときに苦労します。
Capsitranoでは以下の方法で値を設定できます。
set :message, "hello world!"
namespace :test do
task :task1 do
on primary(:app) do
execute 'echo "#{fetch(:message)} batch server!"'
end
end
end
set :message, "hello world!"
でmessage
にhello world!
を設定します。
fetch(:message)
で実際の値を取得します。
他の文法に関してはRuby
の文献通りです。
なお、設定値がない場合にfetch
するとnil
が返却されます。
もし設定値がない場合にはデフォルト値を使いたい場合はfetch(:message, "ここに書く")
のように記述できます。
namespace :test do
task :task1 do
on primary(:app) do
execute 'echo "#{fetch(:message, "not message!!")} batch server!"'
end
end
end
設定値の上書きしたい場合
fetch(:message, "ここに書く")
を使うと分かりにくいので、config/deploy.rb
に規定の値を書いてconfig/deploy/**.rb
で上書きしたいと言うこともできます。
Capistranoではconfig/deploy.rb
→config/deploy/**.rb
の順番にファイルをロードするので同じ設定を書いた場合はconfig/deploy/**.rb
に記述した内容で上書きされます。
実行時に設定値を設定したい場合
実行するたびに設定値を変更したい場合は以下のように記述します。
set :message, ask("what message?", "hello world")
namespace :test do
task :task1 do
on primary(:app) do
execute 'echo "#{fetch(:message)} batch server!"'
end
end
end
これを実行すると以下のようになります。
$ bundle exec cap production test:task1
Please enter What message? (hello world):
入力した値が表示されることが確認できます。
実行するコマンドに引数を追加したい場合
例えばRails
のコマンドを実行する際に環境引数であるrails_env
を引き渡したい場合は以下のように行います。
set :rails_env, :staging
with rails_env: fetch(:rails_env) do
execute :rake, "db:create"
end
このように記述すると以下のコマンドが指定されたロールのサーバーで実行されます。
$ RAILS_ENV=staging bundle exec rake db:create
実行する前にフォルダ/ファイルの確認をしたい場合
フォルダが存在した場合のみ実行する場合は以下のように行います。
within current_path do
# カレントパスがある場合のみ実行される。
end
ファイルを確認する場合
if test "[ ! -e #{shared_path}/.env ]"
# shared/.envが存在しない場合に実施する。
end
こちらが参考になります。
【 test 】 条件式の真偽を判定する
サーバーへファイルをアップロードしたい。
デプロイで管理されているSCM
以外でファイルをアップロードしたい場合は以下のように行います。
(個別タスクとして切り出して、デプロイとは別のタイミングで行う場合が多いので以下のようなタスクになると思います。)
task :upload_file do
on roles(:app) do |host|
if test "[ ! -e #{shared_path}/.env ]"
upload!('../.env.example', "#{shared_path}/.env") # .env
execute 'echo ".env uploaded!"'
end
end
end
この例では、Railsの環境ファイルである.env
をapp
サーバーへアップしてます。
タスクの途中にタスクを追加したい
タスクの途中にタスクを追加するためにはbefore
やafter
コマンドを使用します。
task :task1 do
execute 'echo "execte task1!"'
end
task :task1_1 do
execute 'echo "execte task1_1!"'
end
というタスクがあるときに以下のように定義すると
before :task1, :task1_1
task1
を実行すると以下のように表示されます。
$ cap *** task1
execte task1_1!
execte task1!
また、上記のタスクに対してafterを使うと以下のようになります。
after :task1, :task1_1
$ cap *** task1
execte task1!
execte task1_1!
実際にデプロイに組み込みたい
実際にデプロイに組み込む場合は以下のようになると思います。
Railsを例に記載してますが、タスクの中身は各環境に合わせて変更してください。
namespace :deploy do
# 個別タスクを定義する場合。以下のコマンドで実行
# $ cap *** deploy:db_seed
# もちろん、毎回実行させても良い。
desc 'db_seed must be run only one time right after the first deploy'
task :db_seed do
on roles(:db) do |host|
within current_path do
with rails_env: fetch(:rails_env) do
execute :rake, 'db:seed'
end
end
end
end
# ファイルをアップロードされる前にタスクを挿入する場合。
# ※この例ではdatabseを作成している。
# on rolesよりon primaryの方が適切かもしれない。
before :updated, 'db_create'
task :db_create do
on roles(:db) do
within release_path do
with rails_env: fetch(:rails_env) do
execute :rake, "db:create"
end
end
end
end
# 実際にデプロイが完了した後に処理を行う場合。
after :publishing, :restart
desc 'Restart application'
task :restart do
on roles(:app) do
# 例えばUnicornを再起動させる。
invoke 'unicorn:restart'
end
end
end
このように定義して
$ cap *** deploy
と実行すると、デプロイ処理と上記に記載したタスクが実行されます。
設定する内容
なお、事前に設定する内容で必須なのは以下になります。
set :application, 'application_name' # application名はなんでも良い。
set :repo_url, 'git@gitpub.****.git' # デプロイ対象のリポジトリ
set :branch, 'master' # ブランチの指定をしたい場合はここに記載。
上記にも記載した通りでconfig/deploy/***.rb
に記載すれば上書きできます。
失敗した場合は?
デプロイ中にいずれかのサーバーの一つでも失敗が発生した場合は、すべてのサーバーに対してロールバックが発生します。
一つのサーバーだけ処理が成功するという事はありません。
Capistrano2との違い。
deploy:setupが無くなりました。
記述方法が変わったので、そのままでは使用できません。
Railsに特化してたCapistrano2とは違い、上記のようにCapistrano3では他の環境でも使えるように汎用的なものになってます。