Ansible
Ansible is an agentless automation tool. It connects to machines over SSH or WinRM, runs small units of work called modules, and reports what changed. There is no agent to install on managed hosts and no server to stand up before the first playbook runs. That low floor is a big part of why it spread so widely. Today it handles configuration management, application deployment, ad hoc operations across fleets, and orchestration of multi-step changes. The module ecosystem covers most of what a platform team touches: package managers, services, files and templates, cloud APIs, network devices. Playbooks are YAML, which keeps them readable in review, and most modules are idempotent, so a playbook can run repeatedly and only act when a host drifts from the described state. Red Hat maintains the project, collections package third-party content, and AWX or the Automation Platform add scheduling and RBAC when a team outgrows the CLI.
The Terraform question comes up in almost every Ansible conversation, and the split is cleaner than the debates suggest. Terraform provisions infrastructure: it creates cloud resources, tracks them in a state file, and computes a plan before it changes anything. Ansible configures what already exists: it installs packages, writes config files, restarts services, and enforces settings inside machines. Ansible keeps no state file; each run inspects the hosts and converges them toward the playbook. The common pattern uses both tools. Terraform brings up the instances, networks, and load balancers, then Ansible turns blank machines into working ones. Ansible can also provision cloud resources directly, and one of the guides below covers where that works and where the lack of state becomes a problem.
>>> Ansible still has a place as a core automation backbone tool by shifting from simple script execution to AI-assisted playbook generation, event-driven self-healing workflows, and tight cooperative orchestration alongside Terraform in multi-cloud environments.
Everything linked on this page is mine. I wrote all seventeen guides for Spacelift between 2022 and 2026, covering the tool from first playbook to CI/CD integration. Each link below goes to a short commentary post on this site, and every one of those posts carries the outbound link to the full article. The sections follow the order I would learn the tool in. Start here covers the four fundamentals: the tutorial, playbooks, inventory, and variables. Read those in order and you can automate real work the same week. Day-2 techniques collects the features that keep playbooks maintainable once they grow: roles, modules, templates, Vault, blocks, and the shell escape hatch. Ansible in context steps back to the decisions around the tool: practices, use cases, how it compares with the alternatives, and how it runs against AWS and inside GitHub Actions.
>>> Most of the blogs are still relevant today as they discuss the Ansible primitives but worth noting that Ansible has shifted from a monolithic package to a modular ecosystem split into ansible-core and independent Ansible Content Collections. This decoupling allows modules to update independently from the base engine.Architectural & Ecosystem ShiftsCollections: Modules and plugins are separated from the core runtime into independent namespaces. Fully Qualified Collection Names (FQCN): Short plugin names are deprecated in favor of explicit paths (e.g., ansible.builtin.template).Execution Environments: Container-based images package playbooks, dependencies, and collections for portable execution.
Start here
- Ansible Tutorial for Beginners: Playbook & Examples
Concepts, installation, ad hoc commands and a first playbook, with a demo environment to follow along.
- Ansible Playbooks: Complete Guide with Examples
Playbook structure end to end: variables, handlers, conditionals and loops, each with a runnable example.
- Working with Ansible Inventory - Basics and Examples
Groups, host variables, multiple sources and dynamic inventories, plus layouts that scale with a fleet.
- Ansible Variables: How to Use Different Types of Ansible Variables
Variable types, lists and dicts, registered results and the precedence order that explains most bugs.
Day-2 techniques
- Ansible Roles: Basics, Creating & Using
Why roles exist, the directory anatomy, creating and sharing them, and how collections fit in.
- Ansible Modules - How To Use Them Efficiently (Examples)
The modules worth memorizing, usage patterns and building your own when the built-ins run out.
- How to Create Ansible Template [Examples]
Jinja2 templating: how the template module generates per-host config files inside a playbook.
- Ansible Vault: How to Securely Encrypt Sensitive Data
Encrypting files and strings, password management options, and the rotation habits that keep secrets out of git.
- How to Use Blocks in Ansible Playbooks
Grouping tasks under shared conditionals and privilege, plus rescue and always for real error handling.
- Using Ansible Shell Module to Execute Remote Commands
When shell is justified, how it differs from command, and keeping such tasks idempotent.
Ansible in context
- 50+ Ansible Best Practices to Follow [Tips & Tricks]
The reference list I still point people at: structure, playbooks, variables, roles, execution and security habits.
- 7 Ansible Use Cases - Management & Automation Examples
Seven jobs Ansible does well, from provisioning and config management to security baselines and orchestrated updates.
- Configuration Management with Ansible
The job Ansible was built for, with the comparison against Chef, Puppet and Salt that still decides tool choices.
- Infrastructure as Code with Ansible: Tutorial
Ansible as a provisioning tool: where it fits, its limits, and a worked example creating AWS resources.
- Using Ansible to Automate AWS [Tutorial]
The AWS collection setup, dynamic inventory for hosts that come and go, and a worked tutorial.
- Ansible with GitHub Actions: Automating Playbook Runs
A step-by-step pipeline for playbook runs, with the secrets handling that makes it safe.
- Ansible vs. Jenkins - Key Differences and Comparison
What each tool is for, where they genuinely overlap, and how they work well together in one pipeline.