Skip to content

[BUG] Impossible to build on remote since 2.38.2 #13134

Description

@sprietNathanael

Description

We use docker compose to build images on remote servers.
It worked fine until docker-compose-plugin 2.38.2.
Since then, the docker images are now built on local machine.

Steps To Reproduce

What works

  1. On Ubuntu 25.04, with the package docker-compose-plugin=2.38.1-1~ubuntu.25.04~plucky
  2. execute docker -H ssh://<remoteServer> compose build
  3. The image is present in the remote server and not in the local machine

What does not work

  1. sudo apt remove docker-compose-plugin
  2. sudo apt install docker-compose-plugin=2.38.2-1~ubuntu.25.04~plucky
  3. execute docker -H ssh://<remoteServer> compose build
  4. The image is now present in locale machine and not in the remote server

Compose Version

docker compose version
Docker Compose version v2.38.2



docker-compose version
command not found: docker-compose

Docker Environment

Client: Docker Engine - Community
 Version:    28.3.3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.26.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.38.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 28.3.3
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.14.0-27-generic
 Operating System: Ubuntu 25.04
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 31.02GiB
 Name: chewbacca2
 ID: c5f109fc-1e15-47e5-ac6a-324f935fcd3e
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: fals

Anything else?

I tried with any version >2.38.1, and it never worked

Activity

  1. idsulik commented on Aug 9, 2025

    @idsulik
    Collaborator

    The issue is related to this PR #13007
    We used to always pass DOCKER_HOST env to the bake command, now we specify the env value conditionally

    	if endpoint.Host != actualHost {
    		// We are running with `--host` or `DOCKER_HOST` which overrides selected context
    		env["DOCKER_HOST"] = actualHost
    	}
    

    In my case, the condition is false with/without the -H argument.
    Either we should fix the condition, OR always pass DOCKER_HOST to the bake command.

    @ndeloof could you please check it? I don't know why you assume this We are running with --hostorDOCKER_HOST which overrides selected context in case of the endpoint.Host is not equal to the actualHost

  2. D4VID0x2 commented on Aug 10, 2025

    @D4VID0x2

    Same problem here. Workaround by passing the DOCKER_HOST env var to the docker compose build command instead of the --host argument

  3. ndeloof commented on Aug 26, 2025

    @ndeloof
    Contributor

    @idsulik to prevent #13015 we need to detect the current endpoint address is not the one set by context. dockerCli.ContextStore().GetMetadata(s.dockerCli.CurrentContext()) is expected to report the current context definition, which I would expect is not be impacted by --host .. but is actually 🥹 (I wonder this is a recent change in docker/cli ?)

    I'm investigating for a fix

  4. self-assigned this
    on Aug 26, 2025
  5. thaJeztah commented on Sep 8, 2025

    @thaJeztah
    Member

    is expected to report the current context definition, which I would expect is not be impacted by --host .. but is actually 🥹 (I wonder this is a recent change in docker/cli ?)

    I think that was always the case and by design; when using either DOCKER_HOST or -H / --host, the context is disabled, and the options as specified on the command-line are used (including TLS options, which are otherwise set by the context); here's with a docker 23.0 CLI, which also showed that behavior, so that's not a recent change;

    docker context ls
    NAME           DESCRIPTION                               DOCKER ENDPOINT               ERROR
    default        Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
    my-context *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
    
    docker -H unix:///var/run/docker.sock context ls
    NAME         DESCRIPTION                               DOCKER ENDPOINT               ERROR
    default *    Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
    my-context   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock

    What potentially did change, is that buildx now imports all the top-level options from the CLI, so when running standalone (?) also uses the same flags and env-vars; docker/buildx#3087

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions