Application Deployment A set of slides about application deployment with Chef 

I'm sure most of those millions of pages are legitimate guides to app deployment.... 

Just push to Heroku. Not my problem now... 

To the cloud! 

Build your own • Let's be realistic. • You own your availability. There's a number of reasons why you might need to build your own. How many people were affected by the Amazon EC2 reboot crisis? 

Maybe you want to run your "own heroku" 

Just like you want to run your own EC2... 

Now that's settled! Application Deployment approaches 

how many people have done an application deploy with rsync? cgi-bin, whats up? 

No content

Package management • Rpm • Deb • Pkgsrc • Gems • Eggs • Not a solved problem. There's a million ways to build packages. It depends on your company's systems, of course, but what if that changes? Many times we just want to put the code on the boxes from the source repository. So why don't we just go directly from source control using a tag/branch? 

svn up, right? No one ever did this in production 

Capistrano 

Which is basically, git clone... I mean, there's more to it than that, but seriously. The problem is this doesn't handle any other configuration that needs to happen. Until you write some code to do that... It also isn't aware of anything else in the infrastructure. 

git "/srv/blog_app" do repository "git://github.com/me/blog_app.git" reference "master" action :sync end git "/srv/blog_app" do repository "git://github.com/me/blog_app.git" reference "v2.1.3" action :sync end This is a Chef resource for syncing a repository, on master or on a tag/branch reference 

git "/srv/blog_app" do repository "git://github.com/me/blog_app.git" reference case node.chef_environment when "production" "v2.1.3" else "master" end action :sync end It's an internal Ruby DSL, so we can just use a case statement, too 

chef-deploy Thanks, Ezra and Engine Yard! Ruby is handy, and makes it easy to extend Chef. Example, Chef deploy is a ruby gem that extended chef by adding a new resource 

deploy_revision[/srv/blog_app] Later, the chef-deploy gem was ported to the Chef core client library itself. This does capistrano style deployment of the specified revision. 

deploy_revision "/srv/blog_app" do revision "v2.1.3" repository "git://github.com/me/blog_app.git" user "blog_app" group "www-data" action :deploy end This is continuous deployment. Every time Chef runs, it will deploy the specified revision (say its a branch, or a tag). If the revision is already there, then it takes no further action, it is convergent. 

application_ruby From Opscode's "application" and "application_ruby" cookbooks 

application "blog_app" do path "/srv/blog_app" revision "v2.1.3" repository "git://github.com/me/blog_app.git" rails do database do database "blog_app" username "blog_app" password "awesome_password" end database_master_role "blog_app_database_master" end passenger_apache2 do end end Set up a rails app, complete with database.yml, and passenger config 

application "blog_app" do path "/srv/blog_app" memcached do role "memcached_master" options do ttl 1800 memory 256 end end end Maybe your app needs memcached too? 

Ad-Hoc Deployment • knife ssh • capistrano • fabric (with pychef) knife ssh "role:appserver" "sudo chef-client" 

% query="role:blog_app AND chef_environment:production" % knife ssh "${query}" "sudo chef-client" we want to leverage the power of the Chef Server's search feature. 

require 'chef/knife' require 'chef/search/query' Capistrano::Configuration.instance.load do Chef::Knife.new.configure_chef def chef_role(name, query = "*:*", options = {}) attr = options.delete(:attribute) || :ipaddress nodes = Chef::Search::Query.new.search(:node, query) [0].map {|n| n[attr] } role name, *nodes, options nodes end end https://github.com/cramerdev/capistrano-chef