Enterprise Ansible Automation Training

An in-house training series I designed and delivered at Dynasafe to accelerate Ansible adoption across the engineering team. The curriculum progresses from the fundamentals — agentless SSH + idempotency — through Playbook structure, control flow, and templating, to the production-grade workloads the team actually needed: ELK Stack bring-up and OpenShift (OCP) environment operations.

Audience: Internal engineers with mixed backgrounds — some with Linux operations experience, some application developers with no prior infrastructure-as-code exposure. The course was designed to be accessible to beginners while still leading experienced engineers toward enterprise-grade automation practices.

Format: 6 sessions · 9+ hours of recorded video · original lesson slides · hands-on labs on VirtualBox VMs · a written style guide enforced by ansible-lint.

Delivery Language: Mandarin Chinese.

Solo course designer and instructor:

• Authored the full curriculum from scratch, including learning objectives for each session
• Built reproducible VirtualBox lab environments with one controller and two managed nodes so trainees could reproduce every lab in a contained setup
• Produced all slides, lab handouts, and sample Playbooks
• Recorded and narrated all 6 video sessions (9+ hours total)
• Introduced ansible-lint as a required quality check for lab submissions — non-lint-clean labs were returned for revision before review
• Ran live Q&A sessions and code reviews during the rollout

1. Mixed Skill Levels in the Audience

Some trainees had years of Linux operations experience; others were application developers who had never written YAML. Pacing the curriculum so the first group didn't lose interest and the second didn't drown was the central pedagogical problem.

2. Abstract Concepts Need Concrete Hands

"Idempotency" is easy to define but hard to feel. Loop variable scoping, handler firing conditions, and changed_when semantics all have subtleties that slides cannot convey — trainees only internalize them after running something and watching behavior.

3. Environment Reproducibility

In previous training attempts at the company, half the class would get stuck on environment setup issues (SSH key, sudo, firewall) before writing a single line of Ansible. That completely killed flow.

4. Bridging to Real Client Work

The final session needed to show trainees how the abstract material becomes the real automation they would be writing at work — not another generic "install nginx" lab.

Layered Curriculum with Escape Hatches

Each session has a "core" track (everyone must understand) and optional deep-dive sections (labeled as such). Beginners can skip the deep-dives initially and come back; experienced trainees get enough substance to stay engaged. Every session ends with one hands-on lab that exercises the core track only.

Hands-on From Session One

Every session includes a matching lab. Rather than putting all labs at the end, they are interleaved with the concepts so trainees immediately see ansible all -m ping work across their VirtualBox nodes, see idempotency in practice by re-running the same Playbook, and watch loops expand in real time.

Prebuilt VM Images + Verification Script

I distributed pre-baked VirtualBox images with SSH keys already trusted between the controller and the two managed nodes, plus a single setup script to verify the environment. This eliminated the most common environment-setup failures before trainees wrote their first Playbook.

OpenShift Environment Comparison Capstone

Session 6 walks through a tool I had actually written for client work — an OpenShift environment comparison script that uses K8s modules, environment-switching login, and set operations (difference / intersect) over large configuration dumps. Trainees see how every concept from the earlier sessions appears in a real deliverable.

ansible-lint as a Required Standard

Lab submissions have to be lint-clean. This front-loads the discipline of writing maintainable Playbooks and avoids the "works on my machine but looks terrible" habit that plagues self-taught Ansible users.

Training Delivery

• 6 sessions · 9+ hours of recorded video · original slides and labs
• Reproducible VirtualBox lab environment (Controller + 2 Nodes)
• Introduced ansible-lint-enforced style guide adopted by the team

Team Impact

• Team members onboarded to internal Ansible-based automation workflows
• ansible-lint discipline carried over into production Role repos after training
• Material reused afterward for new-hire onboarding — recordings watched independently

Scope Covered

• Agentless architecture & idempotency fundamentals
• Ad-hoc commands, Vault, Playbooks, control flow, templating, Roles
• Real-world: ELK Stack automation, OCP environment tooling

Teaching Forces You to Structure What You Know

I could "use Ansible" before designing this course. Having to explain why changed_when matters, when a handler actually fires, and how Role variable precedence resolves forced me to close gaps in my own understanding. The curriculum made me a better practitioner, not just a better teacher.

Labs That Mirror Real Work Stick

The OCP comparison capstone took more time to adapt for trainees than any other session, but it was the one trainees referenced months later when they started writing their own Ansible code. "Toy" labs don't stick; labs that look like the work they will actually do, do.

ansible-lint From Day One, Not Day Thirty

Every team that "will clean up the lint warnings later" ships a codebase with hundreds of lint warnings. Making lint-clean a submission requirement in training meant trainees never developed the bad habit in the first place.

Recorded Training Became a Reusable Asset

Live training is engaging but ephemeral. Recording every session meant the material became an ongoing asset — new hires months later received the same structured walkthrough without me having to re-run the course.