Chef Patterns, Configuration Management Tool, SoCalDevOps,

2. Ned Harris
Solutions Engineer, CHEF
ned@chef.io
@nedward777

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

4. Agenda
• Overview
• Chef Software Platform
• Building Blocks
• Chef Patterns and Techniques

5. 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.

6. 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 ServerChef Solo
Ecosystem
(content,plugins,etc.)
Search & Discovery
Chef Success Engineering

7. Building Blocks
Cookbooks
Recipes
Resources

8. 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

9. 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:inetpubwwwrootDefault.htm' do
source "Default.htm.erb"
rights :read, "Everyone"
end
service "w3svc" do
action [ :enable, :start ]
end

10. 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

11. • 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.

12. Environments
Building Blocks
Roles
Cookbooks
Recipes
Resources

13. 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]

14. 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

15. 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.

17. 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.

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

21. • 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

22. 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.

24. 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.

25. 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.

27. 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.

28. 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 .

30. 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.

31. 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?

33. 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

34. Thank You – Questions?