Computing is an endless cycle of inventing ways to isolate code in a private machine, followed by inventing ways to make it easier for those machines to interoperate.
That's a wise statement.
The What, Why and How of Containers
51–60 of 132 posts
Re: The What, Why and How of Containers
#52Is there a guide around that teaches you to build a container from scratch with chroot, namespaces and cgroups?
[deleted]
Re: The What, Why and How of Containers
#53I wish I had read this article a decade ago. For many years I have been wondering "why the heck would I use containers when I have chroot, cgroups and namespaces?" Turns out that's exactly what containers are a packaging of! And I only found out about two years ago. Although this article doesn't go into it, the benefits I've found of using containers rather than rolling isolation by hand is that a lot of semi-standar…
> Turns out that's exactly what containers are a packaging of! Well, no. When people say "containers", they always mean "Docker". And Docker also comes with a daemon with full root permissions and ridiculous security policies. (Like, for example, forcefully turning off your machine's firewall, #yolo. WTF!) P.S. I actually run systemd-nspawn in production, but I am probably the only person on earth to do so.
> P.S. I actually run systemd-nspawn in production, but I am probably the only person on earth to do so.
You're not alone, systemd-nspawn is very much underrated. I have used it a lot for machine containers, though I'm using podman+quadlet+systemd more right now. systemd-nspawn with mkosi for generating workload images is still a nice & powerful ecosystem.
Re: The What, Why and How of Containers
#54I wish I had read this article a decade ago. For many years I have been wondering "why the heck would I use containers when I have chroot, cgroups and namespaces?" Turns out that's exactly what containers are a packaging of! And I only found out about two years ago. Although this article doesn't go into it, the benefits I've found of using containers rather than rolling isolation by hand is that a lot of semi-standar…
> Turns out that's exactly what containers are a packaging of! Well, no. When people say "containers", they always mean "Docker". And Docker also comes with a daemon with full root permissions and ridiculous security policies. (Like, for example, forcefully turning off your machine's firewall, #yolo. WTF!) P.S. I actually run systemd-nspawn in production, but I am probably the only person on earth to do so.
Perhaps I belong to the minority, but I really don't think about containers as Docker. Actually, I don't remember the last time I used Docker for anything. For the past several years, I've been using either Podman or systemd-nspawn, as yourself.
Re: The What, Why and How of Containers
#55Conceptually, I've come to think of containers as a kind of "known-good starting point", the origin of a coordinate system where "movement" is adding things. A set of Dockerfiles form a trie where each line of the Dockerfile is a node in that trie's branch. The great benefit of containers is that they allow you to reach any possible point in the space for a single process, without affecting any other. The other features of containers are, to me, secondary, things like container images, or even access or resource control. The main draw of the tool is giving the user a declarative way to move reliably and repeatedly through system-space, and to do so for any number of processes. (The main cost is the ~20% overhead such a system incurs).
Re: The What, Why and How of Containers
#56Computing is an endless cycle of inventing ways to isolate code in a private machine, followed by inventing ways to make it easier for those machines to interoperate.
Absolute. I feel like society goes through changes in a similar cyclic way. We, as humans, basically have a finite span of understanding and attention, and so, basically create cycles that are longer than that.
Re: The What, Why and How of Containers
#57Earlier quoted context omitted.
Grab a developer off the street and ask them how Docker works. Most of them will have no idea.
Considering my peers, same for system administrators/SRE/Operations people I'm the resident expert because I bothered to piece together "containers" = "applied namespaces"
I can't speak for anyone else, but I definitely feel like there's no time to actually learn about all of these tools before being thrown into them by management/other well-meaning ICs. The end result is everyone is using a tool they know nothing about, with predictable results.
Re: The What, Why and How of Containers
#58Earlier quoted context omitted.
> If you want to reuse the shared parts of binaries But aren't we, when we use OCI images as a packaging mechanism, using containers to essentially throw away that sharing and arrive at a complicated version of static linking, where everything dynamically linked is shipped with the program? Same goes for arguments about ease of patching things. When the software's package is actually an image, you are patching each i…
Someone did once joke that Docker is just static linking for millennials. I chuckle because there's a kernel of truth in there. ;)
Yeah, maybe, but the cute thing here is that docker also "statically links" the config files, history db, image directory, etc etc.
Re: The What, Why and How of Containers
#59Earlier quoted context omitted.
dynamic linking to me seems like solving a problem that filesystems should. deduplicating data.
They do more than that. For instance, they can be swapped easily. Think for instance a security library being updated by the distro security team. It also makes it easier to depend on an LGPL library, nicely allowing the users to modify the LGPL library without having to recompile your program.
>>> Think for instance a security library being updated by the distro security team.
And when your distro doesn't update? When the distro is slow to change?
Flatpak, Appimage, Snaps (why?)... upstream devs are bypassing distro maintainers in a lot of cases.
Re: The What, Why and How of Containers
#60Earlier quoted context omitted.
Funny - it looks like you’re being downvoted for asking what I think is a very natural question. It’s one I’ve asked before; have we just created a more elaborate statically-linked executable via containerization? In the end, Docker/OCI seems like the universal Linux package manager. I’m sure I don’t have the full picture since I’m far more ops than dev though.
For me as a mere user, wanting to run some homelab services, the main advantages to containers are that they make updates easier (don't need to wait for distro), and it makes it much clearer where configuration and data lives, easing backup and rollback by orders of magnitude. Static vs dynamic linking is an implementation detail as far as I'm concerned. If all the dynamic libs needed were in a well-defined location…
I think of myself as a mere user as well, though I manage the container system/orchestration for a small SaaS company as well (we're weirdos who use Swarm instead of Kubernetes) and agree with you regarding the management benefits.