Automatiza la gestión de tus máquinas virtuales y contenedores sin esfuerzo.
Tengo ya cómo unas diez máquinas Linux funcionando en Proxmox: Debian, Ubuntu y Alpine, cada una haciendo sus tareas diarias. Además, un Windows 11 y un Windows Server Core 2019 para las pruebas de SSCM y Azure que estoy haciendo.
Al principio no supone demasiado trabajo mantenerlas. Pero cuando empiezas a tener varias máquinas, repetir las mismas tareas una y otra vez empieza a ser bastante aburrido. Y aburrido, en este oficio, significa peligroso (porque acabas haciendo las cosas a lo loco).
Así que decidí probar Ansible. Y este es el manual de cómo lo estoy montando, con sus fallos y sus soluciones.
¿Qué quiero conseguir?
La idea no es montar una infraestructura empresarial ni complicarnos la vida, eso ya lo hacemos en el trabajo. Quiero poder administrar mi laboratorio desde un único sitio. Nada más. Y nada menos.
Tabla de objetivos (con su estado real):
| Objetivo | Estado |
|---|---|
| Comprobar que todas las máquinas están disponibles | ✅ Hecho |
| Actualizar Debian y Ubuntu (apt) | ✅ Hecho |
| Actualizar Alpine (apk) | ✅ Hecho |
| Gestionar servicios (start/stop/restart) | 🔄 En progreso |
| Instalar software | 🔄 En progreso |
| Crear usuarios | 🔄 En progreso |
| Ejecutar comandos remotos | ✅ Hecho |
| Automatizar tareas repetitivas | 🔄 En progreso |
| Actualizar Windows | ⏳ Pendiente (requiere WinRM) |
| Registrar qué ha ocurrido (logs) | 🔄 En progreso |
Mi laboratorio
Para este manual voy a utilizar un escenario bastante parecido al que podemos encontrar en un laboratorio doméstico o de pruebas:
PROXMOX │ ┌──────────────┴──────────────┐ │ │ ANSIBLE CONTROLLER OTRAS VM/LXC Debian Linux │ │ │ ┌──────┼────────┬─────────┐ │ │ │ │ │ │ Debian Ubuntu Alpine Debian Windows │ │ │ │ ┌───┴────┐ │ │ │ │ │ │ VM/LXC VM/LXC VM/LXC VM/LXC Win11 WServerCore2019
No hace falta que todas las máquinas sean iguales para que esto funcione, de hecho, esa es precisamente la gracia. Tenemos diferentes distribuciones, diferentes servicios y también Windows.
¿Por qué necesito Ansible?
Imaginemos que quiero actualizar todos mis Debian y Ubuntu.
Sin Ansible:
SSH → Debian 1 → apt update && apt full-upgrade -y SSH → Debian 2 → apt update && apt full-upgrade -y SSH → Ubuntu 1 → apt update && apt full-upgrade -y SSH → Debian 3 → apt update && apt full-upgrade -y ...
Y si tengo diez máquinas, acabamos haciendo lo mismo diez veces.
Con Ansible:
ansible servidores -m apt -a "update_cache=yes"
Y Ansible se encarga del resto.
Una orden. Todas las máquinas. Más tiempo para mí.
Pero tengo Alpine...
Aquí aparece una situación interesante de nuestro laboratorio.
Alpine Linux utiliza apk, mientras que Debian y Ubuntu utilizan apt.
No podemos tratar todas las máquinas exactamente igual.
Podemos organizar el inventario:
[debian] debian01 debian02 debian03 [ubuntu] ubuntu01 ubuntu02 [alpine] alpine01 alpine02 [windows] windows11 servercore2019
Ahora podemos decidir qué hacer con cada grupo.
Por ejemplo:
Debian/Ubuntu → apt Alpine → apk Windows → WinRM
Y esto nos permite empezar a ver por qué Ansible resulta tan interesante cuando nuestro laboratorio empieza a crecer.
¿Y Windows?
También vamos a tocar Windows.
En nuestro laboratorio tenemos:
- Windows 11 Pro
- Windows Server Core 2019
Ansible puede administrar Windows, aunque la comunicación y algunas tareas son diferentes a Linux.
Esto nos permitirá ver algo bastante útil:
Ansible │ ┌────────────┴────────────┐ │ │ Linux Windows │ │ ┌─────┼─────┐ ┌────┴─────┐ │ │ │ │ │ Debian Ubuntu Alpine Win11 Server Core
Así que el manual no será simplemente:
"Instala Ansible y ejecuta ping".
La idea será llevarlo desde cero hasta utilizarlo realmente en un laboratorio heterogéneo.
El objetivo del manual
Al terminar tendremos algo parecido a esto:
┌─────────────────┐ │ PROXMOX │ └────────┬────────┘ │ ┌────────▼────────┐ │ Debian Ansible │ │ Controller │ └────────┬────────┘ │ ┌───────────────┼────────────────┐ │ │ │ ▼ ▼ ▼ Linux Linux Windows Debian/Ubuntu Alpine Win11 Server 2019
Y desde nuestro Debian podremos hacer cosas como:
Actualizar servidores
ansible linux -m ...
Comprobar máquinas
ansible all -m ping
Instalar paquetes
ansible debian -m ...
Gestionar servicios
ansible linux -m ...
Y, sobre todo, empezar a crear Playbooks, que serán los que realmente nos permitirán automatizar nuestro laboratorio.
Lo primero: instalar Ansible en el nodo controlador
Un solo nodo Debian será el “jefe” que habla con todos los demás.
Requisitos previos:
- Un Debian 12 recién instalado (o cualquiera que tengas).
- Acceso por SSH a todas las máquinas objetivo (con clave pública, no contraseña).
- Python 3 (viene por defecto en Debian 12).
Instalación (en el nodo controlador):
sudo apt update && sudo apt upgrade -y # Instala Ansible (desde los repos oficiales de Debian)
sudo apt install -y ansible # Verifica la instalación
ansible --versión # Verifica la versión de Phyton
python3 --version
🔑 Paso 2: Generar clave SSH para Ansible
Objetivo: Ansible se autentica sin contraseña hacia Debian/Ubuntu/Alpine y también más adelante hacia Windows (WinRM aparte).
Ahora en el controller, que en nuestro caso es en la MV Debian que tenemos en Proxmox, tenemos que ejecutar el código:
ssh-keygen -t ed25519 -b 4096 -C "ansible-controller" -f ~/.ssh/id_ed25519
Te va a pedir passphrase: Pero lo dejamos en blanco para el laboratorio, aunque en producción tendrías que usar un usuario y contraseña segura.
📤 Paso 3: Copiar la clave pública a todas las VMs/LXC
Vamos por lo simple: ssh-copy-id
Asumiendo que el usuario destino en Linux es el mismo en todas (ej. debian/ubuntu/alpine), por ejemplo:
*NdelA: En un entorno de producción, el usuario no debe de ser nunca el "root" o Administrador en Windows por seguridad, en el lab, pues lo dejamos como queramos ;-)
ssh-copy-id -i ~/.ssh/id_ed25519.pub debian@debian01
ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@ubuntu01
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@alpine01
y así en todos los equipos que tengamos...
📌 Ojo: Revisa esto antes de empezar con el SSH.
Resulta que tenemos bloqueado el SSH con el usuario root, para habilitarlo tenemos que hacer esto:
nano /etc/ssh/sshd_config y descomentamos la línea: PasswordAuthentication y le ponemos un YES en vez de lo que tiene:
Luego hacemos un python3 --version para ver si lo tenemos instalado:
🗂️ Paso 5: Inventario Ansible (para que luego todo encaje)
Ahora vamos a crear un inventario sencillo, por ejemplo:
Vamos a crear una carpeta ~/ansible-lab y dentro hacemos el fichero: inventory.ini con los nodos.
y creamos el fichero inventory.ini
Y lo probamos:
ansible pihole -i inventory.ini -m ping
Nos aparece un hermoso Warning, no te alarmes, es un aviso de Ansible sobre el descubrimiento automático de Python.
Mientras vemos que tenemos un pong, nos alegra ver que funciona.
Si te molesta el warning dichoso como a mí, en el inventory.ini, tienes que añadir una línea
que indique explícitamente qué intérprete Python debe usar Ansible.[linux:vars]ansible_python_interpreter=/usr/bin/python3
Y con eso ya no nos sale el warning.
Ejecutamos el ansible linux -i inventory.ini -m setup -a 'filter=ansible_distribution'
y nos dice las máquinas que tenemos online:Playbooks
Ahora vamos con los playbooks con lo que queremos que hagan:
Primer creamos una carpeta dentro en la misma altura donde teníamos creado el inventory.ini:
Y aquí empieza lo bueno: vamos a crear un único Playbook que:
Detecte el sistema operativo.Use apt en Debian/Ubuntu.Use apk en Alpine.Actualice los paquetes.Nos muestre claramente qué ha hecho.No ejecute nada en Windows.
creamos nuestro primer yml, lo vamos a llamar update-linux.yml con el contenido:
y una vez creado vamos a ejecutarlo:
ansible-playbook -i inventory.ini playbooks/update-linux.yml
Y ya tenemos los equipos actualizados.
Y como guinda del pastel, creamos una tarea para que lo lance semanalmenteY con esto tenemos ya un laboratorio Linux completamente gestionado desde Ansible.
Todo ello desde una sola consola y sin necesidad de ir conectándonos máquina por máquina.Hemos aprendido a:
✅ Instalar Ansible en nuestro controlador Debian
✅ Configurar acceso SSH mediante claves
✅ Crear un inventario organizado por grupos
✅ Ejecutar comandos remotos
✅ Comprobar el estado de las máquinas
✅ Detectar distribuciones automáticamente
✅ Actualizar Debian, Ubuntu y Alpine desde un único PlaybookPero si le dais cariño al post, prometo hacer una segunda vuelta.¿Y Windows?
Windows se ha quedado aparcado por ahora.
No porque Ansible no pueda gestionarlo, sino porque requiere una configuración adicional mediante WinRM, certificados, reglas de firewall y algunos ajustes que merece la pena explicar con calma para no volvernos locos a la primera prueba.
Además, quiero enseñarlo funcionando tanto contra Windows 11 como contra Windows Server Core 2019, que es donde realmente se pone interesante.
De momento sigo de vacaciones, así que toca disfrutar un poco antes de volver a pelearme
con WinRM... 😄
