Configurar Rundeck Proxmox API es el siguiente paso lógico después de tener Rundeck instalado en el LXC. Una cosa es que el servicio arranque y otra distinta dejarlo preparado para hablar con Proxmox por API, guardar el token con algo de orden y empezar a montar una base útil para automatizar tareas en el homelab.
En este montaje sigo con la misma idea del artículo anterior: una sola red, una sola IP para Rundeck y conexión directa con el nodo Proxmox, sin máquina de salto ni historias extra.
En el artículo anterior dejé Rundeck instalado en un LXC de Proxmox, con una sola red y sin complicarme todavía con nada más. Ese era el primer paso. Tener el servicio arrancado y accesible por web.
Ahora toca dejarlo un poco más serio.
Porque una cosa es tener Rundeck funcionando, y otra distinta es tenerlo preparado para hablar con Proxmox por API sin dejar tokens pegados en cualquier sitio ni montar luego el caos cuando empiecen a crecer los jobs. Y aquí, aunque sea un homelab o un laboratorio pequeño, merece la pena dejar una base mínimamente ordenada desde el principio.
En este montaje sigo con la misma idea del artículo anterior. Nada de varias redes, nada de máquina de salto y nada de separar gestión y servicio. Solo una LAN normal, un nodo Proxmox y un LXC de Rundeck con una IP fija.
Requisitos
Aquí doy por hecho que ya tienes Rundeck instalado y accesible por web dentro de tu contenedor LXC. También doy por hecho que el nodo Proxmox y el contenedor de Rundeck están en la misma red y que ambos se ven entre sí sin historias raras.
Para este ejemplo voy a seguir con un esquema muy simple:
Red LAN: 192.168.10.0/24
Proxmox: 192.168.10.10
Rundeck LXC: 192.168.10.50
Puerto API Proxmox: 8006
Puerto web Rundeck: 4440Con eso ya basta para dejar la parte base configurada.
Arquitectura o escenario de partida
En este segundo artículo, la foto sería esta:
Proxmox VE -> 192.168.10.10
Rundeck LXC -> 192.168.10.50Rundeck no va a entrar por SSH a ningún salto ni a otra red intermedia. Va a hablar directamente con la API de Proxmox para validar conectividad y, más adelante, para lanzar despliegues.
Crear un usuario de automatización en Proxmox
Yo aquí no usaría root@pam ni una cuenta personal. Aunque sea un lab, prefiero dejar una cuenta dedicada para automatización desde el principio.
La idea es crear un usuario específico en Proxmox para Rundeck y, sobre ese usuario, generar un API Token. Así el acceso queda más limpio y, si más adelante cambias permisos o rotas el token, no rompes otras cosas que no tengan nada que ver.
Si estás empezando, puedes arrancar con permisos de solo lectura para validar que la API responde y que Rundeck llega bien. Cuando pases al tercer artículo y empieces a desplegar contenedores o máquinas, ya tocará darle permisos más amplios para crear recursos.
Yo aquí lo dejaría con algo así a nivel lógico:
Usuario API: automation@pve
Token: rundeckNo hace falta complicarlo más de la cuenta. Lo importante es que sea una cuenta separada y que no dejes la automatización colgando de un usuario que luego vayas a tocar por otra parte.
Validar que Rundeck llega a la API de Proxmox
Antes de meterte en proyectos, tokens y Key Storage, yo haría una prueba muy simple desde el propio LXC de Rundeck para asegurarme de que la red está bien y que el puerto de la API responde.
Desde el contenedor, lanza algo como esto:
curl -k https://192.168.10.10:8006/api2/json/versionSi esto responde, ya sabes al menos tres cosas. Que Rundeck ve al nodo Proxmox, que el puerto 8006 está accesible y que la API está levantada.
Después de esa prueba básica, puedes hacer otra ya autenticada con el token que acabas de crear. Por ejemplo:
curl -k \
-H "Authorization: PVEAPIToken=automation@pve!rundeck=TU_TOKEN_AQUI" \
https://192.168.10.10:8006/api2/json/nodesAquí no me interesa todavía montar nada raro. Solo confirmar que la autenticación funciona y que la respuesta tiene sentido.
Si esto falla, no tiene ningún sentido seguir tocando Rundeck. Primero arreglas API, red o permisos. Luego sigues.
Crear el proyecto en Rundeck
Una vez que la conectividad base con Proxmox está validada, ya sí tiene sentido entrar en Rundeck y crear el proyecto sobre el que vas a trabajar.
Yo aquí lo dejaría muy simple. Un proyecto nuevo, con un nombre claro y sin meter todavía plugins ni historias extrañas. Algo tipo:
proxmox-labO si quieres algo más legible en la interfaz:
Proxmox LABLo importante no es el nombre. Lo importante es que el proyecto te sirva luego para agrupar jobs, claves, scripts y toda la parte que vas a ir montando.
En este punto yo suelo dejar claras tres cosas desde el principio: el host de Proxmox, la ruta base donde voy a guardar scripts o playbooks y cómo voy a nombrar los jobs. Cuanto antes hagas eso, menos desorden te llevas después.
Guardar el token en Rundeck sin dejarlo en claro
Aquí es donde ya merece la pena hacer las cosas con algo de orden.
Aunque estés en tu casa o en un entorno pequeño, yo no dejaría el token pegado en un script, en un job inline o en una nota rápida dentro del LXC. Luego esas chapuzas se quedan más tiempo del que deberían.
Lo razonable es guardarlo en Key Storage dentro de Rundeck.
Puedes crear una ruta sencilla, por ejemplo algo así:
keys/proxmox/api-tokenY ahí guardar el valor del token o, si prefieres, dejar preparada una estructura un poco más limpia:
keys/proxmox/user
keys/proxmox/token-id
keys/proxmox/token-secretYo para un lab sencillo no me volvería loco. Con guardar bien el secreto y dejar claro qué usuario y qué token se están usando, ya vas bien.
La clave aquí no es solo que funcione. La clave es que, cuando dentro de unas semanas empieces a montar jobs, no tengas que ir buscando credenciales por medio sistema.
Dejar una estructura mínima de trabajo en el LXC
Esto no es obligatorio, pero yo lo haría desde el minuto uno.
Dentro del contenedor de Rundeck dejaría un directorio sencillo para todo lo que vaya a usar luego con Proxmox. Por ejemplo:
sudo mkdir -p /opt/rundeck-lab/{scripts,logs,tmp}
sudo chown -R rundeck:rundeck /opt/rundeck-labCon eso tienes una base limpia para meter pequeños scripts de validación, logs de prueba o ficheros temporales sin terminar mezclándolo todo en cualquier sitio.
No hace falta montar todavía una estructura enorme. Solo dejar un poco de orden.
Crear un primer job de validación en Rundeck
Aquí todavía no voy a desplegar nada. Solo quiero tener un job sencillo que me diga que Rundeck ve a Proxmox.
Yo crearía un job con un nombre claro, algo así:
Validar API ProxmoxY como primer paso, metería un script muy simple que haga la validación básica del endpoint de versión:
#!/bin/bash
set -e
PROXMOX_HOST="192.168.10.10"
echo "Validando API de Proxmox en https://${PROXMOX_HOST}:8006 ..."
curl -k --silent --fail "https://${PROXMOX_HOST}:8006/api2/json/version"
echo
echo "API accesible"Esto no autentica todavía con el token, pero para una primera comprobación desde Rundeck me parece suficiente. Si este job falla, ya sabes que no hay que mirar todavía proyectos ni despliegues. Hay que mirar conectividad básica.
Cuando ese job funcione, ya puedes crear un segundo job, o ampliar este, para probar la autenticación real con el token guardado de forma segura.
Qué dejaría preparado antes del siguiente artículo
Aquí yo no intentaría correr más.
Si ya tienes Rundeck levantado, proyecto creado, token generado, conectividad validada y una primera estructura mínima dentro del LXC, ya tienes la base que hace falta para el siguiente paso.
Y ese siguiente paso sí tendrá más sentido: lanzar desde Rundeck un despliegue real en Proxmox.
Antes de llegar ahí, yo comprobaría una última vez estas cuatro cosas. Que la API responde. Que el token funciona. Que el proyecto en Rundeck ya está creado. Y que no has dejado ningún secreto pegado en texto claro donde no toca.
Problemas comunes
Aquí lo normal es tropezar con cosas bastante concretas.
La primera es que el puerto 8006 no responda desde el LXC de Rundeck. Si eso pasa, antes de tocar nada más revisaría IP, gateway, DNS si aplica y conectividad básica entre ambos equipos.
La segunda es que el token exista, pero no tenga los permisos que necesita. Esto es bastante habitual. Validar la API con un endpoint simple puede funcionar, pero cuando empieces a crear recursos verás rápido si le faltan permisos.
La tercera es dejar el token pegado directamente en scripts de prueba y olvidarse luego de quitarlo. Esto en laboratorio pasa mucho más de lo que debería. Yo intentaría evitarlo desde el primer día.
La cuarta es empezar a crear jobs con nombres raros, scripts sueltos y rutas improvisadas. No rompe nada al principio, pero luego convierte Rundeck en un cajón desastre muy rápido.
Conclusión
La instalación de Rundeck era solo el primer paso. La parte importante empieza cuando dejas el entorno preparado para hablar con otros sistemas sin hacerlo todo deprisa y mal.
En este caso, configurar bien Rundeck para Proxmox no tiene demasiada magia. Se trata de validar la API, crear un usuario de automatización, guardar bien el token y dejar el proyecto un poco ordenado desde el principio. Con eso ya tienes una base bastante mejor que la típica instalación que arranca rápido pero luego no hay por dónde coger.
En resumen, dejar bien montado configurar Rundeck Proxmox API desde el principio te ahorra bastante desorden cuando luego empieces a crear jobs y despliegues reales.
En el siguiente artículo ya sí tocará lo interesante: usar esta base para lanzar un despliegue sencillo en Proxmox desde Rundeck y empezar a automatizar algo real.
Espero que os sirva