What Ansible is

Ansible is an open source automation platform. It is two things at once: a simple automation language for describing infrastructure in files called playbooks, and an automation engine that runs those playbooks.

Describe what makes Ansible simple, powerful and agentless.
List Ansible's main strengths and typical use cases.
Explain the design goals behind "the Ansible way".

Three properties that define Ansible

Playbooks are readable text. You do not need to be a programmer to write one, and tasks run in the order they are written, so a playbook reads like a procedure.

The same tool handles configuration management, application deployment, workflow automation and network automation, and can orchestrate a whole application lifecycle.

Nothing to install on managed hosts. Ansible connects over OpenSSH (Linux) or WinRM (Windows), pushes small programs, runs them, and cleans up.

The agentless design matters more than it first appears. Because there is no agent to install, approve, patch or secure on every host, you can start automating immediately, and there is less infrastructure to attack or maintain.

Strengths worth knowing

Cross-platform. Linux, Windows, UNIX and network devices, on physical, virtual, cloud and container platforms.
Human-readable automation. Playbooks are YAML text files that anyone on the team can read.
Precise descriptions. Every aspect of an environment can be described, and therefore documented, in a playbook.
Version-control friendly. Playbooks and projects are plain text, so they live happily in Git.
Dynamic inventories. The list of managed hosts can be pulled live from external sources such as a cloud provider or Red Hat Satellite.
Orchestration. Ansible integrates with other tools you already run (Jenkins, Puppet, Satellite, HP SA and so on).

The language of DevOps

Communication is at the heart of DevOps. Because a playbook can be read by developers, testers, operators, managers and outside contractors alike, it becomes a shared language across the whole application lifecycle.

Ansible across the application lifecycle: Every team reads the same human-readable playbook, from development through to production.

The Ansible way

Ansible was designed around a few goals. Keep them in mind when you write your own playbooks; they explain a lot of Ansible's behaviour.

Simpler is better. Ansible's tools are deliberately simple to use, and your automation should be simple to read and write too. Strive for the plainest playbook that does the job.

Well-written playbooks document your workflow. A reader should be able to tell what a play does without running it.

Ansible is a desired-state engine. You describe the state you want (the package is installed, the service is running) rather than the commands to get there. Ansible makes only the changes needed to reach that state. Treating Ansible as a scripting language fights its design.

dnf install -y httpd
systemctl start httpd
systemctl enable httpd

Runs every command every time, whether or not it is needed.

- ansible.builtin.dnf:
    name: httpd
    state: present
- ansible.builtin.service:
    name: httpd
    state: started
    enabled: true

States the goal. Changes only what is not already true.

What people use Ansible for

Ansible combines several kinds of automation that other tools often split apart:

Centralising configuration files and settings and deploying them consistently. This is how most people meet Ansible first.Defining an application in playbooks and deploying it through every environment, from development to production.Bringing up systems: PXE-booting and kickstarting bare metal, or creating VMs and cloud instances from templates.Driving CI/CD pipelines, so applications stay correctly deployed through their whole lifecycle.Scanning for and remediating security issues as part of normal automation rather than as an afterthought.Coordinating how many separate configurations interact, so the environment is managed as one whole.

What does it mean to say Ansible is a **desired-state engine**?

Takeaway

Describe what makes Ansible simple, powerful and agentless. Use the chapter lab to check this on a real host.