Ansible Trainer in Pune

Why the push model is the one that clears a change advisory board. What actually happens on a managed host during a run, what is left behind afterwards, and how that compares with a pull model that must be versioned, patched and trusted permanently. Includes an honest account of where agentless is the weaker answer.

Topics: What a run does on the target host, step by step · Push versus pull, and what each asks of the host owner · Why no resident process changes the security conversation · Architecture: control node, inventory, modules, plugins, connection layer · Terminology used precisely — play, playbook, task, handler, role, collection · Where continuous enforcement makes a pull-based tool the better choice

• Assignments: (1) Write the paragraph a change board would need in order to approve an agentless tool on a production-adjacent host; (2) List every artefact a single run leaves behind on a managed host
• Capstone: Produce a one-page architecture note recommending for or against Ansible on a named estate

Connectivity is where most first weeks are lost, and almost none of it is the automation's fault. Key and password SSH, a bastion in the path, connection plugins and timeouts, then the full Windows route — listener configuration, HTTP against HTTPS, NTLM, Kerberos and CredSSP — followed by privilege escalation on both platforms.

Topics: SSH with keys, agents, known_hosts and a jump host in the path · ansible.cfg, connection plugins, timeouts and pipelining · become, become_user and become_method under a restricted sudoers policy · WinRM listeners, ports and certificate validation · Windows authentication: NTLM, Kerberos and CredSSP · Reading a connection failure and deciding whose problem it is

• Assignments: (1) Reach a Windows Server host over WinRM with Kerberos and prove it with win_ping; (2) Configure a non-root automation account that can escalate for only the tasks it needs
• Capstone: Document a connectivity and escalation model a security reviewer would sign off

The design decision that determines whether automation stays maintainable when the hostnames were invented by somebody else. Inventory as a directory rather than a file, groups and groups of groups, host and group variable layout, behavioural parameters, and dynamic sources from a cloud account or a read-only asset register.

Topics: Inventory as a directory, and the order files are loaded in · Groups, groups of groups and the patterns that select them · host_vars and group_vars layout, precedence and naming · Behavioural inventory parameters per host and per group · Dynamic inventory plugins, caching and constructed groups · Mapping an undocumented naming convention onto groups you can target

• Assignments: (1) Restructure a flat three-hundred-line inventory into a directory layout; (2) Build constructed groups from gathered facts rather than from hostnames
• Capstone: Design an inventory covering three environments and two operating systems on a customer-owned estate

Before playbooks, the single-task run — the fastest way to answer a question about a fleet and the safest way to learn how targeting, modules and privilege interact. It is also the right tool during an incident, when a full playbook is more ceremony than the moment allows.

Topics: One task on one host, then a group, then a pattern · Choosing a module from the command line · Verbosity levels and reading module output as JSON · Fact gathering on demand and fact subsets · Ad-hoc runs against Windows targets · Recognising the point where an ad-hoc command should become a playbook

• Assignments: (1) Audit package versions across a mixed fleet using ad-hoc commands only; (2) Collect a fact subset from every host and produce a comparison table
• Capstone: Assemble an ad-hoc runbook answering six recurring operational questions

From a single play to something you would attach to a change ticket. Play targeting and ordering, the result contract every module returns, then the safety machinery: check mode, diff output, tags, limits, step and start-at-task, and serial execution sized to the window you were actually given.

Topics: Play targeting, ordering and the run of tasks · Check mode, and which modules honour it faithfully · Diff output read as a predicted change set · Tags, limits, step mode and start-at-task · serial, max_fail_percentage and rolling behaviour · Idempotency in practice, and the modules that quietly are not

• Assignments: (1) Convert an ad-hoc runbook into a playbook that reports no change on a clean second run; (2) Produce check-mode and diff output in a form a change record can carry
• Capstone: Automate a full service build and prove idempotency by running it three times

The modules that appear in almost every real play, on both sides of a mixed estate. Files, packages, services, users and scheduled tasks on Linux, their Windows counterparts, and the recurring judgement call between a purpose-built module and command, shell, raw or script.

Topics: file, copy, template, lineinfile and blockinfile · package, yum, apt and dnf against win_package and chocolatey · service and systemd against win_service · user, group, cron and win_scheduled_task · command, shell, raw and script — and when each is defensible · Registry, feature and update modules on Windows Server

• Assignments: (1) Replace every shell task in a supplied playbook with a proper module; (2) Build a baseline role that applies cleanly to both a RHEL and a Windows host
• Capstone: Deliver a hardened base-host playbook that runs on both operating systems from one code path

Most surprising behaviour is a precedence question in disguise. Every place a variable can be defined, the order in which they override one another, registered results, prompts and extra variables, gathered and custom facts, and fact caching when gathering is expensive across a slow link to a remote site.

Topics: Variable sources and the full precedence order · Registered variables and exactly when they are set · vars_prompt, extra variables and command-line overrides · Gathered facts, subsets and gather_timeout · Custom facts and fact caching · set_fact against defaults against vars, and why the difference matters

• Assignments: (1) Debug a playbook where the wrong value wins, and explain the precedence rule that caused it; (2) Parameterise a role so one code path serves three environments
• Capstone: Build a single playbook that behaves correctly across three customer environments by variables alone

The constructs that separate engineering from scripting. Conditionals, loops and loop control, blocks with rescue and always, handlers and flush_handlers, include against import, lookups, and Jinja2 filters and tests — then failed_when, changed_when and controlled failure, because automation is judged on how it behaves when something is wrong.

Topics: when, loop, loop_control and until with retries · Blocks, rescue and always · Handlers, notify, listen and flush_handlers · include_tasks against import_tasks, and what that costs tags · Lookups, filters, tests and the map and select family · failed_when, changed_when, ignore_errors and the retry file

• Assignments: (1) Add rescue and always behaviour to a deployment that can fail halfway through; (2) Template a configuration file that differs correctly across environments and both operating systems
• Capstone: Build a rolling deployment with a rescue path, break it deliberately, and prove the recovery

Structuring automation so another team can consume it without reading it. Role layout, defaults against vars, dependencies and duplication rules, the search path — then collections as the distribution unit, with namespaces, versions, requirements files and resolution from a private hub when there is no outbound path to Galaxy.

Topics: Role directory structure and what belongs in each folder · defaults, vars, meta and dependency behaviour · Role duplication, allow_duplicates and the role search path · Collections: namespaces, structure and versioning · requirements.yml and pinning content versions · Consuming collections inside an estate with no route to the public index

• Assignments: (1) Refactor a four-hundred-line playbook into three composable roles; (2) Package those roles into a collection and install it from a local source
• Capstone: Publish an internal collection with pinned versions and a consumer playbook that uses it unchanged

Handling secrets inside the workflow when the credential belongs to somebody else and expires on a date you do not control. Encrypting whole files and single values, multiple vault identities for different audiences, where the vault password lives once a pipeline is running the play, and rotation without a coordinated outage.

Topics: Creating, editing, viewing, rekeying and decrypting vault content · encrypt_string for single values inside a readable file · Vault identities and labels for multiple audiences · Where the vault password lives in a pipeline or an automation server · Separating secret from non-secret variables cleanly · Rotation procedure, offboarding, and proving old material is gone · Reading from an external secret store with a lookup instead

• Assignments: (1) Encrypt one environment's credentials and run against them from a pipeline; (2) Rotate a vault key across a repository that already has history
• Capstone: Design a secrets workflow that survives rotation, an engineer leaving, and an automation server rebuild

Nobody should discover a bug on a host attached to a production line. Lint and syntax gates on merge, Molecule scenarios against containers or virtual machines, assertion-based verification, a staging inventory that genuinely mirrors the target, and a rollback path that is itself automated and tested.

Topics: ansible-lint and yamllint as merge gates · Molecule scenarios, drivers and the converge and verify cycle · Assertions and idempotence checks in verification · A staging inventory that mirrors production rather than approximating it · Writing and testing a rollback path · What evidence to capture from a rehearsal run

• Assignments: (1) Add a Molecule scenario that fails on a deliberately non-idempotent task; (2) Automate the rollback for a role and test it in isolation
• Capstone: Take a role through lint, Molecule and a staging run, and produce the evidence pack for a change window

Turning working playbooks into something another team can run safely without shell access or a copy of the repository. Projects wired to source control, job templates and surveys, credential types and injection, inventory sources, role-based access, workflow templates with approval nodes, and logging an auditor will accept.

Topics: Installing and configuring AWX or Automation controller · Projects, inventory sources and scheduled synchronisation · Job templates, surveys and credential injection · Organisations, teams and role-based access · Workflow templates, approval nodes and convergence · Logging, external aggregation, backup and restore

• Assignments: (1) Publish a job template with a survey a team that has never written a playbook can run; (2) Add an approval node so a production job pauses for a named approver
• Capstone: Hand an application team a self-service workflow they can run unaided, with a complete audit trail