Upload
john-ewart
View
1.336
Download
6
Tags:
Embed Size (px)
DESCRIPTION
This is a presentation I gave for an O'Reilly webinar on the 6th of August, 2014
Citation preview
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 ‣ Riot games ‣ 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? (among others)
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
Chefspecrequire '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 infrastructureaws_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 infrastructureknife 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 needfor more capacity
Provisions a newnode 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!