Runtime: experiment using containerd runtime or containerd/cgroups vs syscalls to isolate user code

[camerondurham]

Look into using containerd/containerd as a container runtime to run processes or using containerd/cgroups to enforce limits instead of Linux syscall setrlimit : https://github.com/camerondurham/runner/blob/9cc6b646cb85552122482783d44008383ea14966/engine/runtime/limits.go#L33

An example of using cgroups instead of resource limits could be setting the pids cgroup value to the proc limit (see the containerd/cgroups repo for what this library can do for cgroups, specifically: https://github.com/containerd/cgroups#create-a-new-cgroup).

Related links:

• containerd: Getting Started
• RedHat: cgroups
• Linux cgroup man pages

Note:

This will likely require setting up a custom Linux VM as these tools cannot be tested in a container. We'd have to adjust the project's deployment strategy accordingly to pursue these alternate libraries/runtimes.

This does not have to be limited to containerd. We can explore other container runtimes besides this, including Docker itself. Ideally using containerd would be preferred since it is a lower level runtime that can expose more customization for us. Docker is really meant for users and dev experience and has many extra features we don't need such as image building included in the Docker daemon.

AC:

If containerd is a good fit:

• determine dependencies required to run a containerd daemon
• create Ansible/Vagrant or some automated configuration to run containerd
• write module to start daemon and execute code in containers

If containerd is not a good fit:

• decide on syscalls and security strategy that our runtime should use