The error handling for the cast to client.TracerDelegate was incorrect,
and previously, a client would unconditionally append an opt.
This results in the scenario that while the ClientOpt was not nil, the
tracer delegate in the ClientOpt was, which isn't an error case
explicitly handled by buildkit.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This moves the detection of the docker daemon's security options into
the driver from the factory, handling them in a similar way to how we do
cgroups.
Because of recent changes that modify error detection in driver
creation, this attempt to contact the docker daemon during builder
creation meant that a docker-container builder could not be created
without access to the docker socket. This patch resolves this, by
defering the Info call to the driver, when the container is actually
created.
Signed-off-by: Justin Chadwell <me@jedevc.com>
also needs to update docker/docker to a60b458 (22.06 branch) otherwise
build breaks since docker/cli#3512 with:
# github.com/docker/cli/cli/flags
vendor/github.com/docker/cli/cli/flags/common.go:40:37: undefined: client.EnvOverrideCertPath
vendor/github.com/docker/cli/cli/flags/common.go:41:37: undefined: client.EnvTLSVerify
vendor/github.com/docker/cli/cli/flags/common.go:89:76: undefined: client.EnvOverrideHost
needs also to update github.com/spf13/cobra to v1.5.0 otherwise
build breaks with:
# github.com/docker/cli/cli-plugins/plugin
vendor/github.com/docker/cli/cli-plugins/plugin/plugin.go:130:4: unknown field 'HiddenDefaultCmd' in struct literal of type cobra.CompletionOptions
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
This patch completes the work started in creating a remote driver:
- Renames the env driver to the remote driver (an alternative suggestion
that should be more user-friendly)
- Adds support for TLS to encrypt connections with buildkitd
- Fixes outstanding review comments
- Reworks the buildx create command endpoint construction to be clearer
and include better support for this new driver.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Set `UsernsMode="host"` only when the daemon is running in userns-remapping mode.
Fix issue 561
The issue will be also fixed in moby/moby PR 43084 (Docker 20.10.13).
This buildx PR helps users of old releases of Docker.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Add --keep-daemon to the `rm` command option to preserve the buildkitd daemon after the buildx context is deleted.
Signed-off-by: Mayeul Blanzat <mayeul.blanzat@datadoghq.com>
This allows the parent cgroup to be customised, which allows resource
limits to be imposed on build containers separately from "user"
containers.
Signed-off-by: David Scott <dave@recoil.org>
The container-driver creates a Linux container (as there currently isn't a
Windows version of buildkitd). However, the defaults are platform specific.
Buildx was using the defaults from the buildkit `util/appdefault' package,
which resulted in Buildx running on a Windows client to create a Linux
container that used the Windows location, which causes it to fail:
invalid mount config for type "volume": invalid mount path: 'C:/ProgramData/buildkitd/.buildstate' mount path must be absolute
This patch hard-codes the destination to the default Linux path.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit c41b006be1 updated the version of
docker/docker in go.mod, but possibly overlooked that there was still a
replace rule present. As a result the version was not actually updated.
This patch removes the replace rule, updating docker/docker to 9f28837c1d93
full diff: 4634ce647c...9f28837c1d
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When booting `docker-container` driver, it will pull and run image
`moby/buildkit:buildx-stable-1`.
If current node cannot connect to dockerhub, driver `docker-container`
will always booting failure.
But user may already load the image manually or pull it from a priviate
registry.
Buildx should check local docker image store after pull failed.
Fixes: #199 issuecomment-561996661
Signed-off-by: Lu Jingxiao <lujingxiao@huawei.com>
Tested with `kind` and GKE.
Note: "nodes" shown in `docker buildx ls` are unrelated to Kubernetes "nodes".
Probably buildx should come up with an alternative term.
Usage:
$ kind create cluster
$ export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"
$ docker buildx create --driver kubernetes --driver-opt replicas=3 --use
$ docker buildx build -t foo --load .
`--load` loads the image into the local Docker.
Driver opts:
- `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.
- `rootless=(true|false)` - Run the container as a non-root user without `securityContext.privileged`. 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"
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Justin Chadwell