Ansible

What is Ansible?

Ansible (by Red Hat) is a widely-used configuration-management and automation tool. You describe the desired state of your systems — packages, services, files, users, and multi-step operational tasks — in simple YAML files called playbooks, and Ansible connects to your machines and makes it so. Its defining characteristic is that it’s agentless: it pushes changes over standard SSH (or WinRM for Windows), so there’s no agent software to install and maintain on managed hosts — a big reason for its popularity and low barrier to entry compared to agent-based predecessors like Chef and Puppet.

Agentless push, and where it fits

The agentless push model is Ansible’s signature. A control node connects out to target hosts and executes tasks; there’s no persistent agent pulling config on a schedule. This makes Ansible easy to start with (install it in one place, point it at hosts with SSH access) and flexible for ad-hoc automation as well as ongoing configuration — it’s used not just to configure servers but to orchestrate deployments, run operational playbooks, manage network devices, and automate almost any repetitive ops task. Like other config tools it aims to be declarative (describe the end state) and idempotent (running a playbook repeatedly converges to the same state safely, rather than blindly re-running commands) — though because playbooks are task sequences, writing genuinely idempotent playbooks is a discipline, not automatic. Ansible sits in the configuration-management category (configuring software on existing machines), complementary to provisioning tools like Terraform that create the machines in the first place — a common pattern is Terraform to provision, Ansible to configure.

The modern-context caveat and practical realities

The same honest framing that applies to Chef applies here: much of what configuration management traditionally did — configuring long-lived mutable servers over time — is being displaced by immutable infrastructure and containers, where the machine/container image is built fully-configured once and replaced rather than mutated. That said, Ansible has stayed more relevant than heavier agent-based tools because of its breadth: it’s widely used for provisioning-adjacent orchestration, network automation, application deployment, and one-off operational tasks even in container-centric shops, and for the substantial world of VMs, bare metal, appliances, and environments not suited to containers. Practical realities: the push/SSH model can be slower at very large scale than a pull-based agent architecture (managing thousands of hosts sequentially over SSH has limits, mitigated with strategies and tools like AWX/Ansible Automation Platform); playbook idempotency requires care (using proper modules rather than raw shell/command tasks, which aren’t idempotent by default); and secrets must be handled with Ansible Vault or an external secrets manager, never plaintext in playbooks. The recurring mistakes: writing non-idempotent playbooks (peppered with raw shell commands) that aren’t safe to re-run, hardcoding secrets, and reaching for server-configuration automation where an immutable image or container would be simpler and more reliable.

What people get wrong

• Non-idempotent playbooks — leaning on raw shell/command tasks instead of proper modules produces playbooks that aren’t safe to re-run, defeating a core benefit.
• Secrets in playbooks: credentials must go in Ansible Vault or an external secrets manager, not plaintext YAML committed to a repo.
• Configuring servers where immutable images fit — for cloud-native workloads, baking a container/image often beats mutating running hosts; use Ansible where mutable/long-lived or non-container systems genuinely warrant it.

Primary source: Ansible documentation