Investigate: Reducing reliance on runArgs for common scenarios: mount points, environment variables

[chrmarti]

No description provided.

[Chuxel]

@chrmarti FYI - After looking into the best way to enable HTTPS support for .NET Core applications, I've updated the vscode-remote-try-dotnetcore sample. It is now a pretty textbook example of where env and mounts would be useful properties. The readme explains why.

"runArgs": [
    "-u", "vscode",
    "-e", "ASPNETCORE_Kestrel__Endpoints__Http__Url=http://*:5000",
    "-e", "ASPNETCORE_Kestrel__Endpoints__Https__Url=https://*:5001",
    "-v", "${env:HOME}${env:USERPROFILE}/.aspnet/https:/home/vscode/.aspnet/https",
    "-e", "ASPNETCORE_Kestrel__Certificates__Default__Password=SecurePwdGoesHere",
    "-e", "ASPNETCORE_Kestrel__Certificates__Default__Path=/home/vscode/.aspnet/https/aspnetapp.pfx"
]

The https://github.com/microsoft/vscode-remote-try-dotnetcore README explains what these things do. Theoretically you could bake the env vars into the Docker image, but leaving them in devcontainer.json allows you to enable/disable HTTPS and change port mappings as appropriate.

I'd expect this to be something people will pretty commonly want to do given .NET Core's out of box self-signed HTTPS certs.

[chrmarti]

To pick up another discussion: We could have two properties: "env" to set variables on the container and "serverEnv" to set variables on the VS Code Server environment. The latter would update when the server is restarted, the former only when the container is rebuilt.

[Chuxel]

@chrmarti That's an excellent idea. In some ways, I almost wonder if it should be flipped. env is what you mention as serverEnv and then there is a containerEnv for run.

env then could also be applied to the attach scenario which would be fantastic.

[chrmarti]

Or devEnv for the server and env for the container. 🤔

Is there a reason to prefer env for the container?

One limitation for the server's environment is that all connected windows will need to reload because we need to restart the agent. (We could look into keeping the old agent and extension hosts around for windows that aren't reloaded yet, but I'm not sure that simply works.)

[Chuxel]

@chrmarti Hmmm. Effectively wouldn't a rebuild would have the same effect, but would be slower?
There's two things driving the thought - one is optimizing the speed that minor changes like this take effect in Remote - Containers. Adding a simple env var ideally wouldn't drive a full rebuild of the entire container. I can see having other changes follow this path over time as an optimization (e.g. adding another extension). The second is I am also thinking a bit about VSO's use of devcontainer.json. In that environment, I'd expect you'd want to do anything you can to prevent having to do a container rebuild, so the restart path would be primary.

[chrmarti]

@Chuxel Correct, with 'agent' I mean the VS Code server process, the container can keep running. The limitation might be that if you have multiple windows open on the same container, you need to reload all of them - not just one - for the change to apply.

[Chuxel]

@chrmarti Yep, but effectively a rebuild would get it to kick in as well, which is why it seems like a better default. It would work in both cases rather than just a full rebuild.

On a related note, on the VSO side, I know they're looking at adding a "restart server" option to allow this kind of thing to kick in. Perhaps we should consider something similar for the remote extensions for the reason you mention. SSH has "Kill" which effectively gets you along the same lines, but containers and WSL don't have a similar concept.

[Chuxel]

@chrmarti Okay, talking with the VSO folks, here's a proposal:

1. env is used on startup
2. containerEnv is used on container create

env is the one we want most people to use for compatibility with VSO anyway. The other thing I am noticing is we do see isssues with people wanting to modfiy the environment based on another environment variable. This is coming up quite a bit for VSO and the PATH. Since env applies after the container is created, we could also have it support a syntax like the following:

"env": [
    "PATH": "${containerEnv:PATH}:/some/other/location
]

Which would take the container's PATH env var and add something to it. This wouldn't work for "-e", but would in this case.

What do you think? Even if we don't add the second part right away, the VSO folks might to solve some issues.

[chrmarti]

Copying @Chuxel 's notes from a wider discussion here:

• containerEnv - Establishes env vars for the container itself focused particularly on situations where the image being used requires specific variables be set. These cannot be changed without recreating the container. containerEnv can refer to ${localEnv:...} in the Remote - Container case. Long term, this could apply to VSO environments created via VS Code, but I'd assume not initially.

• remoteEnv - Establishes env vars that are set when the remote host / container is spun up. They're tied to the start of VS Code server. These can refer to ${localEnv:...} like the above and can also refer to containerEnv to do things like update the path. For example "PATH": "${containerEnv:PATH}:/some/other/location/in/container

User then has the same pattern.

• containerUser is the user that starts the container.
• remoteUser is the user operates in the remote environment - specifically the one that actually starts VS Code server.

[chrmarti]

Note that the resolver API allows the resolver to return environment variables in the ResolverResult. These will apply to the remote extension host even if there is another remote extension host with older environment variables still running on that same container. This is contrary (i.e., better) to what I previously thought where my assumption was that all windows (and thereby remote extension hosts) need to be restarted for a change to "remoteEnv" to apply.