Chef is an automation platform that transforms infrastructure into code. It uses recipes written in Ruby and Erlang languages to configure, deploy, and manage applications across networks. Chef includes a server to store configuration data and recipes, workstations where developers write recipes, and nodes (physical or virtual machines) that are configured by recipes. Key components of Chef include cookbooks (which contain recipes, attributes, files, and templates), nodes, Ohai (which collects node data), and a workflow involving verifying, building, accepting, and delivering changes through shared pipelines.

1. CHEF
CONTINOUS DELIVERY

2. INTRO TO CHEF
 Chef is a powerful automation platform that transforms complex
infrastructure into code.
 Chef automates how applications are configured, deployed and managed
across your network.
 Chef is a configuration management tool written in Ruby and Erlang
languages.
 It uses a pure Ruby, domain specific language for writing system
configuration “recipes”.
 Chef is introduced by Adam Jacob in 2009.
 Chef framework was created by opscode.

3. Overview of Chef
 chef comes in two flavours are
- Open Source Chef
- Enterprise Chef includes features such as multi tenancy.
 Client-Server Architecture.
 Embraces modern web technologies
 A system integration platform.
 Programmatically provision and configure.
 Reconstruct business from code repository data backup and resources.

4. When to use it
 Before considering Chef, make sure you’re familiar with Git, as
it’s required for configuration, and Ruby, as you’ll have to be
writing in it.
 Chef is good for development-focused teams and
environments.
 It’s good for enterprises looking for a more mature solution
for a heterogeneous environment.

5. Chef is infrastructure as code
 Programmatically provision and configure components.
 Treat like any other code base
 Reconstruct business from code repository, data backup, and
bare metal resources.

6. Configuration Management
 The art of identifying, organizing and controlling
modifications to the software being built by a programming
tool.
 We need CM because it is easy to lose track of what changes
and component versions have been incorporated into each
system version.

7. Continuous Delivery
 Continuous Delivery is a software development practice in which continuous integration,
automated testing and automated deployment capabilities allow high quality software to
be developed and deployed rapidly, reliably and repeatedly with minimal manual
overhead.

8. CHEF Components
 The Chef process consists of three core components that interact with one
another: Chef server, actual servers called nodes, and Chef workstation.

9. Chef Server
 The Chef server is as a hub for configuration data. It stores cookbooks, the
policies that are applied to nodes, and metadata that describes each node
managed by Chef.
Nodes
 Nodes use a tool called Chef client to ask the Chef server for configuration
details and then applies them to itself. This process of applying changes on
nodes is called a Chef run.
Chef Workstation
 The Chef workstation or Chef repository, shortly chef-repo, is the project
structure of a Chef-managed project and it is used on a developer
workstation. All Chef components are defined in it: cookbooks,
environments, roles and a test suite.

10. Workstation Components & Tools
 Development Kit: The Chef Development Kit is a package that contains
everything that is needed to start using Chef:
- chef-client and ohai
- chef and knife command line tools
 Chef: Use the chef command-line tool to work with items in a chef-repo, which
is the primary location in which cookbooks are authored, tested, and
maintained, and from which policy is uploaded to the Chef server
 Knife: Use the knife command-line tool to interact with nodes or work with
objects on the Chef server
 Chef-repo is the repository structure in which cookbooks are authored, tested,
and maintained. The chef-repo should be synchronized with a version control
system (such as git), and then managed as if it were source code.
 Kitchen provides a test harness to execute infrastructure code on one or more
platforms in isolation. It uses a driver plugin architecture.

11. Cookbooks
 A cookbook is the fundamental unit of configuration and policy
distribution. A cookbook defines a scenario and contains everything that is
required to support that scenario:
- Recipes that specify the resources to use and the order in
which they are to be applied
- Attribute values
- File distributions
- Templates
- Extensions to Chef, such as custom resources and libraries

12. Cookbook Components
 Recipe: The fundamental part of Chef, it is a collection of resources that are
executed in the order to configure a node.
 Resource: A cross platform abstraction of configurable parts of a node. For
example these could be users, packages, files or directories.
 Attributes - Represent node settings, for example hostname, versions of
programming languages to install, database server etc.
 Metadata: Every cookbook requires a small amount of metadata. A file named
metadata.rb is located at the top of every cookbook directory structure.
 Library: Library allows arbitrary Ruby code to be included in a cookbook, either
as a way of extending the classes that are built-in to the chef-client.
 Template: A cookbook template is an Embedded Ruby template that is used to
dynamically generate static text files. It may contain Ruby expressions and
statements & are a great way to manage configuration files.

13. Nodes
A node is any machine
— physical, virtual, cloud, network device, etc.
— that is under management by Chef.
Types of nodes that can be managed by Chef include, the following:
 Server: A physical node is any active device attached to a network that can run a chef-
client and also allow that chef-client to communicate with a Chef server.
 Cloud: A cloud-based node is hosted in an external cloud-based service, such as
Amazon Web Services (AWS). knife can use these plugins to create instances on cloud-
based services. Once created, the chef-client can be used to deploy, configure, and
maintain those instances.
 Container: Containers are an approach to virtualization that allows a single operating
system to host many working configurations. Containers are popular as a way to
manage distributed and scalable applications and services.
 Network Device: A network node is any networking device—a switch, a router—that is
being managed by a chef-client

14. Chef on Nodes
 Chef Client: A chef-client is an agent that runs locally on every node that is
under management by Chef. When a chef-client is run, it will perform all of the
steps that are required to bring the node into the expected state, including:
- Registering and authenticating the node with the Chef server
- Building the node object
- Synchronizing cookbooks
- Looking for exceptions and notifications, handling each as required.

15. Ohai: A tool that is used to collect system configuration data called Ohai.
which is provided to the chef-client for use within cookbooks. Ohai is run by
chef-client at the beginning of every Chef run to determine system state.
Types of attributes Ohai collects includes
 Operating System
 Network
 Memory
 Disk
 CPU
 Kernel
 Host names
 Fully qualified domain names
 Virtualization
 Cloud provider metadata

16. Chef Server
Chef server acts as a hub for configuration data. It stores cookbooks, the policies that
are applied to nodes & metadata that describes each registered node that is being
managed by the chef-client. Nodes use the chef-client to ask the Chef server for
configuration details, such as recipes, templates & file distributions. The features of
chef server are
 Search indexes allow queries to be made for any type of data that is indexed by the
Chef server, including data bags, environments, nodes, roles.
 Chef management console is a web-based interface for the Chef server that
provides users a way to manage the objects like Nodes, Cookbooks, Recipes, Roles,
Stores JSON data, Environments.
 A data bag is a global variable that is stored as JSON data and is accessible from a
Chef server. A data bag is indexed for searching and can be loaded by a recipe or
accessed during a search.

17. Policy
Policy maps business and operational requirements, process, and workflow to
settings and objects stored on the Chef server:
 Roles define server types, such as “web server” or “database server”
 Environments define process, such as “dev”, “staging”, or “production”
 The cookbooks & cookbook versions in which organization-specific
configuration policies are maintained.
 A run-list defines all of the information necessary for Chef to configure a node
into the desired state. A run-list is stored as part of the node object on the
Chef server.

18. Overview of Chef Workflow
 Chef Workflow is a tool built by Chef for Continuous Delivery of
applications and infrastructure.
 It provides facility for automated testing and deployment.
Chef Workflow has a shared pipeline model.
 Every change has to go through some predefined phases of the pipelines
prior to getting released.
 A pipeline is a series of automated and manual quality gates that take
software changes from development to delivery. Chef Workflow pipeline is
made up of 6 stages: Verify, Build, Acceptance, Union, Rehearsal and
Delivered.

19.  Each project has associated Verify, Build and Acceptance stages. Verify and Build
stages perform tests on the source code. Union, Rehearsal & Delivered are a part
of Shared Pipeline.
 It includes the stages which are unique per project. A developer has control only till
the “Project Pipeline”. Here you push your change, someone reviews and approves
it and then the code is shipped to the Shared Pipeline.
 Verify Stage: The verify stage runs automatically when someone submits a change.
change. It is made up of various phases like:
 Lint: Identifies stylistic problems in your source code
 Syntax :Checks that the code can be parsed
 Unit: Runs unit tests

20. Build Stage: When a change is approved, Chef Workflow merges the change
into the pipeline’s target branch and triggers the Build stage. Build stage
runs lint, syntax and unit phases from Verify stage. This is because your
may have moved ahead since the Verify stage ran on this change
 Quality: Runs additional test suites. Some tests are too time consuming.
They can be put in Build phase instead of the Verify phase
 Security: Security tests as well as functional test suites can be added here
 Publish: Produces the potentially releasable artifacts and makes them
available for rest of the pipeline

21. Acceptance Stage: Till Build stage the pipeline was analysing the source code.
From the acceptance stage onwards, it starts analysing the artifact produced
Build stage. As the name suggests, Acceptance is the stage where the team
decides whether the change should go into production or not.
There are 4 phases in Acceptance stage:
 Provision: Provision infrastructure needed to test the artifacts
 Deploy: Deploy the artifacts to your infrastructure
 Smoke: Run smoke test. They should be short running
 Functional: Run functional tests to assure that changes are meeting the
business requirements

22. Shared Pipeline” is automated by Chef Workflow. It runs the test cases for every stage,
tests the cookbook/application by VM provisioning and if all stages are passed then the
code gets merged into the desired branch.
 Union Stage: A project usually doesn’t work independently. It has dependencies on
several other projects too The purpose of Union stage is to analyse the impact of your
change on the whole system. Here tests are performed with interactions between the
interdependent projects. Phases of Union stage and the remaining stages are same:
provision, deploy, smoke and functional.
 Rehearsal Stage: This stage is triggered if all phases of Union stage pass. The purpose
of this stage is to gain confidence in your change. It repeats the same process as of
Union stage in a different environment. It’s like a pre-production environment.
 Delivered Stage: It is the final stage and its definition can vary according to one’s
requirements. It could mean deploying your changes and making them live, or
publishing a set of artifacts for the customers.

23. Chef Workflow Components
 The build cookbooks reside on Chef Server which decide what happens in each phase. Each
build node is registered with the chef server
 It’s better to have 3 build nodes so that lint, syntax and unit phases can run in parallel.
 For each deploy-able stage of chef workflow there is a web accessible server where you can
verify your changes pushed through pipeline.

24. How to use Chef
 Download Chef Development kit
(https://downloads.chef.io/chef-dk/)
 Create a repo eg. chef-repo (mkdir learn-chef)
 Create a folder to keep cookbooks (mkdir cookbooks)
 Now create a cook book eg. (chef generate cookbook learn_chef)
 Go to https://manage.chef.io/ and create a account on chef.io
 Create an organization
 Configure your workstation to communicate with the Chef server with knife
 knife requires two files to communicate with the Chef server
 Every request to the Chef server is authenticated through an RSA public key-
pair. The Chef server holds the public part; you hold the private part.

25. Pros
 Rich collection of modules and configuration recipes.
 Code-driven approach gives you more control and flexibility over your
configurations.
 Being centred around Git gives it strong version control capabilities.
 ‘Knife’ tool (which uses SSH for deploying agents from workstation) eases
installation burdens.

26. Cons
 The learning curve is steep if you’re not already familiar with
Ruby and procedural coding.
 It’s not a simple tool, which can lead to large code bases and
complicated environments.
 Doesn’t support push functionality.

27. THANK YOU