Day 116: Ansible for configuration management
Ansible: configuring what already exists
Terraform's job is provisioning infrastructure (creating the VM). Ansible's job is configuration management — installing packages, writing config files, ensuring services are running, on machines that already exist. It's agentless (works over SSH, no daemon needed on target machines) and, like Terraform, aims to be idempotent: running the same playbook twice should converge to the same state, not double-apply changes.
- hosts: webservers
become: true
tasks:
- name: Install nginx
apt:
name: nginx
state: present
- name: Ensure nginx is running
service:
name: nginx
state: started
enabled: trueIdempotency, once more
'state: present' and 'state: started' describe a desired end state, not an imperative action — running this playbook against a machine that already has nginx installed and running simply does nothing on the second run. This is Phase 7's idempotency principle, directly applied to configuration management.
Key terms
- Ansible playbook
- A declarative set of tasks describing desired configuration state for target machines.
- Agentless
- Ansible's approach of using SSH rather than requiring a persistent daemon on managed machines.
Why would a team typically use Terraform AND Ansible together, rather than picking just one?
