Attach to container config

[xeor]

Not sure if there are any reasons behind it, but on some of my containers, I want to keep track of them on my own, but attach to them with ease using vscode.

There should be a configuration option to attach to a running container, not just build them.

Something like this:

{
    "name": "my container",
    "containerName": "project_container_1",
    "workspaceFolder": "/workspace",
    "extensions": ["..."]
}

[Chuxel]

@xeor Are you aware of this? https://code.visualstudio.com/docs/remote/containers#_attached-container-configuration-files

[xeor]

thanks @Chuxel .. I read that, but it didn't quite do what I need, since the container-name ends up in another configuration bound per image, per user. I want it bound to the running container name, and the folder.

The usecase is that there is another tool that starts the dev-containers, but I want a unified way of developing on them. Just like the attach to container functionality, but everything specified in the .devcontainer.json

[lysyi3m]

👍🏻 It would be definitely great, if we'll have an ability to store config files for attached connections under VCS in the project dir - to maintain & share this config between team members

[masip85]

Yes, the worst part of it, is that according to docs,it seems possible but it isn't.

I've following the rules from:
(https://code.visualstudio.com/docs/remote/containers#_attached-container-config-reference)
because if you read the docs:
You can also create a devcontainer.json, which describes the development environment you want to create or attach to and lives with your project to share with your team members.
VS Code's container configuration is stored in a devcontainer.json file. This file is similar to the launch.json file for debugging configurations, but is used for launching (or attaching to) your development container instead. You can also specify any extensions to install once the container is running or post-create commands to prepare the environment. The dev container configuration is either located under .devcontainer/devcontainer.json or stored as a .devcontainer.json file (note the dot-prefix) in the root of your project.
so , should be possible,but is not working

[jflam]

I have a command line tool that lets me copy files from my local machine to a remote devcontainer. It is a convenience wrapper for scp. But for this to work, I need to be able to deterministically get the container name for the remote devcontainer. I rely on hacky workarounds to run docker ps on the remote VM to scrape out the image name, but I would prefer generating a deterministic name for the remote container via devcontainer.json (which I also generate using my tool).

Has there been any progress on this? Happy to provide more details of my scenario if it helps. Thx!

[Gepar]

Same as author problem: i have project where docker compose rely on some logic and env variables, it can not be started from vscode using devcontainer.json
After i start container i can attach with vscode but i want also give vscode info about extensions and some user settings.
I found that i can do this using local file with "image name".json (i created it using command "Open attached configuration file") but i want to share this file in project and also i want to link this file only for this project, not for all projects where same docker image used.

[eschumacher-s]

A config that describes actions to take when attaching to a running container would simplify team collaboration. Currently I work around by a combination of creating a custom vscode extension and shell scripts. A lot of that complexity could be replaced by this feature.

[Chuxel]

We've recently added support for adding dev container configuration to image or container labels (specifically the devcontainer.metadata label). See https://containers.dev/implementors/reference/#labels for info. This is not yet supported when attaching, but it is a muscle item for this iteration (see #7479).

So, as long as the mechanism you are using allows you to set labels (e.g. like Docker Compose), you'll be able to do quite a bit without a devcontainer.json (Though as the above article mentions, you can use a devcontainer.json to build an image inclusive of Dev Container Features with the proper lables on it too thanks to the CLI and GitHub Aciton. You can then just reference said image from whatever orchestrator you're using... but that's entirely optional).

The devcontainer.json reference indicates which properties can be used this way.

@chrmarti Should we use this for the red dot issue on this topic?

[chrmarti]

@Chuxel I will open a separate issue to track the plan item. Thanks.

[adnan-muttaleb]

Any update about this issue, can we now maintain the attached container devcontainer config in the workspace?

[adnanmuttaleb]

Workaround that might be helpful, is to Symlink your tracked configs in your repo to the path where vscode actually read the configs:

ln -sf <path to your tracked repo>/nameConfigs/* \ /home/${USER}/.config/Code/User/globalStorage/ms-vscode-remote.remote-containers/nameConfigs

[gremo]

Any update on this?