Misses HP-UX Vault, Solaris Zones, Aix LPAR, and whatever IBM was doing with System 360 and MVS.
The What, Why and How of Containers
81–90 of 132 posts
Re: The What, Why and How of Containers
#82Earlier 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…
The benefit of waiting for maintainers to update your software is that you have a stronger guarantee that it won't break your system, or otherwise fubar something. Maintainers are the adults in the room saying "no, fix your shit" when sloppy developers release crap, which seems to be happening more and more frequently lately.
As for where configuration and data live, that's always available in the docs, and Linux convention puts stuff in /etc, so I'm not sure how containers help. And dynamic libraries are in a well-defined location, with environment variables and other tools that allow you to specify where they live. It's not like dynamic linking is an unsolved problem.
Re: The What, Why and How of Containers
#83Computing 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.
It is like the endless cycle of "microservices" since distributed computing was invented, after computer networks came to be.
Re: The What, Why and How of Containers
#84[deleted]
Re: The What, Why and How of Containers
#85Is there a guide around that teaches you to build a container from scratch with chroot, namespaces and cgroups?
This might be what you're looking for? IIRC it was written for the older cgroup (v1) sysfs interface, so you may need to cross reference it with the cgroup2 documentation
Re: The What, Why and How of Containers
#86If you use chroot to run something, it's interesting how the dynamic libs you need to get in place grows until you are mirroring a whole linux in a subtree. It gives you a sense for how you end up with containers. One thing that is wild to me is how nix solves this problem, of things needing to be linked together. It doesn't solve it with containers, but by rewriting the location of the links in the executable to be…
dynamic linking to me seems like solving a problem that filesystems should. deduplicating data.
Plugins have nothing to do with filesystems.
Re: The What, Why and How of Containers
#87Earlier quoted context omitted.
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.
In the same way a zip file is static linking, I guess, since Docker images are just tarred gzips. But .deb packages can include files and scripts that create directories, too.
Re: The What, Why and How of Containers
#88Earlier quoted context omitted.
No, because you can share common libraries across containers by putting them in a separate layer. For example, if you have a complex service that consists of multiple binaries all written in C++ using boost, then for each binary you can create a container that contains a layer of a base OS (shared), C++ libraries (shared), boost libraries (shared), application binary (unique). All the services can now share their com…
> All the services can now share their common libraries, both on disk and in memory, which reduces I/O and memory use. Wow, how is this possible using layers? How does docker handle it if I subsequently modify one of the files of my layer in my container?
A docker image consists of several layers, each of which contains only the modifications to the layers below it. Each layer and the final image is immutable. Docker uses OverlayFS to provide a unified view of the various layers.
A running container is based on an immutable image and a single writable layer. That writable layer is unique to the container which contains all modifications made to the immutable image by processes running in the container.
Docker relies on the immutability of layers to share them between containers. This is not much different from how regular Linux processes all share the readonly contents of binaries and libraries that they load, while each process has its own private heap space that is not shared with other processes.
That means that deleting a file from a base layer, either when building an image or at runtime from the container, doesn't actually modify the contents of that layer. It only adds a tombstone marker to the writable layer, that indicates the file was deleted, and OverlayFS creates the illusion that the file no longer exists inside that container.
(The flipside is that deleting files from immutable layers doesn't actually free up space because the actual file contents don't go anywhere, but that's rarely a problem.)
Re: The What, Why and How of Containers
#89Earlier quoted context omitted.
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.
Available in static linking via resource files.
Re: The What, Why and How of Containers
#90Earlier quoted context omitted.
Don't forget an endless cycle of inventing ways to make debugging and problem solving harder by adding isolation boundaries and complexity :)
Debugging Docker-anything makes me want to go into drywall, I swear.
Better than going into brick walls I guess