driver: buildkitd-netmode flag to set worker network mode#2270
driver: buildkitd-netmode flag to set worker network mode#2270crazy-max wants to merge 2 commits intodocker:masterfrom
Conversation
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
crazy-max
changed the title
| FROM alpine | ||
| RUN apk add --no-cache curl`) |
There was a problem hiding this comment.
@tonistiigi Let me know if this integration test is enough
There was a problem hiding this comment.
curl doesn't show much. We can test that ip a shows different IP for RUN and RUN --net=host.
There was a problem hiding this comment.
Looks like there is a bug with bridge network mode and host entitlement:
FROM busybox
RUN ip a
RUN --network=host ip a$ docker buildx create --name bridge --buildkitd-flags "--debug --allow-insecure-entitlement network.host --oci-worker-net bridge" --driver-opt "image=moby/buildkit:master" --bootstrap
$ docker buildx --builder bridge build --no-cache .
...
#3 [internal] load .dockerignore
#3 transferring context: 2B done
#3 DONE 0.0s
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
ERROR: failed to solve: failed to load LLB: network.host is not allowed
|
ci failure for docs-upstream workflow is not related: #2269 |
| Platforms []string | ||
| BuildkitdFlags string | ||
| BuildkitdConfigFile string | ||
| BuildkitdNetmode string |
There was a problem hiding this comment.
Why is this adding new option to create instead of just defining a new driveropt?
There was a problem hiding this comment.
For me a driver-opt is driver specific (container config for docker-container with docker api, pod specific for k8s api) while buildkitd-(flags|config) is common. I think this would be confusing to put it as driver-opt.
There was a problem hiding this comment.
I don't think this is an important enough case to have a special option. Basically, it is only a test option for v0.13. After v0.14, if bridge becomes default we don't expect anyone to ever use this anymore.
There was a problem hiding this comment.
After v0.14, if bridge becomes default we don't expect anyone to ever use this anymore.
If we have more network mode in the future that could be valuable I think? Like a wg mode (wireguard) one?
If you don't see this as valuable to keep, I was thinking we could use an env var instead? Something like BUILDKIT_NETMODE or EXPERIMENTAL_BUILDKIT_NETMODE? But current vars https://docs.docker.com/build/building/variables/#build-tool-configuration-variables are not drive for create cmd, only build or bake so might not be ideal 😞
So yeah maybe a driver-opt with a specific description about it saying this is temporary could be ok.
There was a problem hiding this comment.
Maybe we should skip it then and just document setting --buildkitd-flags. We can still keep the test.
There was a problem hiding this comment.
Maybe we should skip it then and just document setting
--buildkitd-flags. We can still keep the test.
Yeah --buildkitd-netmode is more likely a shorthand for --buildkitd-flags="--oci-worker-net=<mode>". I'm fine just documenting --buildkitd-flags to set custom network mode.
| }) | ||
|
|
||
| // TODO: use stable buildkit image when v0.13.0 released | ||
| out, err := createCmd(sb, withArgs("--driver", "docker-container", "--buildkitd-netmode=bridge", "--driver-opt", "image=moby/buildkit:master")) |
There was a problem hiding this comment.
Future follow-up: ideally these cases should be handled so that we can test any buildkit version and test can mark itself to be skipped if it doesn't work with specific version.
2 participants
fixes #2256
needs #2268