PegaProx Docker Manager v2.0.0: del Swarm puro a Docker estándar
El plugin que orquestaba Docker Swarm en PegaProx ahora también corre en hosts Docker standalone. Mismo nombre técnico, nueva identidad: Docker Manager. Modo auto-detectado, 142 tests, deploy LIVE en cluster IDK.
TL;DR
El plugin docker_swarm de PegaProx — el que usamos para orquestar nuestro cluster de tres managers en producción — acaba de saltar a la versión v2.0.0. Cambió el nombre visible a “Docker Manager” porque ahora detecta automáticamente si el host es un Swarm o un Docker standalone y ajusta su UI sin configuración. El identificador técnico del plugin (docker_swarm) se mantiene para no romper instalaciones existentes.
Si ya tienes el plugin instalado en tu PegaProx 0.9.9.x, la actualización es transparente: clonas el repo, recargas el servicio y obtienes la nueva versión.
Qué cambia (y qué no)
Cambia
- Nombre visible en la UI de PegaProx: “Docker Swarm Manager” → “Docker Manager”.
- Modo auto-detectado vía
docker info(LocalNodeState): siactive, render UI Swarm; siinactive, render UI standalone. - Vista standalone nueva: contenedores, imágenes, volúmenes y redes en un dashboard simplificado, sin el ruido de servicios/réplicas/constraints que en standalone no aplican.
- 142 tests verdes sobre los 107 anteriores: cobertura nueva sobre la rama standalone y sobre los hooks de PegaProx 0.9.9.3.
- Hardening regex con
\Zen validadores de paths (tabula menos falsos positivos al matchear nombres de stack que terminan con caracteres especiales).
No cambia
- Plugin id: sigue siendo
docker_swarmpara preservar la migración suave desde v1.x. - API interna del plugin (
register(app)+register_plugin_route(...)): los plugins de terceros que dependen de los hooks no necesitan ajustes. - Storage del state: misma DB SQLite de PegaProx, mismas tablas.
Por qué un plugin plataform-aware
Llevamos el plugin a producción originalmente porque nuestro cluster necesitaba una UI honesta para Docker Swarm que mostrara el estado real (réplicas, constraints, drift entre managers, eventos de service update). Pero en muchos despliegues más pequeños — labs, edge devices, hosts unicornio — Swarm es overkill. Forzar al usuario a leer la UI de Swarm cuando está usando un Docker plano genera fricción gratuita.
La solución correcta no era partir el plugin en dos. Era detectar el modo en runtime y renderizar la vista que corresponde. Una sola distribución, dos experiencias coherentes.
Verificado en dos hosts diferentes
Antes de cortar la versión hicimos un dry-run lado a lado:
- LXC 119 (
pegaproxen pve1) — host Swarm de 3 managers IAS01/02/03. Vista Swarm completa: services, tasks, constraints, drift de réplicas, logs por task. ✅ - LXC 200 (
docker-testen pve2, IP190.160.10.220) — host Docker standalone, sinswarm init. Vista standalone: containers, images, volumes, networks, sin elementos Swarm. ✅
El swap se hizo cambiando un solo campo en el config del plugin (host: 190.160.10.220). El plugin detectó el cambio de modo en el siguiente refresh sin reiniciar el servicio.
Qué viene después
- v2.1: edición inline de constraints y placement preferences sin abrir un editor externo.
- v2.2: history de service updates con diff visual para detectar drift entre lo declarado en stack files y lo actualmente desplegado.
- v3.0 (concept): soporte para Kubernetes (modo auto-detectado igual). Aún en exploración.
El repo público está en github.com/idkmanager/pegaprox-docker-swarm. Issues, PRs y casos de uso son bienvenidos.
Mantenemos el repo bajo el nombre
pegaprox-docker-swarmpor compatibilidad histórica. La versión v2 trae la nueva identidad sin romper enlaces.