docker / buildx

Docker CLI plugin for extended build capabilities with BuildKit
Apache License 2.0
3.53k stars 475 forks source link

docker buildx create error: "unknown flag: --node" #1127

Open bennythejudge opened 2 years ago

bennythejudge commented 2 years ago

Hi, apologies in advance, because it feels like my issue is not really a buildx issue per se but an environment issue and yet I don't know where else to ask for help.

I have a Jenkins worker running in AWS on an EC2 with Amazon Linux2 where I have installed docker 20.10.7 and buildx 0.8.2. A simple Jenkins job with a shell step can invoke the command docker buildx create --node multiarch --use, while another job, executing a Pipeline, gets the error in title:

First case:

+ docker buildx create --node multiarch --use
quizzical_payne

Pipeline with error:

00:24:08  docker buildx create --node multiarch --use
00:24:09  unknown flag: --node
00:24:09  See 'docker --help'.
00:24:09  
00:24:09  Usage:  docker [OPTIONS] COMMAND
00:24:09  
00:24:09  A self-sufficient runtime for containers
00:24:09  
00:24:09  Options:
00:24:09        --config string      Location of client config files (default
00:24:09                             "~/.docker")
00:24:09    -c, --context string     Name of the context to use to connect to the
00:24:09                             daemon (overrides DOCKER_HOST env var and
00:24:09                             default context set with "docker context use")
00:24:09    -D, --debug              Enable debug mode
.....

They are running on the same EC2, as the same user (ec2-user), in different directories but with buildx present in both cases under $HOME/.docker/cli-plugins/docker-buildx.

In the second case, it looks like docker is not "detecting" the presence of the buildx binary at all. I have compared the output of env in both cases and I couldn't see any noticeable difference (with the exception perhaps of SHLVL which is 2 in the working case, and 3 in the non-working one.

What am I doing wrong? What have I disregarded? Has anyone got any idea? Thanks

+ docker buildx version
github.com/docker/buildx v0.8.2 6224def4dd2c3d347eee19db595348c50d7cb491
+ docker version
Client:
 Version:           20.10.7
 API version:       1.41
 Go version:        go1.15.14
 Git commit:        f0df350
 Built:             Wed Nov 17 03:05:36 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.7
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.15.14
  Git commit:       b0f5bc3
  Built:            Wed Nov 17 03:06:14 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0
  GitCommit:        84113eef6fc27af1b01b3181f31bbaf708715301
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
crazy-max commented 2 years ago

while another job, executing a Pipeline, gets the error in title:

Can you post your Jenkinsfile? I would say your "other job" runs inside a container so buildx is not available in it but the first "shell step" runs on the host?

Also be careful with docker buildx create --node multiarch --use because it will create as many builders you run this workflow. Check on your host docker buildx ls, I guess you have a bunch of builders in there.

If you still want to create a builder for each run of this workflow, you might need to remove it in a post section like:

    stages {
        stage('Create builder') {
            steps {
                sh "docker buildx create --name builder-${env.BUILD_ID} --use"
            }
        }
    }
    post { 
        always { 
            sh "docker buildx rm builder-${env.BUILD_ID} --keep-state" // remove mybuilder but keep BuildKit state
        }
    }

Also using --node might not be what you want here but --name to specify the builder name. I specify env.BUILD_ID so it creates a dedicated builder linked to the current invocation in your pipeline and doesn't overlap with another one. --keep-state flag keeps BuildKit state volume on your host so next run of this build will leverage a bit of caching.

But if a single builder is ok, then just create the builder on your host and remove buildx create/rm steps in your workflow.