Docker

Problema En entornos Docker Swarm con un reverse proxy (por ejemplo, Traefik) y un proveedor de identidad (Authelia, Keycloak, etc.) es frecuente que los servicios que implementan OAuth2 necesiten redirigir al usuario a una URL de callback que apunta al host del clúster (ej. auth.example.com). Los contenedores que forman parte de una overlay network de Swarm no pueden alcanzar directamente la IP del nodo host ni el nombre DNS que resuelve a esa IP. La resolución DNS funciona, pero la petición nunca llega porque Docker aísla la red del contenedor del stack de red del host. El síntoma típico es: ...

Problema Los ingenieros que operan clústers de Docker a diario necesitan una forma rápida de inspeccionar, controlar y depurar contenedores sin abandonar la terminal. Las interfaces de usuario basadas en texto (TUI) prometen esa experiencia, pero el mercado está fragmentado: proyectos escritos en Go, Rust o combinaciones de bibliotecas como Bubbletea, gocui y ratatui. Cada TUI ofrece un subconjunto de funcionalidades (monitorización, gestión de Compose, explorador de archivos, etc.) y diferentes niveles de madurez. El reto recurrente es decidir cuál de ellas encaja con el flujo de trabajo, el stack tecnológico y los requisitos de extensibilidad sin invertir tiempo en probar todas. ...

Problema En entornos de auto‑hosting es frecuente combinar un contenedor que necesita salir a Internet (por ejemplo, qbittorrent) con una VPN basada en WireGuard. La práctica consiste en montar un archivo wg0.conf dentro del container y delegar la resolución DNS a un resolvedor interno como Unbound. Cuando la configuración parece correcta pero cualquier llamada a curl, ping o la propia aplicación muestra errores de tipo “Could not resolve host”, el contenedor queda sin acceso a la red externa aunque la interfaz wg0 esté UP. ...

Problema En un homelab o en una pequeña infraestructura de producción, es frecuente mezclar máquinas virtuales (VMs), contenedores LXC y stacks Docker bajo un mismo host. Cada capa tiene su propio mecanismo de actualización: apt upgrade && apt update para sistemas Debian/Ubuntu, scripts de Proxmox para LXC, docker compose pull && docker compose up -d para contenedores, o descargas manuales de binarios desde GitHub. Cuando el número de unidades supera la decena, el proceso manual de conectar por SSH, ejecutar comandos, responder a prompts y reiniciar se vuelve una carga de varias horas cada semana. La necesidad es una solución que coordine esas tareas, preserve la interactividad requerida y sea reutilizable en cualquier entorno similar. ...

Problema Muchos entornos de homelab o servidores de bajo consumo se entregan con una pila de red sin políticas restrictivas: todas las cadenas de iptables están en ACCEPT, no existe un conjunto de reglas nftables y herramientas como UFW no están instaladas. Cuando el host ejecuta servicios que escuchan en 0.0.0.0 (SMB, NFS, rpcbind, VNC, etc.) o lanza contenedores Docker con puertos publicados, esos puertos quedan expuestos a la LAN sin filtro alguno. El síntoma típico es que cualquier máquina en la red local puede conectar a esos servicios sin autenticación adicional, lo que rompe la premisa de “solo los servicios que yo configure”. Además, aplicar reglas de iptables a través de una sesión SSH puede dejar al administrador fuera si la regla bloquea la propia conexión. ...

Problema En muchos entornos de homelab o dispositivos embebidos, el sistema operativo base no incluye una política de firewall activa. Las cadenas de iptables o nftables aparecen con la política ACCEPT y no hay reglas que limiten puertos expuestos. Cuando se despliegan contenedores Docker, el tráfico DNAT se dirige a la cadena FORWARD, de modo que una regla solo en INPUT no protege los puertos publicados. El resultado típico es que cualquier servicio que escuche en 0.0.0.0 queda accesible desde la LAN (SMB, NFS, VNC, etc.) y, si el host está conectado a una VPN, también desde Internet sin una barrera clara. ...

Problema En entornos donde coexisten Docker Swarm y Kubernetes, a menudo surge la necesidad de que contenedores de Swarm consuman servicios expuestos por pods de K8s (y viceversa). Cada orquestador crea su propio overlay de red, su propio DNS interno y, por defecto, no comparten rutas. Cuando los clústers están en redes distintas o en diferentes centros de datos, la comunicación se corta a menos que se establezca una capa de red externa que los una. El patrón típico es: “un micro‑servicio legado sigue en Swarm, pero la nueva funcionalidad está en K8s; ambos deben hablar sin re‑escribir código”. ...

Problema En entornos de auto‑hosting es frecuente combinar wg‑easy (interfaz web para WireGuard) con Caddy como terminador TLS y reverse proxy. El objetivo es acceder a https://wg-easy.example.com sin exponer puertos internos. Un síntoma típico es el mensaje del navegador “Can’t connect to the server” o un error de conexión TCP. El problema no es exclusivo de wg‑easy; ocurre siempre que el proxy no logra resolver o alcanzar el contenedor objetivo dentro de la red Docker. La raíz suele estar en la configuración de la red Docker, la definición del reverse_proxy en el Caddyfile o en la exposición de puertos del servicio wg‑easy. ...

Problema Muchos usuarios de NAS domésticos llegan al punto en que el firmware del fabricante se vuelve una limitación: actualizaciones forzadas, funcionalidades bloqueadas detrás de suscripciones y poca visibilidad sobre el stack subyacente. El patrón típico es querer un servidor de medios, archivos y acceso remoto que sea completamente controlable, reproducible y sin puertos públicos, pero sin renunciar a la estabilidad de un hardware barato. La pregunta recurrente es: ¿cómo montar esa infraestructura desde cero usando Debian y Docker, garantizando redundancia de discos y acceso seguro desde cualquier lugar? ...

Problema Desarrollar y testear aplicaciones que consumen varios servicios de Google Cloud suele requerir que cada API se ejecute en su propio proceso o binario. Los emuladores oficiales de Cloud Storage, Pub/Sub, Firestore y Datastore se distribuyen como ejecutables independientes, cada uno escuchando en puertos diferentes. En entornos CI o en máquinas de desarrollo con recursos limitados, mantener varios procesos activos genera complejidad: hay que coordinar puertos, manejar variables de entorno distintas y, en el peor de los casos, algunos servicios (por ejemplo, Secret Manager o Managed Kafka) no tienen emulador oficial. El patrón recurrente es la fragmentación del entorno local, que dificulta la reproducibilidad de pruebas y ralentiza los pipelines. ...