Direct open VS Code Remote Containers workspace path with code CLI?

[kwlzn]

A very common tooling scenario we have at Twitter is to e.g.:

1. package a development runtime (like a Jupyter Notebook env) in a container
2. we use a CLI to deploy the runtime to a containerized environment (like GKE)
3. once that containerized runtime is running, we understand a "job key" coordinate based on e.g. a pattern like [<$datacenter>/]<$namespace>/<$job_name>-<$environment> that we can use to reference that job
4. for web-based tools, we usually "launch" them via e.g. open $proxy_url/$job_key which completes the launch lifecycle

I think in the tooling use case of using VS Code Remote as a remotely attached front-end, we would love it if there were some way to use the code CLI to automatically connect to containers running in a Kubernetes cluster.

is this possible today? if not, could it be made possible?

for a k8s pod like:

$ kubectl ... -n some_namespace -l name=codespace-devel 

being able to open a path inside it in one CLI invocation, e.g.:

$ code open k8s://some_namespace/codespace-devel/<path/to/src/code>

would make VS Code front-end integration incredibly composable for us and likely others using VS Code Remote Containers.

[fire015]

When working with a remote container on my WSL machine, I run code . to open the project, then I need to open the command palette and then select the "Remote-Containers: Reopen in Container" command.

This seems like a waste of time. It would be better if running code . or code --remote . could detect the presence of a devcontainer.json file and open in the container rather than in WSL.

[Taytay]

See #2133 for what I believe is a related dupe issue.

[emcake]

So you can almost do this right now:

vscode://vscode-remote/k8s-container+podname=<pod_name>+namespace=<namespace>+name=<container_name>+image=<some_string>/root/code/OptionsOEG/workspace.code-workspace

by replacing <pod_name>, <namespace>, <container_name> and <some_string> appropriately. In the original example I stole this from, the image referred directly to the image it was running, but I had trouble replicating this for other containers as the string contained : and / that were escaped . It doesn't seem to matter what the image string is.

The only thing I haven't worked out is the cluster - it uses whatever is the default context in .kube/config. Ideally I'd love to specify that too, interested to know (@chrmarti?) if this is possible to specify in the protocol as well? I can't find anything showing how this is done.

[chrmarti]

@emcake The cluster can currently not be specified. Could you open a feature request for us to track this?

[kwlzn]

@emcake @chrmarti thanks for following up on this in #4975 - that issue is now locked but afaict, doesn't specify the URI spec params that includes the cluster path? can someone help me understand what that should look like now?

[kwlzn]

ah - I was looking for a code CLI flag or URI spec to pass this to, but it seems like the idea here is that the system's URI protocol handler dispatches this - so the exact terminal command (on OSX at least) is literally e.g.

$ open vscode://vscode-remote/k8s-container+podname=notebook-devel-0+namespace=$USER+name=notebook+image=xxx/home/sandbox/workspace

this is 🔥🔥🔥

[kwlzn]

@rzhao271 do you know what the proper way to specify the k8s context (from #4975) in the above URL specification is? that wasn't clear to me in #4975 and the issue was locked before I had a chance to respond.

I'm guessing its something like +cluster=x+ or +context=x+ but just wanted to verify with someone in the know since this is a closed-source impl.

[chrmarti]

@kwlzn It is context. (It maps to --context.)

[kwlzn]

@chrmarti thanks for confirming!

[kwlzn]

to close the loop on this, we've implemented an experimental feature flag in our company-wide DS/ML Jupyter Notebook tooling that allows users to trivially attach VS Code Remote to their Jupyter Notebook instances. this feature has already been met with a warm reception by our eager adopters and we'll continue to pilot this internally.

thanks a ton for the response and support here, much appreciated.

[BitPatty]

Glad you found a fix but I'd still consider this issue a valid feature request for a simplified process via the VSCode CLI.
Especially since other issues are linking to this one as dupe.

[chrmarti]

We are tracking the more general request here: #2133