devcontainer support

[bpmct]

From the spec:

The purpose of the Development Container Specification is to provide a way to enrich containers with the content and metadata necessary to enable development inside them. These container environments should be easy to use, create, and recreate.

A development container is a container in which a user can develop an application. Tools that want to implement this specification should provide a set of features/commands that give more flexibility to users and allow development containers to scale to large development groups.

There is a neat way to use Coder with the devcontainer CLI, but it would be great if the Coder agent had first class support for running workspaces via a devcontainer.

---

Note: We now have docs on using our Devcontainers Alpha.

[ammario]

This feature would ease the transition from local to remote development. We should be able to implement at the terraform-level, similar to #5314.

[ammario]

Per @kylecarbs, release ETA is end of next week.

[cguentherTUChemnitz]

Let me shortly describe a scenario here, where this would help alot in my eyes.

We have several projects with different tooling and setups. Vscode is able to bundle this very nicely directly in the project using .devcontainers and .vscode/settings inside every project bringing up an pre-configured environment in the same way for every developer. This approach still has the problem, that every developer needs a machine with good docker support and performance. But especially for app-development this kind-off falls apart, since we have pre-packaged android environments, but need to run for ios on baremetal macos system. MacOS seems to have crappy docker performance using docker-desktop compared to native docker support of linux, espacially when filesystem translations between host-os filesystem apfs and docker-desktop internal filesystem (e.g. ext4) comes into play (which is the case of the mapped project folder in devcontainers). So this meens at the moment, that we need 2 distinct machines for app-development per developer. One for macOS based for ios development and one for everything else, where the devcointer approach works nice.

In my eyes this problem can be more or less completely avoided, when coder runs on a baremetal linux machine and is able to open git projects in vscode with devcontainer support on project level. Then the app-developer can use just the browser accessing coder for every development task except ios dev, avoiding buy, setup and maintenance of a second machine per developer.

Is that scope of the devcontainer support idea here in coder?

[bodiroga]

Per @kylecarbs, release ETA is end of next week.

Has there been any progress around this? 😉

[Tirzono]

Looks like there has been some work done in #8256 to add documentation how to work with devcontainers in templates.

[bpmct]

Yep! You can try devcontainers + Coder today by following those docs. We're tightening our integration with GitHub to make it easier to work with private repos, which is why it is labeled as alpha but it all works today.

[bpmct]

👋🏼 Docs for using devcontainers are here: https://coder.com/docs/v2/latest/templates/devcontainers

We plan on doing two things before we close out this issue:

• Make it possible to "rebuild" a devcontainer from within the dashboard or VS Code
• Improve UX from within Coder from starting a workspace from a repo (Start from a git repo #8462)

[bpmct]

Feedback is also welcome here or on the envbuilder repo!

[Shocktrooper]

@bpmct Can we add instructions/examples on how to use devcontainers with rootless container variants like rootless podman. We want to allow for devcontainers but don't want to give user controlled pods privileged mode.

[xangelix]

are the customizations.vscode.settings and customizations.vscode.extensions fields planned to be supported?
I believe this is all that is needed for gitpod feature parity other than user-level environment variables which are unrelated to devcontainers.

[Shocktrooper]

are the customizations.vscode.settings and customizations.vscode.extensions fields planned to be supported? I believe this is all that is needed for gitpod feature parity other than user-level environment variables which are unrelated to devcontainers.

@xangelix Couldn't you just use the dotfile capability that already exists to inject user level env vars among other things?

[juanbits]

i have a selfhosted coder-oss, how i can use the devcontainers functionality?

[xangelix]

are the customizations.vscode.settings and customizations.vscode.extensions fields planned to be supported? I believe this is all that is needed for gitpod feature parity other than user-level environment variables which are unrelated to devcontainers.

@xangelix Couldn't you just use the dotfile capability that already exists to inject user level env vars among other things?

kind of, but also kind of not
a lot of the variables I'm thinking of would be user-level secrets that gitpod allows you to set in your user settings, similar to a CI/CD

afaik all of the secret management options in coder right now are not well suited to more ephemeral devcontainer/envbuilder templates

[Shocktrooper]

@xangelix If you can use a terraform datasource to grab secrets from an external system that could work. I plan to do that with hashicorp vault.

[ammario]

Let's take the OOM discussion to #8892