Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (8)
Similaire à Automated Server Configuration and Web Site Deployments with Chef and Capistrano
Similaire à Automated Server Configuration and Web Site Deployments with Chef and Capistrano (20)
Dernier
Dernier (20)
Automated Server Configuration and Web Site Deployments with Chef and Capistrano
- 1. Automated Server Configuration and Web Site Deployments with Chef and Capistrano NLIT Summit 2011 Nick Muerdter 06/15/2011
- 2. 2 Photo from National Library NZ http://www.flickr.com/photos/nationallibrarynz_commons/5015573731
- 3. 3 Bringing Order Photo from U.S. National Archives http://www.flickr.com/photos/usnationalarchives/4011449131
- 4. 4 Party like it’s 2011! Image © Hanna-Barbera and Warner Bros. Entertainment Inc.
- 5. 5 Photo by hey skinny http://www.flickr.com/photos/heyskinny/1464641723
- 7. Automates commands over SSH to multiple servers
- 8. Encapsulates deployment best practices
- 9. Ruby on Rails based, but easily does moreWhat Is Capistrano?
- 10. Getting Started With Capistrano 7 $sudo gem install capistranocapistrano-ext $cd my_project $capify . [add] writing './Capfile' [add] making directory './config' [add] writing './config/deploy.rb' [done] capified!
- 11. Sample config/deploy.rb 8 require"capistrano/ext/multistage" set :application, "my_project" # Supported: `accurev`, `bzr`, `cvs`, `darcs`, `git`, # `mercurial`, `perforce`, `subversion` or `none` set :scm, :subversion set :repository, "https://svn.nrel.gov/my_project/trunk" set :deploy_to, "/var/www/my_project"
- 12. Sample config/deploy/development.rb 9 # Set the servers for this stage. role :app, "dev.nrel.gov" role :web, "dev.nrel.gov" role :db, "dev-db.nrel.gov" # Reduce the number of copies kept for the # development environment. set :keep_releases, 2
- 13. Sample config/deploy/staging.rb 10 # Set the servers for this stage. role :app, "staging.nrel.gov" role :web, "staging.nrel.gov" role :db, "staging-db.nrel.gov"
- 14. Sample config/deploy/production.rb 11 # Set the servers for this stage. role :app, "nrel.gov" role :web, "nrel.gov" role :db, "db.nrel.gov"
- 15. Running Capistrano 12 $ cap staging deploy * executing `development' triggering start callbacks for `deploy' * executing `multistage:ensure' * executing `deploy' triggering before callbacks for `deploy' * executing `deploy:try_setup' * executing `deploy:setup' triggering before callbacks for `deploy:setup' * executing `deploy:gem_bundler:setup' * executing "mkdir -p /srv/afdc/staging/common/my_project /srv/afdc/staging/common/my_project/releases /srv/afdc/staging/common/my_project/shared /srv/afdc/staging/common/my_project/shared/log" servers: ["staging.nrel.gov"] Password: [staging.nrel.gov] executing command command finished in 795ms triggering after callbacks for `deploy:setup' * executing `deploy:shared_children_file_tasks:setup' * executing "mkdir -p /srv/afdc/staging/common/my_project/shared/public/linkcheck && chmodg+w /srv/afdc/staging/common/my_project/shared/public/linkcheck" servers: ["staging.nrel.gov"] [staging.nrel.gov] executing command command finished in 62ms ...
- 17. What we’ve done:
- 18. Per-developer sandbox creation on development
- 19. Per-branch deployment on staging13 Where To Next? Photo from NationaalArchief http://www.flickr.com/photos/nationaalarchief/402623048
- 24. Replicate changes between environments.
- 25. Easily setup similar servers.Image © Comedy Central
- 27. Recipes
- 28. Attributes
- 29. Files
- 30. Templates
- 31. Roles
- 32. Nodes
- 33. Chef Server
- 34. Chef Clients15 Chef Terminology Image © Iannucci'sPizzeria & Italian Restaurant
- 35. package "apache2"do case node[:platform] when"centos", "redhat", "fedora", "suse" package_name"httpd" when"debian", "ubuntu" package_name"apache2" when"arch" package_name"apache" end action :install end service "apache2" template "#{node[:apache][:dir]}/envvars"do source "envvars.erb" group "root" owner "root" mode 0644 notifies :reload, "service[apache2]" end # ... 16 Sample Recipe
- 36. name"ctts_base" description "A base role for ctts.nrel.gov servers." run_list([ "role[base]”, "role[apache]", "role[capistrano]", "role[passenger_apache]", "role[ruby]", "role[tomcat]", "recipe[apache2::mod_cgi]", "recipe[apache2::mod_include]", "recipe[apache2::mod_php5]", "recipe[apache2::mod_ssl]", "recipe[awstats]", ]) default_attributes({ :awstats=> { :log_file=>"/srv/afdc/ctts/eere/current/log/access.log-%YYYY-0%MM-0%DD-0", :domain=>"www.afdc.energy.gov", }, :php=> { :module_oci8=> { :version=>"1.4.4" }, }, }) 17 Sample Role
- 37. 18
- 38. $sudo chef-client Run List is [role[developer_development]] Run List expands to [sudo, chef-client::config, etc::environment, opsview::client, iptables, logrotate, screen, ack, vim, nano, zsh, capistrano, subversion, nginx::source, passenger::nginx, rvm::install, rubygems::client, bundler, java, tomcat, db_config, haproxy, jammit, postgresql::client, supervisor, opsview::check_haproxy, opsview::check_nginx, opsview::check_supervisorctl, opsview::server, opsview::apache, chef-server, docs_site::nginx] Starting Chef Run for devdev.nrel.gov Loading cookbooks [ack, apache2, apt, bluepill, build-essential, bundler, capistrano, chef-client, chef-server, couchdb, daemontools, db_config, docs_site, erlang, etc, gecode, git, haproxy, iptables, jammit, java, logrotate, mysql, nano, nginx, openssl, opsview, passenger, perl, php, postgresql, python, rsync, rsyslog, rubygems, runit, rvm, screen, subversion, sudo, supervisor, tomcat, ucspi-tcp, vim, xml, yum, zlib, zsh] Skipping opsview::client recipe because conflicting opsview::server recipe is enabled Could not find previously defined grants.sql resource Processing package[sudo] action upgrade (sudo::default line 20) Processing template[/var/cache/chef/sudoers] action create (sudo::default line 40) Processing template[/etc/sudoers] action create (sudo::default line 48) Processing directory[/var/run/chef] action create (chef-client::config line 30) Processing directory[/var/cache/chef] action create (chef-client::config line 30) Processing directory[/var/lib/chef] action create (chef-client::config line 30) Processing directory[/var/log/chef] action create (chef-client::config line 30) Processing template[/etc/chef/client.rb] action create (chef-client::config line 38) Processing ruby_block[reload_client_config] action nothing (chef-client::config line 47) Processing template[/etc/environment] action create (etc::environment line 10) Processing package[iptables] action install (iptables::default line 20) Processing execute[rebuild-iptables] action nothing (iptables::default line 22) Processing directory[/etc/iptables.d] action create (iptables::default line 27) Processing cookbook_file[/usr/sbin/rebuild-iptables] action create (iptables::default line 31) ... 19 Running Chef
- 39. 20 Slow Going? Photo from State Library and Archives of Florida http://www.flickr.com/photos/floridamemory/3266993225
- 40. 21 Payoff?Totally, dude. Photo by Calsidyrose http://www.flickr.com/photos/calsidyrose/3198309214
- 41. Capistrano: https://github.com/capistrano/capistrano/wiki Chef: http://www.opscode.com/chef/ http://wiki.opscode.com/display/chef/Home Chef Cookbooks: http://community.opscode.com/cookbooks https://github.com/opscode/cookbooks 22 Resources & Support Photo from Musée McCord Museum http://www.flickr.com/photos/museemccordmuseum/5348751435
- 42. 23 http://slideshare.net/NickBlah nick.muerdter@nrel.gov Photo by Eleaf http://www.flickr.com/photos/eleaf/2536358399
Notes de l'éditeur
- Single production serverDevelop on your live server.Cross fingers and hope you’re perfect.
- Separate servers and environments for development, staging, and production.Manually move things from one stage to the next.
- Maintaining separate servers can be burdensome.Script it! Things are then easily repeatable.Lots of tools and solutions out there. We’ve used Capistrano and Chef.
- Best practices:Deployments are (mostly) atomic: Deployment happens inside separate directory. Only made live at the last minute if all other deployment tasks have succeeded.Previous versions kept around, so rollbacks are quick.Deploy to multiple servers at the same timeLoad balanced application serversPerform tasks on the database server.Not just Ruby on RailsWe use it for lots of PHP applications.Can handle anything that can be automated through SSH.Flexible:Has a set of tasks it executes by default.Tasks can be overwritten or extended using before/after hooks.
- “capistrano-ext” gem: Useful extension to handle multiple server environments (eg, development, staging, production).“Capfile” required file.“config/deploy.rb” main configuration file.
- Lots of variables to control things: https://github.com/peritor/webistrano/wiki/configuration-parametersYou can define your own variables to do other things.
- Per-environment configuration.Define the servers to be used for this environment.Override variable defaults for this environment.
- Per-environment configuration.
- Per-environment configuration.
- Always just one command for an identical deployment.cap development deploycap production deploy
- Our website Apache configuration is part of application’s code base and deployment process.This allows dynamic deployments.cap development deploy SANDBOX=nmuerdterCompletely sets up a separate version of our code at a separate subdomain (eg, nmuerdter.dev.nrel.gov).Each developer doesn’t have to maintain a server, but their code and site is completely separate.cap staging deploy BRANCH=feature-aDeploy a different branch of our code to the staging server at a separate subdomain (eg, feature-a.staging.nrel.gov).Useful when multiple developers are working on different features of the same site, but each feature needs to be reviewed separately.
- Web site deployment only half of puzzle.Underlying servers need to be maintained.What software packages need to be installed? What configuration needs to be made? What about that magic file that needs to be in a certain place or everything breaks?Server changes required for development need to be remembered and applied to each sever when ready (development, staging, then production).Completely different servers often need to be setup similarly (for example, we setup Apache similarly between servers).Duplicate servers for load balancing purposes.
- Cookbooks: Encapsulates everything for a single piece of software (for example, Apache).Recipes: The script that defines the actions to perform to install and configure the software (for example, how to install Apache, what configuration files to install, and more). Written in Ruby.Attributes: Variables that can be set and customized (for example, what ports Apache should listen on).Files: Static files that should be installed onto the server.Templates: Like files, installed onto the server, but can contain attribute variables, so things can be customized depending on the server’s attributes (for example, the httpd.conf file).Roles: Define a series of cookbooks or other roles to run and attributes to set.Reusable, generic roles: “apache”Per-server roles: specific web server.Nodes: Any machine you’re dealing with.Server/Client modelChef Server: The master machine that hosts the chef server. Where cookbooks, roles, etc are stored.Chef Clients: Any machine you wish to configure using chef. The chef server machine itself is also a client.
- “package” defines the software package to install.Your recipe doesn’t have to be cross-platform, but a lot of the available cookbooks are.You give a package name, Chef handles the appropriate logic (yum for RedHat, apt-get for Debian).“service” defines the service that’s available.Again, Chef handles the cross-platform logic (init.d, etc).“template” installs a file onto the server after parsing “envvars.erb” with ruby. Allows for dynamic templates.“node” gives access to the attributes for the server being setup.
- The run list defines which other roles or recipes to run.You can nest roles.Some roles are generic “apache”Others we build for specific server types (eg, the web server responsible for a specific site).default_attributes defines or overrides variables for this specific role. Recipes use these variables to control logic or configuration. Self documenting: Now you know the exact requirements for your machines.
- Web interface available.I only like to use for browsing (not node configuration).I keep logic defined in role files, so changes are tracked in subversion.
- Updating a server, just a matter of running “chef-client”Fetches the run list for this specific machine from the chef server and runs recipes.Only performs actions if needed (eg, software packages only upgraded if needed, files only installed if they differ).I’ve glossed over initially bootstrapping client nodes and the chef server itself, but those directions can be found elsewhere.
- There is undoubtedly upfront overhead with this approach.
- However, the upfront overhead pays off in the long run.Maintenance is easier.CapistranoNew developer? One command sets up their separate sandbox on our development server.Deployments to staging and production are reliable. Always deploy via capistrano and any kinks get worked out early on in staging before going to production.ChefServer software updates? Never forget what you’ve done between your development and production servers.New server? Reuse existing cookbooks to speed up the process.Standardized process is followed.By scripting everything, the scripts become documentation for exactly how a server is configured and what is done during deployment.