The Problem Before the Tool

Scenario: Twelve servers were built by hand over three years. Four have a different timezone, two have an old TLS setting nobody remembers changing, and the newest one is missing a firewall rule. Nobody can say what is on any of them without logging in and looking.

New words, in plain English

• Server - a computer that runs a service for other computers - a web server, a database, a load balancer.
• Configuration - every setting, file, package and service that makes a server behave the way it does.
• Configuration drift - the slow, invisible divergence of machines that were supposed to be identical.
• Configuration management - keeping many machines in a known, written-down, repeatable state - automatically.

Logging into a machine and editing files works exactly once, for exactly one machine, and only while you remember what you did. It does not survive holidays, staff changes, or a rebuild at 3 AM. Configuration management replaces that with a written description of how a machine should be, plus a tool that makes reality match the description.

The key mental shift is from steps to state. A shell script says "run these commands in this order". A configuration-management tool says "this package must be installed, this file must contain this text, this service must be running" - and works out for itself whether anything needs doing. That difference is what lets you safely run the same automation a hundred times.

Ansible is one such tool. Its distinguishing choice is that it installs nothing permanent on the machines it manages.

Analogy: A shell script is a recipe you follow blindly - it will happily crack a second egg into an already-finished omelette. Configuration management is a photograph of the finished dish: the cook looks at what is on the plate and only does the work that is still missing.

A worked example

# The same intent, expressed as desired state rather than as steps.
# Read it as: "after this runs, these three things must be true."
- name: A web server should look like this
  hosts: webservers
  tasks:
    - name: The config file has the right content
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf

    - name: The service is running
      ansible.builtin.service:
        name: nginx
        state: started

In production the payoff is not "typing less". It is that the description lives in version control, so a change to a server becomes a pull request someone reviews; a rebuilt machine comes back identical; and "what is on that box?" has an answer you can read instead of an expedition you have to mount.

Configuration management does not replace judgment, and it does not make a bad design good. What it does is make the current design visible, repeatable and reviewable - which is usually the difference between an outage that takes ten minutes and one that takes ten hours.

Tip: If you can only remember one sentence from this whole track: describe the destination, not the journey.

Goal: Put this to work in the ansible-inventory-groups lab. Open /labs/ansible, pick ansible-inventory-groups, and fix the real broken project - Ansible really does SSH into four managed hosts and converge them.