Ansible: Automatización completa de infraestructura con buenas prácticas

Después de dominar los fundamentos de Ansible, el siguiente paso es estructurar proyectos profesionales que sean mantenibles, seguros y escalables. En este artículo cubriremos la organización de proyectos reales, el uso de ansible-vault para secretos, estrategias de ejecución con tags y limit, validación con check mode, linting y la integración en pipelines de CI/CD.

Estructura de proyecto profesional

Un proyecto Ansible bien organizado separa claramente los inventarios, variables, roles y playbooks. Esta estructura permite gestionar múltiples entornos (desarrollo, staging, producción) con un solo repositorio y facilita la colaboración en equipo.

proyecto-ansible/
├── ansible.cfg              # Configuración global del proyecto
├── inventories/
│   ├── development/
│   │   ├── hosts.yml        # Hosts de desarrollo
│   │   └── group_vars/
│   │       └── all.yml      # Variables comunes de dev
│   ├── staging/
│   │   ├── hosts.yml
│   │   └── group_vars/
│   └── production/
│       ├── hosts.yml
│       ├── group_vars/
│       │   ├── all.yml
│       │   ├── webservers.yml
│       │   └── database.yml
│       └── host_vars/
│           └── web1.yml     # Variables específicas de un host
├── roles/                   # Roles compartidos
│   ├── nginx/
│   ├── php-fpm/
│   └── mariadb/
├── playbooks/
│   ├── site.yml             # Playbook principal
│   └── monitoring.yml       # Playbook secundario
├── vault/                   # Archivos cifrados
│   └── secrets.yml
└── requirements.yml         # Roles externos de Ansible Galaxy```


Gestión de secretos con ansible-vault



ansible-vault permite cifrar archivos completos o variables individuales para que los secretos (contraseñas, claves API, certificados) no queden en texto plano en el repositorio. Los archivos cifrados se integran de forma transparente en el flujo de trabajo.


```
# Cifrar un archivo de variables
ansible-vault encrypt vault/secrets.yml

# Ver/editar el contenido cifrado
ansible-vault view vault/secrets.yml
ansible-vault edit vault/secrets.yml

# Ejemplo vault/secrets.yml (cifrado)
vault_db_password: "Str0ng!Passw0rd"
vault_mariadb_root: "Sup3rS3cur3!R00t"
vault_api_key: "sk-or-...81b6"

# Ejecutar playbook usando el archivo de contraseña vault
ansible-playbook playbooks/site.yml \
  -i inventories/production/hosts.yml \
  --vault-password-file .vault_pass```


Es buena práctica no versionar el archivo .vault_pass y en su lugar usar un gestor de secretos externo (como HashiCorp Vault, AWS Secrets Manager o 1Password) junto con un script que resuelva la contraseña en tiempo de ejecución.



Tags, limit y check mode: control preciso de ejecución



Los tags permiten ejecutar subconjuntos específicos de tareas sin tener que modificar el playbook. --limit restringe la ejecución a ciertos hosts. El check mode (--check) muestra los cambios que se realizarían sin aplicarlos realmente, ideal para validación en entornos de producción.


```
# Ejecutar solo las tareas etiquetadas como "nginx"
ansible-playbook playbooks/site.yml \
  -i inventories/production/hosts.yml \
  --tags "nginx"

# Ejecutar solo en un host específico
ansible-playbook playbooks/site.yml \
  -i inventories/production/hosts.yml \
  --limit web1.example.com

# Check mode: simular cambios sin aplicarlos
ansible-playbook playbooks/site.yml \
  -i inventories/staging/hosts.yml \
  --check --diff

# Combinar todo
ansible-playbook playbooks/site.yml \
  -i inventories/production/hosts.yml \
  --tags "php-fpm" \
  --limit web2.example.com \
  --check```


Ansible-lint y calidad del código



ansible-lint analiza playbooks, roles y archivos de variables en busca de errores, malas prácticas y posibles mejoras. Es una herramienta indispensable para mantener la calidad del código en equipos y proyectos medianos/grandes.


```
# Instalar ansible-lint
pip install ansible-lint

# Ejecutar análisis sobre todo el proyecto
ansible-lint

# Análisis específico de un playbook
ansible-lint playbooks/site.yml

# Ejemplo de reglas que detecta:
# - command-instead-of-module → usar módulos en vez de comandos raw
# - no-tabs → el YAML no debe contener tabs
# - risky-file-permissions → permisos incorrectos en archivos
# - unnamed-task → las tareas deben tener nombre descriptivo```


CI/CD con Ansible



Integrar Ansible en un pipeline de CI/CD (GitHub Actions, GitLab CI, Jenkins) permite validar, probar y desplegar la infraestructura automáticamente con cada cambio en el repositorio. Un pipeline típico incluye linting, check mode en staging y despliegue a producción con aprobación manual.


```
# Ejemplo .github/workflows/ansible.yml
---
name: Ansible CI/CD
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install ansible ansible-lint
      - run: ansible-lint

  deploy-staging:
    needs: lint
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - run: pip install ansible
      - run: |
          ansible-playbook playbooks/site.yml \
            -i inventories/staging/hosts.yml \
            --check --diff

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: pip install ansible
      - run: |
          ansible-playbook playbooks/site.yml \
            -i inventories/production/hosts.yml \
            --vault-password-file <(echo "$VAULT_PASS")```


Con esta estructura y buenas prácticas ya estás listo para gestionar infraestructura a escala profesional con Ansible. La combinación de roles modulares, vault para secretos, check mode, linting y CI/CD te da un flujo de trabajo robusto, seguro y auditable.