# docker buildx create **Descripción:** Crea una nueva instancia de builder **Uso:** `docker buildx create [OPTIONS] [CONTEXT|ENDPOINT]` ## 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 | Opción | Predeterminado | Descripción | | ------------------------------------------------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | `--append` | | Añade un nodo al builder en lugar de cambiarlo | | `--bootstrap` | | Inicia (boot) el builder después de la creación | | `--buildkitd-config` | | Archivo de configuración del demonio de BuildKit | | `--buildkitd-flags` | | Banderas del demonio de BuildKit | | `--driver` | | Controlador (driver) a utilizar (disponibles: `docker-container`, `kubernetes`, `remote`)
| | `--driver-opt` | | Opciones para el controlador (driver) | | `--leave` | | Elimina un nodo del builder en lugar de cambiarlo | | `--name` | | Nombre de la instancia de builder | | `--node` | | Crea o modifica el nodo con el nombre especificado | | `--platform` | | Plataformas fijas para el nodo actual | | `--timeout` | `20s` | Sobrescribe el tiempo de espera (timeout) predeterminado para cargar el estado del builder | | `--use` | | Establece la instancia de builder actual | ## Ejemplos ### Añadir un nuevo nodo a un builder existente (--append) {#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. ```console $ 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} ```text --buildkitd-config FILE ``` Especifica el archivo de configuración que utilizará el demonio de BuildKit. La configuración se puede sobrescribir con [`--buildkitd-flags`](#buildkitd-flags). Consulta un [ejemplo de archivo de configuración del demonio de BuildKit](https://github.com/moby/buildkit/blob/master/docs/buildkitd.toml.md). 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} ```text --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`](#buildkitd-config). Consulta `buildkitd --help` para ver las banderas disponibles. ```text --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`](#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`. ```text --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} ```text --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í](/build/builders/drivers/). #### Controlador `docker` Utiliza el builder que está integrado en el demonio de Docker. Con este controlador, la bandera [`--load`](/reference/cli/docker/buildx/build/#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`](/reference/cli/docker/buildx/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`](/reference/cli/docker/buildx/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`](/reference/cli/docker/buildx/build/#load) para lograrlo. ### Establecer opciones adicionales específicas del controlador (--driver-opt) {#driver-opt} ```text --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`](/build/builders/drivers/docker/) * [Controlador `docker-container`](/build/builders/drivers/docker-container/) * [Controlador `kubernetes`](/build/builders/drivers/kubernetes/) * [Controlador `remote`](/build/builders/drivers/remote/) ### Eliminar un nodo de un builder (--leave) {#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`. ```console $ docker buildx create --name mybuilder --node mybuilder0 --leave ``` ### Especificar el nombre del builder (--name) {#name} ```text --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} ```text --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} ```text --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. ```console $ docker buildx create --platform linux/amd64 $ docker buildx create --platform linux/arm64,linux/arm/v7 ``` ### Cambiar automáticamente al builder recién creado (--use) {#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 ...)`.