support docker context

[maxandersen]

Feature request description

podman context output != docker context output

meaning can't grab the needed values in a way that works on both docker or podman.

Have to do custom handling for podman.

would be great if not necessary.

Suggest potential solution

A clear and concise description of what you want to happen.

Have you considered any alternatives?

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

[vrothberg]

Thanks for reaching out, @maxandersen!

"This guide shows how contexts make it easy for a single Docker CLI to manage multiple Swarm clusters, multiple Kubernetes clusters, and multiple individual Docker nodes." (https://docs.docker.com/engine/context/working-with-contexts)

The context command isn't really something Podman can support IMO. Same for swarm etc. Currently podman context is an alias for podman system connection and I think that's not ideal. It somehow gives the impression to be same as docker context but really isn't. I would very much prefer when podman context errored out with an explanation.

@containers/podman-maintainers WDYT?

[rhatdan]

@maxandersen what output do you expect?

If we new actually the command tools were using, we could fix this. If this is just a command line use, then I agree with @vrothberg hat perhaps we should fail. But if podman context inspect foobar and podman context list are actively used by third party tools,we could make them better.

[Luap99]

My comment from the PR is still valid (#15072 (review)).
It makes no sense to alias connection as docker users need docker compatible output.

While we do not support swarm or connections to k8s clusters directly we can still output in the correct format. But I guess the important part here is how this is going to be used by such tools? If this only about context list, sure sounds easy enough to translate. But things like create or export/import does not sounds like something I would like to implement.

[vrothberg]

I prefer context throwing an error. Podman cannot provide the same kind of behavior or data which may lead to subtle bugs in automation migrating over. Now at the same time, for some it may just be good enough and allow for a seamless migration. It's a tough call especially since context already aliases.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[maxandersen]

Sorry for missing the updates here.

Docker context is supposed to be what testcontainers will use to adapt it to what setup there is available.

I.e. docker context provide info on which configured docker setups are available. I.e. Podman could be one of possible many docker contexts.

As is now docker context when podman is aliased is very different. Not showing the same thing.

[rhatdan]

What do you expect the output to look like? What specific command would you like implemented?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@maxandersen Could you answer the question?

[maxandersen]

@rhatdan sorry. was on pto.

I would expect docker contextor something be able to return same content as what docker context returns :)

i.e.:

/Applications/Docker.app/Contents/Resources/bin/docker context list
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT                                  KUBERNETES ENDPOINT   ORCHESTRATOR
default *           moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux       moby                                                          unix:///Users/manderse/.docker/run/docker.sock

vs

Name                         URI                                                         Identity                                     Default
podman-machine-default       ssh://core@localhost:49844/run/user/501/podman/podman.sock  /Users/manderse/.ssh/podman-machine-default  true
podman-machine-default-root  ssh://root@localhost:49844/run/podman/podman.sock           /Users/manderse/.ssh/podman-machine-default  false

I can't deduce which local docker endpoint to have my tools, testcontainer etc. connect to in the different contexts when it comes to podman.

maybe podman's contexts should show up as a context in straight up docker ?

[rhatdan]

Is this for machine reading or human consumption?

[rhatdan]

Do you want the output like:

NAME                               TYPE        DESCRIPTION        DOCKER ENDPOINT                                  KUBERNETES ENDPOINT   ORCHESTRATOR
podman-machine-default *           podman                         ssh://core@localhost:49844/run/user/501/podman/podman.sock 
podman-machine-default-root        podman                         ssh://root@localhost:49844/run/podman/podman.soc

[nealey]

I just arrived here after becoming confused about what podman context actually did.

In docker, the following are equivalent:

docker context create moo ssh://user@example.org
docker context use moo
docker ps

is equivalent to:

ssh user@example.org docker ps

This is apparently not what podman context does. I still don't understand what podman context is, but it's not this. I expected them to be the same, due to initial "welcome to podman" documents suggesting I could alias docker=podman.

I am just one user, but I would prefer that if podman contexts are a completely different thing (system connections?), podman remove the "compatibility" interface that led me to believe the same mechanism was supported.

[mheon]

Right now, they're hidden commands exclusively for compatibility with certain scripts that use the Docker CLI. Thus far, there has been little demand to do more, so we haven't gone beyond the bare minimum. It's also unlikely we'll ever get to 100% compatibility with docker context given its strong interactions with docker swarm (which we have no intention of supporting). Still, we could definitely support most typical usage by wiring it up to our existing system connection mechanism.

On that note: Why we may not have CLI compatibility here, we expose the same functionality via the podman system connection suite of commands.

[h0tw1r3]

tldr; I think this may be one of those suffering in silence situations. you don't hear much because it doesn't work, so users just keep using docker (with all of it's rootless shortcomings 😢 ) and move on.

Podman doesn't simulate the technical behavior of docker context, so the "compatibility" makes it harder for me to incorporate podman into my environment. We use the JSON output from docker context inspect to identify the current endpoint, which provides pipeline / end user flexibility without having to pass additional arguments, read docker/podman configuration files directly, etc.

Podman

$ podman context ls
Name        URI         Identity    Default
podman context create docker2 --description "test" --docker "host=ssh://docker0:2375"
$ podman context ls
Name        URI                 Identity    Default
docker2     ssh://docker0:2375              true
$ docker context inspect
[]
$ docker context use docker2
$ docker context inspect
[]

Docker

$ docker context ls
NAME        DESCRIPTION                               DOCKER ENDPOINT               ERROR
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
$ docker context create docker2 --description "test" --docker "host=ssh://docker0:2375"
docker2
Successfully created context "docker2"
$ docker context inspect
[
    {
        "Name": "default",
        "Metadata": {},
        "Endpoints": {
            "docker": {
                "Host": "unix:///var/run/docker.sock",
                "SkipTLSVerify": false
            }
        },
        "TLSMaterial": {},
        "Storage": {
            "MetadataPath": "\u003cIN MEMORY\u003e",
            "TLSPath": "\u003cIN MEMORY\u003e"
        }
    }
]
$ docker context use docker2 
docker2
Current context is now "docker2"
h0tw1r3@docker0:~$ docker context inspect
[
    {
        "Name": "docker2",
        "Metadata": {
            "Description": "test"
        },
        "Endpoints": {
            "docker": {
                "Host": "ssh://docker0:2375",
                "SkipTLSVerify": false
            }
        },
        "TLSMaterial": {},
        "Storage": {
            "MetadataPath": "/home/h0tw1r3/.docker/contexts/meta/39158c67a24d980ff94d86f6d39b8a3896f6a902c22035bda87b67568c385b26",
            "TLSPath": "/home/h0tw1r3/.docker/contexts/tls/39158c67a24d980ff94d86f6d39b8a3896f6a902c22035bda87b67568c385b26"
        }
    }
]

[h0tw1r3]

docker context given its strong interactions with docker swarm

I thought this deserved a separate comment. While this may be true, it's also a replacement for the deprecated DOCKER_HOST environment variable. Which is why in my previous comment, you see the default context is a unix socket, even though it's not explicitly configured. As the context ls output would suggest, if you set DOCKER_HOST, that' becomes the default. From what I understand, same functional behavior of podman and the CONTAINER_HOST env var... except with podman, it's not visible through podman system connections or podman context

[rhatdan]

@h0tw1r3 interested in openging a PR to improve the support of docker context?