Archivo del blog

Mostrando entradas con la etiqueta homelab. Mostrar todas las entradas
Mostrando entradas con la etiqueta homelab. Mostrar todas las entradas

01 noviembre 2026

Una vuelta por mi laboratorio doméstico


Estado actual de mi homelab



Hace bastante tiempo que hablo de herramientas concretas, pruebas y servicios, pero pocas veces he enseñado cómo está organizado realmente mi laboratorio a día de hoy.

La base de todo sigue siendo Proxmox. Con el paso de los años he probado distintas formas de montar entornos de pruebas y, para mi uso, sigue siendo una de las opciones más cómodas para gestionar máquinas virtuales y contenedores desde un único lugar, así ahorro espacio y energía.

Actualmente tengo varias máquinas y contenedores con funciones muy distintas.


La capa de virtualización


Dentro de Proxmox mantengo diferentes sistemas según las necesidades de cada servicio.

Debian: administración y automatización


Mi máquina Debian es probablemente la más utilizada de todo el laboratorio ya que es donde tengo instalado Ansible y es donde gestiono buena parte de la infraestructura.

Lo utilizo principalmente para mantener actualizado el entorno completo. En lugar de conectarme una por una a cada máquina para lanzar actualizaciones, comprobar paquetes o realizar tareas repetitivas, puedo hacerlo todo de forma centralizada mediante playbooks.

Reconozco que tardé demasiado en descubrir Ansible. Durante años hice muchas tareas manualmente porque "solo eran unos minutos". El problema es que esos minutos se repetían una y otra vez.

Desde que empecé a utilizarlo cambió bastante mi forma de administrar el laboratorio. Ya no se trata únicamente de ahorrar tiempo. También me permite ser más consistente, documentar lo que hago y repetir procesos cuando lo necesito sin depender de la memoria o de una colección interminable de comandos guardados en notas.

De todas las herramientas que he incorporado al homelab en los últimos años, probablemente Ansible sea una de las que más impacto ha tenido en mi día a día. Me abrió la puerta a una forma mucho más cómoda de gestionar sistemas y entender la automatización.

Ubuntu: el cerebro de la IA local


La máquina Ubuntu está dedicada prácticamente por completo a la inteligencia artificial local.

Aquí es donde se ejecuta Ollama y donde residen los distintos modelos de lenguaje que voy probando, se  podría decirse que es el "cerebro" del laboratorio.

Además, es con diferencia la máquina que más recursos consume de toda la infraestructura. Los modelos actuales no se conforman precisamente con poca memoria o unos pocos núcleos, así que decidí reservar una máquina específica para esta función.

Mantener la IA aislada del resto de servicios me permite experimentar con nuevos modelos, actualizar versiones y realizar pruebas sin afectar a otras partes del laboratorio. Es una separación que agradezco especialmente cuando toca hacer cambios, porque los modelos pueden ser bastante exigentes y no siempre sale todo bien a la primera.

Aunque tengo varios servicios funcionando en paralelo, esta es probablemente la máquina más potente de todo el entorno. Al final, cuando empiezas a jugar con modelos de lenguaje locales, entiendes rápidamente por qué el hardware termina convirtiéndose en parte de la conversación.



Pi-hole


Uno de los servicios más veteranos del laboratorio y, probablemente, el más utilizado.

Llegó cuando mis hijos empezaron a utilizar más dispositivos conectados y yo quería tener algo más de control sobre lo que ocurría en la red doméstica. Lo instalé originalmente en una Raspberry Pi 3B+ y durante bastante tiempo funcionó sin dar ningún problema.

De hecho, fue uno de los motivos que me empujó a montar el servidor actual. A medida que se fueron sumando móviles, tablets, televisores... la Raspberry empezó a quedarse corta para todo lo que tenía que gestionar, el problema fué al querer comprar una rpi4 o una rpi5 que valían mucho más que mi actual equipo.

Actualmente Pi-hole se encarga del filtrado DNS de toda la red doméstica, bloqueando publicidad, dominios no deseados y determinadas conexiones antes incluso de que lleguen a los dispositivos.

Es una de esas herramientas que pasan completamente desapercibidas mientras funcionan. Pero el día que la apagas, todo el mundo se da cuenta enseguida.

Metube


Lo utilizo para gestionar determinadas descargas mediante una interfaz web sencilla.

Es un servicio pequeño, pero muy práctico para evitar depender constantemente de la línea de comandos.

Jellyfin


Mi servidor multimedia.

Aquí centralizo películas, series y otros contenidos para poder acceder a ellos desde cualquier dispositivo de casa sin depender de plataformas externas.

Además, aproveché para digitalizar mi colección de DVD. Hacía años que apenas los utilizaba y, siendo sincero, ya no tengo ningún lector conectado de forma permanente en casa. De esta forma puedo seguir disfrutando de ese contenido sin tener que buscar discos cada vez que quiero ver algo y conectar trastos en el comedor.

Como efecto secundario, también conseguí liberar bastante espacio físico. Cualquiera que haya acumulado películas durante años sabe que unas cuantas estanterías recuperadas siempre vienen bien para otros proyectos.

Máquinas Windows


También mantengo varios sistemas Windows destinados exclusivamente a pruebas y laboratorio.

Actualmente cuento con:

  • Windows Server Core 2019.
  • Windows 11, configurado como mi SAW (Secure Admin Workstation) para el entorno Windows.
La idea es disponer de un entorno lo más parecido posible a los escenarios que puedo encontrar en el trabajo o durante sesiones de aprendizaje.

Windows Server Core me resulta especialmente útil para practicar administración sin depender de una interfaz gráfica, obligándome a utilizar PowerShell, gestión remota y otras herramientas que muchas veces terminan siendo el camino más eficiente en entornos reales.

Por otro lado, mantengo Windows 11 como estación de administración segura del laboratorio. Desde ella realizo tareas administrativas, pruebas de herramientas y validaciones de configuración antes de aplicarlas en otros sistemas.

Aunque la parte de Linux ocupa una parte importante del laboratorio, sigo dedicando tiempo a la plataforma Microsoft. Al fin y al cabo, es una tecnología con la que llevo trabajando muchos años y sigue formando parte de mi día a día.

CasaOS como puerta de entrada


Además de la infraestructura principal, utilizo CasaOS como capa de acceso para varios servicios desplegados mediante contenedores. 

Su objetivo es bastante simple: disponer de un panel cómodo desde el que acceder rápidamente a las aplicaciones que utilizo con más frecuencia y, al mismo tiempo, tener un entorno donde probar nuevos contenedores sin comprometer el resto del laboratorio.

Una de las cosas que más me gustan de CasaOS es precisamente esa facilidad para desplegar servicios en cuestión de minutos. Prácticamente cada día aparecen nuevos proyectos interesantes y resulta muy cómodo poder probarlos de forma rápida antes de decidir si merecen un hueco permanente en la infraestructura.

Si un servicio demuestra ser útil, estable y seguro tras un tiempo de uso, entonces me planteo migrarlo a una máquina o contenedor dedicado dentro de Proxmox. 

De esta forma puedo experimentar sin poner en riesgo otros servicios que ya forman parte del día a día.

Actualmente tengo desplegados:

Open WebUI:  La interfaz que utilizo para interactuar con Ollama estilo chatGPT.

Nginx: Lo utilizo como servidor web y punto de publicación para distintos servicios internos.

n8n: Mi plataforma de automatización, aquí recogemos "webhoooks" para interactuar con nuestro lab y Petete, la IA interna que se encarga de gestionarlo y avisarme por si pasa algo.

Excalidraw: Seguramente sea la aplicación más utilizada de CasaOS, al final pasará a Proxmox.
La instalé inicialmente por curiosidad y pensando en hacer algún esquema rápido, pero la realidad es que quienes más la aprovechan son mis hijos. La utilizan para practicar caligrafía, hacer ejercicios de matemáticas, dibujar y escribir cualquier cosa que se les ocurra, es una pizarra infinita. 
Al final se ha convertido en una especie de pizarra digital disponible desde cualquier dispositivo de casa.
No era el uso que tenía pensado cuando la instalé, pero probablemente sea uno de los servicios que más horas de uso acumula de todo el laboratorio. Y de paso gastamos bastantes menos folios y salvamos el Amazonas.

Fastfetch: Un pequeño servicio que utilizo para verificar información de sistemas y realizar consultas rápidas, no es especialmente complejo, pero resulta cómodo tenerlo siempre disponible, es más por curiosidad que por otra cosa.

La instalación de CasaOS reside sobre dos discos configurados en RAID0. Al tratarse principalmente de un entorno de pruebas y servicios no críticos quería hacer pruebas de configuración, para ver como se comportaba, pero si algún día algo se rompe, la idea es poder reconstruirlo rápidamente en lugar de protegerlo como si fuera un entorno de producción.

PD: Actualmente CasaOS está en desuso. Parece que el desarrollo está centrándose en ZimaOS y, mientras tanto, estoy revisando otras alternativas como LGM-OS, que la verdad me está sorprendiendo bastante.

Intentando no complicarlo más de la cuenta

Como casi todos los homelabs, este entorno ha cambiado muchas veces a lo largo de los años.

He añadido servicios, eliminado otros, migrado sistemas y probado herramientas de todo tipo. Algunas se han quedado durante años y otras apenas han durado un fin de semana antes de desaparecer.

Con el tiempo he llegado a una conclusión bastante simple: mantener un laboratorio útil suele ser más interesante que acumular aplicaciones que apenas utilizamos. Es fácil instalar veinte contenedores en una tarde. Lo difícil es mantenerlos actualizados, documentados y funcionando cuando realmente los necesitas.

También creo que herramientas como CasaOS, LGM, ZimaOS o similares son una excelente puerta de entrada al mundo del homelabber. Permiten perder el miedo a Docker, descubrir nuevos servicios y entender todo lo que se puede montar en casa con relativamente poco esfuerzo.

Pero muchas veces el aprendizaje de verdad empieza cuando quieres ir un poco más allá. Cuando intentas entender qué está pasando por debajo, automatizar tareas con Ansible, montar un proxy inverso, gestionar copias de seguridad o mover un servicio a una máquina dedicada porque ya forma parte de tu día a día.

A día de hoy intento que cada máquina tenga una función clara. Algunas están orientadas a automatización, otras a inteligencia artificial, otras a multimedia y otras simplemente a experimentar.

Y siendo sincero, probablemente dentro de unos meses esta misma publicación ya esté desactualizada.

Eso también forma parte de tener un homelab. Empiezas instalando una aplicación por curiosidad, después pruebas otra más y, casi sin darte cuenta, terminas reorganizando toda la infraestructura para hacer hueco a una nueva idea.

09 octubre 2026

Petete ya está en marcha: instalando Ollama sobre Proxmox con iGPU Intel

La instalación de Petete ha ido sorprendentemente bien. Que ya es decir, ahora  me ha tocado sudar lo que no está escrito para que me funcione con mi Proxmox, y no es por otra cosa que "sus bajos recursos" para lanzar una IA.

La base del proyecto es un contenedor LXC en Proxmox utilizando una imagen de Ubuntu. Una vez desplegado, le hemos asignado recursos sin demasiada compasión, actualizado todos los paquetes y preparado el terreno para empezar a jugar con la IA local.


Pero antes; ¿Qué es Ollama y para qué sirve?

Ollama permite ejecutar modelos de inteligencia artificial directamente en tu ordenador o servidor, sin depender de plataformas externas ni enviar tus conversaciones a servicios en la nube.

Con él puedes descargar y ejecutar modelos como Llama, Qwen, Gemma o DeepSeek, además de integrarlos en otras aplicaciones mediante una API. Si quieres una interfaz gráfica, puedes combinarlo con Open WebUI y tener tu propio asistente de IA accesible desde el navegador.

Lo mejor es que puedes montarlo en tu propio servidor Linux, controlar qué modelos utilizas y experimentar con inteligencia artificial en tu homelab sin necesidad de contratar servicios de pago.

Pero recuerda: El rendimiento dependerá del hardware y de la memoria disponibles.


Primer paso: instalar Ollama


La instalación es tan sencilla como ejecutar un comando por terminal, pero antes necesitamos tener instalado zstd, que es un algoritmo de compresión de datos, como ZIP o GZIP.

Así que primero vamos a instalarlo:

    sudo apt install zstd -y

Y con el zstd --version comprobamos que está


La instalación es tan sencilla como ejecutar:

    curl -fsSL https://ollama.com/install.sh | sh


Una vez completada la instalación, aprovechamos para instalar también el cliente SSH y dejar el entorno listo para trabajar cómodamente desde cualquier terminal.

Y con eso, primer objetivo cumplido: Ollama ya está instalado



Intentando aprovechar la iGPU

Como el equipo dispone de gráfica integrada Intel, la idea era intentar exprimirla para acelerar la ejecución de los modelos, ya que no tenemos una gráfica Nvidia ni una AMD.... así que vamos  a intentar aprovecharla.

Lo primero fue detener el servicio de Ollama y lanzarlo manualmente utilizando Vulkan:


Una vez parado ponemos:

    OLLAMA_VULKAN=1 ollama serve

El resultado fue prometedor: Ollama detectaba la GPU, sabía que existía... pero prácticamente la ignoraba por tratarse de una iGPU. Vamos, que la veía pero no quería salir con ella...


Forzando el uso de la gráfica integrada

Para convencer a Ollama de que la iGPU también merece amor, editamos el servicio:

    nano /etc/systemd/system/ollama.service

Y añadimos las siguientes líneas extras:

Environment="OLLAMA_VULKAN=1" 
Environment="OLLAMA_IGPU_ENABLE=1"


Tras reiniciar el servicio parecía que todo iba a funcionar... pero no. La GPU seguía resistiéndose.


El problema real: permisos


Después de varias pruebas, descubrimos que el verdadero problema no estaba en Vulkan ni en Ollama, sino en los permisos.

El usuario que ejecuta Ollama no pertenecía al grupo con acceso a los dispositivos gráficos, por lo que la aplicación simplemente no podía utilizarlos, así que un pequeño ajuste en los grupos del sistema, reinicio correspondiente y... ahora sí. Ollama podía acceder correctamente a la iGPU.



Y comprobamos que ahora el grupo ollama tiene acceso:


Primera prueba de fuego

Con todo funcionando, llegó el momento más satisfactorio de cualquier instalación: descargar el primer modelo.

Como estamos trabajando en un equipo modesto y sin una gráfica dedicada potente, la descarga y preparación inicial requiere algo de paciencia. Aproximadamente cinco minutos de espera para el primer arranque.

Nada dramático. Tiempo suficiente para un café y para pensar en la siguiente locura que vamos a intentar automatizar



Conclusiones


La instalación de Ollama sobre Proxmox ha resultado mucho más sencilla de lo esperado. La parte más delicada ha sido conseguir que la gráfica integrada Intel fuese realmente utilizable, pero una vez resuelto el tema de permisos, todo ha quedado funcionando correctamente.


Petete ya está vivo.



Porque, seamos sinceros, la inteligencia artificial está muy bien para generar imágenes espectaculares, escribir poemas o discutir sobre filosofía. Pero su verdadera prueba de fuego será evitar que vuelva a descubrir a las dos de la madrugada que el almacenamiento está al 100% y media infraestructura ha decidido declararse en huelga. Esa será su primera tarea. Y probablemente la más importante. 😅






25 agosto 2026

Ansible: Poniendo orden en mi laboratorio Proxmox

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):

ObjetivoEstado
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):

# Actualiza el sistema
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: 



Verás que en el Alpine, no viene configurado el Python3, viene bastante pelado por defecto, por lo que tendremos que instalarlo para que funcione:

apk update && apk add python3


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 semanalmente

 

Y con esto tenemos ya un laboratorio Linux completamente gestionado desde Ansible.

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 Playbook

Todo ello desde una sola consola y sin necesidad de ir conectándonos máquina por máquina.


¿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.

Pero si le dais cariño al post, prometo hacer una segunda vuelta.
De momento sigo de vacaciones, así que toca disfrutar un poco antes de volver a pelearme
con WinRM... 😄

Koozali SME Server en 2026: ¿la alternativa olvidada para las pymes?

Hace unos días un amigo me llamó para hacerme una consulta bastante habitual. Trabaja en una pequeña gestoría de barrio. Son cuatro empleado...