diff --git a/_data/buildx/docker_buildx_bake.yaml b/_data/buildx/docker_buildx_bake.yaml index 88daea3e0bf..03e47a726da 100644 --- a/_data/buildx/docker_buildx_bake.yaml +++ b/_data/buildx/docker_buildx_bake.yaml @@ -5,12 +5,14 @@ long: |- Bake is a high-level build command. Each specified target will run in parallel as part of the build. - Read [High-level build options](https://github.com/docker/buildx#high-level-build-options) - for introduction. - - Please note that `buildx bake` command may receive backwards incompatible - features in the future if needed. We are looking for feedback on improving the - command and extending the functionality further. + Read [High-level build options with Bake](/build/bake/) + guide for introduction to writing bake files. + + > **Note** + > + > `buildx bake` command may receive backwards incompatible features in the future + > if needed. We are looking for feedback on improving the command and extending + > the functionality further. usage: docker buildx bake [OPTIONS] [TARGET...] pname: docker buildx plink: docker_buildx.yaml @@ -130,167 +132,43 @@ examples: |- ### Specify a build definition file (-f, --file) {#file} - By default, `buildx bake` looks for build definition files in the current - directory, the following are parsed: - - - `docker-compose.yml` - - `docker-compose.yaml` - - `docker-bake.json` - - `docker-bake.override.json` - - `docker-bake.hcl` - - `docker-bake.override.hcl` - - Use the `-f` / `--file` option to specify the build definition file to use. The - file can be a Docker Compose, JSON or HCL file. If multiple files are specified + Use the `-f` / `--file` option to specify the build definition file to use. + The file can be an HCL, JSON or Compose file. If multiple files are specified they are all read and configurations are combined. - The following example uses a Docker Compose file named `docker-compose.dev.yaml` - as build definition file, and builds all targets in the file: - - ```console - $ docker buildx bake -f docker-compose.dev.yaml - - [+] Building 66.3s (30/30) FINISHED - => [frontend internal] load build definition from Dockerfile 0.1s - => => transferring dockerfile: 36B 0.0s - => [backend internal] load build definition from Dockerfile 0.2s - => => transferring dockerfile: 3.73kB 0.0s - => [database internal] load build definition from Dockerfile 0.1s - => => transferring dockerfile: 5.77kB 0.0s - ... - ``` - - Pass the names of the targets to build, to build only specific target(s). The - following example builds the `backend` and `database` targets that are defined - in the `docker-compose.dev.yaml` file, skipping the build for the `frontend` - target: - - ```console - $ docker buildx bake -f docker-compose.dev.yaml backend database - - [+] Building 2.4s (13/13) FINISHED - => [backend internal] load build definition from Dockerfile 0.1s - => => transferring dockerfile: 81B 0.0s - => [database internal] load build definition from Dockerfile 0.2s - => => transferring dockerfile: 36B 0.0s - => [backend internal] load .dockerignore 0.3s - ... - ``` - - You can also use a remote `git` bake definition: + You can pass the names of the targets to build, to build only specific target(s). + The following example builds the `db` and `webapp-release` targets that are + defined in the `docker-bake.dev.hcl` file: - ```console - $ docker buildx bake "https://github.com/docker/cli.git#v20.10.11" --print - #1 [internal] load git source https://github.com/docker/cli.git#v20.10.11 - #1 0.745 e8f1871b077b64bcb4a13334b7146492773769f7 refs/tags/v20.10.11 - #1 2.022 From https://github.com/docker/cli - #1 2.022 * [new tag] v20.10.11 -> v20.10.11 - #1 DONE 2.9s - { - "group": { - "default": { - "targets": [ - "binary" - ] - } - }, - "target": { - "binary": { - "context": "https://github.com/docker/cli.git#v20.10.11", - "dockerfile": "Dockerfile", - "args": { - "BASE_VARIANT": "alpine", - "GO_STRIP": "", - "VERSION": "" - }, - "target": "binary", - "platforms": [ - "local" - ], - "output": [ - "build" - ] - } - } + ```hcl + # docker-bake.dev.hcl + group "default" { + targets = ["db", "webapp-dev"] } - ``` - - As you can see the context is fixed to `https://github.com/docker/cli.git` even if - [no context is actually defined](https://github.com/docker/cli/blob/2776a6d694f988c0c1df61cad4bfac0f54e481c8/docker-bake.hcl#L17-L26) - in the definition. - If you want to access the main context for bake command from a bake file - that has been imported remotely, you can use the `BAKE_CMD_CONTEXT` builtin var: - - ```console - $ cat https://raw.githubusercontent.com/tonistiigi/buildx/remote-test/docker-bake.hcl - target "default" { - context = BAKE_CMD_CONTEXT - dockerfile-inline = < [4/4] RUN ls -l && stop: - #8 0.101 total 0 - #8 0.102 -rw-r--r-- 1 root root 0 Jul 27 18:47 bar - #8 0.102 -rw-r--r-- 1 root root 0 Jul 27 18:47 foo - #8 0.102 /bin/sh: stop: not found - ``` - - ```console - $ docker buildx bake "https://github.com/tonistiigi/buildx.git#remote-test" "https://github.com/docker/cli.git#v20.10.11" --print - #1 [internal] load git source https://github.com/tonistiigi/buildx.git#remote-test - #1 0.429 577303add004dd7efeb13434d69ea030d35f7888 refs/heads/remote-test - #1 CACHED - { - "target": { - "default": { - "context": "https://github.com/docker/cli.git#v20.10.11", - "dockerfile": "Dockerfile", - "dockerfile-inline": "FROM alpine\nWORKDIR /src\nCOPY . .\nRUN ls -l \u0026\u0026 stop\n" - } - } + target "db" { + dockerfile = "Dockerfile.db" + tags = ["docker.io/username/db"] } ``` ```console - $ docker buildx bake "https://github.com/tonistiigi/buildx.git#remote-test" "https://github.com/docker/cli.git#v20.10.11" - ... - > [4/4] RUN ls -l && stop: - #8 0.136 drwxrwxrwx 5 root root 4096 Jul 27 18:31 kubernetes - #8 0.136 drwxrwxrwx 3 root root 4096 Jul 27 18:31 man - #8 0.136 drwxrwxrwx 2 root root 4096 Jul 27 18:31 opts - #8 0.136 -rw-rw-rw- 1 root root 1893 Jul 27 18:31 poule.yml - #8 0.136 drwxrwxrwx 7 root root 4096 Jul 27 18:31 scripts - #8 0.136 drwxrwxrwx 3 root root 4096 Jul 27 18:31 service - #8 0.136 drwxrwxrwx 2 root root 4096 Jul 27 18:31 templates - #8 0.136 drwxrwxrwx 10 root root 4096 Jul 27 18:31 vendor - #8 0.136 -rwxrwxrwx 1 root root 9620 Jul 27 18:31 vendor.conf - #8 0.136 /bin/sh: stop: not found + $ docker buildx bake -f docker-bake.dev.hcl db webapp-release ``` + See our [file definition](/build/bake/file-definition/) + guide for more details. + ### Do not use cache when building the image (--no-cache) {#no-cache} Same as `build --no-cache`. Do not use cache when building the image. @@ -367,704 +245,21 @@ examples: |- ``` Complete list of overridable fields: - `args`, `cache-from`, `cache-to`, `context`, `dockerfile`, `labels`, `no-cache`, - `output`, `platform`, `pull`, `secrets`, `ssh`, `tags`, `target` - - ### File definition - - In addition to compose files, bake supports a JSON and an equivalent HCL file - format for defining build groups and targets. - - A target reflects a single docker build invocation with the same options that - you would specify for `docker build`. A group is a grouping of targets. - - Multiple files can include the same target and final build options will be - determined by merging them together. - - In the case of compose files, each service corresponds to a target. - - A group can specify its list of targets with the `targets` option. A target can - inherit build options by setting the `inherits` option to the list of targets or - groups to inherit from. - - Note: Design of bake command is work in progress, the user experience may change - based on feedback. - - HCL definition example: - - ```hcl - group "default" { - targets = ["db", "webapp-dev"] - } - - target "webapp-dev" { - dockerfile = "Dockerfile.webapp" - tags = ["docker.io/username/webapp"] - } - - target "webapp-release" { - inherits = ["webapp-dev"] - platforms = ["linux/amd64", "linux/arm64"] - } - - target "db" { - dockerfile = "Dockerfile.db" - tags = ["docker.io/username/db"] - } - ``` - - Complete list of valid target fields: - - `args`, `cache-from`, `cache-to`, `context`, `contexts`, `dockerfile`, `inherits`, `labels`, - `no-cache`, `no-cache-filter`, `output`, `platform`, `pull`, `secrets`, `ssh`, `tags`, `target` - - ### Global scope attributes - - You can define global scope attributes in HCL/JSON and use them for code reuse - and setting values for variables. This means you can do a "data-only" HCL file - with the values you want to set/override and use it in the list of regular - output files. - - ```hcl - # docker-bake.hcl - variable "FOO" { - default = "abc" - } - - target "app" { - args = { - v1 = "pre-${FOO}" - } - } - ``` - - You can use this file directly: - - ```console - $ docker buildx bake --print app - { - "group": { - "default": { - "targets": [ - "app" - ] - } - }, - "target": { - "app": { - "context": ".", - "dockerfile": "Dockerfile", - "args": { - "v1": "pre-abc" - } - } - } - } - ``` - - Or create an override configuration file: - - ```hcl - # env.hcl - WHOAMI="myuser" - FOO="def-${WHOAMI}" - ``` - - And invoke bake together with both of the files: - - ```console - $ docker buildx bake -f docker-bake.hcl -f env.hcl --print app - { - "group": { - "default": { - "targets": [ - "app" - ] - } - }, - "target": { - "app": { - "context": ".", - "dockerfile": "Dockerfile", - "args": { - "v1": "pre-def-myuser" - } - } - } - } - ``` - - ### HCL variables and functions - - Similar to how Terraform provides a way to [define variables](https://www.terraform.io/docs/configuration/variables.html#declaring-an-input-variable), - the HCL file format also supports variable block definitions. These can be used - to define variables with values provided by the current environment, or a - default value when unset. - - A [set of generally useful functions](https://github.com/docker/buildx/blob/master/bake/hclparser/stdlib.go) - provided by [go-cty](https://github.com/zclconf/go-cty/tree/main/cty/function/stdlib) - are available for use in HCL files. In addition, [user defined functions](https://github.com/hashicorp/hcl/tree/main/ext/userfunc) - are also supported. - - #### Using interpolation to tag an image with the git sha - - Bake supports variable blocks which are assigned to matching environment - variables or default values. - - ```hcl - # docker-bake.hcl - variable "TAG" { - default = "latest" - } - - group "default" { - targets = ["webapp"] - } - - target "webapp" { - tags = ["docker.io/username/webapp:${TAG}"] - } - ``` - - alternatively, in json format: - - ```json - { - "variable": { - "TAG": { - "default": "latest" - } - } - "group": { - "default": { - "targets": ["webapp"] - } - }, - "target": { - "webapp": { - "tags": ["docker.io/username/webapp:${TAG}"] - } - } - } - ``` - - ```console - $ docker buildx bake --print webapp - { - "group": { - "default": { - "targets": [ - "webapp" - ] - } - }, - "target": { - "webapp": { - "context": ".", - "dockerfile": "Dockerfile", - "tags": [ - "docker.io/username/webapp:latest" - ] - } - } - } - ``` - - ```console - $ TAG=$(git rev-parse --short HEAD) docker buildx bake --print webapp - { - "group": { - "default": { - "targets": [ - "webapp" - ] - } - }, - "target": { - "webapp": { - "context": ".", - "dockerfile": "Dockerfile", - "tags": [ - "docker.io/username/webapp:985e9e9" - ] - } - } - } - ``` - - #### Using the `add` function - - You can use [`go-cty` stdlib functions](https://github.com/zclconf/go-cty/tree/main/cty/function/stdlib). - Here we are using the `add` function. - - ```hcl - # docker-bake.hcl - variable "TAG" { - default = "latest" - } - - group "default" { - targets = ["webapp"] - } - - target "webapp" { - args = { - buildno = "${add(123, 1)}" - } - } - ``` - - ```console - $ docker buildx bake --print webapp - { - "group": { - "default": { - "targets": [ - "webapp" - ] - } - }, - "target": { - "webapp": { - "context": ".", - "dockerfile": "Dockerfile", - "args": { - "buildno": "124" - } - } - } - } - ``` - - #### Defining an `increment` function - - It also supports [user defined functions](https://github.com/hashicorp/hcl/tree/main/ext/userfunc). - The following example defines a simple an `increment` function. - - ```hcl - # docker-bake.hcl - function "increment" { - params = [number] - result = number + 1 - } - - group "default" { - targets = ["webapp"] - } - - target "webapp" { - args = { - buildno = "${increment(123)}" - } - } - ``` - - ```console - $ docker buildx bake --print webapp - { - "group": { - "default": { - "targets": [ - "webapp" - ] - } - }, - "target": { - "webapp": { - "context": ".", - "dockerfile": "Dockerfile", - "args": { - "buildno": "124" - } - } - } - } - ``` - - #### Only adding tags if a variable is not empty using an `notequal` - - Here we are using the conditional `notequal` function which is just for - symmetry with the `equal` one. - - ```hcl - # docker-bake.hcl - variable "TAG" {default="" } - - group "default" { - targets = [ - "webapp", - ] - } - - target "webapp" { - context="." - dockerfile="Dockerfile" - tags = [ - "my-image:latest", - notequal("",TAG) ? "my-image:${TAG}": "", - ] - } - ``` - - ```console - $ docker buildx bake --print webapp - { - "group": { - "default": { - "targets": [ - "webapp" - ] - } - }, - "target": { - "webapp": { - "context": ".", - "dockerfile": "Dockerfile", - "tags": [ - "my-image:latest" - ] - } - } - } - ``` - - #### Using variables in functions - - You can refer variables to other variables like the target blocks can. Stdlib - functions can also be called but user functions can't at the moment. - - ```hcl - # docker-bake.hcl - variable "REPO" { - default = "user/repo" - } - - function "tag" { - params = [tag] - result = ["${REPO}:${tag}"] - } - - target "webapp" { - tags = tag("v1") - } - ``` - - ```console - $ docker buildx bake --print webapp - { - "group": { - "default": { - "targets": [ - "webapp" - ] - } - }, - "target": { - "webapp": { - "context": ".", - "dockerfile": "Dockerfile", - "tags": [ - "user/repo:v1" - ] - } - } - } - ``` - - #### Using variables in variables across files - - When multiple files are specified, one file can use variables defined in - another file. - - ```hcl - # docker-bake1.hcl - variable "FOO" { - default = upper("${BASE}def") - } - - variable "BAR" { - default = "-${FOO}-" - } - - target "app" { - args = { - v1 = "pre-${BAR}" - } - } - ``` - - ```hcl - # docker-bake2.hcl - variable "BASE" { - default = "abc" - } - - target "app" { - args = { - v2 = "${FOO}-post" - } - } - ``` - - ```console - $ docker buildx bake -f docker-bake1.hcl -f docker-bake2.hcl --print app - { - "group": { - "default": { - "targets": [ - "app" - ] - } - }, - "target": { - "app": { - "context": ".", - "dockerfile": "Dockerfile", - "args": { - "v1": "pre--ABCDEF-", - "v2": "ABCDEF-post" - } - } - } - } - ``` - - #### Using typed variables - - Non-string variables are also accepted. The value passed with env is parsed - into suitable type first. - - ```hcl - # docker-bake.hcl - variable "FOO" { - default = 3 - } - - variable "IS_FOO" { - default = true - } - - target "app" { - args = { - v1 = FOO > 5 ? "higher" : "lower" - v2 = IS_FOO ? "yes" : "no" - } - } - ``` - - ```console - $ docker buildx bake --print app - { - "group": { - "default": { - "targets": [ - "app" - ] - } - }, - "target": { - "app": { - "context": ".", - "dockerfile": "Dockerfile", - "args": { - "v1": "lower", - "v2": "yes" - } - } - } - } - ``` - - ### Defining additional build contexts and linking targets - - In addition to the main `context` key that defines the build context each target can also define additional named contexts with a map defined with key `contexts`. These values map to the `--build-context` flag in the [build command](buildx_build.md#build-context). - - Inside the Dockerfile these contexts can be used with the `FROM` instruction or `--from` flag. - - The value can be a local source directory, container image (with docker-image:// prefix), Git URL, HTTP URL or a name of another target in the Bake file (with target: prefix). - - #### Pinning alpine image - - ```Dockerfile - # Dockerfile - FROM alpine - RUN echo "Hello world" - ``` - - ```hcl - # docker-bake.hcl - target "app" { - contexts = { - alpine = "docker-image://alpine:3.13" - } - } - ``` - - #### Using a secondary source directory - - ```Dockerfile - # Dockerfile - - FROM scratch AS src - - FROM golang - COPY --from=src . . - ``` - - ```hcl - # docker-bake.hcl - target "app" { - contexts = { - src = "../path/to/source" - } - } - ``` - - #### Using a result of one target as a base image in another target - - To use a result of one target as a build context of another, specity the target name with `target:` prefix. - - ```Dockerfile - # Dockerfile - FROM baseapp - RUN echo "Hello world" - ``` - - ```hcl - # docker-bake.hcl - - target "base" { - dockerfile = "baseapp.Dockerfile" - } - - target "app" { - contexts = { - baseapp = "target:base" - } - } - ``` - - Please note that in most cases you should just use a single multi-stage Dockerfile with multiple targets for similar behavior. This case is recommended when you have multiple Dockerfiles that can't be easily merged into one. - - ### Extension field with Compose - - [Special extension](https://github.com/compose-spec/compose-spec/blob/master/spec.md#extension) - field `x-bake` can be used in your compose file to evaluate fields that are not - (yet) available in the [build definition](https://github.com/compose-spec/compose-spec/blob/master/build.md#build-definition). - - ```yaml - # docker-compose.yml - services: - addon: - image: ct-addon:bar - build: - context: . - dockerfile: ./Dockerfile - args: - CT_ECR: foo - CT_TAG: bar - x-bake: - tags: - - ct-addon:foo - - ct-addon:alp - platforms: - - linux/amd64 - - linux/arm64 - cache-from: - - user/app:cache - - type=local,src=path/to/cache - cache-to: type=local,dest=path/to/cache - pull: true - - aws: - image: ct-fake-aws:bar - build: - dockerfile: ./aws.Dockerfile - args: - CT_ECR: foo - CT_TAG: bar - x-bake: - secret: - - id=mysecret,src=./secret - - id=mysecret2,src=./secret2 - platforms: linux/arm64 - output: type=docker - no-cache: true - ``` - - ```console - $ docker buildx bake --print - { - "group": { - "default": { - "targets": [ - "aws", - "addon" - ] - } - }, - "target": { - "addon": { - "context": ".", - "dockerfile": "./Dockerfile", - "args": { - "CT_ECR": "foo", - "CT_TAG": "bar" - }, - "tags": [ - "ct-addon:foo", - "ct-addon:alp" - ], - "cache-from": [ - "user/app:cache", - "type=local,src=path/to/cache" - ], - "cache-to": [ - "type=local,dest=path/to/cache" - ], - "platforms": [ - "linux/amd64", - "linux/arm64" - ], - "pull": true - }, - "aws": { - "context": ".", - "dockerfile": "./aws.Dockerfile", - "args": { - "CT_ECR": "foo", - "CT_TAG": "bar" - }, - "tags": [ - "ct-fake-aws:bar" - ], - "secret": [ - "id=mysecret,src=./secret", - "id=mysecret2,src=./secret2" - ], - "platforms": [ - "linux/arm64" - ], - "output": [ - "type=docker" - ], - "no-cache": true - } - } - } - ``` - - Complete list of valid fields for `x-bake`: - - `tags`, `cache-from`, `cache-to`, `secret`, `ssh`, `platforms`, `output`, - `pull`, `no-cache`, `no-cache-filter` - - ### Built-in variables - * `BAKE_CMD_CONTEXT` can be used to access the main `context` for bake command - from a bake file that has been [imported remotely](#file). - * `BAKE_LOCAL_PLATFORM` returns the current platform's default platform - specification (e.g. `linux/amd64`). + * `args` + * `cache-from` + * `cache-to` + * `context` + * `dockerfile` + * `labels` + * `no-cache` + * `output` + * `platform` + * `pull` + * `secrets` + * `ssh` + * `tags` + * `target` deprecated: false experimental: false experimentalcli: false diff --git a/_data/buildx/docker_buildx_build.yaml b/_data/buildx/docker_buildx_build.yaml index 381064e5a53..65fe3b559c5 100644 --- a/_data/buildx/docker_buildx_build.yaml +++ b/_data/buildx/docker_buildx_build.yaml @@ -818,7 +818,7 @@ examples: |- - `src`, `source` - Secret filename. `id` used if unset. ```dockerfile - # syntax=docker/dockerfile:1.3 + # syntax=docker/dockerfile:1.4 FROM python:3 RUN pip install awscli RUN --mount=type=secret,id=aws,target=/root/.aws/credentials \ @@ -837,7 +837,7 @@ examples: |- - `env` - Secret environment variable. `id` used if unset, otherwise will look for `src`, `source` if `id` unset. ```dockerfile - # syntax=docker/dockerfile:1.3 + # syntax=docker/dockerfile:1.4 FROM node:alpine RUN --mount=type=bind,target=. \ --mount=type=secret,id=SECRET_TOKEN \ @@ -869,7 +869,7 @@ examples: |- Example to access Gitlab using an SSH agent socket: ```dockerfile - # syntax=docker/dockerfile:1.3 + # syntax=docker/dockerfile:1.4 FROM alpine RUN apk add --no-cache openssh-client RUN mkdir -p -m 0700 ~/.ssh && ssh-keyscan gitlab.com >> ~/.ssh/known_hosts diff --git a/_data/buildx/docker_buildx_create.yaml b/_data/buildx/docker_buildx_create.yaml index 1e763c0129f..e0fb3b1e742 100644 --- a/_data/buildx/docker_buildx_create.yaml +++ b/_data/buildx/docker_buildx_create.yaml @@ -58,7 +58,7 @@ options: - option: driver value_type: string description: | - Driver to use (available: `docker`, `docker-container`, `kubernetes`) + Driver to use (available: `docker`, `docker-container`, `kubernetes`, `remote`) details_url: '#driver' deprecated: false hidden: false @@ -179,6 +179,11 @@ examples: |- can be overridden by [`--buildkitd-flags`](#buildkitd-flags). See an [example buildkitd configuration file](https://github.com/moby/buildkit/blob/master/docs/buildkitd.toml.md). + If the configuration file is not specified, will look for one by default in: + * `$BUILDX_CONFIG/buildkitd.default.toml` + * `$DOCKER_CONFIG/buildx/buildkitd.default.toml` + * `~/.docker/buildx/buildkitd.default.toml` + Note that if you create a `docker-container` builder and have specified certificates for registries in the `buildkitd.toml` configuration, the files will be copied into the container under `/etc/buildkit/certs` and configuration @@ -218,32 +223,59 @@ examples: |- `docker images` and [`build --load`](buildx_build.md#load) needs to be used to achieve that. + #### `remote` driver + + Uses a remote instance of buildkitd over an arbitrary connection. With this + driver, you manually create and manage instances of buildkit yourself, and + configure buildx to point at it. + + Unlike `docker` driver, built images will not automatically appear in + `docker images` and [`build --load`](buildx_build.md#load) needs to be used + to achieve that. + ### Set additional driver-specific options (--driver-opt) {#driver-opt} ``` --driver-opt OPTIONS ``` - Passes additional driver-specific options. Details for each driver: - - - `docker` - No driver options - - `docker-container` - - `image=IMAGE` - Sets the container image to be used for running buildkit. - - `network=NETMODE` - Sets the network mode for running the buildkit container. - - `cgroup-parent=CGROUP` - Sets the cgroup parent of the buildkit container if docker is using the "cgroupfs" driver. Defaults to `/docker/buildx`. - - `kubernetes` - - `image=IMAGE` - Sets the container image to be used for running buildkit. - - `namespace=NS` - Sets the Kubernetes namespace. Defaults to the current namespace. - - `replicas=N` - Sets the number of `Pod` replicas. Defaults to 1. - - `requests.cpu` - Sets the request CPU value specified in units of Kubernetes CPU. Example `requests.cpu=100m`, `requests.cpu=2` - - `requests.memory` - Sets the request memory value specified in bytes or with a valid suffix. Example `requests.memory=500Mi`, `requests.memory=4G` - - `limits.cpu` - Sets the limit CPU value specified in units of Kubernetes CPU. Example `limits.cpu=100m`, `limits.cpu=2` - - `limits.memory` - Sets the limit memory value specified in bytes or with a valid suffix. Example `limits.memory=500Mi`, `limits.memory=4G` - - `nodeselector="label1=value1,label2=value2"` - Sets the kv of `Pod` nodeSelector. No Defaults. Example `nodeselector=kubernetes.io/arch=arm64` - - `rootless=(true|false)` - Run the container as a non-root user without `securityContext.privileged`. [Using Ubuntu host kernel is recommended](https://github.com/moby/buildkit/blob/master/docs/rootless.md). Defaults to false. - - `loadbalance=(sticky|random)` - Load-balancing strategy. If set to "sticky", the pod is chosen using the hash of the context path. Defaults to "sticky" - - `qemu.install=(true|false)` - Install QEMU emulation for multi platforms support. - - `qemu.image=IMAGE` - Sets the QEMU emulation image. Defaults to `tonistiigi/binfmt:latest` + Passes additional driver-specific options. + + Note: When using quoted values for example for the `nodeselector` or + `tolerations` options, ensure that quotes are escaped correctly for your shell. + + #### `docker` driver + + No driver options. + + #### `docker-container` driver + + - `image=IMAGE` - Sets the container image to be used for running buildkit. + - `network=NETMODE` - Sets the network mode for running the buildkit container. + - `cgroup-parent=CGROUP` - Sets the cgroup parent of the buildkit container if docker is using the "cgroupfs" driver. Defaults to `/docker/buildx`. + + #### `kubernetes` driver + + - `image=IMAGE` - Sets the container image to be used for running buildkit. + - `namespace=NS` - Sets the Kubernetes namespace. Defaults to the current namespace. + - `replicas=N` - Sets the number of `Pod` replicas. Defaults to 1. + - `requests.cpu` - Sets the request CPU value specified in units of Kubernetes CPU. Example `requests.cpu=100m`, `requests.cpu=2` + - `requests.memory` - Sets the request memory value specified in bytes or with a valid suffix. Example `requests.memory=500Mi`, `requests.memory=4G` + - `limits.cpu` - Sets the limit CPU value specified in units of Kubernetes CPU. Example `limits.cpu=100m`, `limits.cpu=2` + - `limits.memory` - Sets the limit memory value specified in bytes or with a valid suffix. Example `limits.memory=500Mi`, `limits.memory=4G` + - `"nodeselector=label1=value1,label2=value2"` - Sets the kv of `Pod` nodeSelector. No Defaults. Example `nodeselector=kubernetes.io/arch=arm64` + - `"tolerations=key=foo,value=bar;key=foo2,operator=exists;key=foo3,effect=NoSchedule"` - Sets the `Pod` tolerations. Accepts the same values as the kube manifest tolera>tions. Key-value pairs are separated by `,`, tolerations are separated by `;`. No Defaults. Example `tolerations=operator=exists` + - `rootless=(true|false)` - Run the container as a non-root user without `securityContext.privileged`. Needs Kubernetes 1.19 or later. [Using Ubuntu host kernel is recommended](https://github.com/moby/buildkit/blob/master/docs/rootless.md). Defaults to false. + - `loadbalance=(sticky|random)` - Load-balancing strategy. If set to "sticky", the pod is chosen using the hash of the context path. Defaults to "sticky" + - `qemu.install=(true|false)` - Install QEMU emulation for multi platforms support. + - `qemu.image=IMAGE` - Sets the QEMU emulation image. Defaults to `tonistiigi/binfmt:latest` + + #### `remote` driver + + - `key=KEY` - Sets the TLS client key. + - `cert=CERT` - Sets the TLS client certificate to present to buildkitd. + - `cacert=CACERT` - Sets the TLS certificate authority used for validation. + - `servername=SERVER` - Sets the TLS server name to be used in requests (defaults to the endpoint hostname). ### Remove a node from a builder (--leave) {#leave} diff --git a/_data/buildx/docker_buildx_inspect.yaml b/_data/buildx/docker_buildx_inspect.yaml index a47bba0dcf9..53c28cf953e 100644 --- a/_data/buildx/docker_buildx_inspect.yaml +++ b/_data/buildx/docker_buildx_inspect.yaml @@ -48,6 +48,10 @@ examples: |- The following example shows information about a builder instance named `elated_tesla`: + > **Note** + > + > Asterisk `*` next to node build platform(s) indicate they had been set manually during `buildx create`. Otherwise, it had been autodetected. + ```console $ docker buildx inspect elated_tesla @@ -63,7 +67,7 @@ examples: |- Name: elated_tesla1 Endpoint: ssh://ubuntu@1.2.3.4 Status: running - Platforms: linux/arm64, linux/arm/v7, linux/arm/v6 + Platforms: linux/arm64*, linux/arm/v7, linux/arm/v6 ``` deprecated: false experimental: false diff --git a/_data/buildx/docker_buildx_ls.yaml b/_data/buildx/docker_buildx_ls.yaml index bbe0509043b..36d9fc52c2c 100644 --- a/_data/buildx/docker_buildx_ls.yaml +++ b/_data/buildx/docker_buildx_ls.yaml @@ -5,13 +5,12 @@ long: |- ```console $ docker buildx ls - - NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS + NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS elated_tesla * docker-container - elated_tesla0 unix:///var/run/docker.sock running linux/amd64 - elated_tesla1 ssh://ubuntu@1.2.3.4 running linux/arm64*, linux/arm/v7, linux/arm/v6 + elated_tesla0 unix:///var/run/docker.sock running v0.10.3 linux/amd64 + elated_tesla1 ssh://ubuntu@1.2.3.4 running v0.10.3 linux/arm64*, linux/arm/v7, linux/arm/v6 default docker - default default running linux/amd64 + default default running 20.10.14 linux/amd64 ``` Each builder has one or more nodes associated with it. The current builder's