What Ansible Is and Why You Should Use It

In this series we learn Ansible from the ground up to advanced topics — to the point of writing your own module and designing a project the best-practice way. The hands-on parts have real code, practiced on an EC2 server. Before installing anything, this article explains what Ansible is and why it's worth learning.

The problem: configuring many servers

You have one server: SSH in, install software, edit configs, start the service — by hand. Fine. Now you have ten servers, then a hundred. Doing it by hand is impossible: it's slow, error-prone, and each machine slowly drifts apart (this is called configuration drift). "Why is server #7 broken?" — because someone edited it by hand differently from the rest.

Write a bash script to automate it? Better, but a script is hard to make safe to run repeatedly: running an nginx-install script twice may error out, or you have to write all the "is it already installed?" checks yourself. And bash scripts are hard to read and hard to reuse as the system grows.

Configuration management is the answer: describe the desired state of the system declaratively, then let the tool bring every machine to that state. Ansible is one of the most popular tools for this.

What Ansible is

Ansible is an automation tool: you write out the desired state ("nginx must be installed and running", "this config file must have that content") in YAML files called playbooks, then Ansible applies them across many servers at once.

Two characteristics define Ansible — and they're the two most important keywords of the whole series:

1. Agentless (no agent to install)

Many tools of the same kind (Chef, Puppet) need an agent running in the background on every managed machine. Ansible does not: it connects to the target machine over the existing SSH (and Python already present on the target) to execute. You only install Ansible on one control node; the targets don't need anything extra.

The practical upshot: you get started very fast (no agent to deploy everywhere), and there's no extra background service to maintain/secure on the targets. This is the single biggest reason Ansible is popular.

2. Idempotent (safe to run repeatedly)

Idempotent means running an operation multiple times gives the same result as running it once. Ansible describes the desired state, not the steps: you say "nginx must be installed", not "run apt install nginx". When it runs:

• If nginx is not installed → Ansible installs it (reports changed).
• If nginx is already installed → Ansible does nothing (reports ok).

Running a playbook ten times in a row is safe — it only changes what isn't yet in the desired state. This is the core difference from a bash script, and it's the property that lets you re-run a playbook anytime without worry. We dig deep into idempotency in Article 5.

Core concepts

Five concepts you'll meet constantly:

• Control node — the machine where Ansible is installed and where you run commands. (Your laptop, or a CI server.)
• Managed node (host) — the target machine Ansible manages, connected over SSH.
• Inventory — the list of hosts and how they're grouped (Article 3).
• Module — the unit of work Ansible executes (install a package, copy a file, manage a service...). Ansible ships thousands of modules; you can also write your own (Article 10).
• Task — a single call to a module with specific parameters.
• Playbook — a YAML file gathering tasks to apply to hosts (Article 4).
• Role — a way to package playbooks/variables/templates into a reusable unit (Article 8).

The relationship: you write a playbook of many tasks, each task calls a module, applied to the hosts in the inventory, from the control node over SSH.

Why learn Ansible

• Ubiquitous in DevOps: the de facto standard for configuring servers, deploying applications, automating operations.
• Easy to start: YAML reads like English, and being agentless means no infrastructure to stand up.
• Complements other skills from earlier series: configuring EC2 (AWS series), preparing hosts to run Docker (Docker series), automating away SSH/hand-written scripts (Linux series).

Hands-on: repo and server

This series leans heavily on practice. Two things come with it:

• Sample code (playbooks, roles, custom modules, a best-practice project) is kept at github.com/nghiadaulau/ansible-series — clone it to reference and follow along.
• Practice server: we use an EC2 (set up in Article 2) as a managed node for Ansible to manage for real. At the end of the series we delete it (the cleanup habit from the AWS series — to avoid running up a bill).

Series roadmap

Fundamentals:

1. Ansible architecture — control node, inventory, module, SSH; exactly what happens when you run a playbook (a deep dive into the execution mechanism).
2. Installation and your first ad-hoc commands — set up a control node + EC2, run the ping module.
3. Inventory — hosts, groups, variables, static and dynamic inventory.
4. Playbook — YAML structure, plays, tasks; run your first playbook.
5. Modules and idempotency — how a module executes internally, and why it's idempotent.
6. Variables, facts and templates — variables, gathering facts, Jinja2, precedence order.
7. Handlers, loops, conditionals — notify, loops, conditions, block/rescue.

Organization and extension:

1. Roles — packaging reusable code.
2. Ansible Galaxy and Collections — modern packaging/distribution, FQCN.
3. Ansible Vault — managing secrets safely.
4. Writing custom modules — write your own module in Python.
5. Extending Ansible: filter, lookup, callback plugins — extensibility beyond modules.

Advanced and best practices:

1. Optimization and execution strategies — strategy, delegation, serial/rolling update, async, check mode, tags.
2. Testing with Molecule — test roles properly using containers.
3. Best practices — project structure, role design, ansible-lint.
4. A complete project + wrap-up — put it all together, clean up the EC2, where to go next.

What you need

• A machine to act as the control node (Article 2 installs Ansible). Ansible runs on Linux/macOS; on Windows use WSL.
• Familiarity with the command line and SSH (recall Linux series Article 14) — Ansible connects to hosts over SSH.
• An AWS account to stand up a practice EC2 (or any Linux machine you can SSH into).

Nothing to do after this article yet. Article 1 goes into the architecture: exactly what Ansible does when you run a playbook, and why "agentless over SSH" matters.