# Resolución de problemas Esta página cubre las técnicas de depuración y los problemas comunes que puedes encontrar al migrar a Docker Hardened Images (DHI) o al utilizarlas. ## Depuración general Las Docker Hardened Images priorizan el minimalismo y la seguridad, lo que significa que omiten intencionadamente muchas herramientas de depuración comunes (como shells o gestores de paquetes). Esto dificulta la resolución directa de problemas sin introducir riesgos. Para solucionar esto, puedes utilizar [Docker Debug](/reference/cli/docker/debug/), un flujo de trabajo seguro que adjunta temporalmente un contenedor de depuración efímero a un servicio o imagen en ejecución sin modificar la imagen original. Esta sección muestra cómo depurar Docker Hardened Images localmente durante el desarrollo. Con Docker Debug, también puedes depurar contenedores de forma remota utilizando la opción `--host`. ### Usar Docker Debug #### Paso 1: Ejecutar un contenedor a partir de una Hardened Image Comienza con un contenedor basado en DHI que simule un problema: ```console $ docker run -d --name myapp dhi.io/python:3.13 python -c "import time; time.sleep(300)" ``` Este contenedor no incluye una shell ni herramientas como `ps`, `top` o `cat`. Si intentas: ```console $ docker exec -it myapp sh ``` Verás: ```console exec: "sh": executable file not found in $PATH ``` #### Paso 2: Usar Docker Debug para inspeccionar el contenedor Usa el comando `docker debug` para adjuntar un contenedor de depuración temporal y rico en herramientas a la instancia en ejecución. ```console $ docker debug myapp ``` Desde aquí, puedes inspeccionar los procesos en ejecución, el estado de la red o los archivos montados. Por ejemplo, para comprobar los procesos en ejecución: ```console $ ps aux ``` Escribe `exit` para salir del contenedor cuando hayas terminado. ### Enfoques de depuración alternativos Además de utilizar Docker Debug, también puedes utilizar los siguientes enfoques para depurar contenedores DHI. #### Usar la variante -dev Las Docker Hardened Images ofrecen una variante `-dev` que incluye una shell y un gestor de paquetes para instalar herramientas de depuración. Reemplaza la etiqueta de la imagen por `-dev`: ```console $ docker run -it --rm dhi.io/python:3.13-dev sh ``` Escribe `exit` para salir del contenedor cuando hayas terminado. Ten en cuenta que el uso de la variante `-dev` aumenta la superficie de ataque y no se recomienda como entorno de ejecución para entornos de producción. #### Montar herramientas de depuración con montajes de imágenes Puedes utilizar la función de montaje de imágenes para montar herramientas de depuración en tu contenedor sin modificar la imagen base. ##### Paso 1: Ejecutar un contenedor a partir de una imagen securizada Comienza con un contenedor basado en DHI que simule un problema: ```console $ docker run -d --name myapp dhi.io/python:3.13 python -c "import time; time.sleep(300)" ``` ##### Paso 2: Montar herramientas de depuración en el contenedor Ejecuta un nuevo contenedor que monte una imagen rica en herramientas (como `busybox`) en el espacio de nombres del contenedor en ejecución: ```console $ docker run --rm -it --pid container:myapp \ --mount type=image,source=busybox,destination=/dbg,ro \ dhi.io/python:3.13 /dbg/bin/sh ``` Esto monta la imagen BusyBox en `/dbg`, lo que te da acceso a sus herramientas mientras mantienes inalterada la imagen original del contenedor. Dado que la imagen securizada de Python no incluye las utilidades estándar, debes utilizar la ruta completa de las herramientas montadas: ```console $ /dbg/bin/ls / $ /dbg/bin/ps aux $ /dbg/bin/cat /etc/os-release ``` Escribe `exit` para salir del contenedor cuando hayas terminado. ## Problemas comunes A continuación se detallan problemas específicos que puedes encontrar al trabajar con Docker Hardened Images, junto con las soluciones recomendadas. ### Permisos Las DHI se ejecutan como un usuario no root por defecto para mejorar la seguridad. Esto puede provocar problemas de permisos al acceder a archivos o directorios. Asegúrate de que los archivos de tu aplicación y los directorios de tiempo de ejecución pertenezcan al UID/GID esperado o tengan los permisos adecuados. Para saber con qué usuario se ejecuta una DHI, consulta la página del repositorio de la imagen en Docker Hub. Consulta [Detalles de la variante de la imagen](/dhi/how-to/explore/#detalles-de-la-variante-de-la-imagen) para obtener más información. ### Puertos privilegiados Los contenedores no root no pueden enlazarse a puertos inferiores a 1024 por defecto. Esto lo imponen tanto el tiempo de ejecución del contenedor como el kernel (especialmente en Kubernetes y Docker Engine < 20.10). Dentro del contenedor, configura tu aplicación para que escuche en un puerto no privilegiado (1025 o superior). Por ejemplo, `docker run -p 80:8080 my-image` asigna el puerto 8080 del contenedor al puerto 80 del host, lo que te deja acceder a él sin necesidad de privilegios de root. ### Sin shell Las DHI de tiempo de ejecución omiten las shells interactivas como `sh` o `bash`. Si tu compilación o tus herramientas asumen que hay una shell presente (por ejemplo, para instrucciones `RUN`), usa una variante `dev` de la imagen en una etapa de compilación anterior y copia el artefacto final en la imagen de ejecución. Para saber qué shell tiene una DHI, si es que tiene alguna, consulta la página del repositorio de la imagen en Docker Hub. Consulta [Detalles de la variante de la imagen](/dhi/how-to/explore/#detalles-de-la-variante-de-la-imagen) para obtener más información. Además, usa Docker Debug cuando necesites acceso de shell a un contenedor en ejecución. Para obtener más detalles, consulta [Depuración general](#depuracion-general). ### Diferencias en el punto de entrada Las DHI pueden definir puntos de entrada diferentes en comparación con las Docker Official Images (DOI) u otras imágenes de la comunidad. Para conocer el `ENTRYPOINT` o `CMD` de una DHI, consulta la página del repositorio de la imagen en Docker Hub. Consulta [Detalles de la variante de la imagen](/dhi/how-to/explore/#detalles-de-la-variante-de-la-imagen) para obtener más información. ### Sin gestor de paquetes Las Docker Hardened Images de tiempo de ejecución están simplificadas por seguridad y para ofrecer una superficie de ataque mínima. Como resultado, no incluyen un gestor de paquetes como `apk` o `apt`. Esto significa que no puedes instalar software adicional directamente en la imagen de ejecución. Si la compilación o la configuración de tu aplicación requiere la instalación de paquetes (por ejemplo, para compilar código, instalar dependencias en tiempo de ejecución o añadir herramientas de diagnóstico), usa una variante `dev` de la imagen en una etapa de compilación. Luego, copia únicamente los artefactos necesarios en la imagen final de ejecución.