Ansible tiene una fama curiosa en homelab. Para algunos es la herramienta que separa un laboratorio serio de una colección de servidores tocados a mano. Para otros es meter una oficina de procesos IT dentro de casa para instalar cuatro paquetes y reiniciar un servicio. Las dos posturas tienen parte de razón.
Yo he pasado por fases. La primera es la euforia: todo tiene que estar en Ansible. Usuarios, paquetes, Docker, firewall, SSH, cron, backups, contenedores, dashboards, motd, nombres de host, carpetas, servicios. Si algo se puede escribir en YAML, se escribe. Luego pasan unas semanas, cambias medio laboratorio, el playbook se queda viejo y descubres que tu automatización perfecta también necesita mantenimiento.
La conclusión a la que he llegado es menos épica y más útil: en un homelab pequeño, Ansible merece la pena para lo repetible, lo peligroso y lo que quieres poder reconstruir. Para lo experimental, lo cambiante o lo que haces una vez cada seis meses, a veces un README bueno gana.
Automatizar todo no es madurez. A veces es procrastinación con sintaxis limpia.
El problema real: configuración que vive en la cabeza#
El homelab típico empieza con SSH y memoria muscular. Entras en un servidor, instalas algo, ajustas un fichero, pruebas, funciona, sigues. Al principio va bien porque tienes pocos nodos y recuerdas lo que has hecho.
Después aparecen los síntomas:
- No sabes si todos los servidores tienen las mismas claves SSH.
- Un nodo tiene paquetes que otro no tiene.
- Un cron crítico existe en una máquina pero no en la copia nueva.
- Un usuario tiene sudo en un sitio y en otro no.
- Levantas una VM nueva y pierdes media tarde dejándola igual que las anteriores.
- Hay un cambio de seguridad que sabes que deberías aplicar en todos, pero te da pereza revisar uno por uno.
Ahí Ansible empieza a tener sentido. No por moda, sino porque reduce diferencias invisibles. La deriva de configuración es muy traicionera. El servidor funciona hasta que necesitas repetirlo, migrarlo o entenderlo seis meses después.
La pregunta no es si puedes hacer algo a mano. Casi siempre puedes. La pregunta es si quieres volver a hacerlo a mano cuando estés cansado, con prisa o intentando recuperar un servicio roto.
Mi criterio: automatizar lo que duele repetir#
No uso Ansible como religión. Lo uso como seguro contra tareas aburridas y errores tontos.
Para mí, merece la pena en estas zonas:
- Bootstrap de servidores Linux.
- Usuarios, claves SSH y permisos básicos.
- Paquetes comunes.
- Configuración base de seguridad.
- Montajes de almacenamiento que uso en varios sitios.
- Instalación de agentes de monitorización.
- Cron jobs importantes.
- Plantillas de servicios que quiero poder recrear.
- Comprobaciones predecibles antes de tocar producción doméstica.
No lo suelo usar para cada cambio pequeño de un servicio que está en fase de prueba. Si estoy probando una aplicación nueva, prefiero entenderla primero. Cuando ya sé que se queda, entonces decido si merece playbook.
Esto evita un problema clásico: automatizar desconocimiento. Si no entiendo bien un servicio, escribir Ansible demasiado pronto solo congela una mala decisión en YAML. Y el YAML tiene una capacidad maravillosa para parecer más serio de lo que realmente es.
Inventario pequeño, nombres claros#
En casa no necesito un inventario digno de una multinacional. Necesito nombres que entienda.
Algo como esto ya basta para empezar:
| |
Lo importante no es que sea sofisticado. Lo importante es que refleje roles reales. Si un servidor se llama ubuntu-22-test-final-final, ya hemos empezado mal. Los nombres deberían explicar para qué sirve, no cómo nació.
También prefiero grupos funcionales a grupos demasiado técnicos. No me interesa solo saber qué sistema operativo tiene cada nodo. Me interesa qué papel cumple: Docker, almacenamiento, monitorización, laboratorio, servicios domésticos. Esa clasificación ayuda a no ejecutar cosas donde no toca.
Para variables, empiezo mínimo. Usuario, puerto SSH si cambia, rutas comunes, paquetes por grupo y poco más. Cuando un group_vars empieza a parecer una novela, suelo preguntarme si estoy simplificando la operación o escondiendo complejidad.
Bootstrap: donde Ansible brilla de verdad#
El caso donde más valor le veo es preparar una máquina nueva.
Una VM recién creada o un mini PC recién instalado tiene mucho trabajo repetitivo: actualizar paquetes, crear usuario, meter claves SSH, desactivar acceso root si procede, instalar herramientas básicas, configurar zona horaria, preparar firewall, instalar agente de monitorización, montar almacenamiento, añadir repositorios, dejar logs razonables.
Nada de eso es glamuroso. Todo eso es fácil de olvidar.
Un playbook de bootstrap no tiene que ser enorme para ser útil. De hecho, prefiero que sea aburrido:
| |
Ese fragmento no impresiona a nadie. Pero cuando levantas la décima máquina y todo empieza igual, se agradece. Lo bueno de Ansible no es que parezca avanzado. Es que reduce pequeñas decisiones repetidas.
Seguridad base sin convertirlo en un castillo absurdo#
Ansible también va bien para mantener una línea mínima de seguridad. Claves SSH correctas, usuarios claros, paquetes actualizados, firewall básico, fail2ban si encaja, servicios innecesarios apagados, permisos razonables.
Aquí conviene no pasarse. Un homelab no necesita copiar una guía CIS entera si luego vas a desactivar la mitad porque rompe cosas. Seguridad que no entiendes es una deuda más.
Mi enfoque sería aplicar un mínimo común:
- Solo claves SSH.
- Usuarios separados cuando tiene sentido.
- Sudo explícito.
- Actualizaciones de seguridad automáticas en máquinas poco delicadas.
- Firewall simple.
- Puertos expuestos revisados.
- Servicios de laboratorio separados de servicios familiares.
Ansible ayuda porque puedes revisar esa política en texto. Si mañana quiero cambiar una clave, añadir un usuario o cerrar un puerto en varios nodos, no tengo que confiar en mi paciencia.
Pero tampoco metería cada ajuste raro del sistema en Ansible desde el primer día. Si una regla existe solo para un servidor concreto y no entiendo bien por qué, quizá merece documentación antes que automatización.
Docker y Ansible: buena pareja si no duplicas responsabilidades#
Una duda común es si tiene sentido usar Ansible cuando ya tienes Docker Compose. Para mí sí, pero con límites claros.
Docker Compose define aplicaciones. Ansible prepara el host y pone las piezas en su sitio.
Me gusta usar Ansible para:
- Instalar Docker.
- Crear carpetas base.
- Copiar ficheros
compose.yaml. - Crear
.envsin secretos incrustados en el repo. - Asegurar permisos.
- Lanzar o actualizar stacks concretos.
No me gusta usar Ansible para reconstruir a mano toda la lógica que Compose ya resuelve. Si acabo escribiendo veinte tareas para hacer lo que un compose up hace mejor, algo huele mal.
El patrón sano sería tener cada servicio con su Compose claro y usar Ansible para desplegarlo de forma repetible. El patrón enfermo es tener una abstracción encima de otra encima de otra, hasta que ya no sabes dónde se decide el puerto real.
En casa, la transparencia vale oro. Prefiero una estructura simple que pueda abrir a las doce de la noche sin odiarme.
Backups, cron y tareas delicadas#
Los backups son una zona donde Ansible puede ahorrar disgustos.
No porque haga backups por arte de magia, sino porque deja claro qué tareas existen, dónde corren y con qué configuración. He visto demasiadas veces scripts importantes viviendo en una máquina sin que nadie recuerde cómo llegaron ahí. Eso en un homelab familiar es mala idea.
Si un cron valida copias, sincroniza datos, renueva certificados o revisa discos, me gusta que esté versionado. Ansible puede instalar el script, crear el cron, preparar carpetas y dejar logs en una ruta conocida.
También puede hacer algo muy útil: comprobar precondiciones. Antes de activar una tarea, validar que existe el destino, que hay espacio, que el montaje está disponible o que el binario necesario está instalado. Eso conecta con una idea que ya comenté en backups que sí miro: no basta con crear copias, hay que vigilar que siguen siendo copias útiles.
Eso sí, no convertiría cada cron en una catedral. Si una tarea cabe en diez líneas de shell y se entiende, perfecto. Ansible no tiene que sustituir a todos los scripts. Tiene que ponerlos donde toca y evitar que se pierdan.
Dónde Ansible añade ceremonia#
Hay una parte de Ansible que puede volverse ridícula en un homelab pequeño.
Si tienes dos servidores y cambias una cosa cada tres meses, escribir roles, defaults, handlers, molecule, colecciones, inventarios dinámicos y pipelines puede ser más trabajo que beneficio. Aprendes, sí. Pero no confundamos aprendizaje con necesidad.
Ansible añade ceremonia cuando:
- Automatizas servicios que todavía estás explorando.
- Creas roles genéricos para problemas únicos.
- Escribes variables tan abstractas que nadie sabe qué valor final sale.
- Divides un playbook pequeño en diez ficheros por estética.
- Te da miedo tocar una máquina porque no sabes si Ansible va a pisar cambios manuales.
- Pasas más tiempo arreglando la automatización que el servicio.
La última frase es la alarma. Si la herramienta consume más atención que el problema que resuelve, toca simplificar.
En casa no hay premio por tener la infraestructura más declarativa. El premio es poder recuperar un servicio, migrar una máquina y dormir sin pensar en qué demonios configuraste a mano hace seis meses.
Documentar también es automatizar un poco#
Esto puede sonar raro, pero un README bueno a veces compite muy bien con Ansible.
Si un servicio tiene tres pasos manuales, se toca una vez al año y cada instalación exige decisiones diferentes, quizá no necesito un playbook. Necesito una nota clara:
- Dónde vive.
- Qué datos son importantes.
- Cómo se actualiza.
- Cómo se restaura.
- Qué dependencias tiene.
- Qué no debo tocar alegremente.
Esa documentación reduce incertidumbre. No ejecuta tareas, pero evita tener que reconstruir contexto desde cero. Y en un homelab, el contexto suele ser el verdadero cuello de botella.
Ansible y documentación no son enemigos. De hecho, un buen playbook debería complementar una nota corta. El playbook dice cómo se aplica. La nota dice por qué existe y cuándo no usarlo.
Mi estructura favorita para empezar#
Si hoy montase Ansible en un homelab pequeño, no empezaría con una arquitectura enorme. Haría algo así:
| |
Nada espectacular. Suficiente para crecer sin ponerse barroco.
Primero haría un bootstrap.yml estable. Después uno para hosts Docker. Luego monitorización. Luego backups o tareas programadas. Y pararía ahí hasta que hubiera dolor real.
También ejecutaría en modo prudente. --check cuando tenga sentido, límites por grupo, cambios pequeños y revisión del diff en plantillas. Ansible puede romper varias máquinas a la vez con una eficacia preciosa. Es parte de su encanto y de su peligro.
Secretos: cuidado con el repo bonito#
Un fallo típico es meter secretos en el repositorio porque todo queda más cómodo. Tokens, contraseñas, claves privadas, URLs sensibles, nombres de dominios internos. Mala idea.
Ansible Vault puede servir. También puedes usar variables externas, un gestor de secretos o simplemente separar lo sensible fuera del repo si el entorno es pequeño. Lo importante es no terminar con un repositorio de infraestructura que sea también una caja fuerte abierta.
En homelab esto se relaja demasiado porque “total, es casa”. Precisamente porque es casa conviene ser cuidadoso. Hay backups familiares, contraseñas, documentos, servicios personales y accesos remotos. No hace falta ponerse paranoico, pero sí evitar tonterías.
Mi regla: el repo debe explicar la infraestructura sin regalar las llaves.
Cuándo no usaría Ansible#
No usaría Ansible para cacharreo puro. Si estoy probando una app durante una tarde, la levanto con Docker Compose, tomo notas y ya veremos. Si se queda, entonces decido.
No lo usaría para ocultar falta de criterio. Si no sé si un servicio debe ir en VM, contenedor, NAS o cloud, escribir un rol no resuelve la decisión.
No lo usaría para operaciones peligrosas sin entender el impacto. Cambios de red, firewall, almacenamiento o usuarios con privilegios merecen pruebas pequeñas. Que Ansible pueda ejecutarlo en todos los nodos no significa que deba hacerlo.
Y no lo usaría para impresionar. Esto suena tonto, pero pasa. Un homelab con automatización excesiva puede parecer muy serio y ser frágil. Un homelab con dos playbooks, buenos backups y documentación clara puede ser mucho más sano.
La medida correcta#
La medida correcta de Ansible en casa no es cuántos roles tienes. Es cuántas veces te salva de repetir una tarea aburrida o de olvidar un paso importante.
Si levantas una VM nueva y en diez minutos está lista con usuario, claves, paquetes, Docker, monitorización y backup base, Ansible está haciendo su trabajo.
Si un cambio de seguridad se aplica a cinco máquinas sin entrar por SSH una a una, está haciendo su trabajo.
Si puedes reconstruir un servidor con menos memoria heroica, está haciendo su trabajo.
Si cada pequeño cambio exige entender una capa de abstracción que escribiste con demasiado café, quizá has construido otro problema.
Ansible en homelab pequeño merece la pena cuando baja la fricción. No cuando añade solemnidad. Automatiza lo que se repite, documenta lo que se decide y deja el laboratorio con espacio para seguir siendo laboratorio. Al final, la mejor infraestructura doméstica no es la más elegante. Es la que puedes arreglar con la cabeza cansada sin convertir una noche cualquiera en una auditoría de YAML.