[Buildroot] [External] Re: [PATCH v1 1/1] package/nerdctl: new package

Matthew Weber matthew.weber at collins.com
Mon Mar 29 14:30:46 UTC 2021


Christian,

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...

Best Regards,
Matt


More information about the buildroot mailing list