How Containers Work: Building a Docker-like Container From Scratch
(labs.iximiuz.com)
from sanitation@lemmy.radio to programming@programming.dev on 02 May 13:32
https://lemmy.radio/post/13117243
from sanitation@lemmy.radio to programming@programming.dev on 02 May 13:32
https://lemmy.radio/post/13117243
#programming
threaded - newest
Holy shit, that’s pretty cool. Bookmarked!
Somehow this leads me to appreciate the simplicity of jails or virtualized network stacks in BSD.
Are there actual applications for just name spacing one thing rather than combining them all to create a container? Why design all these steps?
The short answer is that Linux did not approach namespacing from a holistic view, but rather introduced each one at the time when they were deemed useful individually or necessary. Meanwhile, the BSDs looked at what they had from UNIX (ie chroot) and then thought about the fullest logical extent of that idea. And in doing so, looked at every kernel interface and added support to namespace (or jail) them all.
Sure, BSD jails have had their own bugs over the years, but as a design, it’s an incredible testament to building a framework that was ahead of its time by focusing on the fundamentals.
To be clear, there are sometimes use-cases where Docker containers are ran without creating separate namespaces (eg sharing the host’s network namespace) but it’s rarer than the equivalent in BSD jails, where it’s a neutral choices between isolate or reuse namespaces. In that sense, Docker is lightly opinionated into defaulting to all-isolation and makes it hard to remove all the layers, if that’s your jam.
Thank you for weighing in. It sounds to me like Linux may be trying to be less opinionated on how these features are used.
The Linux kernel itself doesn’t really express an opinion – it’s a kernel, it enables you to do most things – but it’s Docker itself that imposes an opinion. And I say this after Docker Engine has basically delegated the runtime to containerd. At bottom, Docker has some serious baggage that needs to eventually be addressed, chiefly IMO the sorry state of networking.
What was done to make Docker usable initially has reared its ugly head a decade later, such as a focus on only supporting Legacy IP and NAT, with very little regard for IPv6. For example, Docker does do IPv6 today but only with NAT66 and zero support for DHCP6-PD upstream routing. This makes it incompatible to how actual v6 networks are set up, where NAT is neither desirable nor necessary. Docker’s idea of networking is so very 1990s that it’s genuinely stifling any improvements beyond the server/client TCP/UDP model.
All the meanwhile, Kubernetes is built atop sensible networking on Linux, and the BSDs have had solid networking primitives for decades. Linux is not the problem, IPv6 is not the problem, BSD is not the problem; it’s just Docker being stuck because of a lack of vision and too many users dependent on the existing behavior.
Credit where it’s due, Docker images defined as files and stores as artifacts in a central repository are a genuine innovation, and that’s precisely what BSD Bastille brings to BSD jails. So in 2026, where the OCI specification has genericized Docker images, anything that’s Docker-specific is slowly losing relevance.