Puppy Linux Discussion Forum

I'm mildly curious about containers since for some use cases they will use far less computer resources than virtualisation with the likes of QEMU.

Had a quick try of Docker installed to my Zorin lite full installed laptop and worked fine - I was actually running a Fedora distro inside the docker container...

Interesting matter I came across is the Kubernetes no longer really supporting Docker, since doesn't need it... Turns out two components used by Docker, containerd and runc are separate and quite small components and Kubernetes can manage these directly, and not just that because there are alternatives that Kubernetes is happy to use to do the actual containerizing. Most all of them seem similar in using the likes of cgroups, namespaces and so on.

Of course, on this forum you can't think of containers without thinking also of the home-grown container-related distro on this forum easyOS. Now, I have no interest in weedogging easyOS from weedogit script point of view (it will of course work best using its own initrd), but just for my associated fun I manually did so to take a look at it. Funnily enough, most all upstream bigger distros are designed to flexibly support alternative initramfs to boot them and that makes them easy to boot with WDL initrd. Puppy distros, and EasyOS similarly, tend to be amongst the most difficult distros to boot with any initrd other than their own one - that's not a problem in reality because they work fine anyway, so no real need to WeeDog them. However it is nearly always possible, fun is fun, and a challenge sometimes a challenge. First hurdle with EasyOS is that it uses aufs built into its supplied kernel - that's usual with traditional Pups too, but traditional Pups, fortunately pretty much always supply overlayfs as a module. The EasyOS img I downloaded did not... That means I had to swap kernel and modules to something else to boot it with WDL initrd since WDL has always used overlayfs since it was first created around three and a half years ago.

Next barrier is that the easyOS busybox sysVinit calls up rc.sysinit script, which is relatively closely tied to matters already set up by EasyOS own initramfs (which I'm not using here since using WDL initrd...). Anyway, to cut long story short, I managed to get it to boot after a few mods to that script... Only major issue thus far is that the booted system refuses to connect to internet - tells me NetworkManager isn't running; maybe a dbus issue I don't know - haven't checked - and don't have time to take it further. But was fun!
EDIT: I am not sure what is needed to fix my NetworkManager issue, but doesn't matter since I managed to connect anyway using simple wiakwifi along with the related /etc/udhcpc/, /etc/wpa_supplicant/ and /usr/share/udhcpc/ folder scripts, taken out of KLV-Airedale, and busybox (posting from it now).
NOTE: Currently I just unsquashed easy.sfs and renamed the resulting squashfs-root uncompressed directory as 07squashfs-root so that is loaded as layer 07 by the overlayfs mount. I could of course use mksquashfs to make it a sfs instead if I wished (i.e. I am no longer using the shown easy.sfs file at all here, just the modified unsquashed 07squashfs-root version of it. The kernel/modules I used were also from KLV-airedale, which made it easy since that contains overlayfs in kernel
EDIT2: It is one thing to get it to boot, but a different matter to get containers working thereafter... I don't know how to - know nothing about it, and may well be that only easy's own initramfs sets things up such as that can work! Doesn't matter - was just a booting experiment anyway and not recommended more generally for this one...

But... as far as my container-related experiments go really, I actually instead plan to make a small WDL_jammy distro (like the 90MB iso I once made of WDL_focal), and to experiment with minimum installs of containerd and runc into that and perhaps Kubernetes. I know nothing about what I'll need yet since that docker experiment was first time I'm used containers, but I'm certainly interested in what I read about containerd - cross-platform and will share libs between containers when same ones needed - that will save a lot of resources! and potentially much more efficient I think than the likes of AppImages, Flatpaks, Snaps, and so on.

containerd is available as a daemon for Linux and Windows:
https://containerd.io/

containerd features: OCI Runtime Spec support (aka runc)
https://github.com/opencontainers/runc
or maybe (in C rather than Go and uses even less resources apparently):
https://github.com/containers/crun

Kubernetes containers docs:
https://kubernetes.io/docs/concepts/containers/

Possibility to share libs to different containers:
https://stackoverflow.com/questions/358 ... containers
https://dl.acm.org/doi/abs/10.1016/j.future.2019.03.049

Virtualization-Containers-Docker-Kubernetics are ALL tossed around with little overall user base knowledge. In Puppyland, it has gotten recent attention to assist the ability to quickly spin up "things" for users.

I am no expert, but have used various Virtualizations which includes these various forms of these for 5 decades (too many).

This opening post is a good write-up perspective.

I would like to draw reader attention to this SHORT video where it clearly and simply explains all of this and presents a clear indication where the industry is now turning to. The benefit is it making clearer what we have been seeing over the forum especially this year. As such it will dispel some of the mislabeling ("good/bad/light/hogs") of the varied technologies at our fingertips as it makes it easy to see what they do and what it should mean when we see the terms used in Puppyland.

Here's hoping members find this knowledge helpful.

Enjoy

@Clarity Thanks for that link. It was very informative.