Buildkit: DOCKER_BUILDKIT=1 prevents custom networks using docker build --network

Created on 6 May 2019  路  19Comments  路  Source: moby/buildkit

Not sure if this is a Docker CLI or BuildKit issue, but when using BuildKit by specifying DOCKER_BUILDKIT=1 as part of a Docker Build in Docker v18.09, a custom Docker network is no longer recognized.

So for example, a command of "docker build --network demo-net ." will now return:

Error response from daemon: network mode "demo-net" not supported by buildkit

Seemingly this means that it only supports specific network modes are being supported, and not custom Docker networks.

arefeature-parity enhancement

Most helpful comment

im also looking at this one. I want to build and add to a custom network along with mongodb to run integration tests;

All 19 comments

cc @kunalkushwaha

I have just stumbled across this too (running an apt_cache container locally to support my builds); believe this is intentional: this conditional pretty much says that no network modes other than host, none, or the default are supported /:

im also looking at this one. I want to build and add to a custom network along with mongodb to run integration tests;

I'm also very interested in this!

any updates at this one?

I faced this issue too when running build in Swarm from CI server. We attach to network where container with private Nuget server resides to pull required packages.
And because of this limitation we can't use buildkit for such builds.

Have run into this issue as well trying to build an image that uses a Redis instance for testing during the build process. Any updates?

I have just stumbled across this too (running an apt_cache container locally to support my builds); believe this is intentional: this conditional pretty much says that no network modes other than host, none, or the default are supported /:

I suspect there just wasn't time/focus to implement the feature, it's marked as a roadblock item in the comment on https://github.com/moby/moby/issues/40379 - if it's removed it would be a definite functional regression.

This is a real blocker for me cause I cannot access my DNS server in another container while building.

Any updates or workaround on this one?

workaround: export DOCKER_BUILDKIT=0

@AkihiroSuda that's not really a workaround since then you cannot use the features provided by docker buildkit. Like secrets, in my case.

This affects us as we use lots of auxiliary containers (SQL Server, Kafka, Redis) to run integration tests during builds.

Without --network, we will have no ways to use the BuildKit, and we'll have to stick to the old build model.

Since BuildKit is now enabled in docker by default we need a solution for this issue, can't use BuildKit without it :(

@RytisLT is that true? I don't see anything indicating that, and https://github.com/moby/moby/issues/40379 seems to say that BuildKit still isn't the default.

@RytisLT yes and no. It's already the default for new installations (or after factory reset) on windows. Source: docker.com

Another workaround, while not ideal, is to --publish any services you needed from the --network and use the host.docker.internal URL from your build to access it:

docker build --tag artifacts - <<EOF
FROM busybox
RUN set -e; \
    mkdir --parents /opt/artifact; \
    echo "hello world" > /opt/artifact/hello;
EXPOSE 8080
ENTRYPOINT ["httpd", "-f", "-h", "/opt/artifact", "-p", "8080"]
EOF

docker run --detach --name artifact-repo --rm --publish-all artifacts
port="$(
  docker inspect \
    --format '{{(index (index .NetworkSettings.Ports "8080/tcp") 0).HostPort}}' \
    artifact-repo)"

docker build --tag tester - <<EOF
FROM busybox
RUN wget --output-document - http://host.docker.internal:${port}/hello
EOF

docker kill artifact-repo

Gives

Error response from daemon: Cannot kill container: artifact-repo: No such container: artifact-repo
Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM busybox
 ---> 219ee5171f80
Step 2/4 : RUN set -e;     mkdir --parents /opt/artifact;     echo "hello world" > /opt/artifact/hello;
 ---> Using cache
 ---> 965724e107bd
Step 3/4 : EXPOSE 8080
 ---> Using cache
 ---> e39c7128ebca
Step 4/4 : ENTRYPOINT ["httpd", "-f", "-h", "/opt/artifact", "-p", "8080"]
 ---> Using cache
 ---> 7102e8ab2186
Successfully built 7102e8ab2186
Successfully tagged artifacts:latest
4696cbdd65268a55cb34ae450a8ec1e51c91bf1eaa5511ac0f4f4e515b34a958
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM busybox
 ---> 219ee5171f80
Step 2/2 : RUN wget --output-document - http://host.docker.internal:32774/hello
 ---> Running in 20c2229c7de7
Connecting to host.docker.internal:32774 (192.168.65.2:32774)
hello world
writing to stdout
-                    100% |********************************|    12  0:00:00 ETA
written to stdout
Removing intermediate container 20c2229c7de7
 ---> 96c004a8abab
Successfully built 96c004a8abab
Successfully tagged tester:latest
artifact-repo

@RytisLT yes and no. It's already the default for new installations (or after factory reset) on windows. Source: docker.com

To clarify, that comment refers to the following Docker for Windows 2.4.0.0 change:

Docker Desktop now enables BuildKit by default after a reset to factory defaults. To revert to the old docker build experience, go to Preferences > Docker Engine and then disable the BuildKit feature.

However, as of version 3.2, _Preferences_ is called _Settings_ and this setting has no real GUI. Basically, one needs to add the following to the configuration field:

  "features": {
    "buildkit": false
  }

Considering that DOCKER_BUILDKIT=1 is now default as indicated above, it may be best to retitle this ticket to just:

Buildkit prevents custom networks using docker build --network

Or, as this tracker is specific to Buildkit, just:

Prevents custom networks using docker build --network

While we're at it, I do not use docker build and still experience this (using docker-compose and a docker-compose.yml file which specifies bridge as a network). So this could be even more generic, like:

Does not support bridge and more network types

It would also mitigate to improve the error message pointing to this ticket or at least clarifying what BuildKit is, or that BuildKit is optional.

Was this page helpful?
0 / 5 - 0 ratings