2015 08-11-scdo-meetup

Ned Harris Solutions Engineer, CHEF

[email protected]

@nedward777

• https://github.com/nedward/socaldevops-realworld

Agenda

•  Overview

•  Chef Software Platform

•  Building Blocks

•  Chef Patterns and Techniques

Overview

•  Chef is an automation framework that enables Infrastructure as Code

•  Chef leverages reusable definitions to automate desired state

•  Chef is API driven

•  Chef supports Linux variants, Unix variants, AIX and Windows, all as first class citizens.

The Chef Software Platform

Chef Analytics Chef Delivery Management console

High availability and replication

Chef Provisioning

Chef Development Kit

Cookbook and policy authoring

Test-driven infrastructure

Containers

Cloud

VMs

Devices

Chef Server Chef Solo

Eco

syst

em

(con

tent

, plu

gins

, etc

.)

Search & Discovery

Chef Success Engineering

Building Blocks

Cookbooks

Recipes

Resources

Building Blocks: What is a Resource?

•  A Resource is a system state you define   Example: Package installed, state of a service, configuration file existing

•  You declare what the state of the resource is   Chef automatically determine HOW that state is achieved

package "httpd" do action :install end

windows_feature "IIS-WebServerRole" do action :install end

Building Blocks: What is a Recipe?

•  A recipe is a collection of Resources •  Resources are executed in the order they are listed

On Linux based OSes:

package "httpd" do action :install end template ”/var/www/index.html" do source ”index.html.erb” mode "0644" end service "httpd" do action [ :enable, :start ] end

windows_feature "IIS-WebServerRole" do action :install end template 'c:\inetpub\wwwroot\Default.htm' do source "Default.htm.erb" rights :read, "Everyone" end service "w3svc" do action [ :enable, :start ] end

Building Blocks: What is a Cookbook?

•  A cookbook is a set of recipes •  A cookbook is a defined set of items

and different outcomes that you expect to address   A cookbook could have a recipe to install

apache2/httpd but also another set of recipes to activate modules required.

./attributes

./attributes/default.rb

./CHANGELOG.md

./metadata.rb

./README.md

./recipes

./recipes/application.rb

./recipes/balancer.rb

./recipes/database.rb

./recipes/default.rb

./recipes/webserver.rb

./templates

./templates/default

./templates/default/mysite.conf.erb

•  Application cookbooks should map 1 to 1 to an application or piece of software

•  Data abstracted from policy, using attributes over hard coded values

A lot of the following patterns assume these tenants are being applied.

Environments

Building Blocks

Roles

Cookbooks

Recipes

Resources

Building Blocks: What is a role?

•  Define reusable roles for Infrastructure Code

chef_type: role default_attributes: my-app: application: version: 1.5.6 description: Role for my application json_class: Chef::Role name: my_application_role run_list: role[base] recipe[my-app::application]

Building Blocks: What is an Environment?

•  Define a reusable environments for Infrastructure Code

chef_type: environment cookbook_versions: database: 2.2.0 default_attributes: myapp: application: version: 1.2.3 description: Our production environment json_class: Chef::Environment name: production

By pinning certain attributes to an environment, you can assure these attributes are global to all nodes within the environment. This allows a single point of control over service configuration to a wide range of servers. You can also pin a cookbook version to an environment, preventing newer versions of that cookbook from being applied to nodes in that environment.

Roles are global in scope, so a change to them can effect any node assigned to that role in any environment. This can lead to unintended consequences.

Pinning attributes to roles.

Because no one organization is the same as another, there is no generic answer to this question.

• What I can do is provide a set of proven patterns and techniques that have been battle tested over time, along with some commonly accepted anti-patterns to avoid.

• By selectively applying these patterns and techniques you can address some of your organization's unique requirements

Note: These patterns are based on tribal knowledge, but not all tribes share the same views. You should look at these patterns objectively based on how they may (or may not) fit for your organization.

Someone has already built 90% of what I want in a community cookbook. It’d be nice to benefit from all that work that has already been done. It’s not 100% the way I need it though.

As its name implies, a wrapper cookbook is one which wraps itself around an existing cookbook, typically an application cookbook. A wrapper cookbook may extend functionality not found in an existing cookbook. In most use cases however it is generally used as a means of changing attributes found in an application cookbook.

This often leads to drift as each version of the cookbook evolves separately. At some point you just own a redundant cookbook, with all the original value of reuse lost.

Copying or forking the application cookbook.

It gets tiring, making sure I’ve added recipes like iptables, dns, ldap etc. to all the different run-lists. I’d like to consolidate all these recipes into a role, but I have been told roles can’t be versioned like cookbooks .

This can lead to an untenable management situation as this base policy evolves over time.

Adding this common base policies ala-cart into many different roles and / or run-lists.

Inside my environment I have a good number of cookbooks that need to be deployed with some variation from one to the next. I’ve been told not to pin attributes to roles though… what do I do?

Roles can apply to all environments within the chef organization. This makes them dangerous. Roles cannot be versioned the way cookbooks can.

Pinning attributes to roles

Thank You – Questions?