Skip to content
This repository has been archived by the owner on Dec 7, 2023. It is now read-only.

docs: FAQ updates related to Docker runtime #880

Open
jhult opened this issue Oct 25, 2021 · 0 comments
Open

docs: FAQ updates related to Docker runtime #880

jhult opened this issue Oct 25, 2021 · 0 comments
Labels
documentation/out-of-date Address that some docs are out of date

Comments

@jhult
Copy link
Contributor

jhult commented Oct 25, 2021

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

Docker, currently the only available container runtime usable by Ignite, is used for a couple of reasons:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

@darkowlzz darkowlzz added the documentation/out-of-date Address that some docs are out of date label Oct 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation/out-of-date Address that some docs are out of date
Projects
None yet
Development

No branches or pull requests

2 participants