'docker context ls' or 'docker context inspect' slow responses with remote servers

[aduzsardi]

• This is a bug report
• This is a feature request
• I searched existing issues before opening this one

Expected behavior

Return current used docker context faster

Actual behavior

while using a remote docker host context through a VPN or over the internet, the listing and inspecting of the contexts is very slow

$ time docker context ls
NAME                DESCRIPTION                               DOCKER ENDPOINT                 KUBERNETES ENDPOINT   ORCHESTRATOR
bb-dev *            BB Dev Environment                        ssh://deploy@192.168.213.214                         swarm
default             Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                           swarm

real	0m2.547s
user	0m0.020s
sys	0m0.015s

If using the default (local) docker context , everything seems to be ok

$ docker context use default
Current context is now "default"
$ time docker context ls
NAME                DESCRIPTION                               DOCKER ENDPOINT                 KUBERNETES ENDPOINT   ORCHESTRATOR
bb-dev              BB Dev Environment                        ssh://deploy@192.168.213.214                         swarm
default *           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                           swarm

real	0m0.026s
user	0m0.024s
sys	0m0.010s

Steps to reproduce the behavior

Output of docker version:

lient: Docker Engine - Community
 Version:           19.03.11
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        42e35e61f3
 Built:             Mon Jun  1 09:12:34 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.11
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       42e35e61f3
  Built:            Mon Jun  1 09:11:07 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker info:

Client:
 Debug Mode: false

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 37
 Server Version: 19.03.11
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-37-generic
 Operating System: Ubuntu 20.04 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 15.56GiB
 Name: aduzsardi-nix
 ID: V6CN:HNWD:PENV:MYG3:2ORG:SYRC:P6LD:HJNM:P3GS:OZ3K:7VTR:6QWV
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  gitlab.bigbrother.lokaal:5005
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.)

I'm connecting to remote docker or docker swarm hosts trough VPNs from home to office network

I want to set my bash prompt to show the docker context currently in use so i know where i am at all times , but the time it takes to return my prompt every time i press the return key on the keyboard takes about ~3s of so it's not usable

The script i was using

$ cat /etc/profile.d/docker_prompt.sh

#!/bin/bash

_get_docker_ctx()
{
    # Get current context
    if type docker &>/dev/null; then
        CONTEXT=$(docker context ls | grep -F '*' | awk '{ print $1}')
    fi
}

__docker_ps1()
{
    _get_docker_ctx
    if [ -n "$CONTEXT" ]; then
        echo "[dctx: ${CONTEXT}] - "
    fi
}

__colored_docker_ps1()
{
    _get_docker_ctx
    if [ -n "$CONTEXT" ]; then
        echo -e "\e[1m\e[37m[\e[92mdctx: \e[36m${CONTEXT}\e[37m] - \e[0m"
    fi

}

And PS1 prompt

export PS1='$(__colored_docker_ps1)\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$'

Proposal

It would be nice if we could read the currently used context from a file or config , so every time you run docker context use ... the config would be updated with the "current-context: something" like kubectl does

[thaJeztah]

This use-case will be addressed by #2500 (which will be in the upcoming 20.x release of docker)

that said; performance of docker context ls is on our radar (given that it's a local action, it shouldn't have to depend on the connection-speed with the currently selected context).

[thaJeztah]

Let me move this ticket to the docker/cli issue tracker for visibility.

[aduzsardi]

Currently if you select a context and the connection with the docker host is down , the commands just hang , will this also be addressed ?
Thank you

[thaJeztah]

Currently if you select a context and the connection with the docker host is down , the commands just hang , will this also be addressed ?

@aduzsardi docker 19.03.12 was released with some improvements (from #2424 and #2515). Not sure from the top of my head if those resolve the full issue, but you could give 19.03.12 a spin to see if it performs better

[aduzsardi]

thank you for the notice , updated docker on my system but i don't see any changes for my use cases

aduzsardi@aduzsardi-nix: ~
└─$ ▶ time __docker_ps1
[dctx: bb-dev]

real	0m3.928s
user	0m0.024s
sys	0m0.015s

keeping in mind that i go through a few routers and a VPN from one country to another to reach my remote docker host
also if i disconnect the VPN and trying to switch back the docker context to the default , it hangs forever until finally changes it back to default

[brynmathias]

I am seeing similar on mac os x.

~ via 🐍 3.8.0 took 14s
➜ time docker context ls
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT                ORCHESTRATOR
default *           moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock   https://localhost:6443 (default)   swarm
docker context ls  0.10s user 0.03s system 2% cpu 5.073 total

~ via 🐍 3.8.0 took 5s
➜ time docker context ls
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT                ORCHESTRATOR
default *           moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock   https://localhost:6443 (default)   swarm
docker context ls  0.09s user 0.04s system 2% cpu 4.616 total

I only have the context that was setup by installing docker desktop
However I noticed the performance degradation when setting up a windows docker context in virtual box

[smhc]

Looks related to both #1955 and #3096
Both of which report the inability to run local commands when using a context that is either invalid or slow performing.

[guillenotfound]

Any updates on this?

[aduzsardi]

i don't see much activity on fixing issues on docker repositories, so probably nothing new about this one either
you are better of not using docker contexts

[tbenthompson]

This is still a problem. It'd be nice to include the docker context in my prompt like spaceship does by default but it makes my zsh prompt super slow so I have to turn it off.

[a-abella]

@tbenthompson If you're still looking, the current non-default context is listed in ~/.docker/config.json under .currentContext. I added current context to my PS1 prompt by sourcing it from this file.

$ time jq -r .currentContext ~/.docker/config.json
swarm-qa

real    0m0.003s
user    0m0.003s
sys     0m0.000s

When the currentContext = default, this item is absent from config.json

I suppose there's no guarantees that this is a stable way to get this information, but it will have to do.