Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The What, Why and How of Containers

annwan.me

Post reply on HN
Print view View original

91–100 of 132 posts

Re: The What, Why and How of Containers

#91

Post by forgotmyinfo »

zer00eyz wrote: post #59
palata wrote: post #18

Earlier quoted context omitted.

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.

Then there's probably a reason, like the changes haven't been tested yet or verified to make sure they don't FUBAR your machine. It's okay to go a little slower to ensure reliability. Plus, do you really want the latest bugs in HEAD anyway?

Re: The What, Why and How of Containers

#92

Post by watermelon0 »

Already__Taken wrote: post #6
adamgordonbell wrote: post #2

If 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.

In practice, dynamic linking might not be achiving that much in the sense of deduplication: https://drewdevault.com/dynlib.html

Re: The What, Why and How of Containers

#93

Post by nurple »

disconnect3d wrote: post #68

It's a nice blog post but it still misses a few important building blocks without which it would be trivial to escape a container running as root. Apart from chroot, cgroups and namespaces, the containers are also build upon: 1) linux capabilities - that split the privileges of a root user into "capabilities" which allows limiting the actions a root user can do (see `man 7 capabilities`, `cat /proc/self/status | grep…

Excellent info! I started head-deving a project similar to nix-snapshotter[0] and I was thinking "ok, I can probably just build CRI impl that builds a rootfs dir with nix and just shell out to bubblewrap to make a "container".

But once I went through that mental exercise I started reading code in containerd and cri-o. Wow, these are _not_ simple projects; containerd itself having a full GRPC-based service registry for driving dynamic logic via config.

One thing I was pretty disappointed about is how deeply ingrained OSI images are in the whole ecosystem. While you can replace almost all functional parts of runtime, but not really the concept of images. I think images are a poor solution to the problem they solve, and a big downside of this is a bunch of complexity in the runtimes trying to work around how images work (like remote snapshotters).

[0] https://github.com/pdtpartners/nix-snapshotter

Re: The What, Why and How of Containers

#94

Post by Zambyte »

mati365 wrote: post #14
Zambyte wrote: post #11

Unfortunately this skips over the history of microkernels, which solve the same problems in a much more elegant way than containers.

Can you elaborate?

The point of containers is to run a process in an isolated environment. Microkernels by design allow isolating any process with very fine grain control, by allowing or disallowing certain IPC connections for a given process. Those connections can be enabled or disabled for a running process as well, which would essentially be like moving a process in and out of a container while it is running. Individual processes can also run entirely isolated stacks for things like networking, storage, etc. in an unprivileged way. The former can be particularly painful to deal with in Linux containers.

Containers are basically monolithic kernels playing catching to the features designed into microkernel-based operating systems.

Re: The What, Why and How of Containers

#95

Post by sltkr »

ahepp wrote: post #76
sltkr wrote: post #30

Earlier 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…

Are you saying that two containers running the same image will share their common libraries in the host kernel's memory? Based on my understanding of cgroups, that seems unintuitive to me. Are you certain that's the case? I may try testing this out when I get a chance.

Yes. And even containers running different images will share the libraries so long as they come from shared layers.

Re: The What, Why and How of Containers

#96

Post by rdtsc »

nurple wrote: post #73
adamgordonbell wrote: post #61

Earlier quoted context omitted.

That all makes sense. But when those 100 binaries end up as 100 OCI images, and then to patch them you need to update those 100 OCI images to have the new version, it does seem like we've gone in a circle a bit. I mean, there are some advantages, if they all share the same base layer, maybe they share those libs at least on disk via a shared layer. But practically, though you are maybe not back where you started, you…

This^ This is one of the biggest issues with containers IMO. This and the layering system, which I think is poorly designed both to configure and to actually do the tasks it's meant to(build and delivery caching). The solutions to this problem in the space have basically been to provide scanners to crack open the containers and detect things with known vulnerabilities. But I have not seen (m)any solutions around thes…

It's like for a few years the whole computing world forgot about security updates and went on a container bender, when woke up one morning realizing what they've done, and then started adding various clunky solutions on top: mutable tags, various tooling to take apart container images and inspect the junk in there, notify and scan for issues etc.

Re: The What, Why and How of Containers

#97

Post by usrusr »

lioeters wrote: post #44
cwillu wrote: post #36

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.

> inventing ways to isolate code in a private machine Reminds me of how Alan Kay described OOP as communicating objects, where each object is a kind of computer. "I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages."

I keep wondering where we would be now if we had not spent a decade or two eagerly running down that lane, before reassessing the be all end all solution nature OOP promised encapsulation to be. Perhaps not as far as we are after doing the meandering that we did, I think OOP has contributed a lot to the post-OOP world we live in now. It's not gone, it has just been demoted from ideology to tool.

Re: The What, Why and How of Containers

#98

Post by jayd16 »

adamgordonbell wrote: post #2

If 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…

Containers are powerful because they solve many computing issues, one of which being able to act as a (lower case c) static container for dynamically linked apps as well as cross-language, multi-executable meta-apps.

Containers also provide many forms of isolation (network, file system etc.), they provide a modern versioning and distribution scheme, composibility (use another container as a base image).

All of these things can, and perhaps should be, done at a the language level as well but containers also work across languages, across linking paradigms, and with existing binaries.

Re: The What, Why and How of Containers

#100

Post by EraYaN »

prmoustache wrote: post #72
zer00eyz wrote: post #64

Earlier quoted context omitted.

>>> Good for them having wishes, yet free software doesn't work that way in most cases. :) Historically I would agree with you. But bottles, and the attitude of some upstream projects is one of "modern", "faster", "support the latest version only" ... Software devs who live in user space want a more "App Store" like delivery mechanism where they have control. The kernel is inclined to never break backwards compatibil…

Honestly I don't understand that obsession of developers with building and distributing binaries themselves. That is the less fun part. When I write something, I just release the source code and I let other do the non fun part for me. You just have to mention the dependencies and how to build and that's it.

Because it's easier to support, easier to answer bug reports and/or crash reports etc. And distros can now not mess up the build too much, which happens a lot with any sufficiently complicated piece of software. Besides your average user does not want to deal with building something like OBS or Ardour or any of these programs that have a ton of dependencies and no real unified package manager to install them.
Post reply on HN