|
|
|
|
|
by 4oo4
80 days ago
|
|
Yes and no, in this case you don't need a local vscode instance to connect to your vscode container, just a browser. It's more similar to self-hosted Github Codespaces, and but I believe code-server was actually released first. Personally I've fiddled enough with podman that that part of it doesn't bother me, and I don't like Docker/Podman desktop (which I think is what devcontainers assume the setup is) and just want to use the docker/podman daemon/cli, so that's something I also don't want to have to mess with. I know you can also point devcontainers at a remote or local docker daemon, but that means giving it full control of the daemon, which is a nonstarter and too risky for me from a security standpoint. I really like to have my podman containers really locked down in terms of capabilities, userns, gvisor, etc. and given that it just wants full control of docker I'm guessing it takes none of that into consideration (or, painful to try and graft on). I also really don't trust VSCode's remoting protocols (especially remote tunnels, which is basically just a reverse shell). So for me it's a matter of having more control over container runtime security (the docker/podman ecosystem usually treats it as an afterthought in favor of convenience, and devcontainers appears to be no different), and it doesn't depend on anything on my machine I'm accessing it from. Since VSCode just a becomes another self-hosted web app this way, it's pretty much the exact same experience no matter where I'm connecting from. |
|