Docker

Problema En muchos homelabs se combinan Pi‑hole como resolutor DNS interno, Nginx Proxy Manager (NPM) para la terminación TLS y Cloudflare Tunnel para exponer servicios al exterior. Cuando los navegadores dentro de la LAN intentan acceder a sub‑dominios gestionados por NPM, aparecen errores como ERR_SSL_UNRECOGNIZED_NAME_ALERT o ERR_QUIC_PROTOCOL_ERROR. La causa típica es que el cliente recibe una respuesta DNS que mezcla direcciones internas (IPv4) con registros externos (IPv6 o A) obtenidos de Cloudflare, lo que rompe la coincidencia del certificado y obliga al navegador a abortar la conexión TLS. ...

Problema Al intentar añadir el repositorio oficial de Docker en una instalación limpia de Ubuntu 26.04, apt devuelve un mensaje similar a: Error: Conflicting values set for option Signed-By regarding source https://download.docker.com/linux/ubuntu/ resolute: /usr/share/keyrings/docker-archive-keyring.gpg != /etc/apt/keyrings/docker.asc Error: The list of sources could not be read. El error indica que la misma fuente APT tiene dos entradas que especifican rutas diferentes para la clave GPG (Signed-By). Cuando apt procesa la lista de fuentes, no puede decidir cuál usar y aborta la operación. ...

Problema En muchas infraestructuras basadas en VMware, los paquetes open‑vm‑tools que llegan desde los repositorios oficiales de la distribución llegan con varios meses de retraso respecto al código fuente de VMware. Ese desfase implica: Falta de correcciones de kernel y controladores que aparecen en versiones upstream. Ausencia de mejoras en la gestión de memoria (balloon) y en la sincronización de tiempo. Vulnerabilidades CVE que permanecen sin parchear hasta que el mantenedor de la distro actualiza el paquete. El síntoma típico es que, tras una actualización del hipervisor, los invitados siguen usando versiones antiguas de vmtoolsd, generando logs de incompatibilidad o, peor, exponiéndose a vulnerabilidades conocidas. La solución “instalar lo que trae la distro” ya no es suficiente en entornos donde la seguridad y el rendimiento son críticos. ...

Problema Los repositorios oficiales de muchas distribuciones entregan versiones de open‑vm‑tools que quedan rezagadas respecto al código fuente upstream. Ese desfase retrasa correcciones de kernel, mejoras del controlador de memoria balloon y parches de vulnerabilidades (CVE). Cuando se ejecutan máquinas virtuales en entornos mixtos –Ubuntu, Debian, RHEL‑based, Fedora o openSUSE– el administrador termina con paquetes inconsistentes: algunos hosts reciben correcciones críticas y otros siguen con versiones vulnerables. La solución manual (descargar el tarball, compilar en cada host y gestionar dependencias) genera contaminación del entorno y dificulta la reproducibilidad. ...

Problema Al intentar autoalojar una aplicación web que combina registro de entrenamientos, gestión de usuarios y un módulo opcional de IA, muchos administradores encuentran fallos intermitentes: el contenedor se reinicia, los enlaces de restablecimiento de contraseña llegan con el esquema incorrecto, o los datos desaparecen tras una actualización. El patrón típico es una configuración Docker incompleta o una integración deficiente con el proxy inverso y los volúmenes persistentes. Cuando la aplicación depende de variables como BASE_URL o de secretos para APIs externas, cualquier desalineación entre el entorno de Docker y el front‑end provoca errores de carga, pérdida de sesiones y problemas de sincronización multi‑dispositivo. ...

Problema En entornos donde Nginx actúa como reverse proxy para varios contenedores Docker, es frecuente encontrarse con que, de forma intermitente, el cliente recibe el certificado TLS del host “default” en lugar del certificado correspondiente al dominio solicitado. El síntoma típico es un error de certificate mismatch al abrir el sitio en el navegador o al ejecutar openssl s_client -servername <dominio> -connect <dominio>:443. La falla no ocurre siempre; en pruebas repetidas el mismo dominio puede devolver su certificado correcto en una ejecución y el certificado del host principal en otra. ...

Problema Equipos pequeños que migran de Docker Compose a un clúster Kubernetes (k3s, EKS, GKE, etc.) suelen perder la agilidad que tenían al desarrollar localmente. En un flujo tradicional con Compose, cada ingeniero monta su código en un contenedor, reinicia al instante y ve los logs en la terminal. Cuando la aplicación pasa a Helm y ArgoCD, el proceso se vuelve más rígido: los pipelines generan imágenes versionadas, los charts se despliegan en entornos de staging y prod, y los desarrolladores ya no tienen una forma sencilla de lanzar una instancia aislada para pruebas rápidas. ...

Problema Los administradores de servidores suelen necesitar acceso rápido a shells y a transferencia de archivos desde cualquier dispositivo, sin instalar clientes locales. Una solución basada en navegador simplifica la gestión, pero al mismo tiempo introduce una superficie de ataque: el servicio maneja credenciales SSH, mantiene sesiones activas y, si se expone sin protección, puede convertirse en un punto de entrada para atacantes. El reto es lanzar un workspace WebSSH que sea fácil de desplegar en un homelab y, al mismo tiempo, cumplir con buenas prácticas de seguridad para entornos internos y para instalaciones accesibles desde Internet. ...

Problema Los runners auto‑hosteados de GitHub Actions son convenientes porque pueden reutilizar infraestructura existente y ejecutar jobs que requieren Docker, Docker‑Compose o herramientas de navegador como Playwright. Sin embargo, cuando el job tiene acceso directo al daemon Docker del host, se rompe el aislamiento esperado: un script malintencionado o un error de configuración puede manipular contenedores del propio host, leer volúmenes sensibles o consumir recursos críticos. Además, la ejecución de código del workflow directamente sobre la máquina física elimina la frontera entre el CI y el entorno de producción, lo que complica la depuración y la rotación de runners. ...

Problema En muchos homelabs y entornos de desarrollo se ejecutan decenas de servicios que apenas se usan. Mantener todos los contenedores activos consume RAM, CPU y, en algunos casos, licencias de red. La práctica habitual es apagar los servicios manualmente o confiar en scripts de cron que los inician a horas predefinidas. Ese enfoque falla cuando un visitante inesperado necesita acceso inmediato: la primera petición llega a un puerto que no responde, el usuario recibe un error y el administrador tiene que intervenir. ...