Roles, templates, Galaxy and Vault

Why roles

A playbook for one web server is fine. When you have nginx, PostgreSQL, monitoring agents and user accounts, across many projects, one long file becomes hard to read and impossible to reuse. A role is a folder with a fixed layout that bundles everything for one job, such as "nginx" or "postgres". A playbook then just lists the roles a group of hosts needs.

The role layout

roles/nginx/
  tasks/main.yml        # the tasks (entry point)
  handlers/main.yml     # handlers, e.g. Reload nginx
  templates/            # Jinja2 templates, e.g. site.conf.j2
  files/                # plain files copied as they are
  vars/main.yml         # role variables (high priority, rarely overridden)
  defaults/main.yml     # default variables (lowest priority, meant to be overridden)
  meta/main.yml         # author, supported platforms, dependencies on other roles

---
- name: Web servers
  hosts: web
  become: true
  roles:
    - common
    - nginx
    - role: node_exporter
      vars:
        node_exporter_port: 9100

Jinja2 templates

Ansible templates use Jinja2, a template language. {{ name }} inserts a variable. {% for %} and {% if %} add loops and conditions. Filters change a value with a pipe, for example {{ port | default(80) }} or {{ name | upper }}. Template files usually end in .j2.

# templates/site.conf.j2
server {
    listen {{ http_port | default(80) }};
    server_name {{ site_name }};
    root /var/www/{{ site_name }};

{% for path in blocked_paths %}
    location {{ path }} { deny all; }
{% endfor %}
{% if enable_gzip %}
    gzip on;
{% endif %}
}

Ansible Galaxy and collections

Ansible Galaxy (galaxy.ansible.com) is a public hub where people share roles and collections. A collection is a package that bundles modules, roles and plugins under a namespace, for example community.general, amazon.aws or community.postgresql. That is why module names look like amazon.aws.ec2_instance.

ansible-galaxy collection install community.general
ansible-galaxy install -r requirements.yml     # install everything listed in a file
ansible-galaxy role init roles/nginx            # create a new role skeleton

Ansible Vault for secrets

Playbooks need secrets: database passwords, API keys, TLS private keys. Never commit them in plain text. Ansible Vault encrypts a whole file, or a single string, with a password (AES-256). The encrypted file can live in Git; Ansible decrypts it in memory when the playbook runs.

ansible-vault create group_vars/db/vault.yml    # create a new encrypted file
ansible-vault encrypt secrets.yml               # encrypt an existing file
ansible-vault edit group_vars/db/vault.yml      # edit it (decrypts in a temporary editor)
ansible-vault view group_vars/db/vault.yml
ansible-vault encrypt_string 'S3cret!' --name 'db_password'   # encrypt one value to paste into YAML
ansible-playbook site.yml --ask-vault-pass                     # or --vault-password-file ~/.vault_pass

A common pattern: group_vars/db/vars.yml holds db_password: "{{ vault_db_password }}" in plain text, and group_vars/db/vault.yml (encrypted) holds vault_db_password. Anyone reading the code can see which variables exist, but not their values.

Testing roles with Molecule

Molecule is a testing tool for roles. It creates a test machine (often a container), applies the role, runs it a second time to check idempotency (no changes expected), runs checks, and then destroys the machine. molecule test runs the whole sequence. It catches broken roles before they reach real servers.

Ansible and Terraform together

They work together: Terraform creates the servers and outputs their IP addresses, and Ansible (using a dynamic inventory plugin that asks the cloud for hosts, or an inventory generated from Terraform outputs) configures them. Each tool can do a little of the other's job, but each is best at its own.

AWX and Ansible Automation Platform

Running playbooks from laptops does not scale for a big team. AWX (open source) and Red Hat Ansible Automation Platform (the commercial product built from it) add a web UI and API, role-based access, stored credentials, schedules and a log of every run. Teams use them so that, for example, the support team can run an approved "restart app" job without having SSH access.

Common mistakes