Attach to running docker container by name in CLI and document code remote CLI options

[JPustkuchen]

Hi and thank you all very much for your hard work on vscode and vscode-remote! It's simply brilliant.

Context

We're using tools like https://github.com/drud/ddev or https://lando.dev/ to build and run smart development docker containers. We're using VSCode Remote to attach to these running containers using the wonderful UI via F1 + Remote-Containers: Attach to Running Container ... There we select the container we'd like to attach to and run it.

Problem

This works, but for developers like you and us the process isn't really perfect. It's clicky here, clicky there for a task where you'd expect to write a shell script and GO :)

I've read many similar issues, most are about how to start devcontainers / k8 or ssh remote connections. Anyway it seems such CLI parameters aren't yet officially documented?

For our use-case (attaching to a running docker container by name from CLI / shell script) I couldn't find a viable solution. That's why I've written this feature request to document the CLI options and provide a clever way to start vscode from CLI / shell script attached to a running container by container name / id.

Proposed solution

1. Document the CLI parameters officially with examples how to start vscode from CLI in remote (devcontainer, attached to running container, k8, ssh, ...?)
2. Allow to attach to a running container from CLI by container name (or document how to do that if that should be possible already)

Once again, thank you very much for your hard work on this wonderful project!

[chrmarti]

There is now a devcontainer CLI, we could add an attach command to that: https://code.visualstudio.com/docs/remote/devcontainer-cli

[joshsedl]

Hey @chrmarti, can't wait for this feature to be implemented! It would really help automatically setting up our programming environment using ddev with VSCode. 👍 Just wanted to sneak in and ask what the current status of this feature is?

[chrmarti]

Hi @joshsedl, still on the backlog. To follow what we are currently up to I recommend checking the current iteration plan. Usually the only pinned issue at the top of https://github.com/microsoft/vscode-remote-release/issues.

[joshsedl]

Ok, thanks for the tip!

[joshsedl]

Since we are tracking this issue here now, I just wanted to quote my proposal from https://github.com/microsoft/vscode-remote-release/issues/5944, to attach VSCode to a container with additional setting and extension flags!

If there could be an easier readable command to attach to a container, instead of using the hex value of the container, + some additional flags which define the location of a settings/extensions.json, to use would be perfect! For example: code-attach-to-container --name my-container-name --extension-path /my/path/to/extensions.json --settings-path /my/path/to/settings.json

[g-kartik]

Hello @chrmarti, this is a very useful feature. I am using git hooks to automatically build and run docker containers on branch checkout and merge. If there is a CLI command to attach to a running container then I could use it in the git hooks script to launch the vs code remote dev environment window, which would be awesome. Can't wait this feature to be built.

[chrmarti]

@g-kartik You could try using this: code --folder-uri vscode-remote://attached-container+$(printf "$CONTAINER_NAME_OR_ID" | xxd -p)/home

[g-kartik]

Thank you @chrmarti . It worked. Could not be more happy!

[joshsedl]

For some reason, printf "$CONTAINER_NAME_OR_ID" | xxd -p lead to two different outcomes depending on the distro:

• Under Windows + WSL2 (with Ubuntu installed) using zsh, it works as expected and prints out the hexvalue of the container name
• Under OpenSUSE Leap using bash, the hex value got split

So instead I am using a differen (probably overcomplicated) command: code --folder-uri vscode-remote://attached-container+$(printf "$CONTAINER_NAME_OR_ID" | od -A n -t x1 | sed 's/ *//g' | tr -d '\n')/home (sed, will delete the spaces and tr the new lines)

[tyler36]

@joshsedl

I had the issue with my ddev-vscode-devcontainer addon to open containers in VScode. It came down to how the terminal would "wrap" longer names into columns.

Using xxd, I change the default from 16 to 64 which resolved my issue.

 ${CODE_EXECUTABLE} --folder-uri "vscode-remote://attached-container+$(printf '%s' $CODE_CONTAINER | xxd -p -c 64)${CODE_PATH}"

[joshsedl]

Thanks, @tyler36! Yea, I probably skipped on "xxd" too fast, Never the less I'll rather use code --folder-uri vscode-remote://attached-container+$(printf "$CONTAINER_NAME_OR_ID" | od -A n -t x1 | sed 's/ *//g' | tr -d '\n')/home now, as "od", "sed" AND "tr" all follow the POSIX standard, making sure, the command works on a wide variety of UNIX derivatives (xxd doesn't). It's probably not a big deal and both are fine, but since it works, it works!

[tyler36]

Thanks @joshsedl . I use WSL ubuntu and it was the solution I stumbled across and worked. Before my post, I checked that my WSL OpenSUS had xxd (it did) but it's good to now know that it doesn't work on some UNIX derivatives.

[tuunit]

I combined the new devcontainer cli with the approach presented here:

CONTAINER_NAME_OR_ID=$(devcontainer up --workspace-folder . | jq -r .containerId) /usr/bin/code --folder-uri vscode-remote://attached-container+$(printf "$CONTAINER_NAME_OR_ID" | od -A n -t x1 | sed 's/ *//g' | tr -d '\n')/workspace

This way I have a oneliner that will start a devcontainer defined in the current working directory and automatically attaches vscode to it. Without using the whole Reopen and Rebuild UI fiasco.

You can even put it into an alias inside your .bashrc or .zhsrc like so:

alias dc="CONTAINER_NAME_OR_ID=\$(devcontainer up --workspace-folder . | jq -r .containerId) && /usr/bin/code --folder-uri vscode-remote://attached-container+\$(printf \"\$CONTAINER_NAME_OR_ID\" | od -A n -t x1 | sed 's/ *//g' | tr -d '\n')/workspace"

The only thing I don't like about this approach, is that it doesn't fully respect all the devcontainer.json settings like for example the name. Which is just a random container uuid now:

I gave this script a shot: https://gist.github.com/ilyasotkov/27e77fd4a1a045bb17f5bcf7f20c1f2e

And with a simple alias like so:

alias devcontainer="/usr/bin/code --folder-uri \$(python3 /workspace/dev-setup/make_devcontainer_folder_uri.py)"

It either starts a new devcontainer from the definition file in your current working directory or will attach to an already existing devcontainer.

[joshsedl]

@tuunit, thanks for sharing!

You say, that you start a devcontainer through "devcontainer up" and attach vscode to it. Do you know if the devcontainer cli can also take a devcontainer.json and use it to attach to an existing container? I saw "devcontainer up --mount", but I am unsure if that does what this issue is originally about.

[tuunit]

create an attached container to an existing container?

How would you attach a container to a container 🤔 Or do I misunderstand what you try to accomplish?

[joshsedl]

@tuunit, sorry not very well worded, I updated my comment. Basically, what I mean is, that an attached vscode supports a subset of devcontainer.json properties. So I basically want to attach to container xyz using the settings defined in a custom devcontainer.json. Maybe, that's what your snippet is doing already and I misunderstood the first part of your comment!

[tuunit]

Ah okay, if you read the last sentence of my original comment. It will answer your question:

It either starts a new devcontainer from the definition file in your current working directory or will attach to an already existing devcontainer.

Meaning if a devcontainer defined by your devcontainer.json is already running, it will automatically attach to it. This statement is valid for the first solution using devcontainers/cli and the custom python method.

[joshsedl]

Thanks a lot @tuunit! That sounds great! 🎉 I thought that part was script specific! So thanks for the clear up!

[joshsedl]

Ok, https://github.com/microsoft/vscode-remote-release/issues/5278#issuecomment-1785723387, doesn't solve this issue's problem yet. devcontainers/cli will always create its own devcontainer, no matter what. As @tuunit already said in his comment:

Meaning if a devcontainer defined by your devcontainer.json is already running, it will automatically attach to it

The talk is of a devcontainer, not a "normal" container to attach to. Meaning if I want to attach VSCode to my dev environment's web server container, I can not do that with the devcontainers/cli, even if I define the same image and name of my webserver docker container, devcontainers/cli, will always create its own container.

Although this could still be a future feature of https://github.com/devcontainers/cli. It might make sense to move this feature request there?

[lakuapik]

Hi @chrmarti @joshsedl the above command works, just curious, is it possible to open in existing workspace that already running devcontainer? instead of opening in new window?