> For the complete documentation index, see [llms.txt](https://citizenseven.gitbook.io/ccna-prep/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://citizenseven.gitbook.io/ccna-prep/ansible-puppet-and-chef.md).

# Ansible, Puppet, & Chef

Day 63

**Configuration drift** is when individual changes made over time cause a device's configuration to deviate from the standard/correct configurations as defined by the company. Although each device has a unique part of the configuration (IP addresses, hostname, etc.), most of a device's configuration is usually defined in standard templates by the network engineers of the company. As individual engineers make changes to devices, the configuration of a device can drift away from the standard. Records of these individual changes and their reasons aren't kept. This leads to issues in future. Even without automation tools, it is best to have standard configuration management practices.

**Configuration provisioning** is how configuration changes are applied to devices. This includes configuring new devices too. Configuration management tools like Ansible, Puppet, and Chef allow us to make changes to devices on a mass scale with a fraction of the time/effort. Two essential components are **templates** and **variables**.

<figure><img src="https://3642595937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKsHxwINrQaKCeVpC90i9%2Fuploads%2F5aKyimTHDzFEe9eSm0uH%2Fimage.png?alt=media&amp;token=471df7f4-195a-4d83-ac62-217090e2d945" alt="templates and variables demo" width="563"><figcaption></figcaption></figure>

**Configuration management tools** are network automation tools that facilitate the centralized control of large numbers of network devices. They can be used to generate configurations for new devices on a large scale, perform configuration changes on devices, check device configurations for compliance with defined standards, and compare configurations between devices/different versions of configurations on the same device.

### Ansible

Ansible is a configuration management tool owned by Red Hat and written in Python. Ansible is agentless - it doesn't require any special software to run on the managed devices. It uses SSH to connect to devices, make configuration changes, extract information, etc. Ansible uses a **push** model - the Ansible server (Control node) uses SSH to connect to managed devices and push configuration changes to them. After installing Ansible itself, several text files must be created:

* **Playbooks** - blueprints of automation tasks. They outline the logic and actions of the tasks that Ansible should do. Written in YAML.
* **Inventory** - list of the managed devices and their characteristics. Written in INI, YAML, or other formats.
* **Templates** - device's configuration files but specific values for variables aren't provided. Written in Jinja2 format.
* **Variables** - list of variables and values. These values are substituted into the templates to create complete configuration files. Written in YAML.&#x20;

<figure><img src="https://3642595937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKsHxwINrQaKCeVpC90i9%2Fuploads%2FyYmQQDHuYDLCITwTIJ3y%2Fimage.png?alt=media&amp;token=433f309f-ac80-4e67-882a-8d23203a477e" alt="ansible demo" width="563"><figcaption></figcaption></figure>

### Puppet

Puppet is written in Ruby. Puppet is typically agent-based. Specific software must be installed on the managed devices but not all Cisco devices support a Puppet agent. It can be run agentless, in which a proxy agent runs on an eternal host and uses SSH to connect to the managed devices and communicate with them. The Puppet server is called the **Puppet master**. It uses a **pull** model - clients pull configurations from the Puppet master. Clients use TCP port 8140 for communication. Instead of YAML, Puppet uses proprietary language for files. **Manifest** text file which defines the desired configuration state of a network device and **template** files are required on the Puppet master.

<figure><img src="https://3642595937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKsHxwINrQaKCeVpC90i9%2Fuploads%2FnwjLohGT28ggtK4c1R6p%2Fimage.png?alt=media&amp;token=c2c48585-a24e-445f-ab61-ccbf9e2c410e" alt="Puppet demo" width="563"><figcaption></figcaption></figure>

### Chef

Chef is written in Ruby. It is agent-based and not all Cisco devices support it. Chef uses a **pull** model. The server uses TCP port 10002 to send configurations to clients. Files use a **DSL** (Domain-Specific Language) based on Ruby. Text files used by Chef:

* **Resources** - configuration objects managed by Chef.
* **Recipes** - outline the logic and actions of the tasks performed on the resources.
* **Cookbooks** - a set of related recipes grouped.
* **Run-list** - an ordered list of recipes that are run to bring a device to the desired configuration state.&#x20;

<figure><img src="https://3642595937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKsHxwINrQaKCeVpC90i9%2Fuploads%2FN7f8BhfQlbr34p2Bfe2T%2Fimage.png?alt=media&amp;token=9a40965d-731c-4ec6-96d6-8eb18221ff57" alt="Chef demo" width="563"><figcaption></figcaption></figure>

Here is the chart comparing the three configuration management tools:

<figure><img src="https://3642595937-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FKsHxwINrQaKCeVpC90i9%2Fuploads%2FR0JkLo5uwwor3vreE3jW%2Fimage.png?alt=media&amp;token=00fc35d4-31aa-484a-a10b-61fad39698a9" alt="summary" width="563"><figcaption></figcaption></figure>

{% file src="/files/LmbF7CIX0wM8Z0JeAkKm" %}