Vscode-remote-release: trying to use podman results in "Docker version 17.06.1 or later required"

Created on 25 May 2020  路  14Comments  路  Source: microsoft/vscode-remote-release


  • VSCode Version: 1.45.1
  • Local OS Version: Fedora 31
  • Remote OS Version: Fedora 31
  • Remote Extension/Connection Type: Container

Steps to Reproduce:

  1. have podman instead of docker
  2. Install addon
  3. attach to running container
  4. "Docker version 17.06.1 or later required"
$ docker version
Version:            1.9.2
RemoteAPI Version:  1
Go Version:         go1.13.10
OS/Arch:            linux/amd64


Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes

bug containers verified

Most helpful comment

I see, we can investigate improving that check.

Remote-Containers will have a setting to specify the "Docker" CLI (which can then be podman) with VS Code 1.46 (currently available with VS Code Insiders).

All 14 comments

We relax the version check only if the executable (after following all symlinks) is called podman. Does that explain the behavior? Did you rename the executable yourself or was it installed this way?

I installed "podman-docker" which is a shell script wrapper around docker. I removed it and made it a symlink - now it works.

I see, we can investigate improving that check.

Remote-Containers will have a setting to specify the "Docker" CLI (which can then be podman) with VS Code 1.46 (currently available with VS Code Insiders).

Some additional info (Fedora 32, same issue with podman-docker installed):

[user@localhost ~]$ whereis docker
docker: /usr/bin/docker /usr/share/man/man1/docker.1.gz

Contents of /usr/bin/docker (added by podman-docker package):

#!/usr/bin/sh
[ -f /etc/containers/nodocker ] || \
echo "Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg." >&2
exec /usr/bin/podman "$@"

On my system (Fedora Silverblue), this area of the filesystem is intentionally immutable, so manual edits to this area aren't (easily) possible or recommended. I did a touch /etc/containers/nodocker as is suggested to suppress the additional output from the wrapper script, but it may be useful to know that the default installation prints that echo line to stderr.

It may be useful to use the docker -v or docker --version commands to differentiate between "podman" and "Docker"; both clearly state their name followed by the word version and a corresponding version string.

Running docker version does not seem to have consistency between the two; Docker displays its full name as "Docker Edition - %distType%" where podman does not report its name at all with the versions I tested (see below).

Examples

Docker Community Edition on Ubuntu 20.04

user@host:~$ docker -v
Docker version 19.03.6, build 369ce74a3c
user@host:~$ docker version
Client: Docker Engine - Community
 Version:           19.03.6
 API version:       1.40
 Go version:        go1.12.16
 Git commit:        369ce74a3c
 Built:             Thu Feb 13 01:27:49 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.6
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.16
  Git commit:       369ce74a3c
  Built:            Thu Feb 13 01:26:23 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

Podman on Fedora 32 Silverblue with podman-docker package

[user@host ~]$ docker -v
podman version 2.0.2
[user@host ~]$ docker version
Version:      2.0.2
API Version:  1
Go Version:   go1.14.3
Built:        Wed Dec 31 19:00:00 1969
OS/Arch:      linux/amd64

Fixing by using docker -v, thanks @DMouse10462 !

I can't seem to figure out how to install podman-docker and it's proving an impossible phrase to search. Can anyone help verify that this is working now or provide steps on how I can verify?

Which distribution? It's available in CentOS/Fedora's repos and the AUR. I'm using Fedora 32 and the package is able to be installed without issue.

https://pkgs.org/search/?q=podman-docker

@DMouse10462 Yes that would explain it, I was on Ubuntu. Are you able to confirm that it works now?

I got it to list my containers, therefore "solving" the titled issue, but couldn't actually get containers to work in practice. Existing Fedora toolbox containers failed to install the server and new containers created in VS Code couldn't access folders due to permissions issues, but these could also be Fedora Silverblue/ostree quirks. I've yet to be able to test it on a non-ostree distro as my other daily driver is Pop! OS (which uses Docker and not Podman).

Got a Fedora Workstation 32 install running (Edit: with podman-docker installed) and, again, no docker version error. However, the socket path used "/var/run/docker.sock" is only available as root, and user-level socket files are located in /run/user/$UID/podman/podman.sock per discussion in containers/podman#4499.

This is _technically_ beyond the scope of the issue of podman not being detected at all, but if this issue represents podman _support_ within the extension then this issue is within scope. The specific error I receive upon attempting to create a container with a repository in a new volume is as shown:

Screenshot from 2020-08-09 02-09-03

Here are the contents of the built-in terminal as of the error:

[42 ms] Start: Resolving remote
[47 ms] Start: Check Docker is running
[47 ms] Start: Run: docker info
[472 ms] Start: Run: docker volume ls -q
[614 ms] Start: Run: docker ps -q -a --filter label=vsch.local.repository=https://github.com/jellyfin/jellyfin --filter label=vsch.local.repository.volume=jellyfin --filter label=vsch.local.repository.folder=jellyfin --filter label=vsch.quality=insider
[764 ms] Start: Run: docker build -f /home/dmouse/.vscode-insiders/extensions/ms-vscode-remote.remote-containers-0.133.0/scripts/volumeBootstrap.Dockerfile -t vsc-volume-bootstrap /home/dmouse/.vscode-insiders/extensions/ms-vscode-remote.remote-containers-0.133.0/scripts
STEP 1: FROM alpine:3.11.2
STEP 2: RUN apk add --no-cache  nodejs  git     openssh-client  docker-cli      ;
--> Using cache 2de3df8f4507fe711469a8ac28971f422cd25166b4f258dd6fce632298e15cc5
STEP 3: COMMIT vsc-volume-bootstrap
--> 2de3df8f450
2de3df8f4507fe711469a8ac28971f422cd25166b4f258dd6fce632298e15cc5
[2324 ms] Cloning Github repository: jellyfin/jellyfin into /workspaces/jellyfin

[2325 ms] Start: Run: docker run -d --mount type=volume,src=jellyfin,dst=/workspaces -v /var/run/docker.sock:/var/run/docker.sock vsc-volume-bootstrap sleep infinity

The recovery container fails as well with the following logs:

[38 ms] Start: Resolving remote
[44 ms] Start: Check Docker is running
[44 ms] Start: Run: docker info
[422 ms] Start: Run: docker ps -q -a --filter label=vsch.local.volume=jellyfin --filter label=vsch.quality=insider
[669 ms] Start: Run: docker build -f /home/dmouse/.vscode-insiders/extensions/ms-vscode-remote.remote-containers-0.133.0/scripts/volumeInspect.Dockerfile -t vsc-volume-inspect /home/dmouse/.vscode-insiders/extensions/ms-vscode-remote.remote-containers-0.133.0/scripts
STEP 1: FROM alpine:3.11.2
STEP 2: RUN apk add --no-cache  nodejs  git     openssh-client  docker-cli     bash     ;
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz
(1/19) Installing ncurses-terminfo-base (6.1_p20200118-r4)
(2/19) Installing ncurses-libs (6.1_p20200118-r4)
(3/19) Installing readline (8.0.1-r0)
(4/19) Installing bash (5.0.11-r1)
Executing bash-5.0.11-r1.post-install
(5/19) Installing ca-certificates (20191127-r2)
(6/19) Installing docker-cli (19.03.5-r1)
(7/19) Installing nghttp2-libs (1.40.0-r1)
(8/19) Installing libcurl (7.67.0-r0)
(9/19) Installing expat (2.2.9-r1)
(10/19) Installing pcre2 (10.34-r1)
(11/19) Installing git (2.24.3-r0)
(12/19) Installing c-ares (1.15.0-r0)
(13/19) Installing libgcc (9.2.0-r4)
(14/19) Installing libstdc++ (9.2.0-r4)
(15/19) Installing libuv (1.34.0-r0)
(16/19) Installing nodejs (12.15.0-r1)
(17/19) Installing openssh-keygen (8.1_p1-r0)
(18/19) Installing libedit (20191211.3.1-r0)
(19/19) Installing openssh-client (8.1_p1-r0)
Executing busybox-1.31.1-r8.trigger
Executing ca-certificates-20191127-r2.trigger
OK: 127 MiB in 33 packages
STEP 3: COMMIT vsc-volume-inspect
--> 40bc6bc5972
40bc6bc5972cac015e365da79a8b6e519551d8a9259d83809ad717644ff35afd
[26069 ms] Start: Run: docker -v
[26245 ms] Start: Run: docker events --format json --filter status=start
[26257 ms] Start: Starting container
[26258 ms] Start: Run: docker run -a STDOUT -a STDERR --mount src=jellyfin,dst=/workspaces,type=volume,volume-driver=local -l vsch.quality=insider -l vsch.remote.devPort=0 -l vsch.local.volume=jellyfin --entrypoint /bin/sh vsc-volume-inspect -c echo Container started ; trap "exit 0" 15; while sleep 1 & wait $!; do :; done
Error: "src=jellyfin,dst=/workspaces,type=volume,volume-driver=local": incorrect mount format: should be --mount type=<bind|tmpfs|volume>,[src=<host-dir|volume-name>,]target=<ctr-dir>[,options]
[26468 ms] Start: Run: docker ps -q -a --filter label=vsch.local.volume=jellyfin --filter label=vsch.quality=insider
[26607 ms] Command failed: docker run -a STDOUT -a STDERR --mount src=jellyfin,dst=/workspaces,type=volume,volume-driver=local -l vsch.quality=insider -l vsch.remote.devPort=0 -l vsch.local.volume=jellyfin --entrypoint /bin/sh vsc-volume-inspect -c echo Container started ; trap "exit 0" 15; while sleep 1 & wait $!; do :; done

@DMouse10462 thanks for the investigation! I'll loop in @chrmarti for how to handle this going forward.

Using a volume is tracked as https://github.com/microsoft/vscode-remote-release/issues/2881. It is currently not supported.

To verify: Install podman-docker and make sure Remote-Containers does not complain about Docker not being a recent enough version.

In that case, I can verify from Fedora Workstation 32 that installing podman-docker and attempting to use it causes the extension to no longer complain about the Docker version and allows the extension to be used.

Thanks for the heads-up on issue 2881.

Was this page helpful?
0 / 5 - 0 ratings