Automating your infrastructure with Chef
Upcoming SlideShare
Loading in...5
×
 

Automating your infrastructure with Chef

on

  • 138 views

This is a presentation I gave for an O'Reilly webinar on the 6th of August, 2014

This is a presentation I gave for an O'Reilly webinar on the 6th of August, 2014

Statistics

Views

Total Views
138
Views on SlideShare
136
Embed Views
2

Actions

Likes
0
Downloads
9
Comments
0

1 Embed 2

https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Automating your infrastructure with Chef Automating your infrastructure with Chef Presentation Transcript

  • AUTOMATING YOUR INFRASTRUCTURE WITH CHEF John Ewart Sr. Software Engineer @ Chef ! @soysamurai :: http://johnewart.net
  • I hope that this talk will… - help you see how chef’s pieces fit together - show you some of the things chef can do - give you the tools to explore chef on your own - get you thinking about advanced uses - make you want to learn more about chef!
  • outline - 10K foot view - code examples - provisioning a server - configuring software - managing local environments - some advanced uses / ideas - resources - Q & A
  • 10,000 foot view
  • what is chef? chef is a tool for automating your infrastructure
  • Chef helps solve the problem of managing systems at scale by bringing the power of code to your infrastructure. You can easily manage complex infrastructure on your own hardware or in the cloud. ! WHY USE CHEF?
  • ‣ facebook ‣ Riotgames ‣ ancestry.com ‣ Splunk ‣ nordstrom Chef is popular among organizations large and small, from small startups to large digital companies like Facebook and Riot Games and even brick-and-mortar companies such as Nordstrom. ! The community around Chef is quite large and growing by the day. In the Chef Supermarket, there are over 1,500 recipes and almost 60,000 registered users. WHO USES CHEF? (amongothers)
  • what can chef do for you? ‣ provision ‣ configure ‣ deploy ‣ orchestrate You can use Chef to provision new hosts. - knife allows you to manually provision a new host - chef-metal can provision large numbers of hosts in parallel ! With Chef you can construct new hosts and automatically configure them with one command.
  • ‣ provision ‣ configure ‣ deploy ‣ orchestrate Using stored configuration and recipes, you can automate configuration of hosts. ! - Install software - Provision users - Configure firewalls - Update kernels - Much more! what can chef do for you?
  • ‣ provision ‣ configure ‣ deploy ‣ orchestrate Deploy application code from GitHub or other source control system. - Fully automate your release cycle - Only perform operations if they are needed what can chef do for you?
  • ‣ provision ‣ configure ‣ deploy ‣ orchestrate Chef knows about your infrastructure - How it’s organized - What your configuration looks like - Health status of your systems ! Leverage centralized configuration data to make informed decisions about your systems. what can chef do for you?
  • - Chef uses recipes that contain a set of managed resources - The Chef engine takes a run list, which contains a list of recipes to be executed on the node - A run list is acted on using providers for each resource, which contain the logic needed to achieve the desired effect for a given platform (update a file, create a user, install a package) - Using this combination of logic and configuration data, the node will converge upon the desired end-state chef in a nutshell
  • - Recipes: Ruby scripts that, when executed, perform a desired behavior such as install software, provision users, and so on. - Cookbooks: Collections of recipes that focus on a specific theme such as managing PostgreSQL or deploying a custom web application key terms
  • - Resources: Abstract Chef primitives that represent real- world components such as: files, templates, directories, packages, users or services. - Providers: Concrete implementations of a resource. For example, the package resource has providers for FreeBSD, Debian, RedHat, OSX and other platforms. key terms
  • - Node: A system that is managed by Chef, this can be any system capable of running the Chef client (and possibly other things in the future) - Role: A collection of recipes and configuration data that, when run together, allow a node to perform a specific role; examples might include a database server or web server but are free-form. key terms
  • - Attributes: Pieces of data that are used to configure your infrastructure. - Environments: Provide a way to maintain similar but different configuration data. For example you might have a production and a test environment with the same roles but different nodes and configuration data key terms
  • - Run list: A list of recipes to execute during a client run. This is generated based on the roles and recipes put into the run list. - Data bags: A generic collection of data stored in Chef that is not specific to any recipe, node or other entity in the system. key terms
  • A resource… - Has a type such as: file, user, package, or service (among others) - Describes an entity on the system - Is abstract and does not provide implementation details - Contains properties that will vary by resource - Provides a building-block for writing recipes - Requires a provider to perform the actual work file "/tmp/hello.txt" do action :create end ! user ‘samwise’ do uid 500 gid 1000 end
  • A recipe… - Uses the Chef recipe DSL - Is comprised of a one or more resources - Provides step-by-step instructions for achieving a desired end-result - Might describe how to: install a MySQL server, create users, or setup HAproxy ! package "haproxy" ! directory node['haproxy']['conf_dir'] ! template "/etc/init.d/haproxy" do source "haproxy-init.erb" owner "root" group "root" mode 00755 variables( :hostname => node['hostname'], :conf_dir => node[‘haproxy__dir'], :prefix => "/usr" ) end
  • file "/tmp/hello.txt" do end a simple recipe Here we use the file resource
  • file "/tmp/hello.txt" do action :create end a simple recipe We specify that the action to take on this resource is to create it
  • file "/tmp/hello.txt" do action :create content "Greetings, Earthling!" end a simple recipe And we can specify the contents of the file
  • recipe development - Recipes can contain as few as one resource - A recipe may contain hundreds of resources - Each recipe should have a specific end-goal - A recipe might: - installing a service, - provisioning users, or - deploy an application - Recipes that are related go together inside of a cookbook - There are many existing cookbooks for common activities
  • case node['platform_family'] when "rhel", "fedora", "suse" include_recipe "postgresql::server_redhat" when "debian" include_recipe "postgresql::server_debian" end One powerful feature of Chef is the ability to write recipes that support multiple distributions or even multiple operating systems Supporting multiple platforms
  • what else can you manage?
  • ["src", "logs", "conf"].each do |child_dir| directory “/opt/webapp/#{child_dir}” do owner node[:webapp][:user] group node[:webapp][:group] mode "0755" action :create recursive true end end ! create directories
  • home_dir = "/home/#{u['id']}" ! user u['id'] do uid u['uid'] gid u['gid'] shell u['shell'] comment u['comment'] supports :manage_home => true home home_dir end create users
  • git "/opt/app/webapp" do repository "https://github.com/johnewart/simplewebpy_app.git" action :sync branch 'master' user node[:webapp][:user] end deploy code
  • app_root = node[:webapp][:install_path] ! python_interpreter = node[:webapp][:python] virtualenv = "#{app_root}/python" ! python_virtualenv "#{virtualenv}" do owner node[:webapp][:user] group node[:webapp][:group] action :create interpreter "#{python_interpreter}" end manage python virtualenvs
  • postgresql_connection_info = { :host => 'localhost', :port => node[:postgresql][:config][:port], :username => 'postgres', :password => node[:postgresql][:password][:postgres] } ! postgresql_database 'webapp' do connection postgresql_connection_info action :create end create databases
  • postgresql_connection_info = { :host => 'localhost', :port => node[:postgresql][:config][:port], :username => 'postgres', :password => node[:postgresql][:password][:postgres] } ! postgresql_database_user node[:webapp][:dbuser] do connection postgresql_connection_info password node[:webapp][:dbpass] action :create end create database users
  • - If you can manage it manually, you can most likely build a custom provider and resource to manage it with Chef - The community of Chef users is quite large, you can probably find it out there on the Internet - If you can’t find it, you can easily build it; there are lots of great examples and resources out there to help <insert activity here>
  • from zero to database server in just a few minutes
  • - Here we will take a quick tour through how to use Chef to install PostgreSQL with just a few commands - This will use the default configuration provided by the cookbook - A good cookbook provides sane default values for this reason - You can always override the attributes by defining them in the Chef server Let’s see how this works
  • - Chef’s knife command provides the equivalent of a command-line swiss-army knife - Allows you to interact with the Chef server to manage configuration data, upload cookbooks, as well as manage remote systems a chef’s tool
  • 1. Creating a new host with a cloud provider 2. Installing the Chef client onto the host and registering it 3. Downloading cookbooks from GitHub 4. Uploading our cookbooks to the Chef server 5. Configuring a PostgreSQL server role 6. Assigning that role to our new host 7. Running chef-client on the host in order to converge it 8. There is no step 8! what we’ll be doing
  • Creating a new droplet with Digital Ocean; this could be any cloud service, or you can use your own physical systems
  • Now that’s it’s created, we have a host!
  • Using knife, we can bootstrap our new node.
  • Bootstrapping will: 1. Install the Chef client 2. Register itself with the Chef server 3. Make an initial run of the Chef client
  • Let’s make sure that the Chef server knows about our new node
  • Now that we have a host, we need some cookbooks!
  • Cookbooks are uploaded to the server for us to use
  • Once again, we can verify that the server know about our newly created objects.
  • knife role edit postgresql_server
  • Let’s take a quick look at our handiwork
  • Once we have a role, we need to assign it to our node.
  • Here’s what our node looks like now
  • knife can do lots of things, one of those things is remote execution of commands.
  • This also means we can execute the Chef client remotely using knife!
  • The Chef client running on our node
  • When it’s complete, Chef tells you how many things were changed and how long it took to finish the run
  • Look, PostgreSQL is now running!
  • - A key tenet of Chef is that configuration should be repeatable and consistent - Running the client multiple times in a row, with no configuration changes will result in the system being untouched (idempotence) - Resource providers determine if there is any work to be done and if there is no work to do, then the resource is left untouched repeatability
  • configuring software
  • - Installing software is not that hard - Package management tools have made that a lot easier - Most folks can apt-get install over SSH (or equivalent) - Configuring software is much harder - Chef can help you keep your configuration consistent software configuration
  • - Easy enough to apt-get install postgresql-server - Consider having 100 database nodes - Harder to keep them consistently configured - Chef knows all about your database servers - Use that info to build a database connection pool server - Let’s look at how we might configure pgpool using Chef example: webapp with pgpool
  • # configure the backends backend_hostname0 = 'db01' backend_port0 = 5432 backend_weight0 = 1 backend_hostname1 = 'db02' backend_port1 = 5432 backend_weight1 = 1 backend_hostname2 = 'db03' backend_port2 = 5432 backend_weight2 = 1 Configuring pgpool - by hand
  • db_servers = search(:node, “role:postgresql_server") ! template "/etc/pgpool.conf" do variables(:db_servers => db_servers) source "pgpool2.conf.erb" owner "root" group "root" mode "644" end Configuring pgpool The configuration portion of a pgpool recipe
  • ! # configure the backends <% @db_servers.each_with_index do |server, index| -%> backend_hostname<%= index %> = ‘<%= server[‘fqdn’] %>’ backend_port<%= index %> = 5432 backend_weight<%= index %> = 1 <% end -%> Configuring pgpool - chef A portion of a pgpool.conf template
  • - This example is very simple but can be expanded - For example you could use some information about the hosts to: - Dynamically change the DB weight - Change how many child processes to run - Alter the max connections - Configuration templates should be simple, like the views in MVC Advanced configuration
  • - With this you could create a role, pg_pool_server - By applying that to a node, you now have a pgpool instance - New nodes with the postgresql_server role are added dynamically - We have enough information to automatically configure an app using your pool
  • pg_pools = search(:node, “role:pg_pool_server”) ! template "#{src_dir}/config.py" do source "config.py.erb" variables({ :dbname => node[:webapp][:dbname], :dbuser => node[:webapp][:dbuser], :dbpass => node[:webapp][:dbpass], # first pgpool host as endpoint (for simplicity) :dbhost => pg_pools[0][‘fqdn’] }) end Configuring your app with chef A small portion of a deployment recipe
  • import web db_params = { 'dbn': 'postgres', 'db': '<%= @dbname %>', 'user': '<%= @dbuser %>', 'pw': '<%= @dbpass %>', 'host' : '<%= @dbhost %>' } DB = web.database(**db_params) cache = False Configuring your app with chef A simple web.py configuration file template
  • Consistent configuration - Chef can do more than simply install software - You can also configure software using the data stored in Chef - Configuring software this way guarantees that you have one source of truth that you can rely on - When your model gets updated with new data so do your configurations
  • provisioning local environments
  • local environments - Chef server provides the functionality required to configure fleets - The core engine of Chef can be used for small-scale configuration - Good for single hosts, application deployments, and more - An ideal tool for development environments to reduce friction !
  • what is chef solo? - Chef solo is designed for small-scale management - Chef solo does not use a central server - It is not designed for large scale infrastructure management - Typical use cases include: - developers managing virtual machines - test installations - small-scale infrastructure management - local application configuration
  • how do I use it? - Installation of Chef solo requires installing a single Ruby gem - Chef-solo is installed as a part of the chef gem - Cookbooks, recipes, and configuration data is stored locally - Can be used with self-provisioned virtual machines - Combine with Vagrant to automate provisioning of virtual hosts
  • limitations - The following features are not supported with Chef solo: - Node data storage - Search indexes - Centralized distribution of cookbooks - A centralized API - Authentication or authorization - Persistent attributes
  • using chef-solo - Using chef-solo is as simple as: - Creating some recipes - Generating a run list - Writing a solo configuration file - Executing chef-solo
  • We create a simple recipe
  • Our recipe creates a file with some contents in $HOME/example.txt
  • Manually create our run list to contain our recipe
  • Configure chef-solo
  • Run chef-solo
  • Check out our handiwork!
  • Prove that Chef runs are idempotent
  • Update our recipe
  • Do it again!
  • managing single hosts - As you can see, you can use the same techniques to manage a single system - A large number of existing cookbooks will work “as-is” - Some recipes will require updates if they rely on server-specific mechanisms ! ! !
  • configuring software - Recipes and configuration files can be delivered with your app - Chef solo can be used to configure the software - Chef’s omnibus installer uses Chef solo to configure itself - Repeatability of configuration means a more consistent experience - Provides a way of programmatically testing your installation - A good experience = happy customers - Happier customers make everyone happy!
  • chef and vagrant - Vagrant and Chef-solo is a very powerful combination - Distribute cookbooks and a Vagrantfile to your users - Developers can be up and running in no time - No need for developers to install services or tools manually - Repeatable, version controlled and easily distributed
  • chef and vagrantVagrant.configure("2") do |config| config.vm.box = "ubuntu/trusty64" config.vm.provision "chef_solo" do |chef| chef.cookbooks_path = "cookbooks" chef.roles_path = "roles" chef.data_bags_path = "data_bags" chef.add_recipe "postgresql::server" end end Here we tell Vagrant to use chef solo and that we want to use the server recipe from the postgresql cookbook.
  • chef and vagrant… chef.add_recipe "apt" chef.add_recipe "nodejs" chef.add_recipe "ruby_build" chef.add_recipe "rbenv::user" chef.add_recipe "rbenv::vagrant" chef.add_recipe "vim" chef.add_recipe "mysql::server" chef.add_recipe "mysql::client" ! chef.json = { rbenv: { user_installs: [{ user: 'vagrant', rubies: ["2.1.2"], global: "2.1.2", gems: { "2.1.2" => [ { name: "bundler" } ] } }] }, mysql: { server_root_password: '' } } ! - Provide JSON configuration data to Chef - Forward ports with Vagrant - Use recipes to: - Install tools for development - Setup database servers - Configure passwords - Install gems - Anything you can think of!
  • things you might do… - Provide an easy-to-use single-command way of building a developer’s environment (very useful for getting new developers bootstrapped working with services) - Configure your shipped software through version controlled JSON files (OmniTI’s Circonus does this) - Manage your local VMs with Vagrant and Chef solo to provide various services or applications
  • mad science!
  • advanced uses for chef - Integrate existing tools with Chef - Test your recipes and infrastructure - Fully automate your deployments - Scale your application capacity with a single command - Provision hundreds of new systems in parallel
  • integrate with Chef - Chef makes it easy to interact with your configuration data - Data is exposed through an HTTP API - By using the API you can extend your existing tools - For ideas on how you might do that, take a look at these: - Ruby gem for talking to Chef’s API - https://github.com/sethvargo/chef-api - Capistrano plugin for working with Chef - https://github.com/gofullstack/capistrano-chef
  • test your infrastructure - Because your configuration is code, you can test it - Testing can range from simple unit tests on recipes to full integration test suites - Chef gives you the ability to test across multiple platforms both at the recipe level inside unit tests as well as integration tests - Test Kitchen (https://github.com/test-kitchen/test-kitchen) is designed for integration testing - ChefSpec (https://github.com/sethvargo/chefspec) is useful for unit testing
  • test kitchen --- driver: name: vagrant ! provisioner: name: chef_solo ! platforms: - name: ubuntu-12.04 - name: centos-6.4 ! suites: - name: default run_list: - recipe[testfile::default] attributes: Test on multiple platforms using Vagrant
  • Chefspec require 'chefspec' ! describe 'mycookbook::default' do let(:chef_run) { ChefSpec::Runner.new.converge(described_recipe) } ! it 'creates a file' do expect(chef_run).to create_file('/tmp/myfile.txt') end end ChefSpec makes it easy to verify your recipes’ functionality.
  • Chefspec let(:chef_run) do runner = ChefSpec::ChefRunner.new( 'platform' => 'windows', 'version' => '2012' ) runner.converge('mysql::server') end ! it 'should include the correct Windows server recipe' do chef_run.should include_recipe 'mysql::server_windows' end Even unit test your recipe’s execution on different platforms
  • fully automated deployments - You can use Chef to completely automate deployments - Model two environments, each configured for a different branch - Write a recipe to deploy your application - Run chef-client on a schedule using cron or another tool - Push code to the test environment branch to deploy to testing - When you are ready, push changes to the production branch - With some automated tests and elbow grease you can automate that step too!
  • scaling your infrastructure - Sometimes your needs outpace your hardware growth - Chef can help you adapt quickly and with ease - Using Chef and cloud services you can expand your capacity Provision cloud server with knife Deploy application with Chef Register host with AWS ELB More capacity!
  • scaling your infrastructure aws_elastic_lb “#{node.myapp.website.load_balancer}" do aws_access_key "#{node.myapp.aws.access_key}" aws_secret_access_key "#{node.myapp.aws.secret_key}" action :register end With the ELB resource, Chef can add your newly configured host to an AWS ELB instance.
  • scaling your infrastructure knife ec2 server create -d ubuntu13.10 -I ami-c6402cf6 -f m3.large -Z us-west-2a -S ssh_key -N hostname -r “role['base_server'],role['webapp']" -g 'sg-e20fddcb,sg-359223ab' With Chef, provisioning a new EC2 instance, deploying your app and registering it with the load balancer is as easy as one command.
  • auto-scaling - With a combination of cloud providers, metrics and Chef you could build a system that automatically grows or shrinks your infrastructure as needed Metrics Chef Cloud provider Scaling Engine Feeds data into scaling engine Determines a need
 for more capacity Provisions a new
 node with knife Brings up new node,
 bootstraps, registers
 with load balancer, etc.
  • chef-metal - chef-metal is designed to allow you to provision systems from a set of configuration files - Use your configuration to provision hundreds of Vagrant instances or EC2 instances - chef-metal is under active development num_webservers = 100 ! 1.upto(num_webservers) do |i| machine "web#{i}" do recipe 'apache' recipe 'webapp' end end
  • resources
  • - Learn Chef - http://learn.getchef.com/ - A great combination of getting started material for new Chef users - Chef Supermarket - http://supermarket.getchef.com - Contains cookbooks, tools and extensions to Chef. Community maintained - Mailing list - http://lists.opscode.com/sympa/info/chef - An active mailing list for users of Chef to communicate resources
  • - Written by me - Instant Chef Starter - Managing Windows Servers with Chef - Chef Essentials (coming soon) - Written by others - Learning Chef (coming soon) - Test-Driven Infrastructure with Chef, 2nd Edition books
  • I hope that this talk has… - helped you see how chef’s pieces fit together - shown you some of the things chef can do - given you the tools to explore chef on your own - gotten you thinking about advanced uses - made you want to learn more about chef!