Ansible Workshop – Overview
Overview
This workshop covers the path from agentless automation fundamentals to secure, reviewable, operations-oriented team usage. Its structure follows the Kubernetes workshop: documentation in docs/, four workshop levels in workshops/, exercises in exercises/, assessments and model solutions in assessments/, runnable examples in examples/, and setup helpers in scripts/.
The workshop focuses on inventories, playbooks, modules, idempotence, roles, collections, Vault, CI checks, controlled rollouts, operations evidence, AWX/Automation Controller orientation, and execution environments.
Quickstart
# Workshop content is provided through the Orthevs Academy.
chmod +x scripts/provision_ansible.sh
./scripts/provision_ansible.sh --dry-run
sudo ./scripts/provision_ansible.sh
ansible --version
Start here:
Audience
The workshop is written for developers with operational responsibility, system engineers, DevOps engineers, platform engineers, SREs, administrators, technical leads, and security engineers.
Learning Path
| Level | Focus | Outcome |
|---|---|---|
| Fundamentals | Control node, inventory, ad-hoc commands, first playbook, modules, handlers, idempotence, check/diff | You can automate small labs safely and validate results. |
| Intermediate | Variables, facts, templates, roles, includes, blocks, Vault basics | You make playbooks maintainable and reusable. |
| Professional | Repository standards, collections, CI, Molecule, orchestration, multiple inventories, runbooks | You operate Ansible as a team and operations model. |
| Advanced + Security | Threat modeling, least privilege, secret flows, supply chain, execution environments, security review | You can assess risks and define safe automation boundaries. |
Structure
Workshop Structure
.
├── assessments/
├── docs/
├── examples/
├── exercises/
├── media/
│ └── pics/
├── scripts/
├── workshops/
├── LICENSE.md
└── README-EN.md
Prerequisites
- Basic Linux, SSH, and YAML knowledge
- Access to a Linux shell with Python 3
- Git and an editor
- Optional: two local test VMs or containers for realistic managed nodes
Working Mode
Verify inventory, scope, syntax, check mode, diff output, execution result, second-run idempotence, and cleanup notes for every meaningful change.
License
Unless stated otherwise, the educational material is licensed under CC BY-NC-SA 4.0. Images and visual media under media/ are excluded and may only be displayed as part of this workshop.
Detailed Orientation
How to Use This Workshop
Do not start with a random playbook. Read the curriculum first, then the matching workshop level, then the example, and only then the exercise. This keeps Ansible from becoming a loose collection of commands. The workshop is a learning path: concepts explain terms, workshops explain flow, examples show small implementations, exercises force your own work, and assessments verify reviewability.
What a Complete Ansible Submission Contains
| Artifact | Purpose |
|---|---|
inventory/hosts.yml |
describe targets, groups, and connection data |
playbooks/site.yml |
declare desired state or diagnostic flow |
roles/ |
encapsulate reusable tasks |
group_vars/ and host_vars/ |
separate data sources and make precedence visible |
collections/requirements.yml |
version external dependencies |
evidence.md |
document scope, check mode, diff, run, and second run |
cleanup.md |
explain cleanup or controlled acceptance of target state |
Minimal Safe Flow
ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Review Questions Before Production-like Usage
- Is the inventory explicit and versioned?
- Are target groups narrower than
all? - Are secrets protected and not logged?
- Is
becomeactive only where needed? - Are collections pinned and reviewed?
- Is the second run idempotent?
- Is rollback or fix-forward realistically described?
- Are monitoring or evidence requirements documented after the run?
Relationship to Other Tools
Ansible does not replace every infrastructure tool. Terraform or OpenTofu are usually better suited for declarative cloud resource provisioning. Kubernetes-native tools are better for running cluster resources. Ansible is strong when existing systems, configuration, services, files, users, network devices, or platform APIs need to be automated in reviewable workflows.
Security Principle
Ansible can execute broad changes with high privileges. The most important security control is therefore not a single tool, but a working model: narrow scope, reviewed credentials, minimal privileges, no real secrets in Git, no secrets in logs, reviewed collections, CI gates, and documented operational approval.