Message ID | 20210323051027.91385-1-christian@paral.in |
---|---|
State | Superseded |
Headers | show |
Series | [v1,1/1] package/nerdctl: new package | expand |
Christian, On Tue, Mar 23, 2021 at 12:11 AM Christian Stewart <christian@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)) I saw the other RFC as well for renaming docker-containerd to containerd, that makes sense to me as the containerd runtime stands alone and this would make any dependencies cleaner with no reference to docker-*. Matt
Hi Matthew, On Tue, Mar 23, 2021 at 5:59 AM Matthew Weber <matthew.weber@collins.com> wrote: > > Christian, > > On Tue, Mar 23, 2021 at 12:11 AM Christian Stewart <christian@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. 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. 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). > > I saw the other RFC as well for renaming docker-containerd to > containerd, that makes sense to me as the containerd runtime stands > alone and this would make any dependencies cleaner with no reference > to docker-*. Yeah, docker-containerd should be renamed to containerd. While it originally was part of Docker, it's now a standalone project with multiple downstream consumers. Best regards, Christian Stewart
Christian, On Fri, Mar 26, 2021 at 12:12 AM Christian Stewart <christian@paral.in> wrote: > > Hi Matthew, > > On Tue, Mar 23, 2021 at 5:59 AM Matthew Weber <matthew.weber@collins.com> wrote: > > > > Christian, > > > > On Tue, Mar 23, 2021 at 12:11 AM Christian Stewart <christian@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
Hi Matthew, On 2021/3/29 下午10:30, Matthew Weber via buildroot wrote: > Christian, > > On Fri, Mar 26, 2021 at 12:12 AM Christian Stewart <christian@paral.in> wrote: >> Hi Matthew, >> >> On Tue, Mar 23, 2021 at 5:59 AM Matthew Weber <matthew.weber@collins.com> wrote: >>> Christian, >>> >>> On Tue, Mar 23, 2021 at 12:11 AM Christian Stewart <christian@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... You can try balenaEngine, which comes from balenaOS, by selecting BR2_PACKAGE_BALENA_ENGINE. Currently, it is a fork of Moby 19.03. Best regards, Tian, Yuanhao
diff --git a/package/Config.in b/package/Config.in index d278e78b68..696d479267 100644 --- a/package/Config.in +++ b/package/Config.in @@ -2456,6 +2456,7 @@ menu "System tools" source "package/monit/Config.in" source "package/multipath-tools/Config.in" source "package/ncdu/Config.in" + source "package/nerdctl/Config.in" source "package/netifrc/Config.in" source "package/numactl/Config.in" source "package/nut/Config.in" diff --git a/package/nerdctl/Config.in b/package/nerdctl/Config.in new file mode 100644 index 0000000000..6c07a62128 --- /dev/null +++ b/package/nerdctl/Config.in @@ -0,0 +1,24 @@ +config BR2_PACKAGE_NERDCTL + bool "nerdctl" + depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS + depends on BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS + depends on BR2_TOOLCHAIN_HAS_THREADS + depends on !BR2_TOOLCHAIN_USES_UCLIBC # containerd + depends on BR2_USE_MMU # util-linux + select BR2_PACKAGE_DOCKER_CONTAINERD # containerd runtime dependency + select BR2_PACKAGE_RUNC # containerd runtime dependency + select BR2_PACKAGE_UTIL_LINUX # runtime dependency + select BR2_PACKAGE_UTIL_LINUX_BINARIES # containerd + select BR2_PACKAGE_UTIL_LINUX_PIVOT_ROOT # containerd + select BR2_PACKAGE_UTIL_LINUX_MOUNTPOINT # containerd + select BR2_PACKAGE_UTIL_LINUX_MOUNT # containerd + help + Docker-compatible CLI for containerd, controlling runc. + + https://github.com/containerd/nerdctl + +comment "nerdctl needs a glibc or musl toolchain w/ threads" + depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS + depends on BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS + depends on BR2_USE_MMU + depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_TOOLCHAIN_USES_UCLIBC diff --git a/package/nerdctl/nerdctl.hash b/package/nerdctl/nerdctl.hash new file mode 100644 index 0000000000..1d2f540940 --- /dev/null +++ b/package/nerdctl/nerdctl.hash @@ -0,0 +1,3 @@ +# Computed locally +sha256 6c2f2cbc70703fed49a0b77a7c0823ad870b9a7b341bfd2a547ae833f24cd921 nerdctl-0.7.2.tar.gz +sha256 4bbe3b885e8cd1907ab4cf9a41e862e74e24b5422297a4f2fe524e6a30ada2b4 LICENSE diff --git a/package/nerdctl/nerdctl.mk b/package/nerdctl/nerdctl.mk new file mode 100644 index 0000000000..a50b6c49bc --- /dev/null +++ b/package/nerdctl/nerdctl.mk @@ -0,0 +1,26 @@ +################################################################################ +# +# nerdctl +# +################################################################################ + +NERDCTL_VERSION = 0.7.2 +NERDCTL_SITE = $(call github,containerd,nerdctl,v$(NERDCTL_VERSION)) +NERDCTL_LICENSE = Apache-2.0 +NERDCTL_LICENSE_FILES = LICENSE + +NERDCTL_GOMOD = github.com/containerd/nerdctl +NERDCTL_LDFLAGS = \ + -X $(NERDCTL_GOMOD)/pkg/version.Version=$(NERDCTL_VERSION) + +# pkg-golang does not support main.go at the root of the project +define NERDCTL_BUILD_CMDS + cd $(@D); \ + $(HOST_GO_TARGET_ENV) \ + $(NERDCTL_GO_ENV) \ + $(GO_BIN) build -v $(NERDCTL_BUILD_OPTS) \ + -o $(@D)/bin/nerdctl \ + $(NERDCTL_GOMOD) +endef + +$(eval $(golang-package))