[Buildroot] [External] Re: [PATCH v1 1/1] package/nerdctl: new package
matthew.weber at collins.com
Mon Mar 29 14:30:46 UTC 2021
On Fri, Mar 26, 2021 at 12:12 AM Christian Stewart <christian at paral.in> wrote:
> Hi Matthew,
> On Tue, Mar 23, 2021 at 5:59 AM Matthew Weber <matthew.weber at collins.com> wrote:
> > Christian,
> > On Tue, Mar 23, 2021 at 12:11 AM Christian Stewart <christian at paral.in> wrote:
> > >
> > > nerdctl is a CLI for containerd (package docker-containerd) which is drop-in
> > > compatible with the Docker Daemon CLI.
> > By chance, do you have any rough estimates on the size difference
> > between the set of GOLang executables between a pure Docker solution
> > and a containerd+ nerdctl? (If I remember correctly Docker was
> > 200-300MB (engine+CLI))
> According to "graph-size":
> - docker-engine: 49MB
> - docker-cli 39MB
> - docker-containerd: 66MB
> - nerdctl: 19.3MB
> So, the savings would be around ~70MB.
Nice, (sort of related) I've been gathering some rough metrics to try
and baseline what a Buildroot container runtime for a Kubernetes edge
device might expect for resource demands on storage/memory/processing.
Ie. containerd+runc vs CRI-O+crun(~300k). The footprint today using
Docker as a runtime is just too large when you also include the
Kubernetes (static) binaries and the resulting CNI containers after
joining a cluster.
> I believe docker-engine and docker-containerd are both much larger
> than they have any right to be at the moment, and can probably be
> minimized to something much smaller by deleting dependencies to
> kubernetes repos, cloud provider libraries, and other features
> probably most Buildroot users don't need.
Or we add some other options which may be better suited to embedded?
> One way to save space would be a "busybox" approach where there are
> multiple symlinks to a single Go binary to implement both
> docker-container, docker-cli, runc, etc. This way the common
> dependencies (i.e. OCI interfaces) are shared between binaries
> (admittedly this is what dynamic linking normally is for).
Oh interesting, is there any precedence for this approach in other
distros? Go binaries are just BIG with all the debug + static
linking.... However, they are pretty portable...
More information about the buildroot