docker buildx create

Descripción

create crea una nueva instancia de builder que apunta a un contexto o punto de conexión (endpoint) de Docker, donde el contexto es el nombre de un contexto de docker context ls y el punto de conexión es la dirección del socket de Docker (por ejemplo, el valor de DOCKER_HOST).

De forma predeterminada, se utiliza la configuración actual de Docker para determinar el valor del contexto o punto de conexión.

Las instancias de builder son entornos aislados donde se pueden invocar construcciones. Todos los contextos de Docker obtienen también la instancia de builder predeterminada.

Opciones

Ejemplos

Añadir un nuevo nodo a un builder existente (--append)

La bandera --append cambia la acción del comando para añadir un nuevo nodo a un builder existente especificado por --name. Buildx elegirá un nodo adecuado para la construcción en función de las plataformas que admita.

$ docker buildx create mycontext1
eager_beaver

$ docker buildx create --name eager_beaver --append mycontext2
eager_beaver

Especificar un archivo de configuración para el demonio de BuildKit (--buildkitd-config)

--buildkitd-config FILE

Especifica el archivo de configuración que utilizará el demonio de BuildKit. La configuración se puede sobrescribir con --buildkitd-flags. Consulta un ejemplo de archivo de configuración del demonio de BuildKit.

Si no especificas un archivo de configuración, Buildx buscará uno por defecto en:

• $BUILDX_CONFIG/buildkitd.default.toml
• $DOCKER_CONFIG/buildx/buildkitd.default.toml
• ~/.docker/buildx/buildkitd.default.toml

Ten en cuenta que si creas un builder docker-container y has especificado certificados para registros en la configuración buildkitd.toml, los archivos se copiarán en el contenedor bajo /etc/buildkit/certs y la configuración se actualizará para reflejarlo.

Especificar opciones para el demonio de BuildKit (--buildkitd-flags)

--buildkitd-flags FLAGS

Añade banderas al iniciar el demonio de BuildKit. Estas tienen prioridad sobre el archivo de configuración especificado por --buildkitd-config. Consulta buildkitd --help para ver las banderas disponibles.

--buildkitd-flags '--debug --debugaddr 0.0.0.0:6666'

Modo de red del demonio de BuildKit

Puedes especificar el modo de red para el demonio de BuildKit bien con el archivo de configuración especificado por --buildkitd-config utilizando la opción worker.oci.networkMode o bien mediante la bandera --oci-worker-net aquí. El valor predeterminado es auto y puede ser bridge, cni o host.

--buildkitd-flags '--oci-worker-net bridge'

Note

El modo de red "bridge" es compatible desde BuildKit v0.13 y se convertirá en el valor predeterminado en la próxima versión v0.14.

Establecer el controlador (driver) del builder a utilizar (--driver)

--driver DRIVER

Establece el controlador (driver) de builder que se utilizará. Un controlador es una configuración de un backend de BuildKit. Buildx admite los siguientes controladores:

• docker (predeterminado)
• docker-container
• kubernetes
• remote

Para obtener más información sobre los controladores de construcción, consulta aquí.

Controlador docker

Utiliza el builder que está integrado en el demonio de Docker. Con este controlador, la bandera --load está implícita de forma predeterminada en buildx build. Sin embargo, actualmente no se admite la construcción de imágenes multiplataforma ni la exportación de caché.

Controlador docker-container

Utiliza un contenedor de BuildKit que se generará a través de Docker. Con este controlador, se admite tanto la construcción de imágenes multiplataforma como la exportación de caché.

A diferencia del controlador docker, las imágenes construidas no aparecerán automáticamente en docker images, por lo que es necesario utilizar build --load para lograrlo.

Controlador kubernetes

Utiliza pods de Kubernetes. Con este controlador, puedes levantar pods con una imagen de contenedor de BuildKit definida para construir tus imágenes.

A diferencia del controlador docker, las imágenes construidas no aparecerán automáticamente en docker images, por lo que es necesario utilizar build --load para lograrlo.

Controlador remote

Utiliza una instancia remota del demonio de BuildKit sobre una conexión arbitraria. Con este controlador, creas y administras manualmente las instancias de buildkit tú mismo, y configuras buildx para que apunte a ellas.

A diferencia del controlador docker, las imágenes construidas no aparecerán automáticamente en docker images, por lo que es necesario utilizar build --load para lograrlo.

Establecer opciones adicionales específicas del controlador (--driver-opt)

--driver-opt OPTIONS

Pasa opciones adicionales específicas del controlador. Para obtener información sobre las opciones de controlador disponibles, consulta la documentación detallada del controlador específico:

• Controlador docker
• Controlador docker-container
• Controlador kubernetes
• Controlador remote

Eliminar un nodo de un builder (--leave)

La bandera --leave cambia la acción del comando para eliminar un nodo de un builder. El builder debe especificarse con --name y el nodo que se elimina se establece con --node.

$ docker buildx create --name mybuilder --node mybuilder0 --leave

Especificar el nombre del builder (--name)

--name NAME

La bandera --name especifica el nombre del builder que se va a crear o modificar. Si no se especifica ninguno, se generará uno automáticamente.

Especificar el nombre del nodo (--node)

--node NODE

La bandera --node especifica el nombre del nodo que se va a crear o modificar. Si no especificas un nombre, el nombre del nodo será por defecto el nombre del builder al que pertenece, con un sufijo de número de índice.

Establecer las plataformas compatibles con el nodo (--platform)

--platform PLATFORMS

La bandera --platform establece las plataformas admitidas por el nodo. Espera una lista separada por comas de plataformas con el formato sistema_operativo/arquitectura/variante. El nodo también detectará automáticamente las plataformas que admite, pero los valores manuales tienen prioridad sobre los detectados y se pueden utilizar cuando múltiples nodos admiten la construcción para la misma plataforma.

$ docker buildx create --platform linux/amd64
$ docker buildx create --platform linux/arm64,linux/arm/v7

Cambiar automáticamente al builder recién creado (--use)

La bandera --use cambia automáticamente el builder actual al que se acaba de crear. Equivalente a ejecutar docker buildx use $(docker buildx create ...).