Containers are tents • Hacker News Board

Re: Containers are tents

#101

Post by rualca » Sat, Jun 12, 2021, 7:50 PM UTC

catlifeonmars wrote: post #94

rualca wrote: post #50

Earlier quoted context omitted.

> Exactly! I don’t see this as a criticism of containerization so much as it is a praise of static linking. Not really. It seems the keyword "static linking" is being abused to refer to stand-alone executables, because that's what some people know. Yet, calling containers a kind of "static linking" is simplistic and incorrect, even taking the standalone executable interpretation info account. If anything, container i…

> More importantly, containers are designed to be both ephemeral and support multiple instances running in parallel on the same machine. This sounds a lot like how all os processes work (regardless of linking type of a binary).

You don't create persistent file system mounts by launching a process, nor do you mount files into the process's file system.

Re: Containers are tents

#102

Post by catlifeonmars » Sat, Jun 12, 2021, 9:12 PM UTC

rualca wrote: post #99

catlifeonmars wrote: post #96

Earlier quoted context omitted.

In practice, I think the analogy holds up. A sizable chunk of use cases for containerization is to confer the benefits of standalone executableness, which is similar to a sizable chunk of use cases for statically linked binaries.

> A sizable chunk of use cases for containerization is to confer the benefits of standalone executableness, No, not really. Just because in the end you get to run an application that does not mean that it's reasonable to explain thins in terms of static linking. This broken metaphor is particularly counterproductive once you take into account that container images also provide you the tools to bundle interpreters, ru…

Yes those are things you can do with containers. I don’t get your point. It’s not like a said containers are only useful for bundling dependencies.

As an aside, I think we’re approaching the concept from two different perspectives. I’m working backwards from a (sub)set of use cases, while you appear to be working forwards from a set of capabilities. I think both approaches have their place.

Re: Containers are tents

#103

Post by djmetzle » Sun, Jun 13, 2021, 4:09 PM UTC

tptacek wrote: post #3

That's a valid way to look at it, but there are other ways. Containers are also a simple, practical way to bundle applications and their dependencies in a relatively standardized way, so they can be run on different compute fabrics. That sense of the term isn't loaded with any specific notion of how attack surfaces should work. I think modern "Docker"'s security properties are underrated†. But you still can't run mul…

> I think modern "Docker"'s security properties are underrated†

100% agree.

The docker/CRI-de-jour (by default) strips off many "dangerous" system capabilities. By default a pid on linux gets something like over one hundred system capabilities, and most container runtimes strip that down to around 50. Those number are not exact.

Stripping down the system level capabilities of your workload is assuredly a security improvement over running that workload "bare metal" on the system.

Ref: https://www.redhat.com/en/blog/secure-your-containers-one-we...

Re: Containers are tents

#104

Post by otabdeveloper4 » Sun, Jun 13, 2021, 6:54 PM UTC

amarshall wrote: post #80

otabdeveloper4 wrote: post #76

Earlier quoted context omitted.

> Just add a Kernel and bootloader and one can boot most images. Certainly not true of any of the images I work with.

What sort of images are you working with? I can fairly straightforwardly boot debian:stable with no modifications to the image using direct kernel boot. Is everything perfect? No, but it does boot.

None of my images bundle a Linux distribution.

(Indeed, most don't even bundle bash or coreutils.)

Re: Containers are tents

#105

Post by srg0 » Sun, Jun 13, 2021, 10:17 PM UTC

If VM is like a nuclear war bunker, containers are like brick and mortar houses. They are not air tight and have glass windows which can be easily broken, but that's where most people live. They're cheaper to build, comfortable enough, and can last a human lifetime most of the time.

An analogy can go a long way. Both ways.

Re: Containers are tents

#106

Post by amarshall » Mon, Jun 14, 2021, 2:08 AM UTC

otabdeveloper4 wrote: post #104

amarshall wrote: post #80

Earlier quoted context omitted.

What sort of images are you working with? I can fairly straightforwardly boot debian:stable with no modifications to the image using direct kernel boot. Is everything perfect? No, but it does boot.

None of my images bundle a Linux distribution. (Indeed, most don't even bundle bash or coreutils.)

Sure, but that still doesn’t necessarily mean it won’t work. I can successfully direct kernel boot a VM where the entire filesystem is just a single statically-linked binary and it boots and runs it (just set init= or put the binary at /sbin/init). Some programs might need /proc /sys /tmp, etc., and if they do a bit more work needs to be done of course, but not all do.

Re: Containers are tents

#107

Post by ric2b » Tue, Jun 15, 2021, 10:52 PM UTC

brian_cunnie wrote: post #70

RcouF1uZ4gsC wrote: post #5

Earlier quoted context omitted.

> Containers are also a simple, practical way to bundle applications and their dependencies in a relatively standardized way, so they can be run on different compute fabrics. What I find interesting, is that many uses of containers are just reinventing statically linked binaries in a more complicated form.

> many uses of containers are ... statically linked binaries in a more complicated form I have found that to be true in at least one case—I had built a custom DNS server in Go (statically linked), and originally planned to run it in a container, but on further reflection realized the container brought no added value, and it was much simpler to write a systemd service control script than to bring in the extra baggage…

That's a very basic example. Let's say your program also depends on ffmpeg to convert some images, psql to interact with a database and a few other non-library dependencies.

With containers you can trivially ensure those are always present and with the correct versions.

Plus containers do give you some security benefits when compared to running natively.

Re: Containers are tents

#108

Post by nijave » Thu, Jun 17, 2021, 1:32 AM UTC

tptacek wrote: post #3

That's a valid way to look at it, but there are other ways. Containers are also a simple, practical way to bundle applications and their dependencies in a relatively standardized way, so they can be run on different compute fabrics. That sense of the term isn't loaded with any specific notion of how attack surfaces should work. I think modern "Docker"'s security properties are underrated†. But you still can't run mul…

>you still can't run multitenant workloads from arbitrary untrusted tenants on shared-kernel isolation

All those bargain basement OpenVZ "VPS" providers beg to differ :)

There's also gVisor

Re: Containers are tents

#109

Post by nijave » Thu, Jun 17, 2021, 1:34 AM UTC

johbjo wrote: post #60

I'd be curious to see services designed to run as PID 1 inside containers, and contain or run nothing else other than the required binaries. Maybe someone is doing this.