Introduction to Ansible

Why do teams choose Ansible instead of distributing configurations manually via SSH? This module explains the agentless architecture: Control Node, Managed Nodes, Inventory and Modules working together. You will understand the difference between push- and pull-based tools and be able to assess when Ansible is the better choice over Terraform, Puppet or Chef.

You install ansible-core on your control node and set up the SSH connection to multiple managed nodes. You configure SSH key authentication, test the connection with ansible -m ping and adapt ansible.cfg to your environment. By the end of this block you will have a working Ansible environment with three managed hosts.

A clean inventory is the foundation of every automation effort. You create inventories in INI and YAML format, group hosts by function (e.g. webservers, databases) and define host and group variables. Then you work with nested groups and see how variables can be organised through group_vars/ and host_vars/ directories.

Before writing playbooks, you use Ansible for quick interventions: with ad-hoc commands you install packages via ansible -m apt, manage services with the service module and copy files to all hosts simultaneously. You learn the principle of idempotency and use ansible-doc to discover which modules are available and how their parameters work.

From syntax to your first working result: you learn the YAML basics (indentation, lists, dictionaries) and write your first playbook. The playbook updates packages, creates a user and deploys a configuration file. You run it with ansible-playbook and observe the output: changed, ok and failed explained in detail.

Ansible offers multiple ways to use data in playbooks. You work with the variable hierarchy (inventory, playbook, role, extra-vars) and understand which level takes precedence. Using the setup module you collect facts about your hosts (OS, IP addresses, memory) and store task results in registers for later decisions.

Not every task should run on every host. With when conditions you control which tasks execute under which circumstances (e.g. only on Debian systems). Loops with loop save you from duplicating tasks for multiple packages or users. Handlers ensure that services only restart when something actually changed. Finally, you use block and rescue for structured error handling.

Static configuration files break when hostnames, IPs or ports differ between environments. With Jinja2 templates you create dynamic configurations: insert variables with {{ }}, iterate lists with {% for %} and transform values with filters like default, join or upper. You build an Nginx configuration template that automatically adapts to each host.

Passwords and API keys do not belong in plain text in your repository. With Ansible Vault you encrypt individual variables or entire files using ansible-vault encrypt. You work with vault IDs for different passwords per environment and integrate Vault into your playbook execution with --ask-vault-pass and password files.

All building blocks from today come together: you write a playbook that installs Nginx, distributes a configuration via Jinja2 template, sets firewall rules with the ufw module and starts the service. Variables control port and server name, a handler restarts Nginx only when the configuration changes. At the end a working web server runs on your managed nodes.

As playbooks grow, structure becomes essential. You create your first Ansible role with ansible-galaxy init and understand the directory layout: tasks/, templates/, handlers/, defaults/ and vars/. Then you refactor yesterday's web server playbook into a reusable role and define role dependencies to manage relationships between roles.

Not everything needs to be written from scratch. On Ansible Galaxy you find community roles for common tasks and integrate them via requirements.yml. You learn the difference between roles and collections (the modern package format since Ansible 2.10) and install a collection with ansible-galaxy collection install. Finally, you check which collections already ship with ansible-core.

Automation needs quality assurance. You configure ansible-lint and see which rules catch typical mistakes (e.g. missing name attributes, deprecated syntax). With --check and --diff you dry-run playbooks before they touch real hosts. Finally, you set up a simple lint check that can be integrated into a CI pipeline.

The workshop's final project: you deploy a three-tier application across multiple hosts. One role installs the database (PostgreSQL), a second one the application server and a third the load balancer (Nginx). Inventory groups, variables and templates from the past days come together. At the end a complete stack runs that you can reproduce with a single ansible-playbook command.

What comes after the basics? This module provides an overview of AWX as a web UI and REST API for Ansible, Execution Environments as containerised runtime environments (the successor to Python virtualenvs) and integrating Ansible into CI/CD pipelines with GitLab CI or GitHub Actions. You get guidance on which of these topics are relevant for your automation journey.