Compartir comentarios
Las respuestas se generan en base a la documentación.

Drivers de compilación

Los drivers de compilación son configuraciones sobre cómo y dónde se ejecuta el backend de BuildKit. Los ajustes de los drivers son personalizables y permiten un control detallado del builder.

Buildx admite los siguientes drivers:

  • docker: utiliza la biblioteca de BuildKit integrada en el demonio de Docker.
  • docker-container: crea un contenedor BuildKit dedicado utilizando Docker.
  • kubernetes: crea pods de BuildKit en un clúster de Kubernetes.
  • remote: se conecta directamente a un demonio de BuildKit gestionado manualmente.

Diferentes drivers admiten distintos casos de uso. El driver predeterminado docker prioriza la simplicidad y la facilidad de uso. Tiene soporte limitado para características avanzadas como la exportación de caché y formatos de salida, y no es configurable. Otros drivers proporcionan más flexibilidad y son mejores para manejar escenarios avanzados.

La siguiente tabla resume algunas diferencias entre los drivers.

Característicadockerdocker-containerkubernetesremote
Cargar imagen automáticamente
Exportación de caché✅*
Salida en formato Tarball
Imágenes multi-arquitectura
Configuración de BuildKitGestionado externamente

* El driver docker no admite todas las opciones de exportación de caché. Consulta Backends de almacenamiento de caché para obtener más información.

Cargar en el almacenamiento de imágenes local

A diferencia de lo que ocurre al utilizar el driver docker predeterminado, las imágenes compiladas con otros drivers no se cargan automáticamente en el almacenamiento de imágenes local. Si no especificas una salida, el resultado de la compilación se exportará únicamente a la caché de compilación.

Para compilar una imagen utilizando un driver no predeterminado y cargarla en el almacenamiento de imágenes, utiliza la bandera --load con el comando de compilación:

$ docker buildx build --load -t <image> --builder=container .
...
=> exporting to oci image format                                                                                                      7.7s
=> => exporting layers                                                                                                                4.9s
=> => exporting manifest sha256:4e4ca161fa338be2c303445411900ebbc5fc086153a0b846ac12996960b479d3                                      0.0s
=> => exporting config sha256:adf3eec768a14b6e183a1010cb96d91155a82fd722a1091440c88f3747f1f53f                                        0.0s
=> => sending tarball                                                                                                                 2.8s
=> importing to docker

Con esta opción, la imagen estará disponible en el almacenamiento de imágenes una vez que termine la compilación:

$ docker image ls
REPOSITORY                       TAG               IMAGE ID       CREATED             SIZE
<image>                          latest            adf3eec768a1   2 minutes ago       197MB

Cargar por defecto

Requiere: Docker Buildx 0.14.0 y posterior

Puedes configurar los drivers de compilación personalizados para que se comporten de manera similar al driver docker predeterminado y carguen las imágenes en el almacenamiento de imágenes de forma predeterminada. Para hacerlo, establece la opción del driver default-load al crear el builder:

$ docker buildx create --driver-opt default-load=true

Ten en cuenta que, al igual que con el driver docker, si especificas un formato de salida diferente con --output, el resultado no se cargará en el almacenamiento de imágenes a menos que también especifiques explícitamente --output type=docker o utilices la bandera --load.

Pasos siguientes

Lee la información de cada driver: