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

81–90 of 109 posts

Re: Containers are tents

#81

Post by nyx__ »

rualca wrote: post #62
vladvasiliu wrote: post #52

Earlier quoted context omitted.

I'd say that the static linking metaphor refers to the container image itself, in that it's standalone and (fairly) "universal". All the other things you talk about could be set up for standalone binaries as some form of orchestration, after installation , as you say. To me, the analogy doesn't have to be 1:1 for it to work. Yes, that means there are edge cases which should be taken into account, but that doesn't mak…

> I'd say that the static linking metaphor refers to the container image itself, in that it's standalone and (fairly) "universal". That metaphor makes no sense beyond the standalone part. Container images are way more than mere stand-alone statically linked binaries, much like an installer (deb/rpm/MSI/PKG/etc) are way more than statically linked binaries. If anything, container images are a kin to fat JARS or macOS'…

Containers aren't Docker. They're a combination of Linux features. Your container runtime might provide health checks and fancy features, but containers do not.

> We're talking about being able to deploy and scale the same app at will in a completely sandboxed and controlled environment. We're talking about treating everything as cattle, from services to system architecture.

Same is true for AMIs and VMs. Containers are the technology, not the pattern.

Re: Containers are tents

#82

Post by tptacek »

foobar33333 wrote: post #66
Saint_Genet wrote: post #59

Earlier quoted context omitted.

Your first paragraph pretty much sums up what docker is, it’s a convenient way to design and build a system, but it is not a security mechanism. If you’re building a system that’s handling classified information, there is probably not an accreditation authority in the world that would let you use containers or even hypervisors as a way to separate different information classes.

Docker _should_ be secure, any part that isn't secure is a bug which can be reported. That disconnected to the reality of whether docker actually is secure, but in theory it is meant to be. Other implementation like podman get even better security by not running as root.

The fundamental flaw of the Docker container security model is the shared kernel, which is a gigantic attack surface in which vulnerabilities are present, somewhat routinely, in functionality that can't be masked off with system call filters.

The win of virtualization is that the machinery required to hypervise a kernel is much, much smaller than the kernel itself; to use the 70s terminology, it's a minimized trusted computing base.

Re: Containers are tents

#83

Post by RexM »

snovv_crash wrote: post #42
0xCMP wrote: post #23

Earlier quoted context omitted.

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

Cool, now do node and ruby, using the same tool.

Re: Containers are tents

#84

Post by nijave »

Modern containers do provide lots of security features with namespaces, seccomp, cgroups (to some extent)

The author seems to largely ignore this. I would consider that a bit stronger than a "tent wall". Comparing it to a tent seems more akin to a plain chroot.

If I have my tent right next to someone else, I can trivially "IPC" just speaking out loud which would be prevented by an IPC namespace (which is Docker's current default container setup)

Also worth mentioning, turning a container into a VM (for enhanced security) is generally easier than trying to do the opposite. AWS Lambda basically does that as do a lot of the minimal "cloud" Linux distributions that just run Docker with a stripped down userland (like Container Linux and whatever its successors are)

Re: Containers are tents

#85

Post by antonvs »

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.

It's pretty common for languages that compile to binaries. Golang, for example. Just inherit your container "FROM scratch". I have a number of service containers that are around 8 - 12MB, which contain compiled Haskell binaries.

Re: Containers are tents

#86

Post by cratermoon »

detaro wrote: post #57
eyeyeyerg wrote: post #56

containers are cattle, VMs were pets. If one does not get the operational differences nor understands that these are completely two different usescases then probably should not work in IT industry

VMs can be cattle. Physical machines can be cattle. This is not tied to the runtime technology, but to how you design and manage your machines and applications.

The original pet v cattle metaphor was indeed inspired by servers, not containers. http://cloudscaling.com/blog/cloud-computing/the-history-of-...

What makes a given component – server, vm, container, whatever – is not the runtime, but how you deal with it when it gets seriously ill. Pets are taken to the vet or hospital to get treatment. Cattle are.. well, read the article I linked.

Re: Containers are tents

#87

Post by coldtea »

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.

>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 problems they solve might go beyond "static linking", but are accidental complexity problems that doesn't go beyond namespacing.

With proper namespacing support, one could trivially build "with GCC 11 and its associated standard libraries and toolchain" on a CI service that ships with "an older version of GCC".

Ideally, one would just need a local folder with the GCC11 and its dependencies, and at most an ENV entry for where to pick up deps (optimally not even that, the GCC11 binary should give precedence to the local versions within the same folder by default).

But, no, instead we need to juggle 20 folder locations, PATH and EVN variables, burn-in build paths into libraries and executables, and so on...

Re: Containers are tents

#88

Post by coldtea »

snovv_crash wrote: post #42
0xCMP wrote: post #23

Earlier quoted context omitted.

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

Python is probably the worst example for achieving this...

The fact that "there are many tools to do this for Python" is already a big red warning sign...

Re: Containers are tents

#89

Post by dilyevsky »

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

It offers the opportunity to throttle noisy neighbors in hopes the party isn't too big.

Cgroups can do the same via cfs

Re: Containers are tents

#90

Post by fsociety »

This is oversimplifying containers and VM by using the house vs tent analogy. Just talking about Docker weakens this too, because Docker is not the only way to setup containers.

> Tents, after all, aren’t a particularly secure place to store your valuables. Your valuables in a tent in your living room, however? Pretty secure.

Containers do provide strong security features, and sometimes the compromises you have to make hosting something on a VM vs. a container will make the container more secure.

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

Cgroups are more than a neat resource isolation mechanism, they work. That's really all there is to it.

Paranoia around trusting the Linux kernel is unnecessary if at the end of the day you end up running Linux in production. If anything breaks, security patches will come quick and the general security attitude of the Linux community is improving everyday. If you are really paranoid, perhaps run BSD, use grsec, or the best choice is to use SELinux IMO.

If anything, you will be pwned because you have a service open to the world, not because cgroups or containers let you down.

Post reply on HN