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

31–40 of 132 posts

Re: The What, Why and How of Containers

#31

Post by chrisweekly »

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…

Slight tangent, but in the nodejs / npm ecosystem, that's one of the things that makes pnpm unique (and IMHO far superior to npm or yarn) -- its node_modules are deduped using symlinks.

Re: The What, Why and How of Containers

#32

Post by forgotmyinfo »

bayindirh wrote: post #24
otabdeveloper4 wrote: post #22

Earlier quoted context omitted.

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

Docker doesn't turn off the firewall, but rather hijacks and repurposes it for itself. It's not any nicer, but it's not the same thing in reality.

Docker punches holes in it:

>By default, all external source IPs are allowed to connect to the Docker host. To allow only a specific IP or network to access the containers, insert a negated rule at the top of the DOCKER-USER filter chain.

Yikes. Should people read the docs? Yes. Should Docker not do this? Also yes.

Re: The What, Why and How of Containers

#33

Post by pjc50 »

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…

Traditionally this is what /usr/lib is for.

Re: The What, Why and How of Containers

#34

Post by forgotmyinfo »

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 basically dynamic linking: you have foo.so sitting somewhere on disk, and multiple processes can just load it whenever. It can't be read-only, though; you need to add new libraries to that directory eventually.

Re: The What, Why and How of Containers

#35

Post by zer00eyz »

bayindirh wrote: post #4
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…

Disclaimer: I'm not a strong containerization proponent. The good part of containers is you isolating the thing you're running. I'm very against resource waste, but if I can spend 90MB on a container image instead of installing a complete software stack to run a task which is executed weekly and runs for 10 minutes, I'd prefer that. Plus, I can create a virtual network and storage stack around the container(s) if I n…

>>> To me, all that points at containers being in some way a solution to Dynamic linking. And maybe an over the top solution. ... Should we be doing more static linking? Not even depending on libc? What are the challenges with that?

>> but it's a ruby application and I need to install the whole stack of things, plus the gems. Instead I containerize it, and keep my system clean.

There was a bit of drama recently with the Bottles project and some Distro maintainers. With the Bottles devs saying "we only want the appimage as a distribution method".

I see containers as a means of distributing software. If that ruby app was a binary, then the container would become baggage.

Re: The What, Why and How of Containers

#37

Post by sevagh »

kqr wrote: post #7

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

[flagged]

Re: The What, Why and How of Containers

#38

Post by zer00eyz »

silverquiet wrote: post #10
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…

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.

If you have a go/rust/zig binary as your application do you need a container to run it?

Maybe, but it makes less sense at that point. If your doing Node/Ruby/Python/PHP then yes the container makes sense to drag your runtime to the server...

Do containers (docker) make sense for dev. Sure, to a point. Because our dev (win/Mac) might not look like our deploy (linux).... If we move to a standardized remote dev model then docker makes less and less sense.

>> It’s one I’ve asked before; have we just created a more elaborate statically-linked executable via containerization?

The bottles project only supports their app image, as they no longer want to be responsible for supporting the disttro maintained packaged version of their product.

Yes containers are becoming a way of dealing with linking, and dependency management. Its a blunt instrument for dealing with software packaging and distribution.

Re: The What, Why and How of Containers

#39

Post by forgotmyinfo »

sevagh wrote: post #37
kqr wrote: post #7

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

[flagged]

Grab a developer off the street and ask them how Docker works. Most of them will have no idea.

Re: The What, Why and How of Containers

#40

Post by dzonga »

something that is nice in the container world -- better than docker are lxc containers - but the steward of the project Canonical seem to have done a bad job with it. last time I played with lxc the ux was clunky.

if you could have the automation / configuration of docker / podman for lxc that would have been nice.

Post reply on HN