Ansible Automation Guide

Automate configuration management, application deployment, and IT orchestration with Ansible — agentless, YAML-based, and works over plain SSH with no agents required.

What is Ansible?

Ansible is an open-source IT automation tool created in 2012 and maintained by Red Hat. It automates configuration management, application deployment, cloud provisioning, and orchestration across Linux, Windows, network devices, and cloud platforms. Unlike agent-based tools, Ansible requires no software on managed nodes — it connects over SSH, pushes small Python modules, executes them, and cleans up. Everything is described in human-readable YAML files called playbooks.

Ansible's simplicity is its greatest strength. A sysadmin who knows SSH and YAML can write their first working playbook within minutes. Ansible is idempotent by design — running a playbook multiple times produces the same result, making it safe to apply repeatedly. It is used by organizations from single-server projects to global enterprises managing hundreds of thousands of nodes with Ansible Automation Platform (AWX/Tower).

Key Features

• Agentless architecture — SSH and Python only, no agent to install or maintain on managed nodes
• YAML playbooks — human-readable, version-controlled, self-documenting automation code
• Roles — reusable, shareable task collections with standard directory layout (tasks/, handlers/, templates/, vars/)
• Dynamic inventory — pull host lists from AWS EC2, GCP, Azure, or any API at runtime
• Handlers — event-driven tasks that fire once at end of play when notified by changed tasks
• Ansible Vault — encrypt secrets at rest, decrypt transparently at runtime
• Jinja2 templates — dynamically generate config files with variables and filters
• AWX / Automation Platform — web UI, RBAC, scheduling, and REST API on top of Ansible core

Inventory File

# inventory/hosts.ini
[web]
web1.example.com ansible_user=ubuntu
web2.example.com ansible_user=ubuntu

[db]
db1.example.com ansible_user=postgres ansible_port=2222

[production:children]
web
db

[production:vars]
ansible_ssh_private_key_file=~/.ssh/prod_key
env=production

Example Playbook

# site.yml
- name: Configure web servers
  hosts: web
  become: true
  vars:
    nginx_port: 80
    app_user: www-data

  pre_tasks:
    - name: Update apt cache
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: Deploy nginx configuration
      ansible.builtin.template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        owner: root
        group: root
        mode: '0644'
      notify: Restart nginx

    - name: Ensure nginx is enabled and started
      ansible.builtin.systemd:
        name: nginx
        state: started
        enabled: true

    - name: Deploy application code
      ansible.builtin.git:
        repo: https://github.com/example/app.git
        dest: /var/www/app
        version: "{{ app_version | default('main') }}"
      notify: Restart app service

  handlers:
    - name: Restart nginx
      ansible.builtin.systemd:
        name: nginx
        state: restarted

    - name: Restart app service
      ansible.builtin.systemd:
        name: myapp
        state: restarted

Jinja2 Template Example

{# templates/nginx.conf.j2 #}
worker_processes {{ ansible_processor_vcpus }};

events {
    worker_connections 1024;
}

http {
    server {
        listen {{ nginx_port }};
        server_name {{ inventory_hostname }};
        root /var/www/{{ app_name | default('app') }};

        {% if ssl_enabled | default(false) %}
        listen 443 ssl;
        ssl_certificate /etc/ssl/certs/{{ inventory_hostname }}.crt;
        ssl_certificate_key /etc/ssl/private/{{ inventory_hostname }}.key;
        {% endif %}

        location / {
            proxy_pass http://127.0.0.1:{{ app_port | default(3000) }};
            proxy_set_header Host $host;
        }
    }
}

Ansible vs Configuration Management Alternatives

Use Cases

• Server provisioning and baseline configuration (packages, users, SSH keys, firewall rules)
• Application deployment pipelines with zero-downtime rolling updates
• Network device automation (Cisco IOS, Juniper, Arista via network modules)
• Cloud provisioning and multi-tier application orchestration across AWS/GCP/Azure
• Security hardening and compliance enforcement via CIS benchmark playbooks
• Disaster recovery automation — fully reproducible environment restoration from playbooks

Pros and Cons