デプロイフックの利用

このドキュメントは英語版のドキュメントを日本語に翻訳したものです。原文に修正があった場合は随時反映致しますが、翻訳作業が完了するまでは英語版が最新の可能性がございます。

更新日: 2013 年 9 月 26 日

デプロイフックとは、デプロイ プロセスの特定のポイントで何を実行するかを記述する Ruby スクリプトです。これによって、特定のニーズに合わせてアプリケーションのデプロイをカスタマイズできます。

たとえば、Resque をアプリケーションで使用している場合、新しいバージョンのアプリケーションをデプロイする際に、デプロイフックによって Resque ワーカーを再起動できます。Airbrake ユーザーは、デプロイ フックを使用して、Airbrake にデプロイを通知できます。

デプロイフックはアプリケーションの APP_ROOT/deploy ディレクトリに配置します。実行する順序は、ey deploy コマンドのドキュメントで指定します。

Capistrano との類似性

Engine Yard のデプロイ システムは、Capistrano のファイルシステム レイアウトを模倣して設計されているため、Capistrano の使用経験のあるユーザーにはなじみがあるはずです。実際に、Engine Yard のデプロイ システムでは Capistrano との下位互換性が依然として保持されているため、必要に応じて、両方のシステムを同時に使用することもできます。

構造とシーケンス

デプロイフックを使用するには、アプリケーションに APP_ROOT/deploy ディレクトリを作成して、指定したフック ファイルをこのディレクトリに保存します。これは、デプロイ プロセス中に適切なタイミングでトリガーされます。ファイルは以下のように定義し、リスト順に実行されます。

APP_ROOT/ 
   deploy/  
    before_bundle.rb  
    after_bundle.rb  
    before_compile_assets.rb  
    after_compile_assets.rb  
    before_migrate.rb  
    after_migrate.rb  
    before_symlink.rb  
    after_symlink.rb  
    before_restart.rb  
    after_restart.rb 

データベースマイグレーションを実行するには、環境全体を読み込む必要があることに注意してください。そのため、アプリケーションを正常に開始するために作成しなければならないシンボリック リンクがある場合は、before_symlink.rb ではなく before_migrate.rb 内に配置します。これは、before_symlink.rb がデータベースマイグレーションの後に実行されるためです。

定義したデプロイ フックは、デプロイには不要な手順にフックしていても呼び出されます。たとえば、after_migrate はデプロイに新しいデータベースマイグレーションがない場合でも呼び出されます。

シェル コマンド

shell commandを実行するruby syntaxがあります。run, run!, sudo, and sudo! . 

以下に例を示します。

run “echo ‘release_path: #{release_path}’ >> #{shared_path}/logs.log”  
run “ln -nfs #{shared_path}/config/foo.yml #{release_path}/config/foo.yml”  
sudo “echo ‘sudo works’ >> /root/sudo.log” 

git コマンドの呼び出し

以下に、デプロイ フックから git コマンドを呼び出す例を示します。

run "exec ssh-agent bash -c 'ssh-add /home/deploy/.ssh/<app>-deploy-key && git clone git@github.com:foo/bar.git #{current_path}/tmp/foo'"

<app> をアプリケーション名に置き換え、git リポジトリのパスを変更します。

デプロイ フックの変数

以下のスクリプトは、chef デプロイ リソースのコンテキストで instance_eval が実行されます。つまり、これらのフックでは特定のコマンドおよび変数が利用できることを意味します。以下に例を示します。

Deploy hooks API

デプロイフックはrubyで記述します。engineyard gemによってデプロイフックには以下のAPIが追加されています。

Note: @configurationはdeprecatedです。configをお使い下さい。

configオブジェクトから以下のAPIにアクセス可能です。

• config.account_name

  アプリケーションがひもづけられたAccount名を返します。

• config.all_releases

  古いものから順に並んだdeployされたreleasesをArrayで返します。

• config.app

  アプリケーションの名前を返します。

• config.current_name

  ユーティリティの場合そのinstanceにつけられた名前を返します。Utility Instance以外の場合はnilを返します。

• config.current_path

  現在のdeployのpathを返します。Deployのsymlinkを実行した後には値が変わります。

• config.current_role

  実行中のinstanceのroleを返します。

  • solo: 一台構成のとき
  • app_master: アプリケーションマスター
  • app: アプリケーションマスター以外のアプリケーション
  • util: ユーティリティ.  current_name によってさらに見分けることができる

• config.deployed_by

  デプロイを行なっているUserの名前を返します。

• config.framework_env

  RAILS_ENV, RACK_ENV, MERB_ENVと PHP_ENV を返します。

• config.environment_name

  Environmentの名前を返します。

• config.input_ref

  branchの名前を返します。: e.g. master か branch.  rollbackの際は使用出来ません。

  Note: Roll back はデータベースや複雑なデプロイフックを使わないことが理想です。データの変更が伴うデプロイでは、deployしrolling forwardsする方が最善である可能性が高いです。

• config.latest_release

  最新のdeployされたリリースディレクトリへのパスを返します。

• config.migrate?

  このdeployでmigrationが実行されるかをtrue / falseで返します。

• config.node

  現在対象としているEnvironmentの、実行中インスタンスとその他のインスタンスの情報を返します。 /etc/chef/dna.json を見ると返される情報を確認することができます。必要な値が他のメソッドで取得可能なら、そのメソッドを使用するほうがいいでしょう。 node では多すぎる情報を得ることになります。

• config.previous_release(current=latest_release)

  現在の一つ前にdeployされたディレクトリへのパスを返します。もしnilの場合は、現在のdeployが一番最初のdeployということになります。

• config.oldest_release

  最も古いdeployされたディレクトリへのパスを返します。

• config.release_dir

  deployされたディレクトリが入っているディレクトリ(release)へのパスを返します。

• config.release_path

  現在のdeployで作成しているreleaseディレクトリへのパスを返します。: e.g. /data/appname/releases/12345678

• config.repo

  アプリケーションのリポジトリURLを返します。

• config.repository_cache

  ローカルにcloneしたアプリケーションのリポジトリを返します。

• config.revision

  depoy対象のSHAを返します。

• config.shared_path

  shard_pathへのパスを返します。: e.g. /data/appname/shared

• config.stack

  webのstackを返します。

• nginx_mongrel: Nginx と Mongrel 
• nginx_passenger: Nginx と Passenger
• nginx_unicorn: Nginx と Unicorn

Helper Methods

以下のHelper Methodsが使用可能です:

• debug()

  STDOUTにログを出力します。verbose が trueの時のみ出力します。

• info()

  STOUTにログを出力します。

• on_app_master(&block)

   block をアプリケーションマスターの時のみ実行します。単一インスタンス構成（Solo）の時も実行されます。

• on_app_servers(&block)

  block をアプリケーションインスタンスのみで実行します。単一インスタンス構成（Solo）の時も実行されます。

• on_app_servers_and_utilities(&block)

  block をアプリケーションインスタンスとユーティリティインスタンスのみで実行します。

• on_utilities(*utility_names, &block)

  Executes block を utility_names に指定したユーティリティインスタンスでのみ実行します。 utility_namesは複数引数にとることができます。

  •  on_utilities() { ... }全てのユーティリティインスタンスで実行
  • on_utilities("alpha") { ... }  “alpha”と名前が付けられたユーティリティインスタンスのみで実行
  • on_utilities("a", "b") { ... } は次のようにもかけますon_utilities(%w[a b]) { ... }　"a", "b"と名前の付けられたユーティリティインスタンスで実行

• run(command)

  command を一般ユーザで実行します (deploy by default).

• run!(command)

  command を一般ユーザで実行します。 実行に失敗した場合deployを中止します。
  Note: このコマンドはengineyard gem2.0を使用してCLIかdashboardからdeployした時のみ実行されます。

• sudo(command)

  command をrootで実行します。

• sudo!(command)

  Executes command をrootで実行します。実行に失敗した場合deployを中止します。
  Note: このコマンドはengineyard gem2.0を使用してCLIかdashboardからdeployした時のみ実行されます。

• warning()

  STDERRにログを出力します。

よくあるご質問

Q1. Composer installの前に実行したい

PHPスタックの場合はbundleをcomposerに置き換えて考えてください。

deploy/before_bundler.rb がcomposer installの前に走ります。また、nodeの場合はそこでnpm installが走ります。

Q2. PHP/nodeの場合、before/after_migration.rb  before/after_compile_assets.rb はどうなるのでしょうか？

実行はされますが、railsのmigration, compile assetsに当たるアクションがありませんので、その前後でプラットフォーム側で何か実行されることはありません。

Q3. ey.yamlのオプションを詳しく知りたい

こちらにございます。　https://github.com/engineyard/engineyard-serverside

このページに関してフィードバックやご質問がございましたら、以下にコメントを入力してください。サポートが必要な場合は、Engine Yard サポートにチケットを送信してください。