Add nc edition with nerdctl included

[afbjorklund]

Also including containerd and buildkit

On distributions with systemd / glibc, those are normally installed by lima using nerdctl-full tarball

This new "nc" edition doesn't change any of the already existing editions, including "std" and "rd".

Closes #34

[jandubois]

I'm not sure what the status is here; please "request a review" if this PR is done now!

[afbjorklund]

I think that I was able to not "disturb" the normal images, and the basic commands seem to work.

I'm not sure it will be useful for the project, but it can be made available - similar to "k3s" edition ?

[afbjorklund]

Removing the CNI duplication and installing BuildKit from apk can be left as future "improvements" ?

[jandubois]

I was just looking through my "requested review" list, and found this PR on it. I somehow missed this before, or thought you were still tweaking it. Please let me know if you think it is ready for final review and merging (after moving the large heredoc to a separate file).

[afbjorklund]

Moved the script out

[afbjorklund]

I fixed the lima installation (of nerdctl) so that it works on alpine (without systemd), but this ISO could still be interesting ?

More of a case study (like k3s), for comparing relative sizes and what not. I don't think it needs to be verified by default etc

[afbjorklund]

If looking good, I will rebase

[afbjorklund]

I think you might need to upgrade alpine to get the new containerd ? Or maybe it will come in "updates" later.

Client:
 Version:   v0.16.0
 Git commit:    0ddaffd2ce304dd917267470883898feff9463dc

Server:
 containerd:
  Version:  v1.5.8
  GitCommit:    1e5ef943eb76627a6d3b6de8cd1ef6537f393a71

https://git.alpinelinux.org/aports/tree/community/containerd/APKBUILD?h=3.15-stable

pkgname=containerd pkgver=1.5.9

[afbjorklund]

Looks like adding nerdctl added +100M, which is half the size of the nerdctl-full "distribution" (200M)

157M    iso/alpine-lima-nc-3.14.3-x86_64.iso
52M iso/alpine-lima-std-3.14.3-x86_64.iso

195M    nerdctl-full-0.16.0-linux-amd64.tar.gz

[jandubois]

I think you might need to upgrade alpine to get the new containerd ? Or maybe it will come in "updates" later.

Yes, we need to upgrade alpine. I tried before, but ran into some issues (with openssh?), so postponed.

Is this necessary for this PR? Or does it make sense to merge it as-is? I'm confused again what the current status is.

[afbjorklund]

I think you might need to upgrade alpine to get the new containerd ? Or maybe it will come in "updates" later.

Yes, we need to upgrade alpine. I tried before, but ran into some issues (with openssh?), so postponed.

Is this necessary for this PR? Or does it make sense to merge it as-is? I'm confused again what the current status is.

It's not needed, once it is done the new version will follow automatically.

Just saw there was a minor difference, depending on "which" nerdctl...

Like if you install nerdctl with lima*, or if you use this nc iso.

* as in:

containerd:
  system: true
  user: false

It is the same situation with for instance Docker, depending on packaging...

If you get the .deb file from docker.com, or if you get the .deb from ubuntu.com

• https://docs.docker.com/engine/install/ubuntu/

• https://packages.ubuntu.com/docker.io

I call it the "vendor" package, or the "system" package ? Same goes for nerdctl.

---

Both versions are fine, if there are important updates they will be backported ?

So you can continue to use the older version, even if newer ones exists elsewhere.

I'm not sure what the ultimate goal here is, do we add it to the README like k3s ?

Or should these "alternative" editions be built, and added as examples to lima ?

I made this one for nerdctl, and the other one for podman. A docker one is trivial.

iso/alpine-lima-std-3.14.3-x86_64.iso

iso/alpine-lima-nc-3.14.3-x86_64.iso iso/alpine-lima-pm-3.14.3-x86_64.iso iso/alpine-lima-de-3.14.3-x86_64.iso

iso/alpine-lima-rd-3.14.3-x86_64.iso

But maybe it doesn't matter with many editions, if all done by automation anyway.

[jandubois]

But maybe it doesn't matter with many editions, if all done by automation anyway.

It doesn't really matter in terms of build resources; it is all automated. But it matters in terms of user confusion: the more editions we have, the harder it becomes to figure out which one to use.

My original intend was to create a toolkit, so users could fine-tune their own edition, and just create the configuration for editions that have actual use cases:

• min for the minimal version that boots and can be tested
• ci for testing the regular cloud-init path in lima
• std for what everyone uses by default in lima
• rd custom-tailored for Rancher Desktop (this repo was originally created for RD and later moved to lima-vm)

So I like have fine-grained LIMA_INSTALL_* options, but don't really want to define every conceivable edition.

I'm tempted to rather have a fat edition (better name suggestions welcome), that includes all of docker, nerdctl, podman, etc, and only include that in the pre-build set of ISOs.

Users can then always define and build a slimmed down edition on their own, but we have an image, that should work for them ready for download.

[afbjorklund]

Maybe "max" ? (Opposed to "min") But I think it would be more a testing version, so that the packages don't interfere too much.

The whole idea of the nerdctl/podman/docker editions was to have a slimmed-down ISO, but maybe leave those as configs ?

So I like have fine-grained LIMAINSTALL* options, but don't really want to define every conceivable edition.

I'm OK with leaving those install options that I tweaked a bit, and then making them better by providing apks upstream.

[afbjorklund]

I think I will do a new PR with just the options, and leave out the "editions" part.

LIMA_INSTALL_CONTAINERD LIMA_INSTALL_BUILDKIT

Probably wait until apk packages are available, for "nerdctl" and for "buildkit".