Cómo centralicé 11 servidores Docker con Dockpeek

Cuando tu homelab empieza a crecer, te enfrentás a un lindo problema acorde a lo que estás armando. Pasás de tener un servidorcito con tres contenedores a desplegar una flota entera. En mi caso: 11 contenedores LXC en Proxmox, cada uno corriendo su propio ecosistema Docker (Mastodon, Matrix, Immich, Jellyfin, la suite Arr, Peertube... una locura hermosa).

El problema es obvio: monitorear el estado de las imágenes, revisar los logs en vivo o ver qué puertos están libres se convierte en un suplicio de abrir terminales SSH o saltar entre pestañas de Portainer.

Buscando una solución liviana y estética, me topé con Dockpeek. Es un dashboard auto-alojado espectacular que te permite centralizar múltiples hosts de Docker en una sola pantalla.

Pero como toda buena historia de éste mundillo hermoso, la instalación "out of the box" falló y hubo que meter manos en la masa para resolver un clásico misterio de redes. Hoy te cuento cómo lo solucioné.

APIs ciegas y el puerto 2375

El plan era sencillo. Dockpeek corre en un contenedor central y se conecta al resto de los servidores remotos a través de la API de Docker (usando el puerto por defecto 2375).

Configuré el archivo docker-compose.yml principal con la lista de mis 11 IPs, levanté el panel y... todos los servidores remotos aparecieron en gris. Caídos.

Por defecto, el demonio de Docker (dockerd) es extremadamente tímido: solo escucha peticiones locales a través de su socket interno (docker.sock). No habla con el mundo exterior.

Intenté levantar un contenedor Socket Proxy (el famoso guardia de seguridad que lee el socket local y lo expone de forma segura hacia la red) en el puerto 2375 de uno de mis LXC remotos, pero la consola me escupió el siguiente error:

docker: Error response from daemon: Bind for 127.0.0.1:2375 failed: port is already allocated

¿El puerto ya estaba ocupado? Tiré un comando de diagnóstico para ver quién era el dueño del puerto 2375 en el LXC:

ss -tlnp | grep 2375

# Resultado: 127.0.0.1:2375 - users:(("dockerd",...))

¿Qué pasaba? El mismísimo Docker nativo del LXC ya estaba usando el puerto 2375, pero con una trampa: estaba atado a 127.0.0.1 (localhost). Es decir, el puerto estaba ocupado para el sistema, pero completamente sordo para mi red local (192.168.0.X). Un callejón sin salida.

Solución: El al puerto 2376

Para no desconfigurar el Docker nativo de cada LXC y evitar colisiones, la jugada fue estandarizar un puerto alternativo que estuviera libre en toda la red: el 2376.

En lugar de pelear con la configuración interna del sistema operativo, desplegué el proxy de seguridad en el puerto 2376 de forma masiva en cada uno de los LXC remotos.

1) El comando a ejecutar en cada LXC remoto

Entré por SSH a cada uno de mis servidores remotos y ejecuté este docker run. Este proxy es genial porque expone la API de Docker hacia la red local, pero en modo solo lectura, impidiendo que cualquiera pueda borrar contenedores de forma remota:

docker run -d \
  --name dockpeek-socket-proxy \
  -p 2376:2375 \
  -e CONTAINERS=1 \
  -e IMAGES=1 \
  -e PING=1 \
  -e VERSION=1 \
  -e INFO=1 \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --restart unless-stopped \
  lscr.io/linuxserver/socket-proxy:latest

(Fijate que en -p 2376:2375: el contenedor adentro escucha en el 2355, pero hacia afuera del LXC lo abrimos en el 2376).

2) El archivo de configuración de Dockpeek unificado

Con todos los proxies remotos escuchando felices en el puerto 2376, volví a mi servidor principal y estructuré el docker-compose.yml de Dockpeek. Pasó de ser un caos a algo más organizado:

services:
  dockpeek:
    image: dockpeek/dockpeek:latest
    container_name: dockpeek
    restart: unless-stopped
    ports:
      - "3420:8000"
    environment:
      - SECRET_KEY=tu_clave_secreta_aqui
      - USERNAME=neoadmin
      - PASSWORD=tu_password_aqui

      # Host 1: El local donde vive Dockpeek
      - DOCKER_HOST_1_URL=unix:///var/run/docker.sock

      # Hosts Remotos: Todos estandarizados al puerto 2376
      - DOCKER_HOST_2_URL=tcp://192.168.0.135:2376
      - DOCKER_HOST_2_NAME=Servicios de Red

      - DOCKER_HOST_3_URL=tcp://192.168.0.132:2376
      - DOCKER_HOST_3_NAME=Servicios Varios

      - DOCKER_HOST_4_URL=tcp://192.168.0.30:2376
      - DOCKER_HOST_4_NAME=Mastodon

      - DOCKER_HOST_5_URL=tcp://192.168.0.247:2376
      - DOCKER_HOST_5_NAME=immich-server

      # ... (Y así repetido armónicamente hasta el Host 11)
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

El resultado: Dockpeek estaba vivo

Tiré un docker compose up -d en el panel central, entré al navegador en el puerto 3420 y la magia ocurrió: los 11 servidores remotos se pusieron en verde al mismo tiempo.

A partir de ahí, el control es absoluto:

• Puedo ver las decenas de contenedores distribuidos por mi red en una sola lista limpia.

• Tengo acceso a los logs en tiempo real de cualquier servicio sin abrir una sola terminal SSH.

• Dockpeek me avisa con un botón flotante qué contenedores tienen actualizaciones pendientes en Docker Hub (y si lo tenés configurado con la última imagen podés actualizarlo directamente desde ahí).

Seguridad ante todo:

Lo mejor de este setup es que si la IP de Dockpeek se ve comprometida, los servidores remotos están a salvo. Al usar el socket-proxy en modo restringido, nadie puede enviar comandos destructivos (como POST para borrar volúmenes o apagar servicios) a través de la red.

Dockpeek mostrando los servicios de mi contenedor con Mastodon y Matrix. Si ves a los lados cada etiqueta pertenece a cada contenedor por separado que se configuró en el docker-compose.yml

¿Vos cómo manejás el monitoreo de tus contenedores cuando se empiezan a multiplicar? ¡Te leo en los comentarios!