What is Ansible?
Updated: 3 days ago
Ansible is an open-source IT automation platform used to configure servers, deploy applications, manage systems and coordinate repeatable operational tasks. It commonly connects from a control node to managed Linux and Unix machines over SSH, while Windows hosts can be managed through WinRM, PSRP or supported SSH configurations. It is often called agentless because it normally does not require a persistent Ansible-specific agent installed on each target.
Ansible playbooks express tasks in YAML. Modules perform the work, inventory identifies managed systems, and roles and collections organise reusable automation. Unlike Terraform, which primarily provisions infrastructure using providers and state, Ansible often focuses on configuration and operational tasks.
The infographic below shows the Ansible workflow, from playbooks and remote connections to repeatable infrastructure changes.
How does Ansible work?
Ansible reads an inventory and playbook on a control node, selects target hosts and executes tasks through connection plugins. Modules typically run on managed systems or interact with APIs, returning results such as whether a change was made or an error occurred.
Define the target hosts and groups in an inventory.
Write a playbook with plays, tasks and modules.
Authenticate using SSH keys, WinRM or another supported method.
Run the playbook and review task results.
Repeat the playbook to maintain the intended configuration.
Execution order, privilege escalation, concurrency, handlers and task conditions influence what happens. A successful run does not prove every application-level outcome is correct.
What are Ansible playbooks?
Playbooks are YAML documents describing plays that target groups of hosts and run ordered tasks. Tasks call modules, such as ansible.builtin.apt, ansible.builtin.copy and ansible.builtin.service, with arguments describing the intended operation.
YAML indentation is significant. Playbooks can contain variables, conditional expressions, loops, tags and error handling. A playbook is not simply a shell script written in YAML.
What are inventory, modules, roles and collections?
Inventory identifies hosts, groups and connection variables. Modules implement individual actions, such as managing a package, user or service. Roles package tasks, variables, handlers, templates and files for reuse. Collections distribute modules, plugins and roles.
Dynamic inventory plugins can retrieve current hosts from cloud services. Treat inventory variables and secrets carefully, particularly when repositories are shared.
Is Ansible really agentless?
In common SSH-based management, Ansible does not require a continuously running Ansible agent on each managed host. However, it still needs compatible remote access and may require Python on managed POSIX systems for many modules. Some modules and connection methods have different requirements.
Windows uses Windows-specific modules and commonly WinRM or PSRP. SSH is also supported for suitable Windows versions and configurations. Agentless does not mean zero prerequisites or zero security considerations.
Ansible vs Terraform
Terraform primarily defines and manages infrastructure resources through provider APIs and state. Ansible primarily coordinates automation tasks and configuration changes through modules and connection plugins. Both can create cloud resources and both can be part of Infrastructure as Code.
A common workflow provisions virtual machines and networks with Terraform, then uses Ansible to configure operating systems, install packages and deploy services. The tools overlap but are not interchangeable.
Ansible vs Kubernetes and Docker
Docker packages and runs containers. Kubernetes schedules and reconciles container workloads across a cluster. Ansible can install container runtimes, prepare nodes, deploy configuration and call Kubernetes APIs through suitable modules.
Kubernetes continuously maintains declared workload state, whereas an ordinary Ansible playbook runs when invoked. Scheduled or event-driven Ansible automation can provide repeated execution, but this is not identical to Kubernetes reconciliation.
Idempotency and configuration drift
An idempotent task aims to leave the system in the same desired state when run repeatedly. Many Ansible modules support this behaviour, but arbitrary shell commands and poorly designed tasks may not.
Ansible does not automatically monitor every host for drift. Repeated playbook runs can restore specified settings, but changes outside the playbook and failures between runs still need monitoring and operational controls.
Check mode, diff mode and handlers
Check mode uses the --check flag to simulate supported changes. Diff mode can show before and after differences for compatible modules. Not all modules support these modes completely, and check mode is not a guarantee that a later real run will succeed.
Handlers are tasks triggered by notifications, commonly to restart a service only after a configuration file changes. Their execution timing and notifications should be understood before using them for production rollouts.
Ansible for network automation
Ansible can automate compatible switches, routers, firewalls and network services using vendor or community collections and APIs. Network device automation may use network_cli, netconf, httpapi or other connection methods rather than ordinary Linux SSH modules.
Always verify device firmware support, command behaviour and rollback options. A network configuration error can interrupt the very connectivity required to repair it.
Security and Ansible Vault
Use least-privilege accounts, protect SSH keys and remote-management credentials, and restrict privilege escalation. Ansible Vault can encrypt sensitive files or variables at rest, but decrypted values still need careful handling during execution.
Use no_log where appropriate to avoid exposing secrets in task output. Validate third-party collections, pin dependencies where practical and audit changes.
Ansible in a home lab
A home lab with several Linux virtual machines or physical servers is a useful environment for learning Ansible. Inventory groups can represent test servers, network appliances and application hosts. Start with package updates or service configuration before automating risky changes.
Use a management network or secure VPN for remote access. A public IP address is not required when the control node can reach hosts through a private network.
How UK broadband affects remote Ansible
Ansible task execution often involves relatively small command and response messages, so network latency and reliability may matter more than headline download speed for simple remote configuration tasks. Large file copies, software packages and backups can make throughput more important.
Remote access can be affected by CGNAT, firewalls, VPN configuration and upload bandwidth. A secure outbound management connection or VPN is usually preferable to exposing SSH or WinRM directly to the internet.
Techie Broadband calculation: transferring a 1 GB package
A decimal 1 GB package contains 8 gigabits. At a theoretical 20 Mbps sustained upload rate, transferring the entire package requires at least 400 seconds, or 6 minutes 40 seconds. At 100 Mbps, the theoretical minimum is 80 seconds. At 500 Mbps, it is 16 seconds.
Real transfers take longer due to overhead, congestion, remote storage and processing. Ansible may instead instruct a server to download the package directly from a repository, so this calculation applies only when the full package crosses the specified connection.
Common Ansible errors
Unreachable hosts: verify DNS, routing, SSH or WinRM connectivity and firewall rules.
Authentication failures: check credentials, keys, remote accounts and privilege escalation.
Missing Python or modules: check managed-node prerequisites and collections.
Undefined variables: inspect variable names, precedence and inventory.
YAML errors: check indentation and task syntax.
Tasks report changed every run: review idempotency and module choice.
Partial failures: inspect which hosts and tasks completed before retrying.
How to troubleshoot an Ansible playbook
Run a syntax check and inspect inventory targeting.
Test connectivity to one affected host using the appropriate connection plugin.
Run with increased verbosity without exposing credentials.
Inspect the failing module, arguments and returned message.
Check permissions, privilege escalation and required dependencies.
Use check and diff modes where supported to understand proposed changes.
Test on a small subset of hosts before rerunning broadly.
Review results and verify the actual application or device state.
Ansible FAQs
Is Ansible free to use?
Ansible Core is open source and can be used without a software licence fee. Commercial offerings such as Red Hat Ansible Automation Platform provide additional enterprise capabilities, support and management services. Running Ansible still incurs costs for infrastructure, staff time and any paid external services.
Does Ansible require Python on every server?
Not universally. Many standard Linux and Unix modules require a compatible Python environment on managed nodes, but some operations can use raw commands or other connection mechanisms. Windows modules typically use PowerShell and have different requirements. Always check the specific module and platform support.
Can Ansible manage Windows computers?
Yes. Ansible supports Windows management through WinRM, PSRP and supported SSH configurations. Windows-specific modules are used for many tasks because ordinary POSIX Python modules are not generally appropriate. Authentication, remoting configuration and permissions must be set up correctly.
What is the difference between Ansible and Terraform?
Terraform is primarily designed to provision and manage infrastructure resources through provider APIs and state tracking. Ansible commonly automates configuration, application deployment and operational tasks through modules and remote connections. Both can interact with cloud services and may be used together in a deployment pipeline.
Does Ansible automatically detect configuration drift?
Not continuously by default. A playbook can compare a host's state with the declared task arguments when it runs and can correct supported differences. However, an ordinary playbook does not monitor all hosts in real time. Scheduled runs, monitoring and reporting are needed when ongoing drift detection matters.
Can Ansible work without an internet connection?
Yes, when the control node can reach its managed systems and required modules, collections and dependencies are available locally. Internet access may be needed to install collections or packages or to call public cloud APIs. The necessary connectivity depends on the particular automation tasks.
Key takeaway
Ansible makes repeatable infrastructure and application administration easier through YAML playbooks, inventories and modules. It is especially useful for configuration management and coordinated operational tasks, but reliability depends on sound access controls, testing, appropriate module behaviour and verification of actual results.
To explore the related technical concepts used in this Ansible guide, visit our broadband terminology guide.
