Docker, currently the only available container runtime usable by Ignite, is used for a couple of reasons:
Running long-lived processes: At the very early Ignite PoC stage, we tried to run the Firecracker
process under systemd, but this was in many ways suboptimal. Attaching to the serial console, fetching
logs, and 2. and 3. were very hard to achieve. Also, we'd need to somehow install the Firecracker binary
on host. Packaging everything in a container, and running the Firecracker process in that container was a
natural fit.
Sandboxing the Firecracker process: Firecracker should not be run on host without sandboxing, as per
their security model.
Firecracker provides the jailer
binary to do sandboxing/isolation from the host for the Firecracker process, but a container does this
equally well, if not better.
Container Networking: Using containers, we already know what IP to give the VM. We can integrate with
e.g. the default docker bridge, docker's libnetwork in general, or CNI.
This reduces the amount of scope and work needed by Ignite, and keeps our implementation lean. It also directly
makes Ignite usable alongside normal containers, e.g. on a host running Kubernetes Pods.
OCI compliant operations: Using an existing container runtime, we do not need to implement everything
from the OCI spec ourselves. Instead, we can re-use functionality from the runtime, e.g. pull, create,
and export.
All in all, we do not want to reinvent the wheel. We reuse what we can from existing proven container tools.
This section seems outdated (specifically in regards to Docker being the only available runtime): https://github.com/weaveworks/ignite/blob/main/docs/FAQ.md#q-why-is-docker-containers-neededused