Ansible

Ansible has been the IT automation standard for over a decade. Its promise is simple: describe the desired state of your servers (installed packages, config files, active services) in readable YAML files, and let the tool apply them. No agent to install on target servers: just SSH. For a team managing 5 servers or more, it's the tool that turns manual tinkering into a reproducible process.

• →TerraformFor infrastructure provisioning rather than configuration, often complementaryView page
• →PuppetIf you manage 10,000+ servers where the pull-based agent model becomes relevant
• →ChefIf your team prefers a Ruby DSL over YAML
• →SaltStackIf you need event-driven automation at large scale
• →Versioned bash scriptsFor 1-2 simple servers: Ansible would be over-engineering

1. 01

   Clean inventory: all servers, groups and variables documented in YAML

2. 02

   Idempotent playbooks, golden rule: you can rerun them 10 times without damage

3. 03

   Reusable roles only when the pattern is confirmed across 2-3 uses

4. 04

   Ansible Vault for all secrets: never plaintext passwords in playbooks

5. 05

   CI integration for automated runs and drift reports

• Ansible or Terraform: do I have to choose?

  No, they're complementary tools. Terraform provisions (creates servers, databases, networks), Ansible configures (installs packages, deploys code, manages services). Many teams use both: Terraform for the IaaS layer, Ansible for the OS and application layer. The classic mistake is trying to do everything with just one.
• Why Ansible rather than Puppet or Chef?

  Agentless approach. Puppet and Chef require an agent installed on each managed server, which adds a dependency, an open port, a service to maintain. Ansible just uses SSH. Your server needs nothing extra. For an SMB, that's significantly simpler to set up and audit. Puppet/Chef keep an edge on very large fleets (10,000+ servers) where the pull-based approach weighs less.
• How much does Ansible setup cost?

  For an SMB with 5-15 servers, expect 3 to 8 days of initial setup: clean inventory, first playbooks (OS updates, app deployment, backups), CI integration. Investment amortized in 2-3 months by reduced manual maintenance time.
• Is it really agentless?

  Yes. Ansible connects via SSH (or WinRM for Windows) and runs Python modules that leave no persistent trace. No daemon, no port to open toward Ansible. The target server doesn't even need to know it's managed by Ansible. Only prerequisites: active SSH and Python on the target (already present on 99% of Linux distributions).
• What's an idempotent playbook and why does it matter?

  Idempotent means you can rerun the playbook as many times as you want without damage. The first run creates the desired state; subsequent runs check and modify nothing if everything is already correct. It's Ansible's most important property: you can audit, verify, recreate without fear. A non-idempotent playbook (that breaks on second run) is a bug, not a feature.