[Containers] Support using nerdctl to connect to a containerd backend

[MurzNN]

Kubernetes deprecated Docker as a container runtime after v1.20 at the end of 2020 year with removing in v1.22 in late 2021.

So now there is more and more servers, that uses other container runtimes (containerd, CRI-O) instead of Docker.

But Visual Studio Code Remote - Containers extension doesn't see CRI containers, that using runtime other than Docker, because instead of list of containers I see the placeholder:

Get started with containers by installing Docker or by visiting the help view.

So, is it possible to add support for other container runtimes to VS Code Remote Containers extension?

[MurzNN]

Now we have nerdctl as a Docker-compatible CLI for containerd, maybe we can reuse it instead of docker backend to manage container operations for VS Code Remote Containers extension?

[MurzNN]

Removing Dockershim and Docker support from Kubernetes is scheduled for Kubernetes v1.24.

[chrmarti]

You can use a Docker compatible CLI by changing this setting:

When I tried nerdctl with lima a while ago, it looked like it was not fully compatible with the Docker CLI yet.

[Chuxel]

We should make this more specific about nerdctl. Updating the subject.

Remote - Containers does not touch container engines or daemons directly but rather interacts with CLIs. It makes no assumptions about how the engine functions. There's no "containerd, CRI-O" CLI per-se. For example, Docker itself uses containerd on Linux, so really it's already supported. Dockershim going away will not have any affect.

The issue is that each CLI that needs to be supported will require separate work unless it supports everything the docker CLI does with the same arguments. Podman is closest but there are always nuances.

While the nerdctl CLI is part of the containerd project, it currently has gaps most notably around the missing --mount property that has replaced -v and automatic creation of named volumes in either syntax (nerdctl requires a separate command be called). Would love to see those gaps resolved.

[MurzNN]

nerdctl is only one option, most easier to integrate (because of Docker compatibility), but we have also crictl that must give compatibility with any CRI-compatible container engine!

So maybe split the issue to 2 parts - nerdctl and crictl?

[Chuxel]

We should track crictl as a separate issue. Each CLI will be a separate effort. Raised #6075

[Chuxel]

FYI - For those not aware, the dev container CLI is now open source and is what the extension uses to interoperate with container engines if anyone has interest in contributing. https://github.com/devcontainers/cli

[Anutrix]

Any updates on this?

[kidbrax]

FYI - For those not aware, the dev container CLI is now open source and is what the extension uses to interoperate with container engines if anyone has interest in contributing. https://github.com/devcontainers/cli

@Chuxel I checked the devcontainers/cli repo and searched for APIVersion and got no results. This leads me to believe the change we need is not in that repo, since the command VSCode runs when spinning up a devcontainer (when trying finch) is finch version --format {{.Server.APIVersion}}.

Is the code for this extension not open? This repo is just for feedback, correct?

[Chuxel]

FYI - For those not aware, the dev container CLI is now open source and is what the extension uses to interoperate with container engines if anyone has interest in contributing. https://github.com/devcontainers/cli

@Chuxel I checked the devcontainers/cli repo and searched for APIVersion and got no results. This leads me to believe the change we need is not in that repo, since the command VSCode runs when spinning up a devcontainer (when trying finch) is finch version --format {{.Server.APIVersion}}.

Is the code for this extension not open? This repo is just for feedback, correct?

Yeah, I'd recommend opening an issue in the CLI repository to discuss the specific scenario you are looking into.

@chrmarti is the version check in the CLI or extension? Generally, seems like these kinds of checks should end up in the CLI (if not the broader spec) so they can be contributed, but I'm not sure if this is a proposed feature.

[chrmarti]

The version check is in the extension. Making that more tolerant now.

[jsamuel1]

nerdctl and finch also don't support --sig-proxy=false
This appears to be a fixed parameter in devcontainer when using single-container devcontainer configurations.
https://github.com/containerd/nerdctl/blob/main/docs/command-reference.md#whale-nerdctl-attach

(Offending Line in devcontainer code: https://github.com/devcontainers/cli/blob/f7d4c853bf8c284d784173f3e915a34d961b0b55/src/spec-node/singleContainer.ts#L396 )

[chrmarti]

I'm hesitant to make details like --sig-proxy=false conditional on the detected CLI as that might quickly become a long list of cases to distinguish given the growing list of Docker-like CLIs.

The more tolerant version check is available in Dev Containers extension 0.330.0-pre-release.

[Bigous]

I'm hesitant to make details like --sig-proxy=false conditional on the detected CLI as that might quickly become a long list of cases to distinguish given the growing list of Docker-like CLIs.

Hi @chrmarti ,

In this case, for docker, you are tuning off the feature... and this feature doesn't even exists in nerdctl... you can safely be "non conditional" just detecting you are using nerdctl (which it already do) and not sending the argument.

Could that be a solution?

[CodeChanning]

A --sig-proxy change was merged to nerdctl yesterday that should supports the flag in run
containerd/nerdctl#3043