Almacén de imágenes de containerd con Docker Engine
El almacén de imágenes de containerd es el backend de almacenamiento predeterminado para Docker Engine 29.0 y posteriores en instalaciones nuevas. Si realizaste una actualización desde una versión anterior, tu demonio continuará utilizando los controladores gráficos heredados (overlay2) hasta que habilites el almacén de imágenes de containerd.
containerd, el entorno de ejecución de contenedores estándar de la industria, utiliza snapshotters en lugar de los controladores de almacenamiento clásicos para guardar los datos de imágenes y contenedores.
NoteEl almacén de imágenes de containerd no está disponible cuando se utiliza la reasignación de espacios de nombres de usuario (
userns-remap). Consulta moby#47377 para obtener más detalles.
Por qué utilizar el almacén de imágenes de containerd
El almacén de imágenes de containerd utiliza snapshotters para gestionar cómo se almacenan y acceden las capas de imágenes en el sistema de archivos. Esto difiere de los controladores gráficos clásicos como overlay2.
El almacén de imágenes de containerd permite:
- Compilar y almacenar imágenes multiplataforma localmente. Con los controladores de almacenamiento clásicos, necesitas constructores (builders) externos para imágenes multiplataforma.
- Trabajar con imágenes que incluyen atestaciones (provenance, SBOM). Estas utilizan índices de imágenes que el almacén clásico no admite.
- Ejecutar contenedores Wasm. El almacén de imágenes de containerd admite cargas de trabajo de WebAssembly.
- Utilizar snapshotters avanzados. containerd admite snapshotters acoplables que proporcionan características como la descarga diferida (lazy-pulling) de imágenes (stargz) o la distribución de imágenes de par a par (peer-to-peer) (nydus, dragonfly).
Para la mayoría de los usuarios, el cambio al almacén de imágenes de containerd es transparente. El backend de almacenamiento cambia, pero tus flujos de trabajo siguen siendo los mismos.
Uso del espacio en disco
El almacén de imágenes de containerd utiliza más espacio en disco que los controladores de almacenamiento heredados para las mismas imágenes. Esto se debe a que containerd almacena las imágenes tanto en formato comprimido como descomprimido, mientras que los controladores heredados solo almacenaban las capas descomprimidas.
Cuando descargas una imagen, containerd conserva las capas comprimidas (tal como se reciben del registro) y también las extrae en el disco. Este almacenamiento dual significa que cada capa ocupa más espacio. El formato comprimido permite descargas y subidas más rápidas, pero requiere una capacidad de disco adicional.
Importantcontainerd utiliza una ruta de almacenamiento independiente de la del directorio de datos de Docker. Si previamente configuraste un directorio de datos personalizado para Docker (por ejemplo, para usar una partición diferente), el almacenamiento de containerd no se mueve automáticamente a esa ubicación. Necesitas configurar el directorio de datos de containerd por separado para evitar llenar tu partición raíz.
Para configurar el directorio de datos de containerd, consulta Configurar la ubicación del directorio de datos.
Si el espacio en disco es limitado, considera lo siguiente:
- Limpiar regularmente las imágenes no utilizadas con
docker image prune - Utilizar
docker system dfpara supervisar el uso del disco - Configurar el directorio de datos para usar una partición con espacio adecuado
Habilitar el almacén de imágenes de containerd en Docker Engine
Si estás actualizando desde una versión anterior de Docker Engine, debes habilitar manualmente el almacén de imágenes de containerd.
ImportantCambiar los backends de almacenamiento oculta temporalmente las imágenes y los contenedores creados con el otro backend. Tus datos permanecen en el disco. Para acceder a las imágenes antiguas de nuevo, vuelve a tu configuración de almacenamiento anterior.
Añade la siguiente configuración a tu archivo /etc/docker/daemon.json:
{
"features": {
"containerd-snapshotter": true
}
}Guarda el archivo y reinicia el demonio:
$ sudo systemctl restart docker
Después de reiniciar el demonio, verifica que estás utilizando el almacén de imágenes de containerd:
$ docker info -f '{{ .DriverStatus }}'
[[driver-type io.containerd.snapshotter.v1]]
Docker Engine utiliza el snapshotter de containerd overlayfs por defecto.
NoteAl habilitar el almacén de imágenes de containerd, las imágenes y contenedores existentes del controlador overlay2 permanecen en el disco pero quedan ocultos. Reaparecerán si vuelves a cambiar a overlay2. Para utilizar tus imágenes existentes con el almacén de imágenes de containerd, súbelas primero a un registro o utiliza
docker savepara exportarlas.
Migración automática experimental
Docker Engine incluye una característica experimental que puede cambiar automáticamente al almacén de imágenes de containerd bajo ciertas condiciones. Esta característica es experimental. Se proporciona para quienes deseen probarla, pero empezar desde cero es el enfoque recomendado.
CautionLa característica de migración automática es experimental y puede no funcionar de manera fiable en todos los escenarios. Realiza copias de seguridad antes de intentar utilizarla.
Para habilitar la migración automática, añade la característica containerd-migration a tu /etc/docker/daemon.json:
{
"features": {
"containerd-migration": true
}
}También puedes configurar la variable de entorno DOCKER_MIGRATE_SNAPSHOTTER_THRESHOLD para que el demonio cambie automáticamente si no tienes contenedores y tu cantidad de imágenes es igual o inferior al umbral. Para systemd:
$ sudo systemctl edit docker.service
Añade:
[Service]
Environment="DOCKER_MIGRATE_SNAPSHOTTER_THRESHOLD=5"Si no tienes contenedores en ejecución o detenidos y tienes 5 o menos imágenes, el demonio cambiará al almacén de imágenes de containerd al reiniciar. Tus datos de overlay2 permanecen en el disco pero se ocultan.
Recursos adicionales
Para obtener más información sobre el almacén de imágenes de containerd y sus capacidades en Docker Desktop, consulta Almacén de imágenes de containerd en Docker Desktop.