Docker

Problema En muchos homelabs los servicios expuestos al exterior se acceden mediante un subdominio gestionado por un proveedor DNS externo (por ejemplo app.my.domain). Cuando el mismo subdominio se resuelve dentro de la red local, el tráfico suele salir a Internet y volver a entrar, lo que genera latencia innecesaria y, sobre todo, problemas de TLS: el certificado emitido para la IP pública no coincide con la IP interna y aplicaciones como Jellyfin rechazan la conexión. El patrón típico es: ...

Problema En entornos donde varios contenedores se ejecutan de forma continua, mantener las imágenes actualizadas es una tarea rutinaria pero delicada. La mayoría de los administradores confían en herramientas que descargan la última versión, recrean el contenedor y continúan con la operación. El punto crítico ocurre cuando la nueva imagen contiene errores de inicio, fallos de dependencias o configuraciones que hacen que el contenedor nunca alcance un estado saludable. En esos casos el proceso de actualización deja el servicio inoperativo hasta que se detecta manualmente el problema y se revierte a la versión anterior. El tiempo de inactividad, aunque breve, puede romper flujos de CI/CD, afectar usuarios finales y generar alertas innecesarias. ...

Problema En entornos de auto‑hosting es frecuente necesitar acceder a una aplicación web que corre dentro de Docker desde fuera de la red local. La solución típica es abrir puertos en el router o instalar el cliente VPN de Tailscale directamente en el host. Ambas opciones tienen inconvenientes: los puertos expuestos quedan visibles a Internet y la instalación del cliente VPN modifica la pila de red del sistema operativo, provocando conflictos con otras VPN, con iCloud Private Relay o con la configuración DNS del host. El objetivo es obtener un endpoint HTTPS accesible solo desde dispositivos autorizados, sin tocar la configuración de red del host y sin exponer la máquina completa a la tailnet. ...

Problema En entornos homelab donde TrueNAS actúa como nodo de almacenamiento y también ejecuta contenedores Docker (a través de Dockhand o plugins), es frecuente querer exponer varios servicios mediante un único punto de entrada. El objetivo suele ser: Un reverse proxy que escuche en 80/443 en una IP dedicada. Certificados TLS válidos tanto para acceso externo (Let’s Encrypt) como para tráfico interno LAN, evitando que los dispositivos locales consuman ancho de banda de la nube. Resolución DNS interna que apunte los sub‑dominios al alias IP del proxy, sin interferir con la red de la ISP. Integración con herramientas de hardening (crowdsec, geoblocking, Suricata). El bloqueo típico ocurre cuando el contenedor del proxy no puede unirse a la red que TrueNAS ha configurado (bridge, macvlan o alias). El error se manifiesta como “network not found” o “port already allocated”, y la UI de Dockhand muestra que el contenedor está detenido. Sin una red adecuada, los certificados ACME no pueden validar dominios y la resolución DNS interna no funciona. ...

Problema Mantener un servicio web de e‑commerce (API de búsqueda, sincronizador de catálogos y analítica) en un entorno doméstico implica varios retos simultáneos: exposición segura a Internet sin una IP estática, gestión de actualizaciones sin tiempo de inactividad, respaldo fiable de datos críticos y rendimiento aceptable con recursos limitados (CPU de 2 hilos, 8 GB RAM, 12 W de consumo). Cuando la carga supera los miles de requests por día, la combinación de concurrencia en SQLite, contenedores Docker y túneles externos puede volverse inestable si no se planifica una arquitectura coherente. ...

Problema En entornos de desarrollo o homelab es frecuente ejecutar Nginx Proxy Manager (NPM) dentro de Docker mientras que la aplicación que se desea exponer, como Jellyfin, corre directamente sobre Windows. Cuando el contenedor de NPM intenta enrutar el tráfico al host, el cliente recibe un 502 Bad Gateway y los logs indican connect() failed (111: Connection refused) while connecting to upstream "http://<IP>:8096/". El síntoma es idéntico aunque la IP usada sea la local del equipo, host.docker.internal o cualquier alias configurado. El problema no es DNS externo ni puertos del router; la falla ocurre dentro del stack de red de Docker/WSL2. ...

Problema Muchas pymes quieren mover una aplicación que ya funciona en Docker Compose en laptops de desarrollo a un servidor físico on‑premise con Windows Server 2022. El reto no es solo “instalar Docker”, sino armar una cadena completa: asignar discos para datos persistentes, exponer los servicios de forma segura, automatizar backups y dejar la puerta abierta a accesos remotos futuros. Cuando la infraestructura es nueva, es fácil omitir pasos críticos (por ejemplo, montar volúmenes en el disco correcto o configurar el arranque automático del daemon) y terminar con un stack que se cae al primer reinicio o que muestra advertencias de certificado en los navegadores de los empleados. ...

Problema Los equipos de startups suelen lanzar aplicaciones web con rapidez y con recursos humanos limitados. La arquitectura de producción debe soportar tráfico variable, almacenar activos pesados (imágenes, videos) y ofrecer observabilidad sin que el equipo dedique gran parte de su tiempo a la operación de la infraestructura. En este contexto surge la pregunta recurrente: ¿es razonable adoptar un clúster de Kubernetes gestionado desde el primer día, o conviene iniciar con una solución más ligera (Docker Compose, ECS, Cloud Run) y migrar después? ...

Problema Los sistemas de orquestación de flujos (Airflow, Prefect, etc.) suelen requerir que cada worker tenga acceso directo a la base de datos central para leer el estado de los jobs y actualizar sus resultados. En entornos con nodos en la periferia –por ejemplo, un Raspberry Pi en el garaje, una VM detrás de NAT en la casa de los padres o un cluster de GPU aislado en una red de alta seguridad– esa arquitectura obliga a abrir puertos, crear VPNs o exponer credenciales de base de datos. Cada vez que el acceso a la DB falla, los workers se quedan colgados, pierden tareas o, en el peor de los casos, se pierde la trazabilidad completa del flujo. El síntoma típico es “el worker no puede conectarse a Postgres” o “el scheduler se queda sin heartbeat”. El reto es mantener la flexibilidad de ejecutar tareas en contenedores, procesos o pods sin comprometer la seguridad ni la disponibilidad del backend. ...

Problema En muchos homelabs la lista de contenedores crece de forma orgánica: se añaden servicios copiando archivos docker‑compose.yml antiguos, se asignan puertos a mano y se crean volúmenes sin una política clara. Con el tiempo aparecen colisiones de puertos, variables de entorno olvidadas y health checks ausentes. Cada error obliga a volver a la máquina, revisar logs y, a menudo, a reiniciar manualmente los stacks. El patrón es claro: la configuración declarativa no está versionada ni validada antes de llegar al host, lo que genera inconsistencias y tiempo de inactividad evitables. ...