As a platform administrator, you have the option to enable Container-based Virtual Machines as an Environment deployment option. This option allows users to run system-level programs inside their Environment including Docker and systemd.
Navigate to Manage > Admin > General to enable this option.
5.4(released Nov 24th, 2019).
hostPathmounts. Read more about why this is still secure here.
Coder first launches a supervising container with privileged. This container is standard and included as part of the Coder release package. As part of the Environment build process, the supervising container launches an inner container using the sysbox container runtime. This inner container is the user’s Environment. The user cannot gain access to the supervising container at any point during the lifecycle of their Environment. The isolation between the user’s Environment container and it’s outer, supervising container is what provides strong isolation.
During Environment startup, Coder checks for the presence of
the Environment Image. If the file exists, it's used as the container entrypoint
PID of 1. If your image OS distribution does not link the
/sbin/init, you'll need to do this manually in your Dockerfile.
The following snippet demonstrates how an image can specify
systemd as the
FROM ubuntu:20.04 RUN apt-get update && apt-get install -y \ build-essential \ systemd # use systemd as the init RUN ln -s /lib/systemd/systemd /sbin/init
Be sure to install the
docker packages into your Environment Image. For a
seamless experience, use systemd and register the
dockerd is automatically run during initialization.
The following snippet demonstrates how an image can register the
service in its Dockerfile.
FROM ubuntu:20.04 RUN apt-get update && apt-get install -y \ build-essential \ git \ bash \ docker.io \ curl \ sudo \ systemd # Enables Docker starting with systemd RUN systemctl enable docker # use systemd as the init RUN ln -s /lib/systemd/systemd /sbin/init