From ffae9d4288f737e5e0606ede0a7acf7615272620 Mon Sep 17 00:00:00 2001 From: Kazuyoshi Kato Date: Fri, 30 Aug 2019 13:20:16 -0700 Subject: [PATCH] Explain why do we need to have our own containerd binary Building a Go plugin is hard. Signed-off-by: Kazuyoshi Kato --- README.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 064cde69f..fffb8fb10 100644 --- a/README.md +++ b/README.md @@ -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 @@ -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).