Ansible
Think it through.

Ansible is a configuration management and automation tool that uses SSH (no agent needed) and YAML playbooks. It is procedural and focuses on configuring existing systems. Terraform is declarative and focuses on provisioning infrastructure. Ansible is idempotent, agentless, and primarily used for OS config, app deployment, and orchestration. Terraform is used for cloud resource provisioning. They complement each other — Terraform provisions VMs, Ansible configures them.

A Playbook is a YAML file containing one or more plays. Each play maps a group of hosts to a set of tasks executed in order. Example: - name: Configure web server; hosts: webservers; become: yes; tasks: - name: Install nginx; apt: name: nginx state: present. Playbooks are the entry point for all automation. They can include variables, handlers, templates, roles, and conditionals.

A Role is a reusable, self-contained unit of automation with a standard directory structure: roles/role_name/{tasks, handlers, templates, files, vars, defaults, meta, library, lookup_plugins, module_utils}. Each directory contains a main.yml that Ansible loads automatically. Roles are referenced in playbooks: - hosts: webservers; roles: [common, nginx]. Roles can have dependencies (meta/main.yml). Pre-built roles are shared via Ansible Galaxy.

Modules are discrete units of code that Ansible runs on targets. Types: (1) System — package, service, user, mount, firewalld. (2) Commands — command, shell, raw, script. (3) Files — copy, template, file, fetch, lineinfile. (4) Database — mysql_db, postgresql_db, mongo_db. (5) Cloud — ec2, gce, azure_rm, s3. (6) Kubernetes — k8s, helm. (7) Network — ios, junos, nxos. Modules are idempotent — they check current state before making changes. ansible-doc -l lists all available modules.

Ansible Vault encrypts sensitive data (variables, files) at rest. Commands: ansible-vault create secret.yml, ansible-vault encrypt vars.yml, ansible-vault view secret.yml. Run playbooks with --ask-vault-pass or --vault-password-file. Encrypted variables are decrypted at runtime. Multiple vault passwords are supported (labeled vault IDs): ansible-playbook --vault-id prod@prompt site.yml. Vault encrypts the entire file content (AES-256). For per-value encryption, use lookup plugins or integrate with HashiCorp Vault.

Variable precedence (lowest to highest): (1) role defaults, (2) inventory file vars, (3) inventory group_vars, (4) inventory host_vars, (5) playbook group_vars/host_vars, (6) set_facts, (7) play vars, (8) play vars_prompt, (9) play vars_files, (10) role vars (from roles/x/vars/main.yml), (11) block vars, (12) task vars, (13) include_vars results, (14) registered vars, (15) extra vars (-e "key=value"). Extra vars always win. Use ansible-inventory --vars to debug variable resolution. Variables in group_vars/all/ apply to all hosts.

Tools: (1) ansible-playbook --check — dry-run (reports changes without making them). (2) --diff — shows what would change. (3) Molecule — testing framework for Ansible roles: creates instances (Docker, Vagrant, AWS), runs converge, verifies with verify (using testinfra), and destroys. (4) ansible-lint — checks playbooks for best practices and anti-patterns. (5) Testinfra — Python test framework for verifying system state after Ansible runs: def test_nginx_running(host): assert host.service("nginx").is_running. (6) Ansible-specific CI in GitHub Actions with molecule action.

Handlers are tasks that only run when notified by other tasks. Defined under handlers:, triggered via notify: handler_name. They run once at the end of the play, even if notified multiple times. Common use: restarting a service after config change: - name: Restart nginx; service: name: nginx state: restarted; listen: restart nginx. Use meta: flush_handlers to run handlers immediately (e.g., before a task that depends on the handler's effect). Handlers can also be triggered by listen (multiple handlers with the same listen topic).

Strategy: (1) Use serial to control batch size: - hosts: app_servers; serial: 1 (one at a time). (2) Pre-check: run health check before removing old version. (3) Deploy new version with a symlink swap: deploy_dir: /app/current (symlink to /app/releases/v2). (4) Use delegate_to with a load balancer to remove/add nodes from the LB pool: - name: Remove from LB; delegate_to: localhost; haproxy: state: disabled; host: "{{ inventory_hostname }}". (5) Post-check: wait for new app to be healthy: uri: url: http://localhost:8080/health; status_code: 200. (6) Rollback on failure: symlink back to previous release. The serial: 1 ensures only one server is down at a time.