Ansible for Cloud Server Configuration

After the Instance Exists, Something Has to Keep It Right

Provisioning creates machines. Bootstrapping sets them up once. Neither answers the question that arrives a month later: are all eleven servers still configured the way we think they are?

Configuration management tools answer that question by describing the desired state of the inside of a machine and re-applying it whenever you ask. Ansible is the most approachable of them, largely because it refuses to install anything on the servers it manages.

This guide is aimed at someone who already has cloud instances running and has been keeping them in shape with a folder of shell scripts and good intentions.

Agentless, and Why That Matters Here

Ansible runs from your workstation or a build runner. It opens an SSH connection to each target, copies small Python modules across, executes them, collects the results and removes them. There is no daemon on the server and no certificate authority to operate.

For cloud fleets that property is worth a lot. A newly created instance is manageable the instant SSH accepts your key, with no enrolment step and nothing to reinstall when you rebuild it. It also means the tool adds no attack surface to the machines themselves.

The trade off is that a run takes as long as the slowest host, and that the control machine needs network reach to everything. For a few dozen servers this is a non issue. At several hundred, forks and pipelining become settings you actually tune.

Requirements are modest: Python on the targets, which every mainstream server image already has, and SSH access using the same keys you use interactively. Key hygiene is covered in SSH keys for cloud servers.

Inventory: Naming the Machines

An inventory lists hosts and arranges them into groups. The simplest version is an INI or YAML file in the repository, with groups such as web, db and staging. Group membership is what lets one playbook behave differently per tier.

Hand maintained inventories rot quickly in a cloud environment where instances come and go. Ansible solves this with dynamic inventory plugins that query a provider API and build the host list at run time, tagging hosts by region, label or tag so your groups stay accurate without edits.

Plugins exist for the major platforms and for most developer clouds. Configure one with a small YAML file and confirm it works before writing any tasks.

ansible-inventory -i inventory.linode.yml --graph

Group variables live in a group_vars directory keyed by group name, host specific values in host_vars. Getting that layout right early saves a painful refactor later, because it is where environment differences belong.

A Playbook, Read Top to Bottom

A playbook is YAML describing plays, each of which targets a group and lists tasks. Tasks call modules, and modules are where the real work happens.

- hosts: web become: true tasks: - name: Install nginx ansible.builtin.package: name=nginx state=present

Notice what is absent. There is no check for whether nginx is already installed, no branching on the distribution's package manager, and no error handling for a second run. The module owns all of that.

Templates are the other workhorse. The template module renders a Jinja2 file with your variables and copies it into place, and it can notify a handler so the service reloads only when the rendered content actually changed.

- name: Deploy site config ansible.builtin.template: src=site.conf.j2 dest=/etc/nginx/conf.d/site.conf notify: reload nginx

That notify line is the pattern worth internalising. Handlers run once at the end of a play, no matter how many tasks notified them, so a run that changes three config files triggers exactly one reload.

Idempotence Is a Property You Have to Earn

A correct playbook produces changes on the first run and reports nothing changed on the second. That signal is genuinely useful: a run that reports changes on an unmodified fleet is telling you a task is lying about its state.

Most built in modules are idempotent already. The exception is command and shell, which run whatever you give them every time. Whenever you reach for them, add a guard with creates, removes or a when condition derived from an earlier fact.

Treat every shell task as a small piece of technical debt. If you have twenty of them, you have written a shell script with extra YAML around it, and you have none of the reporting the tool exists to provide.

Roles, Reuse and Where Secrets Go

Once a playbook passes a couple of hundred lines, split it into roles. A role is a directory with a fixed layout, holding tasks, handlers, templates, files and default variables for one coherent responsibility such as "base hardening" or "postgres client".

Roles are consumed by name, which makes a top level playbook read like a description of the system rather than a list of instructions. Shared roles can be pulled from a requirements file, though vetting third party code that runs as root on every server deserves the same scrutiny as any other dependency.

Secrets need a deliberate answer. Ansible Vault encrypts variable files at rest so they can live in the repository, with the key supplied at run time. It is a reasonable baseline, but a managed secret store is better once more than one system needs the same value, for reasons set out in managing API keys and secrets in cloud projects.

The official Ansible playbook guide documents the role layout, variable precedence and the full module index.

Running It Against Real Servers Without Fear

Three habits make the difference between a tool you trust and one you avoid.

First, roll changes out in slices. The --limit flag restricts a run to one host or group, and serial in a play processes a batch at a time so a bad change reaches two servers instead of forty.

Second, run it regularly, not only when something is broken. A playbook applied once a day keeps drift measured in hours. A playbook applied twice a year is a script whose assumptions have quietly expired.

Third, decide the boundary with your provisioning tool and keep it. Creating the instance, its firewall and its DNS belongs to infrastructure as code with Terraform. Getting the machine to the point where SSH works belongs to cloud-init. Everything after that is Ansible's.

The approach is provider neutral by design, which suits mixed estates. If you are assembling one, the Linode account listings describe what such an account includes, and the DigitalOcean versus Linode comparison covers how their APIs differ where a dynamic inventory plugin has to read them.

Questions Newcomers Ask