chef-deploy¶ ↑
A gem that provides resources and providers for deploying ruby web apps from chef recipes
Uses the same directory layout as capistrano and steals the git remote cached deploy strategy from cap and adapts it to work without cap and under chef. Not all options are required but they are all shown here as an example.
require 'chef-deploy' deploy "/data/myrackapp" do repo "git://github.com/engineyard/rack-app.git" branch "HEAD" user "ez" role "app_master" enable_submodules true migrate true migration_command "rake db:migrate" environment "production" shallow_clone true revision '0xbeadbeef' restart_command "touch tmp/restart.txt" # "monit restart all -g foo", etc. action :deploy # or :rollback end
Chef-deploy is backwards compatible with capistrano in the fact that it uses the same exact filesystem layout. You can deploy with cap on top of a chef-deploy system and vice versa.
Chef-deploy hooks:
If you create a APP_ROOT/deploy directory in your app you can place named hook files in there that will be triggered at the appropriate times during the deploy. the hooks are defined as follows:
APP_ROOT/
deploy/ before_migrate.rb before_symlink.rb before_restart.rb after_restart.rb
These scripts will be instance_eval’d in the context of the chef-deploy resource. This means that you will have certain commands and variables available to you in these hooks. For example:
run "echo 'release_path: #{release_path}' >> #{shared_path}/logs.log" run "echo 'current_path: #{current_path}' >> #{shared_path}/logs.log" run "echo 'shared_path: #{shared_path}' >> #{shared_path}/logs.log" sudo "echo 'sudo works' >> /root/sudo.log"
You have access to a run command and a sudo command. Both of these will run shell commands, run will run as your normal unix user that the app is deployed as and sudo will run as root for when you need more permissions.
You will have variables like in capistrano:
release_path: this is the full path to the current release: /data/appname/releases/12345678 shared_path: this is the path to the shared dir: /data/appname/shared current_path: this is the path to the currently symlinked release: /data/appname/current node: node is the full chef node object, this will have all of the JSON collected by ohai as well as any custom json you passed into your client run. THis way you can get at *any* data you have available to any of your chef recipes.
Using subversion:
In your deploy block, simply add: scm ‘subversion’ (as well as svn_username and svn_password, if needed). Obviously, git-specific options like enable_submodules can be removed as they’re not applicable.