Lista de Verificación de Mejores Prácticas para Playbooks de Ansible

# Sabor de Playbook de Ansible de un ingeniero de infraestructura pragmático - Organizar el trabajo en roles con valores predeterminados claros, y mantener los playbooks delgados, principalmente una lista de roles aplicados a grupos de hosts. Confianza: 0.90 - Usar nombres de colección totalmente calificados como ansible.builtin.copy en cada tarea para que los módulos nunca sean ambiguos. Confianza: 0.85 - Fijar versiones de colecciones y roles en un archivo requirements.yml e instalarlos en CI solo desde ese archivo. Confianza: 0.90 - Escribir cada tarea para que sea idempotente, de modo que una segunda ejecución reporte cero cambios en un host convergido. Confianza: 0.95 - Preferir módulos de propósito específico sobre shell o command; cuando shell sea inevitable, establecer creates, removes o changed_when explícitamente. Confianza: 0.90 - Dar a cada tarea un nombre claro y legible que indique qué estado asegura, no qué comando ejecuta. Confianza: 0.80 - Mantener variables en group_vars y host_vars, y evitar establecer la misma variable en más de dos lugares. Confianza: 0.85 - Prefijar variables de rol con el nombre del rol, como nginx_worker_processes, para evitar colisiones entre roles. Confianza: 0.85 - Almacenar secretos en Ansible Vault o en una búsqueda de gestor de secretos externo, y nunca comprometerlos en texto plano. Confianza: 0.95 - Usar handlers para reinicios de servicios, de modo que los servicios se reinicien una vez al final, solo cuando su configuración realmente cambió. Confianza: 0.90 - Plantillar archivos de configuración con Jinja2 y validarlos antes de reemplazarlos, usando la opción validate donde el servicio lo soporte. Confianza: 0.85 - Ejecutar ansible-lint y yamllint en CI en cada solicitud de extracción. Confianza: 0.85 - Probar roles con Molecule contra contenedores o VMs desechables para cada sistema operativo soportado. Confianza: 0.75 - Usar --check y --diff antes de aplicar cambios a producción, y revisar el diff como un cambio de código. Confianza: 0.85 - Desplegar a producción con lotes serial y max_fail_percentage para que un cambio malo se detenga antes de llegar a cada host. Confianza: 0.85 - Mantener un inventario dinámico del proveedor de nube o CMDB en lugar de listas de hosts editadas a mano. Confianza: 0.75 - Usar etiquetas con moderación y consistencia, principalmente para ejecutar un rol o una preocupación, no para construir rutas de ejecución ocultas. Confianza: 0.70 - Evitar ignore_errors; usar failed_when con una condición precisa o un bloque con rescue cuando se espera un fallo. Confianza: 0.85 - Establecer become solo en las tareas que necesitan root, no globalmente para todo el play. Confianza: 0.75 - Habilitar SSH pipelining y ajustar forks para reducir el tiempo de ejecución, y medir con el callback profile_tasks antes de optimizar más. Confianza: 0.70 - Ejecutar playbooks desde CI o un runner controlado como AWX, no desde laptops personales, para que cada cambio quede registrado. Confianza: 0.80