Ansible Trainer

The problem before the tool. Why server configuration drifts, what breaks when it does, and how the major approaches differ. Ansible's architecture and execution model, and an honest comparison against Chef and Puppet — including where Ansible is the wrong answer.

Topics: Configuration management problems and solutions · What Ansible is and its benefits · Ansible vs Chef vs Puppet · Ansible architecture and execution model · Core terminology · How Ansible works over SSH

• Assignments: (1) Map an existing manual server build to an automation plan; (2) Document three drift risks in a real environment
• Capstone: Produce an architecture note arguing for or against Ansible for a specific estate

YAML as Ansible uses it — the subset that matters and the whitespace traps that cause most first-week failures. Setting up a working development environment, then the objects everything else is built from: modules, plays, playbooks, inventory and configuration.

Topics: YAML syntax and common pitfalls · Ansible development environment setup · Modules, plays and playbooks · ansible.cfg and configuration precedence · Inventory basics · Command-line entry points

• Assignments: (1) Set up a working control node and two managed hosts; (2) Fix a set of deliberately broken YAML files
• Capstone: Build a reproducible lab environment you keep for the rest of the course

How Ansible actually connects, and how to make that work in environments with real security constraints. Password and key-based SSH, connecting as another user, privilege escalation, and the connectivity failures that look like Ansible bugs but are not.

Topics: SSH with password · SSH with keys · Connecting as another user · Passwordless and agent-based connections · Privilege escalation with become · Diagnosing connection failures

• Assignments: (1) Configure key-based access across the lab fleet; (2) Set up privilege escalation for a non-root automation account
• Capstone: Document a connectivity model suitable for a security-reviewed environment

Before playbooks, the command line. Running a single task against one host, then many, then a group — the fastest way to build an accurate mental model of how modules, inventory and targeting interact.

Topics: One task on localhost · One task on a remote host · Multiple hosts via inventory · Targeting inventory groups · Choosing modules from the command line · Output formats and verbosity

• Assignments: (1) Perform a fleet-wide audit using only ad-hoc commands; (2) Patch a package across a host group
• Capstone: Build an ad-hoc runbook for five common operational tasks

The part that decides whether an Ansible estate stays maintainable. Static inventory, groups and groups of groups, behavioural parameters, splitting inventory across a directory, and dynamic inventory sourced from cloud providers.

Topics: Inventory groups · Groups of groups · Behavioural inventory parameters · Inventory directories and splitting · host_vars and group_vars layout · Dynamic inventory from cloud providers

• Assignments: (1) Restructure a flat inventory into a scalable layout; (2) Wire up a dynamic inventory against a cloud account
• Capstone: Design an inventory for a multi-environment, multi-region estate

From a single play to a structured playbook. Targeting, tasks, ordering and execution against local and remote hosts — plus the check-mode and diff workflow that makes running against production defensible.

Topics: Writing a play using modules · Playbook structure and ordering · Running against local and remote hosts · Check mode and dry runs · Diff output · Limiting and tagging runs

• Assignments: (1) Convert an ad-hoc runbook into a playbook; (2) Add check-mode safety to an existing playbook
• Capstone: Automate a complete service build from bare host to running application

The modules that appear in almost every real playbook, and the differences that matter: when command is wrong and shell is right, why raw exists, and how file, copy, template, service and the package modules behave when the target state is already met.

Topics: setup, command, shell, raw and script · file, copy and mount · user, group and cron · apt, yum and the generic package module · service and systemd · git, mail and SELinux modules

• Assignments: (1) Replace shell tasks with proper modules across a playbook; (2) Build a user and permissions baseline role
• Capstone: Produce a hardened base-server playbook using only idempotent modules

Where variables come from, and which one wins. Playbook variables, external files, included vars, registered results, prompts, command-line overrides, inventory host and group vars, and gathered facts — with the precedence order that explains most surprising behaviour.

Topics: Playbook and external file variables · Registered variables · Prompted and command-line variables · host_vars and group_vars · Gathered facts and custom facts · Variable precedence order

• Assignments: (1) Debug a playbook where the wrong variable value wins; (2) Parameterise a role using defaults and overrides
• Capstone: Build a single playbook that behaves correctly across three environments by variables alone

The constructs that turn scripts into engineering: handlers, conditionals, loops, blocks, includes versus imports, lookups, and Jinja2 templating. Then error handling and troubleshooting, because production automation is judged on how it fails.

Topics: Handlers and notification · Conditionals and loops · Blocks, rescue and always · Includes vs imports · Lookups · Jinja2 templating, filters and tests · Error handling and troubleshooting

• Assignments: (1) Add rescue behaviour to a failure-prone deployment; (2) Template a configuration file across environments
• Capstone: Build a zero-downtime rolling deployment with proper failure handling

Structuring automation so it can be shared. Role directory layout, defaults and dependencies, execution and duplication rules, the role search path, and embedding modules and plugins. Then Ansible Galaxy for publishing and consuming roles.

Topics: Role directory structure · Role defaults and variables · Role dependencies and duplication · Role search path · Embedding modules and plugins in roles · Galaxy: search, install, create, publish

• Assignments: (1) Refactor a monolithic playbook into composable roles; (2) Publish a role and consume it from another project
• Capstone: Build an internal role library with dependencies and versioning

Handling credentials inside the automation workflow instead of alongside it. Creating, editing, viewing, rekeying and decrypting encrypted content, and the practical question of where the vault password itself lives in CI.

Topics: Vault use cases · Creating and editing encrypted files · Viewing and decrypting · Rekeying and rotation · Encrypting existing files · Vault passwords in CI pipelines

• Assignments: (1) Encrypt an environment's credentials and run against them; (2) Rotate a vault key across a repository
• Capstone: Design a secrets workflow that survives key rotation and CI automation

Operating Ansible for an organisation rather than an individual. Tower/AWX installation, organisations, projects, job templates, inventories, LDAP and Kerberos authentication, logging and backup. Then integrations with Docker, AWS and Azure, and writing custom modules and plugins when nothing existing fits.

Topics: Tower installation and configuration · Organisations, projects and job templates · Tower inventories and imports · LDAP and Kerberos authentication · Logging, aggregation and backup · tower-cli · Ansible with Docker, AWS and Azure · Developing custom modules and plugins

• Assignments: (1) Stand up Tower/AWX and publish a job template; (2) Write a custom module and call it from a playbook
• Capstone: Deliver a self-service automation platform an application team could use unaided