De cron y bash a Ansible: automatización idempotente de servidores
Por qué los scripts bash dejaron de escalar a partir de la tercera máquina y cómo modelar la infraestructura con Ansible: roles, inventarios, vault y ejecución segura desde un nodo de control.
El punto de inflexión
Una flota de tres servidores se puede gestionar con bash y SSH. A partir del cuarto, los scripts empiezan a divergir: una máquina tiene la versión vieja de un parche, otra olvida un usuario, otra mantiene un cron que ya nadie recuerda haber añadido. La salida disciplinada es declarar el estado deseado, no las acciones, y ejecutarlo de forma idempotente.
Organización de roles e inventario
Un layout que envejece bien: inventories/{prod,staging}/hosts.ini con group_vars por entorno, roles/ con un rol por responsabilidad (common, ssh, mysql, nginx, app) y playbooks de alto nivel que sólo componen roles. Las credenciales viven en ansible-vault con la clave fuera del repositorio; cualquier secreto en texto plano en un playbook es un incidente esperando a ocurrir.
# site.yml
- hosts: web
become: true
roles:
- common
- ssh-hardening
- { role: nginx, tags: ['nginx'] }
- { role: app, tags: ['deploy'] }Idempotencia real, no aparente
Un módulo que reporta changed=true en cada ejecución porque compara timestamps o re-renderiza un template idéntico es un bug. Antes de considerar un rol terminado, ejecutarlo dos veces seguidas debe dejar el segundo run con changed=0 en todas las tareas relevantes. Esa disciplina hace que las ejecuciones contra producción dejen de dar miedo.