Migrar desde Alpine o Debian
Las Docker Hardened Images (DHI) están disponibles tanto en variantes basadas en Alpine como en Debian. En muchos casos, migrar desde otra imagen basada en estas distribuciones consiste únicamente en cambiar la imagen base en tu Dockerfile.
Esta guía te ayuda a migrar de una Docker Official Image (DOI) existente basada en Alpine o Debian a DHI.
Si utilizas una Docker Official Image basada en Debian, migra a la variante DHI basada en Debian. Si utilizas una imagen basada en Alpine, migra a la variante DHI basada en Alpine. Esto minimiza los cambios en la gestión de paquetes y dependencias durante la migración.
Diferencias clave
Al migrar de imágenes no securizadas a DHI, ten en cuenta estas diferencias clave:
| Elemento | Imágenes no securizadas | Docker Hardened Images |
|---|---|---|
| Gestión de paquetes | Los gestores de paquetes suelen estar disponibles en todas las imágenes. | Por lo general, los gestores de paquetes solo están disponibles en las imágenes con la etiqueta dev. Las imágenes de ejecución no contienen gestores de paquetes. Usa compilaciones multi-stage y copia los artefactos necesarios de la etapa de compilación a la etapa de ejecución. |
| Usuario no root | Normalmente se ejecuta como root por defecto. | Las variantes de tiempo de ejecución se ejecutan como el usuario no root por defecto. Asegúrate de que el usuario no root tenga acceso a los archivos y directorios necesarios. |
| Compilación multi-stage | Opcional | Recomendado. Usa imágenes con etiquetas dev o sdk para las etapas de compilación e imágenes que no sean dev para la ejecución. |
| Certificados TLS | Puede ser necesario instalarlos. | Contienen certificados TLS estándar por defecto. No es necesario instalar certificados TLS. |
| Puertos | Pueden enlazarse a puertos privilegiados (inferiores a 1024) al ejecutarse como root. | Se ejecutan como usuario no root por defecto. Las aplicaciones no pueden enlazarse a puertos privilegiados (inferiores a 1024) cuando se ejecutan en Kubernetes o en versiones de Docker Engine anteriores a la 20.10. Configura tu aplicación para que escuche en el puerto 1025 o superior dentro del contenedor. |
| Punto de entrada | Varía según la imagen. | Pueden tener puntos de entrada diferentes a los de las Docker Official Images. Inspecciona los puntos de entrada y actualiza tu Dockerfile si es necesario. |
| Shell | La shell suele estar disponible en todas las imágenes. | Las imágenes de ejecución no contienen una shell. Usa imágenes dev en las etapas de compilación para ejecutar comandos de shell y luego copia los artefactos a la etapa de ejecución. |
Pasos de migración
Paso 1: Actualizar la imagen base en tu Dockerfile
Actualiza la imagen base en el Dockerfile de tu aplicación a una imagen securizada. Normalmente será una imagen etiquetada como dev o sdk porque tiene las herramientas necesarias para instalar paquetes y dependencias.
El siguiente fragmento de diff de un Dockerfile muestra la imagen base antigua reemplazada por la nueva imagen securizada.
NoteDebes autenticarte en
dhi.ioantes de poder descargar Docker Hardened Images. Usa tus credenciales de Docker ID (el mismo usuario y contraseña que usas para Docker Hub). Si no tienes una cuenta de Docker, crea una de forma gratuita.Ejecuta
docker login dhi.iopara autenticarte.
- ## Original base image
- FROM golang:1.25
+ ## Updated to use hardened base image
+ FROM dhi.io/golang:1.25-debian12-dev
Ten en cuenta que DHI no tiene una etiqueta latest con el fin de promover las mejores prácticas en torno al control de versiones de las imágenes. Asegúrate de especificar la etiqueta de versión adecuada para tu imagen. Para encontrar la etiqueta correcta, explora las etiquetas disponibles en el Catálogo de DHI. Además, la distribución base se especifica en la etiqueta (por ejemplo, -alpine3.22 o -debian12), así que asegúrate de seleccionar la variante correcta para tu aplicación.
Paso 2: Actualizar la imagen de ejecución en tu Dockerfile
NoteSe recomiendan las compilaciones multi-stage para mantener la imagen final mínima y segura. Las compilaciones de una sola etapa son compatibles, pero incluyen la imagen
devcompleta y, por lo tanto, dan como resultado una imagen más grande con una superficie de ataque más amplia.
Para garantizar que tu imagen final sea lo más mínima posible, debes utilizar una
compilación multi-stage. Todas las etapas de tu Dockerfile deben utilizar una imagen securizada. Mientras que las etapas intermedias normalmente utilizarán imágenes etiquetadas como dev o sdk, tu etapa final de ejecución debe utilizar una imagen de ejecución.
Utiliza la etapa de compilación para compilar tu aplicación y copia los artefactos resultantes a la etapa final de ejecución. Esto garantiza que tu imagen final sea mínima y segura.
El siguiente ejemplo muestra un Dockerfile multi-stage con una etapa de compilación y una etapa de ejecución:
# Build stage
FROM dhi.io/golang:1.25-debian12-dev AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp
# Runtime stage
FROM dhi.io/golang:1.25-debian12
WORKDIR /app
COPY --from=builder /app/myapp .
ENTRYPOINT ["/app/myapp"]Después de actualizar tu Dockerfile, compila y prueba tu aplicación. Si encuentras problemas, consulta la guía de Resolución de problemas para ver los problemas y soluciones comunes.
Ejemplos específicos de lenguajes
Consulta la sección de ejemplos para ver ejemplos de migración específicos de cada lenguaje: