> To learn more about Envbuilder’s use cases and benefits, check out our introductory blog post here!
Envbuilder allows you to build development environments from a Dev Container on Docker and Kubernetes or OpenShift.
In this post, we’ll explore some examples. These examples assume you already have an existing dev container spec in the .devcontainer folder at the root of your project’s repository. If you don’t, check out VS Code’s Dev Containers Tutorial.
Vanilla Kubernetes
Quick example
Here is an example Kubernetes manifest that shows how to spawn a Pod from the Dev Container spec available in our envbuilder-starter-devcontainer repository and obtain an interactive Bash shell from it.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: workspaces-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
path: "/mnt/data" # Path on the node where the PersistentVolume's data will be stored, this is an example
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: workspaces-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: manual
---
apiVersion: v1
kind: Pod
metadata:
name: devcontainer
spec:
containers:
- name: devcontainer-main
image: ghcr.io/coder/envbuilder
env:
# URL to the repository where the .devcontainer folder we want to load is located
- name: ENVBUILDER_GIT_URL
value: "https://github.com/coder/envbuilder-starter-devcontainer"
# Sleep forever
- name: ENVBUILDER_INIT_SCRIPT
value: "sleep infinity"
volumeMounts:
- mountPath: /workspaces
name: workspaces-volume
volumes:
- name: workspaces-volume
persistentVolumeClaim:
claimName: workspaces-pvcAfter applying the manifest (e.g., via kubectl apply), you should be able to run kubectl exec --stdin --tty devcontainer -- bash to get a bash session.
Running Staging Environments in Dev Containers
Running your staging environment using Dev Containers can have multiple benefits.
The main advantage is having all the debugging tools you know and love ready to start debugging any issues that may arise in the staging environment.
Additionally, this approach helps identify and eliminate any bugs or issues that might be present in the Dev Container spec.
In this example, we’ll run an ephemeral web server using Deno, but you can easily modify this manifest to run the staging environment for your project.
1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Pod
metadata:
name: staging
spec:
containers:
- name: staging-main
image: ghcr.io/coder/envbuilder
env:
- name: ENVBUILDER_GIT_URL
value: "https://github.com/denoland/deno"
- name: ENVBUILDER_INIT_SCRIPT
value: "deno run --allow-net --allow-read jsr:@std/http/file-server"Caching
In both of these cases, the Dev Container will be built from scratch every time you start the pod, which is fine for prototyping but can become quite slow.
To speed up your builds, you can cache the layers of the image.
Using a Container Registry
Envbuilder supports caching layers in a container registry. To enable this, configure authentication to your registry and set the ENVBUILDER_ environment variable.
See the “Layer Caching” section in Envbuilder’s README for more information.
Using a Volume
Envbuilder also supports caching layers in a folder, but this method is only intended for testing. For production, it’s best to use a container registry.
You can mount a PersistentVolume to the Pod and pass its path in the ENVBUILDER_ environment variable.
Conclusion
Envbuilder streamlines the setup and management of development environments, making workflows more efficient and flexible. Whether for prototyping or production, it offers a powerful solution for modern development needs.
You can check out EnvBuilder on Github. Want a demo? Contact us.