Descubrimiento automático de servicios Docker

En pocas palabras: Portracker es una herramienta open source de mostafa-wahied, publicada en GitHub, que escanea los puertos abiertos de un servidor y los cruza con el daemon de Docker para armar un inventario web de servicios. Corre en Linux, Docker y TrueNAS, y guarda todo en SQLite sin base de datos externa.

Portracker es una herramienta open source que escanea automáticamente los puertos en uso de un servidor y los cruza con los contenedores de Docker para armar un inventario navegable desde el navegador. El proyecto vive en GitHub bajo el usuario mostafa-wahied, corre en Linux, Docker y TrueNAS, y no necesita base de datos externa: guarda todo en SQLite. Si alguna vez te preguntaste “¿qué carajo está escuchando en el 8080?”, esto es para vos.

El descubrimiento automático de servicios Docker con portracker consiste en leer el estado real del sistema (puertos abiertos vía las herramientas del sistema operativo) y combinarlo con la información que expone el daemon de Docker sobre qué contenedor publicó qué puerto. El resultado es una interfaz web que lista servicios, hosts y puertos sin que nadie tenga que mantener una planilla a mano. Es un inventario vivo, no documentación.

En 30 segundos

Qué es: portracker, proyecto open source de mostafa-wahied alojado en GitHub, que descubre y lista los puertos y servicios de un servidor.
Dónde corre: Linux, Docker y TrueNAS. También hay guías de instalación para NAS de Synology publicadas por terceros.
Sin dependencias pesadas: usa SQLite embebido, no requiere PostgreSQL, Redis ni un cluster de consenso.
Multi-host: podés agregar otras instancias como peers y ver todo desde una sola pantalla.
Ojo: es un inventario, no un firewall ni una herramienta de seguridad. No cierra nada, solo te muestra qué hay.

¿Por qué automatizar el descubrimiento de servicios es crítico en Docker?

Porque en un host con Docker los puertos cambian sin que nadie avise. Cada docker compose up puede publicar puertos nuevos, un contenedor reiniciado con -P agarra un puerto efímero distinto, y la planilla que hiciste en marzo ya no sirve en julio. El descubrimiento automático de servicios Docker resuelve eso leyendo el estado real del sistema en vez de confiar en documentación escrita por humanos apurados.

Ponele que tenés un homelab con doce contenedores. Levantás uno nuevo, te tira “port is already allocated”, entrás a buscar quién lo tiene tomado, corrés docker ps, no aparece, corrés ss -tulpn, resulta que era un servicio del host que instalaste hace ocho meses y te olvidaste.

Ese es el escenario cotidiano. Y escala mal: multiplicá por tres servidores y ya perdiste media tarde.

El otro problema es de superficie de exposición. Un servicio que quedó escuchando en 0.0.0.0 cuando debía estar en 127.0.0.1 es una puerta abierta que nadie recuerda haber dejado así, y si no tenés un inventario que te lo muestre en pantalla, no lo vas a descubrir hasta que alguien más lo descubra primero (spoiler: esa persona no te va a avisar). Acá viene lo bueno: un listado automático de puertos por host te deja auditar eso en dos minutos. Más contexto en integrar en tu pipeline de CI/CD.

¿Cómo funciona el descubrimiento automático de puertos en portracker?

Portracker combina dos fuentes de datos: el escaneo de puertos abiertos del sistema operativo y la información que expone el daemon de Docker. Del sistema saca qué procesos están escuchando y en qué interfaz; de Docker saca a qué contenedor corresponde cada puerto publicado, su nombre y su imagen. Cruza ambas cosas, las guarda en una base SQLite local y las muestra en una interfaz web.

La distinción clave, y la que más confunde a quien recién arranca con contenedores, es entre puerto interno y puerto publicado. Un contenedor de nginx escucha en el 80 adentro de su namespace de red, pero si lo publicaste como -p 8443:80, desde afuera lo alcanzás en el 8443. Herramientas que solo miran el host ven el 8443 y no saben de quién es; herramientas que solo miran Docker ven el mapeo pero no ven los servicios del host que no están en contenedores.

Collectors por plataforma: el proyecto tiene recolectores distintos según dónde corra, con uno específico para TrueNAS además del genérico de Linux y Docker.
Persistencia SQLite: la base va en un archivo, con lo cual el backup es copiar un archivo y listo.
UI web: todo el consumo es desde el navegador, sin cliente de escritorio ni agente separado por servicio.
Peers: una instancia puede consultar a otras y presentar la vista agregada.

¿Qué requisitos tiene portracker para funcionar?

Necesitás un host con Docker corriendo y acceso al socket del daemon (/var/run/docker.sock), un navegador moderno y poco más. No hay que levantar PostgreSQL, ni Redis, ni un cluster de tres nodos para el quórum. Esa es la diferencia práctica más grande contra las soluciones de service discovery pensadas para producción distribuida.

Docker activo: sin daemon no hay metadata de contenedores, solo verías puertos sueltos sin dueño.
Socket montado: el contenedor de portracker necesita leer el socket para consultar la API de Docker. Es el requisito con más implicancias de seguridad, y lo tratamos abajo.
Espacio en disco mínimo: la base SQLite de un homelab pesa poco, no vas a notarla.
Navegador moderno: la UI es una app web, no hay binario de escritorio que instalar.

¿Cómo instalar portracker con Docker paso a paso?

La instalación estándar es un contenedor con el socket de Docker montado y un volumen para la base SQLite. La forma canónica y actualizada del comando está en el repositorio oficial en GitHub, que es la fuente que conviene mirar antes de copiar cualquier comando de un blog (incluido este). La estructura general es esta:

Creá el volumen de datos. Un directorio en el host donde va a vivir la base SQLite, así sobrevive a los recreados del contenedor.
Montá el socket de Docker en modo lectura. Con :ro al final del mount reducís (no eliminás) el riesgo del socket expuesto.
Publicá el puerto de la UI. Y acá va el consejo que casi nadie sigue: publicalo en 127.0.0.1 y llegá por túnel SSH o VPN, en vez de dejarlo escuchando en todas las interfaces.
Entrá a la UI y verificá el descubrimiento. Si el socket está bien montado, los contenedores aparecen con nombre e imagen, no como puertos anónimos.

Si preferís seguir un tutorial visual, hay un video de instalación disponible en YouTube y una guía específica para NAS de Synology en mariushosting, que es probablemente la más detallada para ese hardware particular.

¿Cómo configurar portracker en TrueNAS y en Linux puro?

En TrueNAS Scale se despliega como aplicación de contenedor usando la infraestructura nativa del sistema, y portracker incluye un collector pensado específicamente para esa plataforma. En Linux sin Docker el enfoque es distinto: el descubrimiento se apoya en las herramientas del sistema para enumerar sockets en escucha, y perdés la parte de metadata de contenedores porque no hay contenedores que consultar.

La diferencia entre plataformas importa más de lo que parece. Un NAS típico tiene servicios del sistema (SMB, NFS, la propia UI de administración) que no viven en contenedores, mezclados con apps que sí. Sin un collector que entienda esa dualidad, la mitad de tu inventario aparece sin identificar. Te puede servir nuestra cobertura de en tu servidor de automatización.

Eso sí: verificá siempre la documentación del repo para tu versión. Los collectors evolucionan y lo que vale hoy puede cambiar en el próximo release.

¿Cómo monitorear varios servidores con peers en portracker?

Agregando otras instancias de portracker como peers desde la interfaz. Cada servidor corre su propia instancia con su propio collector local, y una de ellas consulta a las demás para presentar la vista consolidada. No hay un servidor central obligatorio ni un agente liviano separado: todas las instancias son iguales, y vos elegís desde cuál mirás.

El modelo tiene una ventaja concreta sobre centralizar todo en un nodo: si el host que usás como “principal” se cae, las otras instancias siguen funcionando por su cuenta y podés entrar a cualquiera de ellas directamente. La contra es que tenés que mantener N instancias actualizadas en vez de una sola, y que cada peer necesita alcanzabilidad de red hacia los demás, lo cual en una red con VLANs segmentadas es exactamente el tipo de detalle que descubrís a las dos de la mañana.

Para infraestructura repartida entre un servidor en casa y un VPS, el patrón razonable es dejar cada instancia escuchando solo en la interfaz privada y unir los hosts por VPN. Si tu VPS está en un proveedor local, con donweb.com tenés la ventaja de latencia baja hacia Argentina, que para una UI web interactiva se nota.

¿Portracker o Consul? Comparativa con otras herramientas de descubrimiento

Portracker y Consul resuelven problemas distintos aunque las dos digan “service discovery”. Portracker es un inventario para humanos: descubre qué hay corriendo y te lo muestra. Consul es un registro para máquinas: los servicios se registran, otros servicios los consultan por DNS o API, y hay health checks que sacan del pool a los que fallan. Si lo que querés es que tu aplicación resuelva dinámicamente dónde está otro servicio, portracker no es la herramienta.

Herramienta	Para qué sirve	Dependencias	Consumidor
portracker	Inventario de puertos y servicios por host	Docker + SQLite embebido	Humano (UI web)
Consul	Registro de servicios, DNS interno, health checks	Cluster propio con quórum	Aplicaciones y balanceadores
Registrator	Registrar contenedores Docker en un backend	Requiere Consul/etcd detrás	El registro que tengas atrás
docker-gen	Generar archivos de config desde eventos Docker	Docker + tus templates	nginx, HAProxy y similares
Prometheus + exporters	Métricas y alertas en el tiempo	Prometheus, storage, Grafana	Dashboards y alertmanager

descubrimiento automático de servicios docker diagrama explicativo

¿Dónde gana portracker? En el caso del homelab o el servidor único donde montar un cluster de Consul es desproporcionado. Instalás un contenedor, mirás la pantalla, entendés tu infraestructura. Fin. Esto se conecta con lo que analizamos en monitoreo local sin APIs externas.

¿Dónde pierde? En cualquier escenario donde el consumidor del descubrimiento sea un programa y no una persona. Kubernetes ya tiene su propio service discovery integrado, las mallas de servicio manejan enrutamiento y mTLS, y un entorno con autoscaling necesita que el registro se actualice en segundos con health checks reales. Nada de eso es lo que portracker intenta hacer.

¿Cuánto consume portracker y qué limitaciones técnicas tiene?

El proyecto no publica benchmarks oficiales de CPU y memoria, así que cualquier número que leas por ahí conviene tomarlo con pinzas. Lo que sí se puede afirmar por diseño: al usar SQLite embebido y no levantar servicios auxiliares, el footprint es sensiblemente menor al de un stack con base de datos externa más cache más panel aparte.

Las limitaciones conceptuales son más interesantes que las de recursos. Un escáner de puertos ve lo que está escuchando ahora, no lo que estuvo escuchando hace diez minutos ni lo que va a levantar el cron de las 3 AM. Para redes Docker custom donde los contenedores se hablan entre sí sin publicar puertos al host, la información visible es parcial por definición: ese tráfico nunca toca la interfaz del host.

Y hay una limitación de seguridad que hay que decir con todas las letras: montar el socket de Docker en un contenedor es dar acceso equivalente a root en el host. Aunque lo montes read-only, la API de Docker permite operaciones que se traducen en control total de la máquina. No es un problema de portracker en particular, lo comparten todas las herramientas de esta categoría, pero cambia dónde deberías desplegarlo (tu homelab, sí; un host multi-tenant con usuarios que no controlás, pensalo dos veces).

Qué está confirmado y qué no

Confirmado: el proyecto es open source y su código está publicado en GitHub, con espejo del proyecto en SourceForge.
Confirmado: soporta Linux, Docker y TrueNAS, y hay guías de terceros para instalarlo en NAS de Synology.
Confirmado: usa SQLite y no exige base de datos externa.
No confirmado: cifras de consumo de recursos, roadmap de integraciones con Prometheus o Grafana, y cualquier comparativa de performance contra herramientas enterprise. Nada de eso surge de las fuentes disponibles.
Verificá vos: la licencia exacta y la versión vigente, directamente en el repositorio. Es el único lugar donde ese dato está siempre al día.

Errores comunes al usar portracker

Montar mal el socket de Docker. Si el path del mount está equivocado o los permisos no dan, portracker arranca igual pero muestra puertos sin identificar. Los contenedores tienen que aparecer con nombre e imagen: si ves puertos anónimos, el problema es el socket, no el escaneo.
Creer que es una herramienta de seguridad. Portracker te muestra qué está expuesto, no lo cierra. El firewall lo seguís necesitando igual. Confundir visibilidad con protección es el clásico error de quien instala un dashboard y se queda tranquilo.
Monitorear un solo host de varios. Instalás en el servidor principal, ves ese inventario, y los otros dos siguen siendo una caja negra. Si tenés varios hosts, configurá los peers desde el día uno o el inventario que ves es una fracción del real.
Publicar la UI en 0.0.0.0. Un panel que lista todos tus servicios y puertos abiertos es justo lo que un atacante quiere encontrar. Bindealo a localhost y entrá por VPN o túnel SSH.
Esperar visibilidad de redes Docker internas. Los contenedores que se comunican por una red bridge custom sin publicar puertos no aparecen como servicios expuestos, porque no lo están. Eso es correcto, no es un bug.

Preguntas Frecuentes

¿Qué es portracker exactamente?

Portracker es una herramienta open source de descubrimiento e inventario de puertos y servicios para Linux, Docker y TrueNAS, desarrollada por mostafa-wahied y publicada en GitHub. Escanea los puertos en uso del sistema, los cruza con la metadata de los contenedores Docker y los presenta en una interfaz web, guardando todo en una base SQLite local. Complementá con en entornos privados y aislados.

¿Portracker es gratis?

Sí, es un proyecto de código abierto con su repositorio público en GitHub y un espejo en SourceForge. No tiene edición paga ni modelo de suscripción anunciado. Para conocer los términos exactos de uso y redistribución, revisá el archivo de licencia en el repositorio, que es la única fuente autoritativa sobre eso.

¿Portracker funciona en Kubernetes?

No es su caso de uso. Portracker está pensado para hosts con Docker, Linux y TrueNAS, donde el descubrimiento se apoya en el daemon de Docker y en los puertos del sistema operativo. Kubernetes ya tiene service discovery nativo mediante Services y DNS interno, que resuelve ese problema a nivel del cluster.

¿Qué diferencia hay entre portracker y Consul?

Portracker descubre servicios que ya están corriendo y se los muestra a una persona; Consul es un registro donde las aplicaciones se inscriben y otras aplicaciones las consultan por DNS o API, con health checks incluidos. Portracker no necesita cluster ni base de datos externa; Consul en producción se despliega con varios nodos para mantener quórum.

¿Es seguro montar el socket de Docker en portracker?

Montar el socket de Docker equivale a otorgar privilegios de root sobre el host, incluso montándolo en modo lectura. Es un requisito compartido por todas las herramientas que leen metadata de contenedores, no una particularidad de portracker. Para un homelab o un servidor propio es un riesgo aceptable; en un host compartido con usuarios que no controlás, evaluá un proxy de socket con permisos restringidos.

Conclusión

Portracker no inventa una categoría nueva ni reemplaza a Consul, y su autor tampoco lo pretende. Lo que hace es tapar un agujero concreto que tiene cualquiera con más de un servidor y varios contenedores: saber qué está escuchando dónde, sin mantener documentación a mano. Un contenedor, una UI, un archivo SQLite.

Si tenés un homelab o un par de VPS, probalo. Levantalo en el host que peor conocés, mirá la lista de puertos que aparece y contá cuántos no podés explicar de memoria. Ese número es el argumento para instalarlo.

Después bindeá la UI a localhost, configurá los peers de los otros hosts y andá al repositorio a chequear la licencia y la versión vigente antes de meterlo en algo que te importe.

Portracker: descubrí qué corre en tus servidores Docker