TSR – The Server Room – Shownotes – Episode 40 – Continuous Configuration Automation Tools) – Ansible

What is Infrastructure as a code?

Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.The IT infrastructure managed by this process comprises both physical equipment, such as bare-metal servers, as well as virtual machines, and associated configuration resources. The definitions may be in a version control system. It can use either scripts or declarative definitions, rather than manual processes, but the term is more often used to promote declarative approaches.

Types of Approaches

There are generally two approaches to IaC: declarative (functional) vs. imperative (procedural).

The difference between the declarative and the imperative approach is essentially ‘what‘ versus ‘how‘ .

The declarative approach focuses on what the eventual target configuration should be
The imperative focuses on how the infrastructure is to be changed to meet this.

The declarative approach defines the desired state and the system executes what needs to happen to achieve that desired state.

Imperative defines specific commands that need to be executed in the appropriate order to end with the desired conclusion.


There are two methods of IaC: ‘push‘ and ‘pull‘ .

The main difference is the manner in which the servers are told how to be configured. In the pull method the server to be configured will pull its configuration from the controlling server. In the push method the controlling server pushes the configuration to the destination system.

CCA Tools ( Continuous Configuration Automation Tools)

ChefPullDeclarative and imperative
OtterPushDeclarative and imperative
SaltStackPull and PushDeclarative and imperative
Ansible / Ansible TowerPushDeclarative and imperative
Notable CCA tools
Ansible and Ansible Tower highlighted in Bold as This Episode focuses on those two

To be Able to Continue We have to see very briefly What is DevOps?

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.

DevOps is complementary with Agile software development, several DevOps aspects came from Agile methodology.

CCA Tools Relationship to DevOps

IaC can be a key attribute of enabling best practices in DevOps – Developers become more involved in defining configuration and Ops teams get involved earlier in the development process.Tools that utilize IaC bring visibility to the state and configuration of servers and ultimately provide the visibility to users within the enterprise, aiming to bring teams together to maximize their efforts.Automation in general aims to take the confusion and error-prone aspect of manual processes and make it more efficient, and productive. Allowing for better software and applications to be created with flexibility, less downtime, and an overall cost effective way for the company. IaC is intended to reduce the complexity that kills efficiency out of manual configuration. Automation and collaboration are considered central points in DevOps; Infrastructure automation tools are often included as components of a DevOps toolchain.

What is Ansible?

Ansible is an open-source software provisioning, configuration management, and application-deployment tool enabling infrastructure as code.It runs on many Unix-like systems, and can configure both Unix-like systems as well as Microsoft Windows. It includes its own declarative language to describe system configuration. Ansible was written by Michael DeHaan and acquired by Red Hat in 2015. Ansible is agentless, temporarily connecting remotely via SSH or Windows Remote Management (allowing remote PowerShell execution) to do its tasks.

The term “ansible” was coined by Ursula K. Le Guin in her 1966 novel Rocannon’s World and refers to fictional instantaneous communication systems.

The Ansible tool was developed by Michael DeHaan, the author of the provisioning server application Cobbler and co-author of the Fedora Unified Network Controller (Func) framework for remote administration.

Ansible, Inc. (originally AnsibleWorks, Inc.) was the company set up to commercially support and sponsor Ansible.Red Hat acquired Ansible in October 2015.

Ansible is included as part of the Fedora distribution of Linux, owned by Red Hat, and is also available for Red Hat Enterprise Linux, CentOS, openSUSE, SUSE Linux Enterprise, Debian, Ubuntu, Scientific Linux, and Oracle Linux via Extra Packages for Enterprise Linux (EPEL), as well as for other operating systems

Unlike most configuration-management software, Ansible does not require a single controlling machine where orchestration begins. Ansible works against multiple systems in your infrastructure by selecting portions of Ansible’s inventory, stored as edit-able, version-able ASCII text files.

Not only is this inventory configurable, but you can also use multiple inventory files at the same time and pull inventory from dynamic or cloud sources or different formats (YAML, INI, etc)

Any machine with Ansible utilities installed can leverage a set of files/directories to orchestrate other nodes. The absence of a central-server requirement greatly simplifies disaster-recovery planning.

Nodes are managed by this controlling machine – typically over SSH. The controlling machine describes the location of nodes through its inventory. Sensitive data can be stored in encrypted files using Ansible Vault since 2014.

In contrast with other popular configuration-management software — such as Chef, Puppet, and CFEngine — Ansible uses an agentless architecture with Ansible software not normally running or even installed on the controlled node.

Instead, Ansible orchestrates a node by installing and running modules on the node temporarily via SSH. For the duration of an orchestration task, a process running the module communicates with the controlling machine with a JSON-based protocol via its standard input and output.

When Ansible is not managing a node, it does not consume resources on the node because no daemons are executing or software installed.

Design goals

The design goals of Ansible include:

  • Minimal in nature. Management systems should not impose additional dependencies on the environment.
  • Consistent. With Ansible one should be able to create consistent environments.
  • Secure. Ansible does not deploy agents to nodes. Only OpenSSH and Python are required on the managed nodes.
  • Highly reliable. When carefully written, an Ansible playbook can be idempotent, to prevent unexpected side-effects on the managed systems. It is entirely possible to have a poorly written playbook that is not idempotent.
  • Minimal learning required. Playbooks use an easy and descriptive language based on YAML and Jinja templates.


Modules are mostly standalone and can be written in a standard scripting language (such as Python, Perl, Ruby, Bash, etc.). One of the guiding properties of modules is idempotency, which means that even if an operation is repeated multiple times (e.g., upon recovery from an outage), it will always place the system into the same state.

Inventory configuration

The Inventory is a description of the nodes that can be accessed by Ansible. By default, the Inventory is described by a configuration file, in INI or YAML format whose default location is in /etc/ansible/hosts. The configuration file lists either the IP address or hostname of each node that is accessible by Ansible. In addition, nodes can be assigned to groups.

An example inventory:


This configuration file specifies three nodes: the first node is specified by an IP address and the latter two nodes are specified by hostnames. Additionally, the latter two nodes are grouped under the webservers group.

Ansible can also use a custom Dynamic Inventory script, which can dynamically pull data from a different system and supports groups of groups.


Playbooks are YAML files that express configurations, deployment, and orchestration in Ansible and allow Ansible to perform operations on managed nodes. Each Playbook maps a group of hosts to a set of roles. Each role is represented by calls to Ansible tasks.


- hosts: webservers
    http_port: 80
    max_clients: 200
  remote_user: root
  - name: ensure apache is at the latest version
      name: httpd
      state: latest
  - name: write the apache config file
      src: /srv/httpd.j2
      dest: /etc/httpd.conf
    - restart apache
  - name: ensure apache is running
      name: httpd
      state: started
    - name: restart apache
        name: httpd
        state: restarted

Ansible Tower

Ansible Tower is a REST API, web service, and web-based console designed to make Ansible more usable for IT teams with members of different technical proficiencies and skill sets. It is a hub for automation tasks. Tower is a commercial product supported by Red Hat, Inc. but derived from AWX upstream project, which is open source since September 2017.

There is also another open source alternative to Tower, Semaphore, written in Go.

Red Hat’s Ansible Tower


Semaphor ( Ansible Tower Open Source Alternative)


Infrastructure as a code


AnsibleFest 2020 (13-14. October 2020)