Allow using podman instead of docker

[JacekPliszka]

Red Hat based systems prefer podman instead of docker.

Could you add configuration option so podman can be used locally in place of docker?

Most commands are identical.

[bwateratmsft]

This capability would be added for several commands via #1596. I don't know if Dockerode supports it, I've not tried; but if it does then that would cover most of the scenarios.

[bwateratmsft]

Seems like Dockerode (thus the explorer view and a ton of commands) cannot work with Podman today, but, Podman seems to have an HTTP API in the works that would make it at least partially compatible: https://podman.io/blogs/2020/01/17/podman-new-api.html

Without Dockerode, probably the only thing that could still be done is the docker build (well, podman build) command and a few other basics; changing this to Podman is possible today because of #1596.

We'll leave this open for now, but until the Podman HTTP API exists, the extension would not be very useful when used with Podman.

[Nuc1eoN]

Podman v2.0 has been released with a new HTTP API, so this is not a blocker anymore.

[bwateratmsft]

Thanks @Nuc1eoN! We'll take a look and see what does and doesn't work.

[bwateratmsft]

Here's what I've come up with so far.

What works*

• Presumably most CLI commands would work, to whatever extent the Podman CLI has parity, but I haven't looked that far into it
• Containers list along with at least most related commands
• Images list along with at least most related commands
• Prune actions

*Had to connect with Remote - SSH since there's no clear way to reach Podman remotely, more on that below

What does not work

• Debugging could only possibly work for Linux users as it is heavily dependent on the daemon being local
• Quite a few properties from the Docker Engine API are missing in containers, images, and networks listing. For example, the Created/CreatedAt values are inconsistent; no container status; no network ID.
• Creating networks
• Anything pertaining to volumes (404)
• Anything pertaining to contexts
• Containers list won't show stopped containers
• The API service has to be manually started each reboot which is annoying (though it could definitely be configured to start automatically)
  • It is also per-user, consequently it cannot use constant socket paths
• docker-modem would need to be changed to support Podman over ssh, since it uses docker system dial-stdio which would not work
• No current documentation on setting up an SSH connection with the remote client (all that I could find pertains to the legacy varlink implementation)
• There is either no API documentation or I cannot find it. The Docker engine API documentation is not a good substitute as there are too many inconsistencies. At a minimum, these inconsistencies would need to be documented.

@Nuc1eoN, @JacekPliszka, anyone else -- what are your primary use cases? How serious are these limitations for your workflows?

[JacekPliszka]

Sorry, my projects on the topic got cancelled so I do not have use case at the moment. :(
One project stayed with VMs, the other is migrating from VMs to ADF + Databricks.

It is python ETL based on pandas - when dataset arrives the VM with proper memory/CPU is started, data is processed and VM deleted.

[9034725985]

I get this message: Failed to connect. Is Docker installed?

$ podman --version
podman version 2.0.4

Visual Studio Code on Fedora 32

[PavelSosin-320]

Podman and Docker are 2 different products with 2 different purposes!
Docker is a server that builds and manages Docker images and runs them in the client-server scenario.
Podman is the toolchain for the development of Serverless Cloud applications deployed to the Kubernetes cluster.
Podman allows quick-start creation of main Kubernetes artifact - Pod containing single Docker container then
the generation of Pod definition YAML using podman KUBE generate,
then enrichment of its definition,
then testing of Pod using podman KUBE play
then deployment the definition to Kubernetes cluster like in Podman vs Docker-compose
Podman doesn't need a server because the target architecture is serverless. It can run locally too or Inside container. Podman does compatible with Docker but it is more important that podman is compatible with Kubernetes.
in other words dev-container and dev-pod are 2 different things.

[omajid]

I am trying to use vscode on Fedora 33. And I can build containers using the podman-provided docker command, not much else is working.

what are your primary use cases? How serious are these limitations for your workflows?

My main reason for installing vscode at all was to debug a .NET Core application running inside a container. I can do most other actions (building, testing, releasing) using the CLI, but interactive debugging is the one place where I have no workaround.

[JacekPliszka]

Podman and Docker are 2 different products with 2 different purposes!

Sorry but for the majority of users purpose is exactly the same - something that runs your containers.

[tmds]

@bwateratmsft can you look into making the plugin pick up and use podman?

What does not work

podman docker compatibility is continuously being improved. This plugin shouldn't work around discrepancies. Things that don't work can be reported against podman.

*Had to connect with Remote - SSH since there's no clear way to reach Podman remotely, more on that below

Technically it should be possible to port forward the unix socket over ssh, and that should 'just work'.

The API service has to be manually started each reboot which is annoying (though it could definitely be configured to start automatically)
It is also per-user, consequently it cannot use constant socket paths

You can check the path at /run/user/<uid>/podman/podman.sock and use it. If it doesn't exist, suggest the user to run systemctl --user enable --now podman.socket.

[m3nowak]

If you landed here and want to use Docker extension with Podman on linux:

1. systemctl --user enable --now podman.socket
2. in your settings set 'docker.dockerodeOptions' (Docker: Dockerode Options) as {"socketPath":"/run/user/<your uid>/podman/podman.sock" }

Keep in mind, that not every feature will work as expected, some may be broken.

[PavelSosin-320]

Thanks! I would like to eliminate Docker as Kubernetes and OpenShift did it. Docker is high taxation solution where multiple layers have to be installed and maintained only to run Dev-container using runc - the real OCI container runtime used in Docker.
Swarm???
Dockerd ???
Containerd ???
Dev-container is not designed to be serverless, scalable, fail-over, rolled-upgradable, etc. to utilize them.
The docker build product requires a repository.
Podman produces a single meta-file pod-resource .yaml which can be run by Podman or Kubernetes on the same computer, remote computer, or any Kubernetes cluster.
Extension of Workspace Pod by side-car toolsets maintained by tool developers takes 5 seconds instead of long minutes of the dev-container build.
Everything what I already tested I tested on Ubuntu 20.04 WS: distro, not on Linux.
Ubuntu Kube's Micro k8s is already cri-o based. It doesn't use Docker as Container runtime.

[PavelSosin-320]

@tmds @bwateratmsft
When I think "Podman" I think "neither server nor client is needed". In other words, after throwing the Docker into the trash bin I would like to throw Dockerod into the same trash bin. Podman is CLI. I can execute any CLI command locally with no "middleware" or remotely using SSH as a "middleware". To run the Podman commands in WSL I can use wsl -e prefix.
To make Podman command programmatic processable or easy-renderable I can use the --format option.
The object model of Podman commands is provided in the API spec but it doesn't require me to use socket.

[tmds]

@PavelSosin-320 minimizing the effort relies on using the docker compatible interfaces exposed by podman, which includes the podman cli, and also the API service exposed through the podman socket.

@bwateratmsft based on what was said, supporting podman boils down to:

1. Detect if the system has podman, for example by running podman version.
2. Use the socket at /run/user/<uid>/podman/podman.sock when it exists, or suggest the user to run systemctl --user enable --now podman.socket if it doesn't.

[PavelSosin-320]

It doesn't take into account the docker / podman maintanence. But it is the main purpose of the Podman project supported by "Maintanence champion" company. Podman, Docker, Kubernetes share the same set of standarts: OCI, CNI, Rest API.
Rest API libraries are provided by the same centralized way. For example: Kubernetes Rest API client Javascript. and as famous Fabric8 Kubernetes REST API client Java.
The development efforts are already minimized in the Cloud world.

[tmds]

@bwateratmsft do the suggested steps in #1590 (comment) make sense? Is this something that can be included in one of your next sprints?

Once vscode-docker uses the podman socket, any further issues can probably be reported against podman itself (https://github.com/containers/podman).

[PavelSosin-320]

@JacekPliszka Docker is not a must To build, copy and run OCI container images. You can choose:
Runc, CRun, Dockerd, machined, Cri-O, Kata. Buildah. The exact meaning of OCI includes: there are executives that build and Run OCI images. This executable files are run as as programs in all environments. The Client, Server and REST API are optional.
My example in the Fedora WSL distro:
buildah from node
node-working-container
buildah images
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/library/node latest 1db64f55f800 5 days ago 964 MB
k8s.gcr.io/pause 3.2 80d28bedfe5d 11 months ago 688 KB
[root@MSI-wsl ~]# buildah containers
CONTAINER ID BUILDER IMAGE ID IMAGE NAME CONTAINER NAME
ec1dc549b831 * 1db64f55f800 docker.io/library/node:latest node-working-container
buildah run ec1dc549b831 node --version
v15.6.0
There is no reason to mistify Docker - this is only yet another server.
Good news: I'm able to run Podman & Buildah on the different WSL Distros including non-Debian The cross-distro solution for Arkane-genie exists to fulfill Podman's dependency from systemd.

[ucheNkadiCode]

Hello, thanks for your interest in this and thanks in particular to @menmikimen for investigating ways to make this work. We’ve found that that approach works well. You can also use docker.host == unix:///run/user/<your uid>/podman/podman.sock instead of using docker.dockerodeOptions. To recap, here’s the steps:

1. Run command: systemctl --user enable --now podman.socket
2. Set docker.host to: unix:///run/user/1000/podman/podman.sock (this will persist once it is set)

We expect most features will work. Several commands will use docker by default but can be configured to use podman instead using Command Customization. Other than that, most explorer features should work fine. You can also set the alias docker = "podman" in linux as well.

As we don’t have the resources to test Podman we cannot claim support, but we’re willing to put forth a reasonable effort to remove arbitrary roadblocks to it working. We feel the above steps are simple enough that they can suffice for now. If there are specific issues, please file them here or with Podman as appropriate.

[carwyn]

I've tried the above @ucheNkadiCode and tried opening a file from within the container via vscode but got this:

cannot open docker://<snip>/etc/nginx/nginx.conf?fileType%3Dfile%26containerOS%3Dlinux%26path%3D%252Fetc%252Fnginx%252Fnginx.conf.
Detail: Unable to read file 'docker://<snip>/etc/nginx/nginx.conf?fileType=file&containerOS=linux&path=%2Fetc%2Fnginx%2Fnginx.conf' (Error: (HTTP code 501) unexpected - not implemented )

I'm guessing this is a podman side feature that's not implemented yet or has anyone got the basic file open to work? I'll take this over to the podman issues if I've understood this correctly.

[bwateratmsft]

@carwyn Yeah, I think it's something not yet implemented in Podman. We use the https://docs.docker.com/engine/api/v1.41/#operation/ContainerArchive endpoint, I wouldn't be surprised if that's not implemented yet.

[richli]

It looks like it should support it?

https://docs.podman.io/en/latest/_static/api.html#operation/getArchive

[bwateratmsft]

It's possible that's a relatively new addition and the version @carwyn has doesn't have it? Not sure.

[carwyn]

These seem relevant to this, it looks like this "Docker API /containers/{id}/archive" will be implemented in Podman 3?

containers/podman#6050
containers/podman#8126

[PavelSosin-320]

@carwyn win I'm currently testing Podman 3.0 RC1 on Fedora33 WSL image. If something specific needs testing I can run it on my distro.

[bwateratmsft]

I think that the changes made in #2984 also should help with using Podman.