Skip to content

Explain why do we need to have our own containerd binary #254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 30, 2019
Merged

Explain why do we need to have our own containerd binary #254

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,11 +37,12 @@ Firecracker microVMs to run containers:
gRPC proxy plugin. We currently have two implementations of a snapshotter: a
[naive](snapshotter/cmd/naive) copy-ahead implementation and a
[devmapper-based](snapshotter/cmd/devmapper) copy-on-write implementation.
* A [control plugin](../firecracker-control) managing the lifecycle of the
runtime and implementing our [control API](../proto/firecracker.proto) to
manage the lifecycle of microVMs. The control plugin is compiled in to the
containerd binary, which requires us to build a specialized containerd binary
for firecracker-containerd.
* A [control plugin](firecracker-control) managing the lifecycle of the
runtime and implementing our [control API](proto/firecracker.proto) to
manage the lifecycle of microVMs. The control plugin is compiled in to the
containerd binary since [building a Go plugin out-of-tree is hard](https://github.com/golang/go/issues/20481),
which requires us to build a specialized containerd binary for
firecracker-containerd.
* A [runtime](runtime) linking containerd (outside the microVM) to the
Firecracker virtual machine monitor (VMM). The runtime is implemented as an
out-of-process
Expand All @@ -53,7 +54,7 @@ Firecracker microVMs to run containers:
* A [root file filesystem image builder](tools/image-builder) that
constructs a firecracker microVM root filesystem containing runc and
the firecracker-containerd agent.

For more detailed information on the components and how they work, see
[architecture.md](docs/architecture.md).

Expand Down