mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
docs: restructure dev container documentation (#21157)
Dev container admin docs were scattered across two locations: the Docker-based
integration under extending-templates/ and Envbuilder under managing-templates/.
There was no landing page explaining that two approaches exist or helping admins
choose between them.
This moves everything under admin/integrations/devcontainers/ with a decision
guide at the top. Dev containers are an integration with the dev container
specification, so integrations/ is a natural fit alongside JFrog, Vault, etc.
Stub pages remain at the original locations for discoverability.
New structure:
admin/integrations/devcontainers/
├── index.md # Landing page + decision guide
├── integration.md # Docker-based dev containers
└── envbuilder/
├── index.md
├── add-envbuilder.md
├── envbuilder-security-caching.md
└── envbuilder-releases-known-issues.md
Refs #21080
This commit is contained in:
Mathias Fredriksson
@@ -0,0 +1,145 @@
|
||||
# Add an Envbuilder template
|
||||
|
||||
A Coder administrator adds an Envbuilder-compatible template to Coder. This
|
||||
allows the template to prompt the developer for their dev container repository's
|
||||
URL as a [parameter](../../../templates/extending-templates/parameters.md) when they create
|
||||
their workspace. Envbuilder clones the repo and builds a container from the
|
||||
`devcontainer.json` specified in the repo.
|
||||
|
||||
You can create template files through the Coder dashboard, CLI, or you can
|
||||
choose a template from the
|
||||
[Coder registry](https://registry.coder.com/templates):
|
||||
|
||||
<div class="tabs">
|
||||
|
||||
## Dashboard
|
||||
|
||||
1. In the Coder dashboard, select **Templates** then **Create Template**.
|
||||
1. Use a
|
||||
[starter template](https://github.com/coder/coder/tree/main/examples/templates)
|
||||
or create a new template:
|
||||
|
||||
- Starter template:
|
||||
|
||||
1. Select **Choose a starter template**.
|
||||
1. Choose a template from the list or select **Devcontainer** from the
|
||||
sidebar to display only dev container-compatible templates.
|
||||
1. Select **Use template**, enter the details, then select **Create
|
||||
template**.
|
||||
|
||||
- To create a new template, select **From scratch** and enter the templates
|
||||
details, then select **Create template**.
|
||||
|
||||
1. Edit the template files to fit your deployment.
|
||||
|
||||
## CLI
|
||||
|
||||
1. Use the `template init` command to initialize your choice of image:
|
||||
|
||||
```shell
|
||||
coder template init --id kubernetes-devcontainer
|
||||
```
|
||||
|
||||
A list of available templates is shown in the
|
||||
[templates_init](../../../../reference/cli/templates.md) reference.
|
||||
|
||||
1. `cd` into the directory and push the template to your Coder deployment:
|
||||
|
||||
```shell
|
||||
cd kubernetes-devcontainer && coder templates push
|
||||
```
|
||||
|
||||
You can also edit the files or make changes to the files before you push them
|
||||
to Coder.
|
||||
|
||||
## Registry
|
||||
|
||||
1. Go to the [Coder registry](https://registry.coder.com/templates) and select a
|
||||
dev container-compatible template.
|
||||
|
||||
1. Copy the files to your local device, then edit them to fit your needs.
|
||||
|
||||
1. Upload them to Coder through the CLI or dashboard:
|
||||
|
||||
- CLI:
|
||||
|
||||
```shell
|
||||
coder templates push <template-name> -d <path to folder containing main.tf>
|
||||
```
|
||||
|
||||
- Dashboard:
|
||||
|
||||
1. Create a `.zip` of the template files:
|
||||
|
||||
- On Mac or Windows, highlight the files and then right click. A
|
||||
"compress" option is available through the right-click context menu.
|
||||
|
||||
- To zip the files through the command line:
|
||||
|
||||
```shell
|
||||
zip templates.zip Dockerfile main.tf
|
||||
```
|
||||
|
||||
1. Select **Templates**.
|
||||
1. Select **Create Template**, then **Upload template**:
|
||||
|
||||
|
||||
|
||||
1. Drag the `.zip` file into the **Upload template** section and fill out the
|
||||
details, then select **Create template**.
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
To set variables such as the namespace, go to the template in your Coder
|
||||
dashboard and select **Settings** from the **⋮** (vertical ellipsis) menu:
|
||||
|
||||
<Image height="255px" src="../../../../images/templates/template-menu-settings.png" alt="Choose Settings from the template's menu" align="center" />
|
||||
|
||||
## Envbuilder Terraform provider
|
||||
|
||||
When using the
|
||||
[Envbuilder Terraform provider](https://registry.terraform.io/providers/coder/envbuilder/latest/docs),
|
||||
a previously built and cached image can be reused directly, allowing dev
|
||||
containers to start instantaneously.
|
||||
|
||||
Developers can edit the `devcontainer.json` in their workspace to customize
|
||||
their development environments:
|
||||
|
||||
```json
|
||||
# …
|
||||
{
|
||||
"features": {
|
||||
"ghcr.io/devcontainers/features/common-utils:2": {}
|
||||
}
|
||||
}
|
||||
# …
|
||||
```
|
||||
|
||||
## Example templates
|
||||
|
||||
| Template | Description |
|
||||
|---------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Docker dev containers](https://github.com/coder/coder/tree/main/examples/templates/docker-devcontainer) | Docker provisions a development container. |
|
||||
| [Kubernetes dev containers](https://github.com/coder/coder/tree/main/examples/templates/kubernetes-devcontainer) | Provisions a development container on the Kubernetes cluster. |
|
||||
| [Google Compute Engine dev container](https://github.com/coder/coder/tree/main/examples/templates/gcp-devcontainer) | Runs a development container inside a single GCP instance. It also mounts the Docker socket from the VM inside the container to enable Docker inside the workspace. |
|
||||
| [AWS EC2 dev container](https://github.com/coder/coder/tree/main/examples/templates/aws-devcontainer) | Runs a development container inside a single EC2 instance. It also mounts the Docker socket from the VM inside the container to enable Docker inside the workspace. |
|
||||
|
||||
Your template can prompt the user for a repo URL with
|
||||
[parameters](../../../templates/extending-templates/parameters.md):
|
||||
|
||||
|
||||
|
||||
## Dev container lifecycle scripts
|
||||
|
||||
The `onCreateCommand`, `updateContentCommand`, `postCreateCommand`, and
|
||||
`postStartCommand` lifecycle scripts are run each time the container is started.
|
||||
This could be used, for example, to fetch or update project dependencies before
|
||||
a user begins using the workspace.
|
||||
|
||||
Lifecycle scripts are managed by project developers.
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Envbuilder security and caching](./envbuilder-security-caching.md)
|
||||
@@ -0,0 +1,25 @@
|
||||
# Envbuilder releases and known issues
|
||||
|
||||
## Release channels
|
||||
|
||||
Envbuilder provides two release channels:
|
||||
|
||||
- **Stable**
|
||||
- Available at
|
||||
[`ghcr.io/coder/envbuilder`](https://github.com/coder/envbuilder/pkgs/container/envbuilder).
|
||||
Tags `>=1.0.0` are considered stable.
|
||||
- **Preview**
|
||||
- Available at
|
||||
[`ghcr.io/coder/envbuilder-preview`](https://github.com/coder/envbuilder/pkgs/container/envbuilder-preview).
|
||||
Built from the tip of `main`, and should be considered experimental and
|
||||
prone to breaking changes.
|
||||
|
||||
Refer to the
|
||||
[Envbuilder GitHub repository](https://github.com/coder/envbuilder/) for more
|
||||
information and to submit feature requests or bug reports.
|
||||
|
||||
## Known issues
|
||||
|
||||
Visit the
|
||||
[Envbuilder repository](https://github.com/coder/envbuilder/blob/main/docs/devcontainer-spec-support.md)
|
||||
for a full list of supported features and known issues.
|
||||
@@ -0,0 +1,66 @@
|
||||
# Envbuilder security and caching
|
||||
|
||||
Ensure Envbuilder can only pull pre-approved images and artifacts by configuring
|
||||
it with your existing HTTP proxies, firewalls, and artifact managers.
|
||||
|
||||
## Configure registry authentication
|
||||
|
||||
You may need to authenticate to your container registry, such as Artifactory, or
|
||||
Git provider such as GitLab, to use Envbuilder. See the
|
||||
[Envbuilder documentation](https://github.com/coder/envbuilder/blob/main/docs/container-registry-auth.md)
|
||||
for more information.
|
||||
|
||||
## Layer and image caching
|
||||
|
||||
To improve build times, dev containers can be cached. There are two main forms
|
||||
of caching:
|
||||
|
||||
- **Layer caching**
|
||||
|
||||
- Caches individual layers and pushes them to a remote registry. When building
|
||||
the image, Envbuilder will check the remote registry for pre-existing layers
|
||||
These will be fetched and extracted to disk instead of building the layers
|
||||
from scratch.
|
||||
|
||||
- **Image caching**
|
||||
|
||||
- Caches the entire image, skipping the build process completely (except for
|
||||
post-build
|
||||
[lifecycle scripts](./add-envbuilder.md#dev-container-lifecycle-scripts)).
|
||||
|
||||
Note that caching requires push access to a registry, and may require approval
|
||||
from relevant infrastructure team(s).
|
||||
|
||||
Refer to the
|
||||
[Envbuilder documentation](https://github.com/coder/envbuilder/blob/main/docs/caching.md)
|
||||
for more information about Envbuilder and caching.
|
||||
|
||||
Visit the
|
||||
[speed up templates](../../../../tutorials/best-practices/speed-up-templates.md)
|
||||
best practice documentation for more ways that you can speed up build times.
|
||||
|
||||
### Image caching
|
||||
|
||||
To support resuming from a cached image, use the
|
||||
[Envbuilder Terraform Provider](https://github.com/coder/terraform-provider-envbuilder)
|
||||
in your template. The provider will:
|
||||
|
||||
1. Clone the remote Git repository,
|
||||
1. Perform a "dry-run" build of the dev container in the same manner as
|
||||
Envbuilder would,
|
||||
1. Check for the presence of a previously built image in the provided cache
|
||||
repository,
|
||||
1. Output the image remote reference in SHA256 form, if it finds one.
|
||||
|
||||
The example templates listed above will use the provider if a remote cache
|
||||
repository is provided.
|
||||
|
||||
If you are building your own Dev container template, you can consult the
|
||||
[provider documentation](https://registry.terraform.io/providers/coder/envbuilder/latest/docs/resources/cached_image).
|
||||
You may also wish to consult a
|
||||
[documented example usage of the `envbuilder_cached_image` resource](https://github.com/coder/terraform-provider-envbuilder/blob/main/examples/resources/envbuilder_cached_image/envbuilder_cached_image_resource.tf).
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Envbuilder releases and known issues](./envbuilder-releases-known-issues.md)
|
||||
- [Dotfiles](../../../../user-guides/workspace-dotfiles.md)
|
||||
@@ -0,0 +1,53 @@
|
||||
# Envbuilder
|
||||
|
||||
Envbuilder is an open-source tool that builds development environments from
|
||||
[dev container](https://containers.dev/implementors/spec/) configuration files.
|
||||
Unlike the [Dev Containers integration](../integration.md),
|
||||
Envbuilder transforms the workspace image itself rather than running containers
|
||||
inside the workspace.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> For most use cases, we recommend the
|
||||
> [Dev Containers integration](../integration.md),
|
||||
> which uses the standard `@devcontainers/cli` and Docker. Envbuilder is an
|
||||
> alternative for environments where Docker is not available or for
|
||||
> administrator-controlled dev container workflows.
|
||||
|
||||
Dev containers provide developers with increased autonomy and control over their
|
||||
Coder cloud development environments.
|
||||
|
||||
By using dev containers, developers can customize their workspaces with tools
|
||||
pre-approved by platform teams in registries like
|
||||
[JFrog Artifactory](../../jfrog-artifactory.md). This simplifies
|
||||
workflows, reduces the need for tickets and approvals, and promotes greater
|
||||
independence for developers.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
An administrator should construct or choose a base image and create a template
|
||||
that includes a `devcontainer_builder` image before a developer team configures
|
||||
dev containers.
|
||||
|
||||
## Devcontainer Features
|
||||
|
||||
[Dev container Features](https://containers.dev/implementors/features/) allow
|
||||
owners of a project to specify self-contained units of code and runtime
|
||||
configuration that can be composed together on top of an existing base image.
|
||||
This is a good place to install project-specific tools, such as
|
||||
language-specific runtimes and compilers.
|
||||
|
||||
## Coder Envbuilder
|
||||
|
||||
[Envbuilder](https://github.com/coder/envbuilder/) is an open-source project
|
||||
maintained by Coder that runs dev containers via Coder templates and your
|
||||
underlying infrastructure. Envbuilder can run on Docker or Kubernetes.
|
||||
|
||||
It is independently packaged and versioned from the centralized Coder
|
||||
open-source project. This means that Envbuilder can be used with Coder, but it
|
||||
is not required. It also means that dev container builds can scale independently
|
||||
of the Coder control plane and even run within a CI/CD pipeline.
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Add an Envbuilder template](./add-envbuilder.md)
|
||||
Reference in New Issue
Block a user