Configuration Management with Ansible is a course in configuring many servers at once automatically, covering inventories, ad-hoc commands, playbooks, modules, Jinja2 templates, roles, Galaxy and Ansible Vault, with hands-on work across several lab machines. It suits system administrators, DevOps engineers and infrastructure teams who want every server built to the same standard.
Once an organization runs dozens of servers, configuring each one by hand wastes time, creates inconsistency between machines and leaves no audit trail. Ansible solves this by describing the desired state of machines in YAML and bringing every server into that state at once, with no agent to install because it works over existing SSH. This course takes learners from Ansible fundamentals to real organizational use: managing
inventory, running ad-hoc commands, writing playbooks, using the modules that matter for packages, services and files, variables and Jinja2 templates, organizing code into roles, separating dev and production environments, protecting secrets with Ansible Vault, and the idempotency principle that makes repeated runs safe. Every topic is hands-on against several lab machines at once. (2 days, 6 hours per day, 12 hours in total, Intermediate level.)
Course Details
A 2-day course, 6 hours per day (12 hours in total), delivered as lectures with hands-on labs against several machines at once. Intermediate level. Learners take home a lab guide, complete playbook and role samples, and a new-server setup checklist. Ansible is open source and can be used in the organization at no licensing cost.
Section 1: Configuration Management Concepts
The problems with manual configuration: slow, inconsistent and unauditable
How Ansible works: agentless over SSH and the declarative model
Ansible versus provisioning tools such as Terraform, and using them together
The idempotency principle: repeated runs produce the same result
Section 2: Installation and Inventory Management
Installing Ansible on the control node and preparing SSH keys to the targets
Writing file-based inventory, grouping hosts and setting group and host variables
Verifying connectivity and troubleshooting failed connections
Lab: set up the control node and connect to several target machines
Section 3: Ad-hoc Commands
Running one command across many machines without writing a playbook
Using basic modules ad-hoc: ping, command, shell and copy
Targeting hosts with patterns and limiting concurrency
Lab: check status and gather information from all machines with ad-hoc commands
Section 4: Writing Playbooks
Playbook structure: plays, tasks, handlers and readable naming
Using become for privilege escalation and setting the connection user
Dry runs with check mode and reviewing changes with diff
Lab: write a playbook that installs and configures a web server on all targets
Section 5: Modules for Real Work
Managing packages, services, users and groups with standard modules
Managing files, directories, permissions and copying files to targets
Using conditionals (when), loops and error handling
Lab: write a playbook that prepares a new machine against the organization checklist
Section 6: Variables, Facts and Templates
Variable precedence and where to define variables
Using facts gathered from target machines to drive decisions
Generating configuration files with Jinja2 templates tailored per machine
Lab: generate a configuration file from a template that adapts to each host
Section 7: Roles and Code Organization
Standard role structure: tasks, handlers, templates, files, vars and defaults
Refactoring long playbooks into reusable roles
Using roles from Ansible Galaxy and assessing their trustworthiness first
Lab: convert your playbook into a role and reuse it
Section 8: Managing Multiple Environments
Separating inventory and variables across dev, staging and production
Using group_vars and host_vars for environment-specific values
Rolling updates so services do not all restart at once
Lab: run the same playbook against two environments with different settings
Section 9: Security and Ansible Vault
Storing passwords and keys safely with Ansible Vault and encrypting variable files
Least-privilege permissions for the account that runs Ansible
Practices for keeping Ansible code in Git without leaking secrets
Lab: encrypt a secrets file with Vault and consume it from a playbook
Section 10: Production Use and Maintenance
Writing genuinely idempotent playbooks and testing before touching production
Structuring an Ansible project so a team can work on it together
Running Ansible from CI/CD and keeping run logs
Using Ansible with Terraform: provision the machine then configure it immediately
Section 11: Capstone and Next Steps
Capstone: write a playbook set that prepares a new server completely for service
Present your role structure and the reasoning behind the design
A first-30-days plan for adopting Ansible in your organization
Workshop: present your playbooks and review the code together
No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770
Terraform focuses on provisioning infrastructure, such as virtual machines, networks and cloud databases, tracking it in state. Ansible focuses on configuration management inside machines, such as installing packages, editing configuration files and starting services, over SSH without installing an agent. In practice they are often used together: Terraform creates the machines and Ansible configures them straight afterwards.
Idempotency means running a playbook any number of times gives the same result, because Ansible modules check the current state and change only what differs from what you declared. If a package is already installed, it is not reinstalled and the task reports ok rather than changed, so you can safely rerun playbooks to fix drifted machines. Avoid command or shell where a dedicated module exists, as they do not know the existing state.
Start by writing an inventory that puts the web servers in one group, and test connectivity with the ping module. Then write a playbook targeting that group, use become to escalate privileges, and add tasks to install the package, generate the configuration file from a template and enable the service. Use a handler to restart the service only when the configuration changes, and do a check and diff run before running for real.
It suits system administrators who look after many servers, DevOps engineers who want to automate machine configuration, infrastructure teams that want every server built to one standard, and people who create machines with Terraform and need to configure them. You should know basic Linux commands, understand SSH and SSH keys, and be able to read YAML. Programming is not required.
You will be able to write inventories and run ad-hoc commands across many machines, write playbooks that build new servers to your organisation's checklist, generate per-host configuration with Jinja2 templates, organise code into reusable roles, separate settings for dev, staging and production, protect secrets with Ansible Vault, and run Ansible from CI/CD after Terraform. Participants who complete the training receive a Certificate of Completion with its own number, which can be verified online.
Yes. It can be run in-house for your team, with examples adapted to your own work, such as writing playbooks around the server configuration checklist your team already follows. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.
Building and changing infrastructure by hand through a web console creates inconsistency, leaves no audit trail and makes it hard to reproduce an environment. Terraform solves this by expressing infrastructure as code that lives in Git, is reviewed through…
Linux runs behind almost every server, cloud platform and container in use today. Whether you work with Docker, Kubernetes, AWS or Azure, Linux is the foundation you need. This course is designed for system administrators and anyone moving into infrastructure…
