Management
Before users can create a CVM-enabled workspace, a site manager must enable CVMs. To do so:
- Go to Manage > Admin > Infrastructure.
- Toggle the Enable Container-Based Virtual Machines option to Enable.
Customization
Once you've enabled CVMs, you can customize the behavior of your deployment and workspaces.
These settings will apply to workspaces after they have been rebuilt.
Default workspaces to CVMs
Once you've enabled CVMs, you can control whether all new workspaces should be built as a CVM or not.
If you would like all newly created workspaces to be CVMs, toggle Default to container-based virtual machines to On.
While this toggle changes the default workspace creation setting, users can still override this setting. For example, if you enable CVMS and set them as the default, a user can still create non-CVM workspaces (and vice versa).
Caching
To improve the startup time for CVM-based workspaces, you can enable caching.
Cached CVMs require the shiftfs kernel to be present on the node. Some
distributions (such as Ubuntu) include shiftfs. If you're unsure if shiftfs
is present on your nodes, you can check by running modinfo shiftfs. If no
output is returned, you do not have shiftfs installed.
If you don't want to install shiftfs yourself, you can have Coder install the
module automatically for you. It is important that you do not have secure boot
enabled and that you have the kernel headers installed if you want Coder to
install shiftfs on your behalf.
GPUs are not supported with cached CVMs at this time.
Self-contained workspace builds
By default, Coder initializes workspaces by running commands inside the
container. Workspaces, however, control the initialization sequence instead when
you enable self-contained workspace builds. This enables cluster operations
that restrict command execution inside containers using the Kubernetes API, such
as the kubectl exec command.
Workspace process logging
Workspace process logging enables auditing of commands executed inside the workspace container.
TUN device
Coder allows the creation of custom network interfaces using the Linux TUN
device. When using the Enable TUN device setting, Coder workspaces will have
a /dev/net/tun device mounted into the workspace at build time. VPN usage
often requires a TUN device.
Users may need root (or sudo) access within their workspace to use the TUN
device and start a VPN client.
At this time, Coder does not support TUN devices for non-Kubernetes workspace types, such as EC2 or Docker.
If you're working with EC2 workspaces, we recommend enabling privileged mode in the workspace provider settings, which will allow users to create their own TUN device.
We've tested this feature using the Tailscale VPN within Coder. Remember that you may have to change your VPN settings to keep any persistent files (such as configuration/identity) files in your home volume, as any data outside the home volume is cleared when the workspace is rebuilt.
FUSE device
Coder allows the creation of custom filesystems using the Linux FUSE userspace
filesystem device. By enabling the Enable FUSE device setting, Coder
workspaces will have a /dev/fuse device mounted into the workspace at build
time. These devices are often used to mount specialized filesystems, such as
Google Cloud Storage buckets, to your workspace.
Users may need root (or sudo) access within their workspace to use the FUSE
device and start a FUSE filesystem.
At this time, Coder does not support FUSE devices for non-Kubernetes workspace types, such as EC2 or Docker.
If you're working with EC2 workspaces, we recommend enabling privileged mode in the workspace provider settings, which will allow users to create their own FUSE device.
For example, you can mount a directory from a remote SSH server using sshfs:
mkdir /tmp/mnt
sshfs user@host:/ /tmp/mnt
Then, in a second terminal, run ls /tmp/mnt to list the files from the remote
host. You should also be able to see a fuse.sshfs entry in the output from the
mount command.