-
Notifications
You must be signed in to change notification settings - Fork 928
docs: add comprehensive dev containers documentation with examples #18582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
3506fa2
to
06d714c
Compare
cafacc7
to
cfcef3c
Compare
I had some trouble getting the example working with my barebones deployment, and I think it's because of the docker-in-docker requirement I'm going to have to come back for some more testing |
@@ -1,4 +1,4 @@ | |||
# Dev containers | |||
# Envbuilder Dev Containers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does it lead with Envbuilder
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to decide what to do with this set of docs - I re-titled them and made some quick changes to sections to be envbuilder-specific
we aren't removing envbuilder with this PR, so I want to strip these down as much as possible, but don't want to remove and redirect the docs just yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add some sort of notice to this page that users should pick the new devcontainer approach instead of envbuilder?
docs/admin/templates/extending-templates/dev-containers-envbuilder.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't quite get through everything, but here's some initial feedback.
1. In the `devcontainers-cli` module block, add: | ||
```terraform | ||
depends_on = [module.nodejs] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't have any success with depends_on
in my testing either
my goal was to ship this as a doc folks can use as a standalone, but that's going to have to come with a future iteration, so I'm going to remove the <details>
expand
|
||
```terraform | ||
resource "coder_devcontainer" "my-repository" { | ||
resource "coder_devcontainer" "project" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad you used the same name (project
) here and in the workspace folder. We should potentially call it out that this name is how users will be connecting to the devcontainer (e.g. ssh://project.<workspace>.me.coder
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to standardize the examples and configs we use so that someone using a combination of docs can have a linear/consistent experience. At some point, I think it'd be good to have a heavily commented set of examples that we can use both for teaching and for a docs style guide.
For now, I just added a comment on this line
base_dir = "/home/coder/project" | ||
} | ||
resource "coder_devcontainer" "project" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unfortunate folder_name
can't be used here. 😔 I'm really of two-minds using this for the sub-agent name when present but it is what it is.
We support devcontainer.json
customization to change the name on a per-project basis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't really have that documented, but I think we should def add it in the next iteration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adding: it would be great as part of or in addition to the Agent naming
section
|
||
### Disable dev containers integration | ||
|
||
To disable the dev containers integration in your workspace, add the `CODER_AGENT_DEVCONTAINERS_ENABLE` environment variable to your existing `coder_agent` block: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is incorrect, the env must be set before the agent is started, i.e. on the Docker container. We could potentially implement this behavior but it's currently not supported (/cc @DanielleMaywood thoughts?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed to
To disable the dev containers integration in your workspace, set the `CODER_AGENT_DEVCONTAINERS_ENABLE= "false"` environment variable.
moved to "ready for review" while I tech test the remaining examples |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm slightly concerned at how many things were subtly wrong and that I haven't caught them all.
```console | ||
coder ssh --container keen_dijkstra my-workspace | ||
coder ssh --container my-container-name my-workspace | ||
``` | ||
|
||
Remember to replace: | ||
|
||
- `my-container-name` with the dev container agent name. | ||
- `my-workspace` with your workspace's name. | ||
|
||
> [!NOTE] | ||
> | ||
> SSH access is not yet compatible with the `coder config-ssh` command for use | ||
> with OpenSSH. You would need to manually modify your SSH config to include the | ||
> `--container` flag in the `ProxyCommand`. | ||
> Starting with Coder v2.24.0, `coder config-ssh` works with dev containers. | ||
> If you’re using an older Coder version, add `--container <name>` to the | ||
> `ProxyCommand` entry in your SSH config. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this section could be worded better. It gives priority to the old pattern using a hidden CLI flag that was only made available during early access.
I believe we should instead focus entirely on how to do it with the current agent-based approach.
Coder automatically forwards any port declared in `appPort`, `forwardPorts`, | ||
or exposed by `docker-compose.yml`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct @mafredri?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, called this out in another section I believe.
|
||
## Rebuild prompt does not appear | ||
|
||
1. Confirm that you saved `devcontainer.json` (or changes to `devcontainer.local.json`) in the correct repo path detected by Coder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. Confirm that you saved `devcontainer.json` (or changes to `devcontainer.local.json`) in the correct repo path detected by Coder. | |
1. Confirm that you saved `devcontainer.json` in the correct repo path detected by Coder. |
## Rebuild prompt does not appear | ||
|
||
1. Confirm that you saved `devcontainer.json` (or changes to `devcontainer.local.json`) in the correct repo path detected by Coder. | ||
1. Run `coder devcontainer rebuild` manually. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This command does not exist.
@@ -9,8 +12,22 @@ If your dev container fails to start: | |||
- `/tmp/coder-agent.log` | |||
- `/tmp/coder-startup-script.log` | |||
- `/tmp/coder-script-[script_id].log` | |||
- `/tmp/devcontainer-build.log` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't exist.
1. `customizations.coder.name` in `devcontainer.json` | ||
1. Resource name used in terraform (`resource "coder_devcontainer" "name"`) | ||
1. Project directory name (name of folder containing `devcontainer.json` or `.devcontainer` folder) | ||
1. If project directory name is already taken, the name is expanded to include the parent folder (`/home/coder/some/project` -> `project` (taken) -> `some-project`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mafredri did that PR make it into the release? If so, this section is outdated with regards to naming using the terraform resource.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we now ignore the terraform resource name so we can remove this line:
1. Resource name used in terraform (`resource "coder_devcontainer" "name"`)
|
||
Choose the new integration if: | ||
|
||
- Your workspace image can run Docker (DinD, Sysbox, or a mounted Docker socket). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we should suggest a mounted Docker socket as an approach. It will cause issues with filesystems (cc @mafredri)
Envbuilder remains a solid choice when: | ||
|
||
- Docker isn’t available or allowed inside the workspace image. | ||
- The platform team wants tight control over container contents via Terraform. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this point makes sense
|
||
- Docker isn’t available or allowed inside the workspace image. | ||
- The platform team wants tight control over container contents via Terraform. | ||
- A single layered environment is sufficient (no need for separate sub-containers). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neither does this
## Troubleshooting | ||
|
||
1. Run `docker ps` inside the workspace to ensure Docker is available. | ||
1. Check `/tmp/startup.log` for agent logs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. Check `/tmp/startup.log` for agent logs. | |
1. Check `/tmp/coder-agent.log` for agent logs. |
Uh oh!
There was an error while loading. Please reload this page.