Domina Ansible Playbook: Patrones Avanzados para Producción 2026

Por qué importa hablar de playbooks en serio y no de tutoriales básicos

La mayoría de tutoriales de Ansible que circulan por la red se quedan en el “Hola Mundo”: un ansible.builtin.ping, un apt y un copy. Funcionan para empezar, pero el día que tienes que desplegar parches a 40 servidores heterogéneos, validar el orden de reinicio de servicios o revertir un cambio que salió mal, esos tutoriales no te sirven. Ahí entran los playbooks pensados para producción: bloques con rescue y always, estrategias de ejecución explícitas, vault bien integrado, lint endurecido y, opcionalmente, una plataforma como Red Hat AAP 2.6 que orquesta todo desde un panel.

Con ansible-core 2.21.5 como rama estable (PyPI, release 8-sep-2026) y el resto del ecosistema (ansible-lint 26.9.0, Ansible community package 14.0.0, AAP 2.6 patch 4-ago-2026) ya consolidado, 2026 es el año para subir el listón de tus playbooks. Esta guía está orientada a sysadmins que ya pasaron el tutorial básico y quieren escribir playbooks que aguanten scrutiny en producción.

Anatomía de un playbook: lo que siempre debes declarar

Un playbook completo tiene cinco bloques que conviene declarar siempre, aunque algunos queden vacíos: targets (qué hosts afecta), variables (qué necesita cada tarea), tareas (qué se hace), handlers (qué se ejecuta cuando algo cambia) y estrategia (cómo se reparte el trabajo). Dejar la estrategia por defecto funciona, pero declararla deja claro el contrato.

---
- name: Desplegar parches críticos en servidores web
  hosts: web
  become: true
  strategy: linear
  gather_facts: true
  vars:
    service_a_reiniciar: "nginx"
    timeout_apt: 300
  tasks:
    - name: Asegurar cache apt actualizada
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600
    - name: Instalar solo parches de seguridad
      ansible.builtin.apt:
        upgrade: safe
      notify: reiniciar servicio
  handlers:
    - name: reiniciar servicio
      ansible.builtin.service:
        name: "{{ service_a_reiniciar }}"
        state: restarted

La diferencia entre un playbook de prueba y uno de producción está en los detalles que faltan en este bloque: la estrategia linear ejecuta un host a la vez (útil cuando hay dependencia entre nodos), pero free (la opción por defecto desde 2.0) es más rápida para nodos independientes. Si despliegas algo que afecta una base de datos compartida, linear te salva de condiciones de carrera. Si parchear 40 servidores homelab, free con forks: 20 reduce el tiempo a la mitad.

Bloques, rescue y always: tolerancia a fallos controlada

El block con rescue y always es el equivalente Ansible de un try/catch/finally. Permite agrupar tareas que deben ejecutarse juntas, revertir el estado si alguna falla y ejecutar limpieza sin importar el resultado. Es el patrón correcto para operaciones como actualizaciones de base de datos o reemplazos de configuración que requieren rollback explícito.

- name: Actualizar configuración de nginx con rollback
  block:
    - name: Respaldar configuración actual
      ansible.builtin.copy:
        src: /etc/nginx/nginx.conf
        dest: /etc/nginx/nginx.conf.bak
        remote_src: true
        mode: '0644'
    - name: Desplegar nueva configuración
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        mode: '0644'
        validate: 'nginx -t -c %s'
    - name: Recargar nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded
  rescue:
    - name: Restaurar configuración desde respaldo
      ansible.builtin.copy:
        src: /etc/nginx/nginx.conf.bak
        dest: /etc/nginx/nginx.conf
        remote_src: true
        mode: '0644'
    - name: Notificar fallo al operador
      ansible.builtin.debug:
        msg: "Rollback ejecutado en {{ inventory_hostname }}"
  always:
    - name: Limpiar archivo temporal
      ansible.builtin.file:
        path: /etc/nginx/nginx.conf.bak
        state: absent

El validate en el módulo template ejecuta nginx -t -c %s antes de aplicar el cambio. Si la validación falla, Ansible no escribe el archivo y salta al rescue. Esta validación previa es la que separa un playbook amateur de uno que puede correr en producción un viernes a las 5pm. Recuerda: el rescue solo se ejecuta si una tarea del block falla. Si la validación es exitosa y el cambio se aplica, el always corre igual y limpia el respaldo.

Strategies y serial: el orden de ejecución importa

La estrategia por defecto (free) reparte el trabajo entre todos los hosts en paralelo sin importar dependencias. Para la mayoría de operaciones sirve. Pero cuando un cambio requiere un orden estricto (un proxy antes que el backend, una base de datos maestra antes que las réplicas) necesitas serial para procesar hosts en lotes y controlar el blast radius si algo falla.

- name: Rolling update de cluster de base de datos
  hosts: db
  become: true
  serial:
    - 1
    - "25%"
    - "100%"
  max_fail_percentage: 25
  tasks:
    - name: Detener servicio de base de datos
      ansible.builtin.service:
        name: postgresql
        state: stopped
    - name: Actualizar paquete postgresql
      ansible.builtin.apt:
        name: postgresql-15
        state: present
        update_cache: true
    - name: Iniciar servicio de base de datos
      ansible.builtin.service:
        name: postgresql
        state: started

El serial acepta números enteros, porcentajes y listas. El ejemplo procesa primero 1 host (el canario), luego el 25% del resto y finalmente el 100%. Si el 25% del lote falla, max_fail_percentage: 25 aborta la ejecución para evitar dejar el cluster en estado inconsistente. Esta combinación de serial + max_fail_percentage es la base del patrón “rolling update con canary” que usan plataformas como AAP 2.6 en su workflow job template.

Vault y cifrado de secretos: lo que nunca va en texto plano

Ansible Vault cifra archivos YAML completos o variables individuales con AES256. La regla es dura: ningún secreto en texto plano dentro de un playbook que se versiona en Git. La forma estándar en 2026 es separar secrets en archivos cifrados por entorno y referenciarlos desde el playbook.

# Cifrar un archivo de variables por entorno
ansible-vault encrypt group_vars/production/vault.yml
# Editar sin descifrar manualmente
ansible-vault edit group_vars/production/vault.yml
# Ver qué variables hay sin editar
ansible-vault view group_vars/production/vault.yml

Para ejecutarlo, pasas la contraseña con --ask-vault-pass, --vault-password-file o la variable de entorno ANSIBLE_VAULT_PASSWORD_FILE. En pipelines de CI, lo correcto es montar la contraseña desde un secret manager (HashiCorp Vault, GitHub Actions Secrets, GitLab CI Variables) y nunca escribirla en el repositorio.

# group_vars/production/vault.yml (cifrado)
vault_db_password: "p4ssw0rd-produccion-2026"
vault_api_token: "tok_live_4f8e2c9a..."
# group_vars/production/vars.yml (en claro, importa el vault)
db_user: "app_prod"
db_host: "db.internal.lan"
# playbook.yml
- name: Desplegar aplicación con secretos cifrados
  hosts: app
  become: true
  vars_files:
    - group_vars/production/vars.yml
    - group_vars/production/vault.yml
  tasks:
    - name: Crear archivo de configuración con secretos
      ansible.builtin.template:
        src: app.conf.j2
        dest: /etc/myapp/app.conf
        mode: '0640'
        owner: root
        group: myapp

Desde ansible-core 2.18 está disponible ansible-vault encrypt_string para cifrar una variable individual dentro de un archivo en claro. Útil cuando solo una línea necesita cifrado y el resto del archivo es legible. Verifica el resultado con ansible-vault view antes de commit.

Ansible-lint 26.9.0: profile production en CI

El linter endurecido de Ansible cambió su esquema de versiones a calendario (YY.MM) en 2024 y la rama 26.x ya está consolidada. La versión 26.9.0 (septiembre 2026) trae correcciones para falsos positivos en el rule name cuando se usan bloques con rescue, soporte completo para ansible-core 2.21 y reglas nuevas en el tag opt-in. El profile production aplica el conjunto completo de reglas de seguridad, idempotencia y sintaxis que cualquier equipo profesional debería correr antes de merge.

# Instalar ansible-lint 26.x alineado con tu ansible-core
pip install 'ansible-lint>=26.9.0,<27.0.0'
# Correr con el profile production
ansible-lint --profile production playbook.yml
# Salida: Passed/Failed por archivo y tag (core, idempotency, security, syntax)

Las reglas más útiles del tag security son no-log-password (no loguear secretos), risky-shell-pipe (no usar shell con pipes sin pipefail) y var-naming (no usar nombres de variables reservados de Python). El tag idempotency te obliga a usar state: present en lugar de state: latest cuando quieres evitar actualizaciones accidentales. Integra ansible-lint en tu pipeline con pre-commit:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/ansible/ansible-lint
    rev: v26.9.0
    hooks:
      - id: ansible-lint
        files: .(yaml|yml)$

Si tu playbook falla el lint en CI, no lo apruebes. La regla fqcn (Fully Qualified Collection Name) exige que uses ansible.builtin.copy en vez de copy. Esto evita ambigüedad cuando tu playbook importa 10 colecciones y todas tienen un módulo con nombre similar.

Molecule: testing real de roles antes de producción

Molecule es el estándar para probar roles de Ansible. Crea un entorno efímero (Docker, Podman o Vagrant), aplica el rol, ejecuta playbooks de verificación y destruye el entorno. La versión actual (6.x, alineada con ansible-core 2.21) simplifica la configuración con molecule default init y soporta escenarios paralelos para probar el mismo rol contra múltiples distribuciones.

# Inicializar molecule dentro de un rol existente
cd roles/webserver
molecule init scenario
# Ejecutar el escenario default
molecule test
# Escenarios paralelos (Ubuntu + Debian + Rocky)
molecule matrix --parallel test

El escenario por defecto tiene seis fases: dependency (instala colecciones), lint (corre ansible-lint), cleanup (destruye instancias previas), destroy (asegura estado limpio), create (lanza contenedores), prepare (configura prerequisites), converge (aplica el rol), idempotence (verifica que una segunda ejecución no haga cambios) y verify (corre tests de Ansible o pytest). Si quieres saltarte create/destroy durante desarrollo iterativo, usa molecule converge y molecule login.

AAP 2.6 patch 4-ago-2026: qué resuelve

Red Hat publicó el 4 de agosto de 2026 el patch acumulativo para Ansible Automation Platform 2.6 con 24 correcciones distribuidas en 12 componentes. Los tres arreglos más relevantes para sysadmins que usan AAP en producción: corrección del bug en imágenes de execution environment (EE) que existían en automation hub antes del upgrade 2.6→2.7 (junio-2026), soporte oficial para PostgreSQL 16 como backend del controller, y nueva Automation Dashboard con métricas en tiempo real de uso por organización.

Si todavía corres AAP 2.4 o 2.5, el ciclo de soporte termina en octubre 2027 para 2.5 y mayo 2027 para 2.4. AAP 2.6 es la rama estable recomendada para nuevas instalaciones en lo que resta de 2026. La migración entre versiones mayores sigue siendo reinstalación del controller + migración de base de datos + reimport de credenciales, no hay upgrade in-place.

Vale la pena el switch a playbooks "profesionales"

Si tus playbooks hoy consisten en tareas lineales de 10 líneas sin handlers ni vault, el salto a bloques con rescue + serial + lint + molecule parece overkill. No lo es. El costo de escribir el primer playbook con estas prácticas es de unas 4 a 6 horas más que el tutorial básico. El ahorro lo ves la primera vez que un cambio sale mal: rollback automático en lugar de debugging a las 2am, lint en CI en lugar de surprises en producción, molecule tests en lugar de "funciona en mi máquina".

Para un homelab de 1 a 3 servidores, las prácticas de bloque + vault + lint siguen valiendo, aunque molecule puede ser excesivo. Para equipos de 5+ personas gestionando 20+ servidores, AAP 2.6 es la pieza que convierte Ansible de "scripts que alguien mantiene a mano" en plataforma con RBAC, audit log, workflows reutilizables y aprobación manual antes de cambios en producción. El ecosistema completo de 2026 ya soporta ansible-core 2.21 con el resto de herramientas actualizadas, no hay razón para quedarse en ramas EOL.

Conclusión

En 2026 los playbooks de Ansible viven o mueren por tres prácticas: bloques con rescue para tolerancia a fallos, vault para secretos y lint con profile production antes de cualquier merge. El resto (strategies, serial, molecule, AAP) son herramientas para cuando la base anterior ya está consolidada. Empieza por ahí y ve sumando según crezca tu infraestructura.

Si todavía no tienes ansible-core 2.21 instalado, el upgrade desde 2.19 o 2.20 es directo: pip install --upgrade ansible-core en tu nodo de control. Verifica la compatibilidad de tus colecciones con ansible-galaxy collection check antes de desplegar cualquier cambio. La rama 2.19 entra en EOL el 30 de noviembre de 2026, así que tienes dos meses para migrar si todavía corres esa versión.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux