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

111–120 of 132 posts

Re: The What, Why and How of Containers

#111

Post by adamgordonbell »

nonameiguess wrote: post #102
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…

I haven't seen any other response mention it yet, but containers are also heavily used for web-exposed services in part because of address space and port contention. Network namespaces allow you to graft an overlay network onto your physical network in a relatively simple and easy way (not that it's actually easy, but networking never is). Otherwise, sure, nix can rewrite the RPATH in your ELF file to make it pull dy…

I think what you are saying is true, and my knowledge of networking is pretty slim.

But, to play along with my static linking thought-exercise: if you take a process and put it in a network namespace then is it a container? I wouldn't say it is. Container runtimes might have a nice interface for namespacing, but namespacing something doesn't make it a container.

I guess my thought experiment is if things are statically linked binaries and you had a way to run them with the control group and namespace settings you wanted, would the packaging aspect of containers add anything?

The elites don't want you to know it, but namespaces are just there for the taking. You can grab as many as you want. You can set the memory limit on any process with cgroups, no docker desktop required. :)

Anyways, just a thought experiment about how the industry sometimes seems to be going in a circle, in the fashion of the lady who swallowed a fly.

Re: The What, Why and How of Containers

#112

Post by akvadrako »

otabdeveloper4 wrote: post #22
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…

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

No they don't. Kubernetes doesn't usually use docker, nor does Redhat / Fedora come with docker, but podman.

Maybe you mean: "they always mean OCI images".

Re: The What, Why and How of Containers

#113

Post by moondev »

otabdeveloper4 wrote: post #22
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…

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

Except when they mean

containerd without docker crio lxc windows containers podman

Re: The What, Why and How of Containers

#114

Post by zinodaur »

kube-system wrote: post #108
zinodaur wrote: post #77

I'm still not sold on the "why" wrt kubernetes. I hate that my resource hog map reduce jobs run on the same kernel and contend for the same resources as my user facing live site service.

That is one of the reasons why. Containers share the kernel and system resources. When you want to start running a bunch of containers in a particular configuration, that's when you'd use a container orchestration tool like kubernetes to define how and where you want those containers to run across multiple systems. While you could schedule containers manually, or just run your application on VMs or hardware manually,…

I guess I would prefer "kubernetes but with VMs instead of containers". The overhead of running in a VM is not very high, and a hypervisor can restrict resource usage much more effectively - so that we could still bin pack map reduce jobs on the same machines as live site services

Re: The What, Why and How of Containers

#115

Post by kube-system »

zinodaur wrote: post #114
kube-system wrote: post #108

Earlier quoted context omitted.

That is one of the reasons why. Containers share the kernel and system resources. When you want to start running a bunch of containers in a particular configuration, that's when you'd use a container orchestration tool like kubernetes to define how and where you want those containers to run across multiple systems. While you could schedule containers manually, or just run your application on VMs or hardware manually,…

I guess I would prefer "kubernetes but with VMs instead of containers". The overhead of running in a VM is not very high, and a hypervisor can restrict resource usage much more effectively - so that we could still bin pack map reduce jobs on the same machines as live site services

If your kubernetes nodes are VMs then you can do both at the same time for different parts of your application.

Re: The What, Why and How of Containers

#116

Post by mikewarot »

Containers are a bad take on a solved problem. The problem was encountered, studied[0] and solved, decades ago.

During the Viet Nam conflict, the Air Force needed to plan missions with multiple levels of classified data. This couldn't be done with the systems of that era. This resulted in research and development of multi-level security, the Bell-LaPadula model[2], and capability based security[1].

Conceptually, it's elegant, and requires almost no changes in user behavior while solving entire classes of problems with minimal code changes. It's a matter of changing the default from all access to no access, all the way down to the kernel.

[0] https://csrc.nist.rip/publications/history/ande72.pdf

[1] https://en.wikipedia.org/wiki/Capability-based_security

[2] https://en.wikipedia.org/wiki/Bell%E2%80%93LaPadula_model

Re: The What, Why and How of Containers

#117

Post by c-hendricks »

forgotmyinfo wrote: post #82
magicalhippo wrote: post #42

Earlier quoted context omitted.

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

Right, but a piece of software having a distribution maintainer doesn't mean it will never have bugs, and if it's a container there's already much less risk of it breaking my system.

As for your second paragraph, that's very idealistic. Config can live in /var, /usr, /home, /usr/local, literally anywhere. I find it much nicer when all data / configuration for a piece of software is all self contained.

Re: The What, Why and How of Containers

#120

Post by tutfbhuf »

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…

You are right. If you put 100 dynamically linked binaries into 100 OCI images, then you have the same security issues all over again. As best practice, I would recommend using a container vulnerability scanner that can identify containers requiring updates (list CVEs). I think all major cloud providers have such a service available, and there are some free and open-source tools available, such as Trivy and Clair. It is also beneficial to use official container images that have frequent patches available for their base images. If you use a base image like 3.9-slim instead of 3.9.19-slim, you can, for example, pin your Python version to 3.9, but you get patches. But this again only works if you do not have a "FROM scratch" image with just a single fully static binary.
Post reply on HN