Best Practices and Advanced Patterns

As your Ansible automation grows, following best practices becomes essential for maintainability, security, and scalability. This lesson covers recommended patterns, Ansible Vault, collections, and CI/CD integration.

---

Recommended Directory Layout

The official Ansible best practices suggest the following project structure:

production/               # Production inventory
staging/                  # Staging inventory
group_vars/
+-- all.yml               # Variables for all hosts
+-- webservers.yml        # Variables for webservers
+-- dbservers.yml         # Variables for dbservers
host_vars/
+-- web1.example.com.yml  # Host-specific variables
roles/
+-- common/               # Base role for all servers
+-- nginx/                # Web server role
+-- postgresql/           # Database role
+-- monitoring/           # Monitoring agent role
playbooks/
+-- site.yml              # Master playbook
+-- webservers.yml        # Web server playbook
+-- dbservers.yml         # Database playbook
ansible.cfg               # Project configuration
requirements.yml          # Role and collection dependencies

The Master Playbook (site.yml)

---
- import_playbook: playbooks/webservers.yml
- import_playbook: playbooks/dbservers.yml

This lets you run the entire infrastructure with one command:

ansible-playbook -i production site.yml

---

Idempotency

The most important principle in Ansible automation:

Every task should be safe to run multiple times without changing the result.

Idempotent vs Non-Idempotent

Approach	Idempotent?	Why
apt: name=nginx state=present	Yes	Only installs if not already present
command: apt-get install nginx	No	Runs every time, reports changed
service: name=nginx state=started	Yes	Only starts if not running
command: systemctl start nginx	No	Runs every time, reports changed
template: src=... dest=...	Yes	Only updates if content changed
command: cp /src /dest	No	Copies every time

Tip: Prefer purpose-built modules over command and shell. If you must use command, add creates or changed_when to make it idempotent.

---

Ansible Vault

Ansible Vault encrypts sensitive data (passwords, API keys, certificates) so it can be safely stored in version control.

Encrypting and Decrypting

# Encrypt a file
ansible-vault encrypt group_vars/production/secrets.yml

# Decrypt a file
ansible-vault decrypt group_vars/production/secrets.yml

# Edit an encrypted file
ansible-vault edit group_vars/production/secrets.yml

# View an encrypted file
ansible-vault view group_vars/production/secrets.yml

# Encrypt a string
ansible-vault encrypt_string 'SuperSecret123' --name 'db_password'

Using Encrypted Files in Playbooks

# Provide the vault password at runtime
ansible-playbook site.yml --ask-vault-pass

# Use a password file
ansible-playbook site.yml --vault-password-file ~/.vault_pass

# Set in ansible.cfg
# vault_password_file = ~/.vault_pass

Vault Best Practices

Practice	Description
Separate secrets	Keep encrypted vars in their own files (e.g., secrets.yml)
Use vault IDs	Label vaults for different environments (--vault-id prod@prompt)
Never commit plaintext	Encrypt before committing to version control
Rotate passwords	Change vault passwords and re-encrypt periodically

---

Ansible Collections

Collections are a distribution format for Ansible content (modules, roles, plugins, playbooks):

# Install a collection
ansible-galaxy collection install amazon.aws

# Install from requirements
ansible-galaxy collection install -r requirements.yml

requirements.yml with Collections

---
collections:
  - name: amazon.aws
    version: ">=7.0.0"
  - name: community.general
  - name: ansible.posix

roles:
  - name: geerlingguy.nginx

Using Collection Modules

tasks:
  # Fully Qualified Collection Name (FQCN)
  - name: Create an S3 bucket
    amazon.aws.s3_bucket:
      name: my-bucket
      state: present

Tip: Always use the Fully Qualified Collection Name (FQCN) in playbooks for clarity and to avoid module name conflicts.

---

CI/CD Integration