# Backends de almacenamiento de caché Para garantizar compilaciones rápidas, BuildKit almacena automáticamente el resultado de la compilación en su propia caché interna. Además, BuildKit también admite exportar la caché de compilación a una ubicación externa, lo que permite importarla en futuras compilaciones. Una caché externa se vuelve casi indispensable en entornos de compilación de CI/CD. Estos entornos suelen tener poca o ninguna persistencia entre ejecuciones, pero sigue siendo importante mantener el tiempo de ejecución de las compilaciones de imágenes lo más bajo posible. El controlador `docker` predeterminado admite los backends de caché `inline`, `local`, `registry` y `gha`, pero solo si tienes habilitado el [almacén de imágenes de containerd](/desktop/features/containerd/). Otros backends de caché requieren que selecciones un [controlador](/build/builders/drivers/) diferente. > [!WARNING] > > Si usas secretos o credenciales dentro de tu proceso de compilación, asegúrate de manipularlos usando la [opción `--secret` dedicada](/reference/cli/docker/buildx/build/#secret). > Gestionar secretos manualmente usando `COPY` o `ARG` podría resultar en la filtración de credenciales. ## Backends Buildx admite los siguientes backends de almacenamiento de caché: - `inline`: incrusta la caché de compilación en la imagen. La caché inline se envía a la misma ubicación que el resultado de salida principal. Esto solo funciona con el [exportador `image`](/exporters/image-registry/). - `registry`: incrusta la caché de compilación en una imagen separada y la envía a una ubicación dedicada independiente de la salida principal. - `local`: escribe la caché de compilación en un directorio local del sistema de archivos. - `gha`: sube la caché de compilación a la [caché de GitHub Actions](https://docs.github.com/en/rest/actions/cache) (beta). - `s3`: sube la caché de compilación a un [bucket de AWS S3](https://aws.amazon.com/s3/) (no publicado). - `azblob`: sube la caché de compilación a [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/) (no publicado). ## Sintaxis de comandos Para usar cualquiera de los backends de caché, primero debes especificarlo en la compilación con la [opción `--cache-to`](/reference/cli/docker/buildx/build/#cache-to) para exportar la caché al backend de almacenamiento que elijas. Luego, usa la [opción `--cache-from`](/reference/cli/docker/buildx/build/#cache-from) para importar la caché desde el backend de almacenamiento a la compilación actual. A diferencia de la caché local de BuildKit (que siempre está habilitada), debes exportar e importar explícitamente todos los backends de almacenamiento de caché. Ejemplo de comando de `buildx` usando el backend `registry` para importar y exportar caché: ```console $ docker buildx build --push -t / \ --cache-to type=registry,ref=/[,parameters...] \ --cache-from type=registry,ref=/[,parameters...] . ``` > [!WARNING] > > Como regla general, cada caché escribe en alguna ubicación. Ninguna ubicación puede recibir escrituras dos veces sin sobrescribir los datos almacenados en caché anteriormente. Si quieres mantener varias cachés con diferentes ámbitos (por ejemplo, una caché por rama de Git), asegúrate de usar ubicaciones diferentes para la caché exportada. ## Cachés múltiples BuildKit admite múltiples exportadores de caché, lo que te permite enviar la caché a más de un destino. También puedes importar desde tantas cachés remotas como quieras. Por ejemplo, un patrón común es usar la caché tanto de la rama actual como de la rama principal. El siguiente ejemplo muestra cómo importar caché desde múltiples ubicaciones usando el backend de caché de registro (`registry`): ```console $ docker buildx build --push -t / \ --cache-to type=registry,ref=/: \ --cache-from type=registry,ref=/: \ --cache-from type=registry,ref=/:main . ``` ## Opciones de configuración Esta sección describe algunas opciones de configuración disponibles al generar exportaciones de caché. Las opciones descritas aquí son comunes para al menos dos o más tipos de backend. Además, los diferentes tipos de backend también admiten parámetros específicos. Consulta la página detallada sobre cada tipo de backend para obtener más información sobre qué parámetros de configuración se aplican. Los parámetros comunes descritos aquí son: - [Modo de caché](#modo-de-caché) - [Compresión de caché](#compresión-de-caché) - [Tipos de medio OCI](#tipos-de-medio-oci) ### Modo de caché Al generar una salida de caché, el argumento `--cache-to` acepta una opción `mode` para definir qué capas incluir en la caché exportada. Esto es compatible con todos los backends de caché excepto con la caché `inline`. El modo se puede configurar en cualquiera de estas dos opciones: `mode=min` o `mode=max`. Por ejemplo, para compilar la caché con `mode=max` con el backend registry: ```console $ docker buildx build --push -t / \ --cache-to type=registry,ref=/,mode=max \ --cache-from type=registry,ref=/ . ``` Esta opción solo se establece al exportar una caché usando `--cache-to`. Al importar una caché (`--cache-from`), los parámetros relevantes se detectan automáticamente. En el modo de caché `min` (el predeterminado), solo se almacenan en caché las capas que se exportan a la imagen resultante, mientras que en el modo de caché `max`, se almacenan en caché todas las capas, incluso las de los pasos intermedios. Aunque la caché `min` suele ser más pequeña (lo que acelera los tiempos de importación y exportación y reduce los costos de almacenamiento), la caché `max` tiene más probabilidades de obtener más aciertos de caché. Dependiendo de la complejidad y la ubicación de tu compilación, deberías experimentar con ambos parámetros para encontrar los resultados que mejor te funcionen. ### Compresión de caché Las opciones de compresión de caché son las mismas que las [opciones de compresión del exportador](/exporters/#compression). Esto es compatible con los backends de caché `local` y `registry`. Por ejemplo, para comprimir la caché de `registry` con compresión `zstd` compression: ```console $ docker buildx build --push -t / \ --cache-to type=registry,ref=/,compression=zstd \ --cache-from type=registry,ref=/ . ``` ### Tipos de medio OCI Las opciones OCI de caché son las mismas que las [opciones OCI del exportador](/exporters/#oci-media-types). Estas son compatibles con los backends de caché `local` y `registry`. Por ejemplo, para exportar caché con tipos de medio OCI, usa la propiedad `oci-mediatypes`: ```console $ docker buildx build --push -t / \ --cache-to type=registry,ref=/,oci-mediatypes=true \ --cache-from type=registry,ref=/ . ``` Esta propiedad solo es significativa con la bandera `--cache-to`. Al recuperar la caché, BuildKit detectará automáticamente los tipos de medio correctos que debe usar. De forma predeterminada, el tipo de medio OCI genera un índice de imagen para la imagen de caché. Algunos registros de OCI, como Amazon ECR, no admiten el tipo de medio de índice de imagen: `application/vnd.oci.image.index.v1+json`. Si exportas imágenes de caché a ECR o a cualquier otro registro que no admita índices de imagen, establece el parámetro `image-manifest` en `true` para generar un único manifiesto de imagen en lugar de un índice de imagen para la imagen de caché: ```console $ docker buildx build --push -t / \ --cache-to type=registry,ref=/,oci-mediatypes=true,image-manifest=true \ --cache-from type=registry,ref=/ . ``` > [!NOTE] > Desde la versión v0.21 de BuildKit, `image-manifest` está habilitada de forma predeterminada.