Ansible Trainer in Bangalore

How the pieces actually fit: control node, inventory, connection plugins and the configuration precedence that decides which ansible.cfg is in force. The split between ansible-core and the community package, and why that split changes how you version automation.

Topics: Control node, managed hosts and the SSH execution path · ansible.cfg precedence and the settings worth changing · ansible-core versus the community package · Collections as the unit of distribution · Command-line entry points: ansible, ansible-playbook, ansible-inventory, ansible-doc · Where Ansible is the wrong tool

• Assignments: (1) Audit an existing repository and list every source of configuration precedence in force; (2) Document the connection and privilege path from control node to a production host
• Capstone: Produce a one-page architecture note describing how Ansible is versioned, distributed and executed in your organisation

The design decision that determines whether an estate stays maintainable at five hundred hosts. Static inventory in a directory, groups and groups of groups, host and group variables, and dynamic inventory plugins sourced from cloud accounts.

Topics: Inventory directories, multiple sources and merge behaviour · Groups, groups of groups and behavioural parameters · host_vars and group_vars layout that maps to environments · Host patterns, --limit and targeting mistakes that reach the wrong fleet · Dynamic inventory plugins for AWS, Azure and GCP · Inventory caching and keyed groups

• Assignments: (1) Convert a flat INI inventory into a directory layout with three environments; (2) Wire a dynamic inventory plugin against a cloud account and group hosts by tag
• Capstone: Design an inventory for a multi-environment, multi-region estate and prove targeting with --list-hosts

Writing automation that a change advisory board would sign off. Play structure and ordering, handlers and notification, check mode with diff, tags and limits, serial batching, and the block, rescue and always structure that defines what a partial failure leaves behind.

Topics: Play structure, ordering and pre/post tasks · Handlers, notify, listen and flush_handlers · Check mode, --diff and modules that do not support them · Tags, --limit and --start-at-task · serial, max_fail_percentage and rolling execution · block / rescue / always and deliberate failure handling

• Assignments: (1) Add check-mode safety and tags to an existing production playbook; (2) Convert a failure-prone deployment into a serial rolling update with rescue
• Capstone: Build a zero-downtime rolling deployment and deliberately break it mid-run to prove the rescue path

Where values come from and which one wins. Role defaults, inventory variables, play and task variables, registered results, extra-vars, gathered facts, custom and external facts — and the precedence order that explains almost every surprising Ansible behaviour.

Topics: The full precedence order, worked through in a live example · Role defaults versus role vars · Registered variables, when to use set_fact, and scoping · Gathered facts, custom facts and fact caching · Jinja2 templating, filters, tests and lookups · Debugging with ansible-inventory and --extra-vars

• Assignments: (1) Debug a repository where the wrong variable value wins and explain the rule that caused it; (2) Template one configuration file that behaves correctly across three environments
• Capstone: Parameterise a role so a single codebase serves dev, staging and production through variables alone

Structuring automation so it can be shared and upgraded. Role layout, defaults, dependencies and the search path; then collections — building them, versioning them, pinning them in requirements.yml, and serving them from a private hub rather than the public internet.

Topics: Role directory structure, defaults, meta and dependencies · include_role versus import_role and when the difference matters · Building a collection: galaxy.yml, namespaces and semantic versioning · requirements.yml, pinning and reproducible installs · Private Galaxy hub or artifact repository as the source of truth · Refactoring a monolithic playbook without a big-bang rewrite

• Assignments: (1) Decompose a 400-line playbook into three composable roles; (2) Package roles into a collection, version it and consume it from another repository
• Capstone: Publish an internal collection with pinned dependencies that another team can adopt unaided

Keeping credentials inside the automation workflow instead of beside it. Encrypting files and single values, multiple vault IDs for separate environments, rekeying, and the unattended decryption problem every CI pipeline eventually hits.

Topics: encrypt, decrypt, view, edit and rekey · encrypt_string for single values inside plain files · Multiple vault IDs and per-environment keys · Vault password files, scripts and CI secret stores · Rotation without breaking running pipelines · Where Vault stops and a secrets manager begins

• Assignments: (1) Encrypt one environment's credentials and run a playbook against them unattended; (2) Rotate a vault key across a repository with no downtime
• Capstone: Design a secrets workflow that survives key rotation, CI automation and an auditor's questions

The practice that separates an estate that can be changed from one nobody dares touch. Syntax checking, ansible-lint rule sets, molecule scenarios against containers or cloud instances, and a CI gate that blocks a merge rather than reporting after the fact.

Topics: --syntax-check, --list-tasks and dry-run discipline · ansible-lint profiles and suppressing rules honestly · Molecule scenarios, drivers and the converge/idempotence/verify cycle · Testing idempotency as an assertion, not a hope · Wiring role tests into a CI pipeline · Managing test matrices across OS versions

• Assignments: (1) Add a molecule scenario to an existing role and make the idempotence step pass; (2) Configure a CI job that fails the build on lint violations
• Capstone: Put a role library under lint and molecule tests with a merge gate that a reviewer can trust

Operating Ansible for an organisation rather than yourself. The settings that decide fleet-run duration, then AWX or Tower: projects wired to source control, job templates and surveys, credentials, RBAC, logging and backup — so an application team can run automation without shell access to the control node.

Topics: forks, SSH pipelining and persistent connections · Fact caching and gather_subset · linear, free and host_pinned strategies · AWX/Tower projects, inventories, credentials and job templates · Surveys, workflows and scheduled jobs · RBAC, LDAP integration, logging and backup · Writing a custom module or filter plugin when nothing fits

• Assignments: (1) Reduce a slow fleet-wide run using forks, pipelining and fact caching, and measure the difference; (2) Stand up AWX and publish a job template with a survey for an application team
• Capstone: Deliver a self-service automation workflow another team can run unaided, with RBAC and an audit trail