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

71–80 of 132 posts

Re: The What, Why and How of Containers

#71

Post by ahepp »

If this struck your interest, but you want more nitty gritty examples and details, you may find the following article interesting: https://ericchiang.github.io/post/containers-from-scratch/

If I'm remembering correctly from when I ran through the instructions at home, it was written for the original cgroup sysfs interface rather than the more modern cgroup2 [0]. You can figure out which you're running with

> mount | grep cgroup > cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)

which turns the examples is a nice "check your understanding"

[0]: https://docs.kernel.org/admin-guide/cgroup-v2.html#basic-ope...

Re: The What, Why and How of Containers

#72

Post by prmoustache »

zer00eyz wrote: post #64
bayindirh wrote: post #50

Earlier quoted context omitted.

> Bottles devs saying "we only want the appimage as a distribution method". Good for them having wishes, yet free software doesn't work that way in most cases. :) > I see containers as a means of distributing software That's OK. Docker is a tool, and tools can be held and used in many ways.

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

Re: The What, Why and How of Containers

#73

Post by nurple »

adamgordonbell wrote: post #61
tutfbhuf wrote: post #48

Earlier quoted context omitted.

One issue with static linking is that your dependencies will likely have critical CVEs over time. If you keep all your libraries separate on the filesystem, you can just do a "apt update; apt upgrade", and you will have all the latest patches. This will patch security issues in e.g. libssl or libc for all your applications that are dynamically linked against this shared libraries, which can be quite a few. In static…

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 these scanners to facilitate the lifecycle of landing fixes.

Even if you provided a tree of a-proved base containers for each deployment lang in your org, you can't just update the base and deploy the world, there's not even tooling to automate working over the "FROM hierarchy" of images where you could detect which need to use new bases.

Because of the difficulty in managing large container hierarchies, in some orgs the later drives a common methodology of making image tags mutable, i.e. `ruby:myorg-v2`, which makes the FROM more like a dynamic link reference that gets updated automatically on the next build. I view this workaround as a regression brought on by the _still_ incredibly poor and complex SDLC tooling around managing images.

Re: The What, Why and How of Containers

#74

Post by ahepp »

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.

Deduplication, in the sense of physical space reduction, seems like the least strong argument one could make for dynamic linking these days.

The strongest argument I can think of, is enabling system managers (distro maintainers, even end users) to update dependencies. This might be to apply a security patch, enable some kind of tracing for profiling an application, and so on.

Re: The What, Why and How of Containers

#75

Post by forgotmyinfo »

cjk2 wrote: post #69
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.

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.

Re: The What, Why and How of Containers

#76

Post by ahepp »

sltkr wrote: post #30
adamgordonbell wrote: post #19

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

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.

Re: The What, Why and How of Containers

#78

Post by FuriouslyAdrift »

palata wrote: post #20
mati365 wrote: post #14

Earlier quoted context omitted.

Can you elaborate?

I'd love to get more details, too. Sounds interesting!

Probably referring to library operating systems and making a unikernel instead of a shared kernel container.

https://www.sigarch.org/leave-your-os-at-home-the-rise-of-li...

Re: The What, Why and How of Containers

#79

Post by nurple »

brabel wrote: post #8
Already__Taken wrote: post #6

Earlier quoted context omitted.

dynamic linking to me seems like solving a problem that filesystems should. deduplicating data.

That's an interesting way to look at it. If all dynamic libs lived on a read-only location, then the file system could actually only store the libs in one place and the other "copies" would be just symlinks to that... and when the OS loaded such lib, it would automatically know that despite being in different locations, the libs were the same (they're all symlinks to the same place). Is this something that has been a…

This is exactly how nix works, except instead of symlinks it actually modifies the binaries at buld-time to point its dynamic library paths to absolute paths in the store which includes a source-derived hash in place of a version.
Post reply on HN