// THE REBEL BLOG

Thoughts on free software, privacy, and taking back control

2026-03-148 min readDevOps

Ansible: Configuration Management Without the Headache

You've got ten servers. Then twenty. Then fifty. Each one needs the same packages, the same configurations, the same security updates. SSH'ing into each one manually? That's not scaling—that's suffering.

This is where Ansible comes in. Born in 2012 and acquired by Red Hat in 2015, Ansible is an open-source automation tool that handles configuration management, application deployment, and orchestration. And unlike many DevOps tools, it's refreshingly simple to learn.

Why Ansible?

1. Agentless

Here's Ansible's killer feature: it doesn't require installing agents on your managed nodes. Need to configure a new server? Just have SSH access. That's it. No additional software, no daemons running, no agent updates to manage.

2. YAML-Based

Playbooks—the scripts that define your automation—are written in YAML. If you can read English, you can read Ansible playbooks. No domain-specific programming languages to learn, no complex syntax to memorize.

3. Idempotent

Fancy word, simple concept: running the same playbook twice should produce the same result. Ansible checks the current state before making changes. If a package is already installed, it skips it. If a config file already has the right content, it doesn't rewrite it. This makes playbooks safe to run repeatedly.

4. Huge Ecosystem

Thousands of modules exist for everything: managing packages, services, files, cloud resources, containers, databases. Chances are, if you need to automate it, someone has already written a module for it.

How It Works

Ansible follows a simple model:

  • Control Node: The machine where Ansible runs (your laptop, a CI server, a dedicated management host)
  • Managed Nodes: The servers you want to configure (accessed via SSH)
  • Inventory: A list of managed nodes, optionally organized into groups
  • Modules: Units of work (install package, create user, copy file)
  • Playbooks: YAML files defining what to do

A Simple Example

Want to ensure Nginx is installed and running on a list of web servers? Here's your entire playbook:

---
- name: Configure web servers
  hosts: webservers
  become: yes
  
  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: present
      
    - name: Ensure Nginx is running
      service:
        name: nginx
        state: started
        enabled: yes

Run it with ansible-playbook webservers.yml, and Ansible connects to every server in the "webservers" group, installs Nginx, and ensures it's running and enabled at boot.

Core Concepts

Inventory

Define your servers in a file (INI or YAML format):

[webservers]
web01.example.com
web02.example.com
web03.example.com

[dbservers]
db01.example.com

[webservers:vars]
ansible_user=admin

Modules

Modules are the building blocks. Ansible ships with hundreds of built-in modules. Common ones include:

  • apt/yum – package management
  • service – manage services
  • copy/template – file distribution
  • file – file attributes
  • command/shell – run commands
  • user/group – manage users

Tasks

Tasks are the smallest unit of action. Each task calls a module with specific parameters:

tasks:
  - name: Install Python
    apt:
      name: python3
      state: present

Handlers

Handlers are tasks that only run when notified. Use them for things that should only happen on changes:

tasks:
  - name: Copy Nginx config
    copy:
      src: nginx.conf
      dest: /etc/nginx/nginx.conf
    notify: restart Nginx

handlers:
  - name: restart Nginx
    service:
      name: nginx
      state: restarted

Variables

Make your playbooks reusable with variables:

---
- name: Deploy web app
  hosts: webservers
  vars:
    app_port: 8080
    app_user: www-data
  
  tasks:
    - name: Create app user
      user:
        name: "{{ app_user }}"

Roles: Organizing Complex Playbooks

As your automation grows, cramming everything into one playbook becomes unmanageable. Enter roles—a way to organize playbooks into reusable structures:

roles/
  common/
    tasks/
      main.yml
    handlers/
      main.yml
    templates/
    files/
  nginx/
    tasks/
      main.yml
    templates/
  mysql/
    tasks/
      main.yml

Each role handles one piece of infrastructure. Combine them in a playbook:

---
- name: Configure web server
  hosts: webservers
  become: yes
  
  roles:
    - common
    - nginx
    - mysql
Roles are to Ansible what functions are to programming—reusable, composable, testable.

Real-World Use Cases

Server Provisioning

Spin up a new VM, then run an Ansible playbook to configure it: install packages, set up users, configure SSH, harden security, deploy applications. From bare metal to production-ready in minutes.

Configuration Drift Correction

Servers tend to drift over time—someone manually edits a config, a package gets updated unexpectedly. Run Ansible regularly to ensure all servers match your desired state.

Application Deployment

Deploy new versions of your application across all servers with a single command. Roll back just as easily by pointing to a previous version.

Disaster Recovery

Lost a server? Rebuild it from scratch with Ansible. Your playbooks serve as documentation of exactly how each server should be configured.

Multi-Environment Management

Same playbook, different variables for dev, staging, production. Ansible's inventory and variable system makes it easy to manage multiple environments with the same code.

Ansible vs. Terraform

A common question: should I use Ansible or Terraform? The short answer: both.

  • Terraform is for infrastructure provisioning—creating cloud resources, networks, VMs
  • Ansible is for configuration management—installing software, configuring apps, managing state on existing servers

Use Terraform to create your servers, then use Ansible to configure them. They complement each other perfectly.

Getting Started

Ready to try Ansible? Here's your path:

  1. Install Ansiblepip install ansible or use your system's package manager
  2. Create an inventory – List some servers you want to manage
  3. Test connectivityansible all -m ping
  4. Write your first playbook – Something simple, like installing a package
  5. Add more tasks – Build up complexity gradually
  6. Organize with roles – Refactor into roles as playbooks grow

Start with one server. Practice the basics. Then scale up. You'll never go back to manual configuration.

The Bottom Line

Ansible strips away the complexity of configuration management. No agents to install, no steep learning curve, no vendor lock-in. Just SSH, YAML, and the satisfaction of infrastructure that reproduces itself.

Whether you're managing five servers or five thousand, Ansible lets you treat your infrastructure as code. Define desired state, apply it consistently, sleep better at night.

Your servers deserve better than manual SSH. Automate all the things.

// Comments

Leave a Comment