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

Containers are tents

increment.com

Post reply on HN
Print view View original

41–50 of 109 posts

Re: Containers are tents

#41

Post by otabdeveloper4 »

RcouF1uZ4gsC wrote: post #5
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…

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

A Docker image is really just a .tar.gz under the hood, with a little bit of metadata.

A Docker image is really just a chroot + some cgroups resource limits.

Re: Containers are tents

#42

Post by snovv_crash »

0xCMP wrote: post #23
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.

I think of Docker as a universal static compiler. And I mean that in a positive way: static compiling makes a lot of sense with the incredible complexity we're often finding ourselves in. There really are no other ways to distribute node/ruby/python apps in a static way and when there is it's limited in serious ways beyond often being ONLY for a specific ecosystem (e.g. wheels for python).

There are many ways of doing this for Python... pyinstaller, py2exe, Nuitka to name a few

Re: Containers are tents

#43

Post by amarshall »

otabdeveloper4 wrote: post #41
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.

A Docker image is really just a .tar.gz under the hood, with a little bit of metadata. A Docker image is really just a chroot + some cgroups resource limits.

> A Docker image is really just a chroot + some cgroups resource limits.

No, because an image specifies nothing about the runtime. Just add a Kernel and bootloader and one can boot most images. Further most container runtimes include a lot more than chroot and resource limits. Namespace isolation (process, user, network), seccomp rules, SELinux contexts, etc.

Re: Containers are tents

#44

Post by tjpnz »

mrweasel wrote: post #35
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.

If it was just a replacement for statically linked binaries, I’d be less concerned. In reality people stuff EVERYTHING in into containers, database, queue, a webserver and your application, it all goes into one container.

You might be able to get away with that for a development environment ala Vagrant. But doing that in production sounds scary, and I'm saying that as a mere dev (who has very little to do with ops).

Re: Containers are tents

#45

Post by amarshall »

eVeechu7 wrote: post #16

>Finally, there’s the whole business of resource isolation. While cgroups are pretty neat as an isolation mechanism, they’re not hardware-level guarantees against noisy neighbors. Because cgroups were a later addition to the kernel, it’s not always possible to ensure they’re taken into account when making system-wide resource management decisions. I don't think virtualization really offers hardware-level guarantees a…

VMs provide stronger guarantees for maximum CPU, network, and disk usage, as well as memory size consumption. This because the abstraction boundaries are fairly clear (e.g. threads and virtual devices).

Re: Containers are tents

#46

Post by mrweasel »

crummy wrote: post #37
mrweasel wrote: post #35

Earlier quoted context omitted.

If it was just a replacement for statically linked binaries, I’d be less concerned. In reality people stuff EVERYTHING in into containers, database, queue, a webserver and your application, it all goes into one container.

I thought one of the first rules was one container per app/service/whatever.

Correct, you also shouldn’t have supervisor processes in a container, as this prevents detection of crashed containers.

We’ve seen container with all sorts of weirdness, where half the service could crash and Docker would never notice, because the supervisor process was still running and that was the entry point for the image.

Re: Containers are tents

#47

Post by globular-toast »

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…

Technically what you're describing is an image. Might sound pedantic but interchanging container and image does often cause confusion in my experience.

Re: Containers are tents

#48

Post by globular-toast »

RcouF1uZ4gsC wrote: post #5
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…

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

Static linking was done out of necessity more than anything. It's the obvious way to compile a program. The fact that you got a single distributable executable was merely a convenient side effect.

Re: Containers are tents

#49

Post by rualca »

nickelpro wrote: post #17
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.

Those are two different things. If I need GCC 11 and its associated standard libraries and toolchain to build my app, and I need to build that app on CI services that ship an older version of GCC, I need some way to bundle my dependencies for arbitrary compute fabrics. The answer to this is a container. Containers don't "reinvent" static linking, they solve problems that go beyond static linking.

> The answer to this is a container. Containers don't "reinvent" static linking, they solve problems that go beyond static linking.

This.

I would also point out that containers handle also other critical features like it's virtual network, which obviously goes way beyond what may be simplistically described as "static linking".

Re: Containers are tents

#50

Post by rualca »

catlifeonmars wrote: post #21
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.

Exactly! I don’t see this as a criticism of containerization so much as it is a praise of static linking. What containerization enables is that it allows you to confer some of the advantages of static linking to languages and libraries that don’t natively support it.

> 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 images are installers, and containers are the end-result of installing and configuring these containers, which is barely noticed because it works so well even and specially the networking part. More importantly, containers are designed to be both ephemeral and support multiple instances running in parallel on the same machine.

Then there's also the support for healthchecks, which allows container engines to not only determine when they should regenerate containers, but also provides out-of-the-box support for blue-green deployments.

And absolutely none of this fits the "static linking" metaphor.

Post reply on HN