How to run chef-client in why-run mode aka “no-operation”

why-run mode is a way to see what the chef-client would have configured, had an actual chef-client run occurred. This approach is similar to the concept of “no-operation” (or “no-op”): decide what should be done, but then don’t actually do anything until it’s done right. Run the executable in why-run mode, which is a type of chef-client run that does everything except modify the system.

When why-run mode is enabled, a chef-client run will occur that does everything up to the point at which configuration would normally occur. This includes

1. Getting the configuration data,
2. Authenticating to the Chef server,
3. Rebuilding the node object,
4. Expanding the run-list,
5. Getting the necessary cookbook files,
6. Resetting node attributes,
7. Identifying the resources, and
8. Building the resource collection and
9. Does not include mapping each resource to a provider or configuring any part of the system.

How to run chef-client?

$sudo chef-client -o 'recipe[ntp]' --why-run$ sudo chef-client -o 'recipe[ntp]' -W

Tagged : / / /

Ecosystem of chef and Its associated tools explained

Chef Apply
chef-apply is an executable program that runs a single recipe from the command line. Is part of the Chef development kit. A great way to explore resources

Chef
The chef executable is a command-line tool which Generates applications, cookbooks, recipes, attributes, files, templates, and custom resources (LWRPs) and Ensures that RubyGems are downloaded properly for the chef-client development environment along with Verifies that all components are installed and configured correctly

Knife
knife is a command-line tool that provides an interface between a local chef-repo and the Chef server. knife helps users to manage Nodes, Cookbooks and recipes, Roles, Environments, and Data Bags, Resources within various cloud environments, The installation of the chef-client onto nodes, Searching of indexed data on the Chef server

Chef Client
The Chef client works with the Chef server to bring nodes to their desired states with policies you provide as recipes. The chef-client executable can be run as a daemon. 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
• Compiling the resource collection by loading each of the required cookbooks, including recipes, attributes, and
• all other dependencies
• Taking the appropriate and required actions to configure the node
• Looking for exceptions and notifications, handling each as required

Chef Development Kit
The Chef development kit contains all you need to develop and test your infrastructure, built by the awesome Chef community. Chef Development Kit has following Component installed…

• fauxhai
• kitchen-vagrant
• openssl
• delivery-cli
• test-kitchen
• git
• berkshelf
• chefspec
• knife-spork
• inspec
• tk-policyfile-provisioner
• opscode-pushy-client
• chef-dk
• chef-sugar
• chef-client
• generated-cookbooks-pass-chefspec
• chef-provisioning
• package installation

Chef Server
The Chef server makes it easy to automate your infrastructure, manage scale and complexity, and safeguard your systems.

Chef Server has following tools which should be running…

• bookshelf
• nginx
• oc_bifrost
• oc_id
• opscode-erchef
• opscode-expander
• opscode-solr4
• postgresql
• rabbitmq
• redis_lb

InSpec
InSpec is an open-source testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security and policy requirements.

Push Jobs Client
The Push Jobs client communicates with the Push Jobs server, which extends the Chef Server to allow you to execute commands across hundreds or even thousands of nodes in your Chef-managed infrastructure.

Push Jobs Server
The Push Jobs server add-on, along with its associated client, extends the Chef Server to allow you to execute commands across hundreds or even thousands of nodes in your Chef-managed infrastructure.

Supermarket
Supermarket is an artifact repository that makes it easy to browse, use, and share communal cookbooks and tools within your organization.

Chef Automate
One platform with a unified workflow, end-to-end visibility, and automated compliance over your entire Chef ecosystem.

Chef Compliance
Assess and monitor infrastructure compliance and use InSpec compliance profiles to validate that production servers are properly configured.

Chef Backend
Chef High Availability makes it easy to build high-availability Chef clusters on any infrastructure.

Chef Manage
Chef Manage is an Enterprise Chef add-on that enables a web-based user interface for visualizing and managing nodes, data bags, roles, environments, cookbooks and role-based access control (RBAC).

Kitchen or Test Kitchen
kitchen is the command-line tool for Kitchen, an integration testing tool used by the chef-client. Kitchen runs tests against any combination of platforms using any combination of test suites. Each test, however, is done against a specific instance, which is comprised of a single platform and a single set of testing criteria.

“Test Kitchen is an integration tool for developing and testing infrastructure code and software on isolated target platforms.” It creates test machines, converges them, and runs post-convergence tests against them to verify their state. Test Kitchen is written in Ruby. It has a plugin system for supporting machine creation through a variety of virtual machine technologies such as vagrant, EC2, docker, and several others. Test Kitchen makes it easy for Chef developers to test cookbooks on a variety of platforms. It uses busser to install post-convergence integration test tools such as Serverspec or BATS that actually perform the tests.

foodcritic
Foodcritic is a helpful lint tool you can use to check your Chef cookbooks for common problems.
http://www.foodcritic.io/

ChefSpec
ChefSpec is a framework that tests resources and recipes as part of a simulated chef-client run. ChefSpec tests execute very quickly. When used as part of the cookbook authoring workflow, ChefSpec tests are often the first indicator of problems that may exist within a cookbook.
ChefSpec is packaged as part of the Chef development kit. To run ChefSpec
$chef exec rspec https://docs.chef.io/chefspec.html RuboCop Rubocop is a Ruby command-line tool that performs lint and style checks based on the community driven Ruby Style Guide. It performs static analysis of any Ruby code, which includes Chef recipes, resources, library helpers, and so forth. Rubocop can be configured via .rubocop.yml to exclude certain rules, and it can be run with “–lint” to perform only lint checking, excluding all style checks. Rubocop is used in the Chef community in cookbooks to make contributions more consistent and easier to manage. Serverspec Serverspec is an “outside-in” integration test framework. It is platform and tool agnostic, and is used by other configuration management systems to verify systems are configured as desired. It checks the actual state of the target node by executing commands locally, via SSH, via WinRM, or other remote transports. Serverspec is implemented in RSpec, and uses RSpec test syntax. Chef Internal – How Chef maintain the state of each resources internally? Chef Client A chef-client is an agent that runs locally on every node that is under management by Chef. The chef-client executable can be run as a daemon. 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 • Compiling the resource collection by loading each of the required cookbooks, including recipes, attributes, and all other dependencies • Taking the appropriate and required actions to configure the node • Looking for exceptions and notifications, handling each as required RSA public key-pairs are used to authenticate the chef-client with the Chef server every time a chef-client needs access to data that is stored on the Chef server. This prevents any node from accessing data that it shouldn’t and it ensures that only nodes that are properly registered with the Chef server can be managed. Ohai Ohai is a tool that is used to collect system configuration data, which is provided to the chef-client for use within cookbooks. Ohai is run by the chef-client at the beginning of every Chef run to determine system state. Ohai includes many built-in plugins to detect common configuration details as well as a plugin model for writing custom plugins. The types of attributes Ohai collects include but are not limited to: • Operating System • Network • Memory • Disk • CPU • Kernel • Host names • Fully qualified domain names • Virtualization • Cloud provider metadata Attributes that are collected by Ohai are automatic level attributes, in that these attributes are used by the chef-client to ensure that these attributes remain unchanged after the chef-client is done configuring the node. Ohai collects data for many platforms, including AIX, Darwin, Linux, FreeBSD, OpenBSD, NetBSD, Solaris, and any Microsoft Windows operating systems. What is the significance of the default directory under chef cookbook /templates? What is the significance of the default directory under chef cookbook /templates? A cookbook is frequently designed to work across many platforms and is often required to distribute a specific template to a specific platform. This is a New in Chef Client 12.0. A cookbook can be designed to support the distribution of templates across platforms, while ensuring that the correct template ends up on each system. The pattern for template specificity depends on two things: the lookup path and the source. The first pattern that matches is used: /host-$fqdn/$source /$platform-$platform_version/$source
/$platform/$source
/default/$source /$source

Use an array with the source property to define an explicit lookup path. For example:
template ‘/test’ do
source [“#{node.chef_environment}.erb”, ‘default.erb’]
end

The following example emulates the entire file specificity pattern by defining it as an explicit path:
template ‘/test’ do
source %W{
host-#{node[‘fqdn’]}/test.erb
#{node[‘platform’]}-#{node[‘platform_version’]}/test.erb
#{node[‘platform’]}/test.erb
default/test.erb
}
end

A cookbook may have a /templates directory structure like this:
/templates/
windows-6.2
windows-6.1
windows-6.0
windows
default

and a resource that looks something like the following:
template ‘C:\path\to\file\text_file.txt’ do
source ‘text_file.txt’
mode ‘0755’
owner ‘root’
group ‘root’
end

This resource would be matched in the same order as the /templates directory structure. For a node named host-node-desktop that is running Windows 7, the second item would be the matching item and the location:
/templates
windows-6.2/text_file.txt
windows-6.1/text_file.txt
windows-6.0/text_file.txt
windows/text_file.txt

default/text_file.txt