vscode-remote-oss icon indicating copy to clipboard operation
vscode-remote-oss copied to clipboard

Devcontainers

Open Weissnix4711 opened this issue 3 years ago • 4 comments

Hello,

Can this be used for devcontainers? If so, how?

I wish to use devcontainers with VSCodium, however the official remote containers extension fails during container creation, at the installation of the code server within the container.

Can this extension help? Or have I completely misunderstood the purpose of it?

Thanks, Thomas Aldrian

Weissnix4711 avatar Sep 02 '22 12:09 Weissnix4711

This extension will not download & run the remote extension host (REH) for you like the Microsoft one does. You have to download it yourself from the VSCodium release page. I have not tested it but in theory it should work with containers:

  • spin up a container and set up a port forwarding from an internal remote port the REH will listen on to a local port on the host that VSCodium will connect to
  • run a shell in the container, download the REH and unpack it somewhere (make sure it is exactly the same release as the one on your host or it will fail with "authentication" errors)
  • start the REH in the container
  • connect using this extension to the local port

EDIT: I was thinking about real hosts, in the case of containers it is probably enough just to expose the internal port to the host and connect to it.

xaberus avatar Sep 02 '22 16:09 xaberus

Do you think instructions (with commands) for how to do this could be added to the README?

Validark avatar Oct 16 '22 19:10 Validark

Sure! I am short on time at the moment & have no too much experience with containers right now, so somebody would have to a pull request :wink:.

xaberus avatar Oct 20 '22 20:10 xaberus

I've looked into it and it seems to be doable in principle.

I've got an extension running (forked from vscode-remote-oss, with some bits from Open Remote - WSL) that starts a container with devcontainer up and runs VSCodium server inside as a “feature” (a devcontainer addon). After it starts, we can connect to it as usual (open new window, resolve the authority and connect to the exposed server).

It is very flaky though:

  • only single container can be setup as the CLI doesn't support forwardPorts yet (https://github.com/devcontainers/cli/issues/186)
  • you have to specify the port as appPort in the config itself, it can't be specified as a CLI option
  • there are further problems that need to be solved if we want docker-compose support: https://github.com/devcontainers/cli/issues/433

Overall, the dev containers CLI seems to be an afterthought, so the experience would likely still be pretty bad. I'll publish my code after I clean up a bit, but I don't think it's worth continuing this approach until the issues with the CLI are resolved.

notpushkin avatar Oct 30 '23 18:10 notpushkin