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

91–100 of 109 posts

Re: Containers are tents

#91

Post by ta988 »

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

Yes and they tend to all crumble when you have complex use cases with numpy, scipy, qt etc They can be a pain to deploy and manage remotely as well.

Re: Containers are tents

#92

Post by throwaway894345 »

nijave wrote: post #84

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

I’m a big proponent of containers, but in fairness to TFA, I don’t know how to configure namespaces, second, or cgroups and I don’t know what settings my orchestrator uses by default. If containers can be secure but we don’t enable those security features properly, then it’s a bit of a moot point. That said, I think (but am not sure) most of us understand enough not to trust containers for isolation between untrusted processes, so I don’t regard containers as lightweight VMs, but rather collocated processes with their own namespaces. When I run untrusted code, like jupyterhub, I make sure those untrusted containers get scheduled onto their own dedicated mode pool with single tenancy (at which point the container is more of a tooling/orchestration convenience than a resource optimization tool).

Re: Containers are tents

#93

Post by throwaway894345 »

rossmohax wrote: post #31

I believe, that success of containers is not because of lightweightness or other isolation properties of them. Containers won dev mindshare because of ease packaging and distribution of the artifacts. Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up.

> Somehow it is Docker, not VM vendors came up with a standard for packaging, distributing and indexing for glorified tarballs and it quickly picked up.

IMO the important, catalyzing difference is that Docker containers have a standard interface for logging, monitoring, process management, etc which allow us to just think in terms of “the app” rather than the app plus the SSH daemon, log exfiltration, host metrics daemon, etc. In other words, Docker got the abstraction right: I only care about the app, not all of the ceremony required to run my app in a VM. These common interfaces allow orchestration tools to provide more value: they aren’t just scheduling VMs, they’re also managing your log exfiltration, your process management, your SSH connection, your metrics, etc, and all of those things are configurable in the same declarative format rather than configuring them with some fragile Ansible playbook that requires you to understand each of the daemons it is configuring, possibly including their unique configuration file/filesystem conventions and syntaxes.

Re: Containers are tents

#94

Post by catlifeonmars »

rualca wrote: post #50
catlifeonmars wrote: post #21

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

Re: Containers are tents

#95

Post by [deleted] »

fsociety wrote: post #90

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

[deleted]

Re: Containers are tents

#96

Post by catlifeonmars »

rualca wrote: post #50
catlifeonmars wrote: post #21

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

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.

Re: Containers are tents

#98

Post by rualca »

nyx__ wrote: post #81
rualca wrote: post #62

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

> Containers aren't Docker.

Discussing if containers are Docker or not I'm this discussing is a non-sequitur fueled by needless nitpicking and being pedantic for being pedantic.

The whole point is that all those features that I listed are basic container features, not higher-level concepts provided at the container orchestration level.

> Same is true for AMIs and VMs.

No, not really. Running something in a VM is not the same as running a containerized process.

Re: Containers are tents

#99

Post by rualca »

catlifeonmars wrote: post #96
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…

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, run shells, and create temporary file systems automatically.

Talking about containers in any way that leaves out the containing part is counterproductive and a bad mental model.

Re: Containers are tents

#100

Post by nyx__ »

rualca wrote: post #98
nyx__ wrote: post #81

Earlier quoted context omitted.

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…

> Containers aren't Docker. Discussing if containers are Docker or not I'm this discussing is a non-sequitur fueled by needless nitpicking and being pedantic for being pedantic. The whole point is that all those features that I listed are basic container features, not higher-level concepts provided at the container orchestration level. > Same is true for AMIs and VMs. No, not really. Running something in a VM is not…

I'm not saying that running something in a VM is the same as in a container -> that's the whole point of the article. I'm saying that just like you should treat containers like cattle, you can treat VMs like that too. What do you think folks did before containers existed :)
Post reply on HN