Make a CLI-only DockerApiClient

[bwateratmsft]

We need an implementation of DockerApiClient that uses CLI only. This will work better with a wider range of scenarios than the CLI + HTTP daemon through Dockerode + gRPC daemon. Plus it mostly removes the need to look up the Docker context during activation...

Potentially resolves:

• Dockerode features don't work with TCP daemon + certificates #2058
• Enable use of gpg-agent for Explorer view population #3295, "Failed to connect. Is Docker running?" in all docker views using a remote docker context #3590, Failed to connect. Is docker running? #3605
• Support rootless, daemonless podman inside WSL #3241, Allow using podman instead of docker #1590, Add support for detecting podman. #3306, On a Mac, the extension keeps timing out when using Podman instead of Docker #3367, Need support for nerdctl #3411
• No running container shows in container view after deploying image to ACI #2941, extension cannot list aci containers on linux #2933, No running container shows in container view after deploying image to ACI #3578
• [Codespaces] Fail to create a new ACI context in codespace environment #2391
• Don't communicate with docker until necessary #3475
• Remove notification to install Docker Desktop #3596
• Maybe The new created context start to move back and forth shortly in context view #2442

Related to #2977, #3281

[bwateratmsft]

I've noticed that com.docker.cli tends to be drastically faster than docker, though we would only want it to be used for background tasks (i.e. those where the user doesn't see the command line).

[bwateratmsft]

Work is ongoing for this, it will need to be moved to the 1.21.0 milestone.

[ucheNkadiCode]

We are continuing to work on a path forward for supporting other Container runtimes. This will be moved to the 1.22 milestone.

[bwateratmsft]

I know a lot of folks are interested so I wanted to give an update. Work on this is proceeding in earnest right now (as in, we're past most of the planning and really writing code!). We have rather ambitious plans so it will take some time.

[benatshippabo]

I know a lot of folks are interested so I wanted to give an update. Work on this is proceeding in earnest right now (as in, we're past most of the planning and really writing code!). We have rather ambitious plans so it will take some time.

Thanks for the update @bwateratmsft! I'm so glad this is underway

[elasticdotventures]

@bwateratmsft

fwiw, podman usage is exploding right now, it's hot -- since the Docker licensing switch, seems a lot of peep's are like "welp, I ought to at least try not using docker" .. and subsequently all the "not-docker" projects have accelerated (because suddenly everybody is aware that docker might lower that $10m to $5m, or even $1m next week) ... so the alternatives are gaining significant maturity and many bugfixes in the past few months. I must report in many respects podman rootless is on par with docker (which definitely wasn't true when this issue was opened). I was quite surprised!

Do want to start a branch for this? would you accept contributions/ideas?
Maybe some Q&A rubber-duck'in & brainstorming to fast-track -- I think sometimes explaining the detail in discussion is helpful.
I did a bit of pondering, research and .. wow! yeah, what a clusterf*ck this is. Still wrapping my head around the situation & educating myself on all the choices. 😲 .. hopefully the comments below are helpful in the brainstorming & planning.

So in #3531 - you wrote: "The plans are not final, but in rough terms we're envisioning separate extensions being able to register alternative container runtime providers with the Docker extension."

my response to your idea: 😄 very clever indeed! .. but yeah, what you are proposing is A LOT more work, feels like this could snowball into a major version change and might have some backward compatibility issues.

my concerns/thoughts:

• as I said in Support rootless, daemonless podman inside WSL #3241 - plugin fatigue is real, the vscode extensions marketplace is full of "bit-rot" from unmaintained plugins, and it's troublesome to imagine extensions that are incept'ing eachother, risk of unreversable changes (hope your workspace settings aren't syncing across multiple machines, blabla.) that would be an initial concern. keeping things in sync, too many versions & system specific configurations. .. and vscode-docker plugin, it's already popular, very widely used, I think probably 99% of devs ought to be using oci containers .. - so can multiple extensions be installed and the first one to run, or do they all run? would uninstalling xyz leave the original abc extension configuration overwritten? or are you envisioning some type of drop down/checkbox of registered providers / per functional group (will it be single provider for everything -- or probably it should iterate through all providers for a group/function, i.e. containers, images, registries, networks, volumes, contexts?) maybe the runtime providers would be found in settings.json and be set as an [] array? .. and the extensions would call a method to add/remove themselves when they install/uninstall from a workspace? .. or would all the runtime providers still come in the vscode-docker package but just have separate source files with the similar interface implementation(s)?

• the main issue with the topic for Make a CLI-only DockerApiClient #3263 "Make a CLI-only DockerApiClient" there would/could be multiple CLI's each handling a different part of what docker monolithic cli+socket presently does. So yeah, this might get hairy rather quickly, not all tools provide all functionality. I can see your point it's not a 1:1 mapping for functionality & the socket certainly isn't universal - cli is. the choices I found -- buildkit, buildah, runc, podman, img, containerd & nerdctl, kaniko, pouch, ocibuilder so you are thinking one extension per cli? .. all options seems ugly. glad you're thinking comprehensive! .. I was only thinking podman.
  ☝️ the list came from: https://dev.to/thakkaryash94/how-many-ways-to-build-a-container-image-4g3p

• when you say 'cli' do you mean literally a shellExecute? because the socket/api seems surficially are usually a much cleaner/preferred interface. CLI's aren't frequently known for their regression(s) across version(s) .. cli's break all the time, they're fugly in that respect. docker certainly isn't/wasn't an exception in that regard, that's why the socket-api is generally preferred/recommended (again, this is my fwiw). podman v2 and beyond have libpod have this, dockerode uses this, also cli's are a pita when you need support both windows & linux right? .. at a minimum, should have a debug/logging diagnostic(s) checkbox with this level of complexity. but you're thinking cli because that's the minimum interface they all should have?

• Also, and this is sort of stupid, but also I can recall at least one situation where my own WSL machine was setup long ago - the socket & containered was in a separate host/vm/container. so I think the cli will probably access the socket (technically I don't think podman does, it's strictly CLI), but does the switch to cli require the containerd to be in the same os context as the editor? (i'm not even sure on the answer) .. so there wouldn't be an explicit requirement that it MUST be a cli, it could still be a socket? or ssh tunnel? .. i.e. it's not always CLI only, but it might be cli only (provided it implements the same methods & responses when called)

• re: extension(s) add maximum level of configurability, vs. balancing new user complexity out of the box - 'do what I want' behavior -- cuz, we'd want vscode-docker to get 5 star ratings on the marketplace right?? mmmh, okay -- so maybe some method/button for auto-detect my installed tools(s)/suggest extensions button so it works out of the box and doesn't require dev's to guess / bang their head too hard to get this working. Certainly the error message "Is docker installed" isn't the right error anymore, could be at least a dozen other reasons. 😁

I think docker is one of those 'dev/ops' chores that most pure-dev's don't really understand all that well (and this level of fragmentation & too many choices DEFINITELY doesn't help). I appreciate that you're tackling this holistically.

Hope this dialog is helpful.

[bwateratmsft]

Thanks for your thoughts, we appreciate the input! I'll try to address some of your questions here:

Do want to start a branch for this? would you accept contributions/ideas?

The key work on the container runtimes library is still in a private repository but we should be opening it up soon; certainly some time before release. I'll update on this issue once it is opened. We love contributions!

so can multiple extensions be installed and the first one to run, or do they all run

We think that, fundamentally, all of the runtimes deal with the same objects and offer the same operations on those objects. There are exceptions of course (e.g. Podman doesn't have contexts, as far as I'm aware), so we'll need a reasonable user experience in those cases, but I think that's manageable. Consequently, we can create a common interface to abstract away the specific runtime.

The architecture we're envisioning is that the Docker extension would permit other extensions to register a container runtime provider conforming to that common interface (and it would also register a Docker provider with itself). Thus, the Docker extension would always be present; marked as a dependency of the other extensions. In addition, the Docker extension would need some kind of experience for choosing which provider should be active; I'm thinking of doing something like what Python has for selecting the interpreter path--that is, an item in the status bar, and when you click it, it allows you to select which provider to use. There also needs to be graceful handling for when these extensions are uninstalled without the setting being updated. Separately from all this work in the Docker extension, we (Microsoft) would probably work on these "sidecar" extension(s) for Podman and Nerdctl.

when you say 'cli' do you mean literally a shellExecute?

Yes, mostly. There are some operations that we perform behind-the-scenes in a non-visible shell. There are also others that we very deliberately execute in the VSCode terminal as a task, so that users can see both the command itself and the output (for example, building images). Naturally, we'll need to make both of these work regardless of the runtime in use.

As you noted, there are significant advantages to using the HTTP API, instead of the CLI. It's more compatible and much faster. However, we've found a common class of issues (many of them linked in the original comment) that basically boil down to "I have the CLI working, why doesn't the explorer view work?" We are taking a risk using the CLI, but we're hoping that we can avoid the worst of it by continuing to be agile with releases of the extensions. Based on data we've seen, users update VSCode extensions very quickly--usually immediately upon startup, often before the extension activates. Since auto-updating is the default, this isn't terribly surprising. Our hope is that if we encounter a break in the CLI, we can get a fix out to users very quickly.

For what it's worth, the Remote - Containers extension went through similar challenges and also ended up going CLI-only.

[wenbingzhang]

This is how I set up support for podman

settings.json

    "docker.host": "tcp://192.168.64.3:2979",
    "docker.dockerPath": "podman",

podman-remote

# user=root
/usr/bin/podman system service --time=0 tcp:0.0.0.0:2979

[bwateratmsft]

This has now been released in Docker extension version 1.23.0.

[gliptak]

1.23.0 still shows

with

    "docker.dockerPath": "/usr/bin/podman",

was above to be corrected in this update?

Name: Docker
Id: ms-azuretools.vscode-docker
Description: Makes it easy to create, manage, and debug containerized applications.
Version: 1.23.0
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker

[bwateratmsft]

Podman isn't intended to work yet, still working on that in #3241 / #1590. Parts of it may work with that path setting but we haven't tested it. I'm not familiar with that warning, though, it might actually be coming from the Remote - Containers extension.

[gliptak]

#1590