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

61–70 of 109 posts

Re: Containers are tents

#61

Post by zaphirplane »

smitty1e wrote: post #12

I explain that if the an Amazon Virtual Private Cloud (VPC) is a datacenter "cloud", then a container implementation is a "puff". Virtualizing the kernel like the Amazon Machine Image (AMI) virtualizes a chip core sounds great. But now, in the "puff", all of those networking details that AWS keeps below the hypervizor line confront us. Storage, load balancing, name services, firewalls. . . Containers can solve packag…

I have to say inventing a new metaphor for container made it harder to follow the point you were trying to make

Re: Containers are tents

#62

Post by rualca »

vladvasiliu wrote: post #52
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…

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's bundles, but even that metaphor leaves key features out, like healthchecks, image inheritance, and of course support for software defined networking.

> To me, the analogy doesn't have to be 1:1 for it to work.

The whole point is that the metaphor makes no sense and completely misses the whole point of containers.

No one uses containers because they want statically linked binaries. Or even installers or packages. At all.

What container users want is what containers provide and neither statically linked binaries or zips or installers or bundles come close to offer. 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. We're talking about out-of-the-box support for healthchecks, and restart apps when they fail.

Each and every single one of these features is made available with docker run. That's what containers offer.

None of this has anything to do with static linking anything, and insisting on this metaphor shows that people completely miss the whole point of containers.

Re: Containers are tents

#63

Post by mercora »

encryptluks2 wrote: post #2

Starts off saying VMs are like brick and mortar houses and containers are like tents. I agree somewhat but there has been significant progress to sandbox containers with the same security we'd expect from a VM. It isn't a ridiculous idea that VMs will one day be antiquated, but probably won't happen for a few more years.

i don't think that is necessarily the case but instead i believe in the near future the differences between container sandboxes and virtual machines might be less clear.

I imagine CPU and memory namespaces coming implemented on hardware isolation features like VT-d io-mmus and alike thus making virtual machines integrated into some sandboxing feature.

Re: Containers are tents

#64

Post by nickjj »

IMO comparing containers to an apartment is more accurate than a tent.

Because with an apartment each tenant gets to share certain infrastructure like heating and plumbing from the apartment building, just like containers get to the share things from the Linux host they run on. In the end both houses and apartments protect you from outside guests, just in their own way.

I went into this analogy in my Dive into Docker course. Here's a video link to this exact point: https://youtu.be/TvnZTi_gaNc?t=427, that video was recorded back in 2017 but it still applies today.

Re: Containers are tents

#65

Post by leephillips »

I’ve found systemd-nspawn useful. Use debootstrap to install a minimal Debian system inside your system, then boot it with this command. It isolates the filesystem while sharing the network interface, and is convenient for most things that I guess people use Docker for. I wonder why it’s not mentioned more often.

Re: Containers are tents

#66

Post by foobar33333 »

Saint_Genet wrote: post #59
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…

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.

Re: Containers are tents

#67

Post by onei »

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.

Pretty sure this is what tini[1] is for, and there's supervisord[2] for more complex use cases, e.g. running multiple processes. Neither are a full replacement for traditional systemd, which I heard you can technically run in a container these days, but I've never seen anyone try.

[1] https://github.com/krallin/tini

[2] https://github.com/Supervisor/supervisor

Re: Containers are tents

#68

Post by dijit »

leephillips wrote: post #65

I’ve found systemd-nspawn useful. Use debootstrap to install a minimal Debian system inside your system, then boot it with this command. It isolates the filesystem while sharing the network interface, and is convenient for most things that I guess people use Docker for. I wonder why it’s not mentioned more often.

I know it sounds like I want to be spoonfed, but do you have a walkthrough of this flow?

I'd be interested in trying it out but I don't want to spend some hours reading documentation trying to get it working.

Re: Containers are tents

#69

Post by foobar33333 »

unethical_ban wrote: post #4

Container tech can be used for small scale "pet" deployment, but my understanding is that the true benefit of containers come with seeing them as "cattle". You should never login to the shell of a container for config. All application state lives elsewhere, and any new commit to your app triggers a new build. If that's not for you, then while containers like proxmox/LXC can still be handy, you're just doing VM at a d…

>You should never login to the shell of a container for config

I absolutely do this and think it works great. Fedora has built a tool called "toolbox" which is basically a wrapper on podman which can create and enter containers where you can install development tools without touching your actual OS.

I basically do all of my development inside a container where the source code is volume mounted in but git/ruby/etc only exist in the container.

This has the benefit of letting me very quickly create a fresh env to test something out. Recently I wanted to try doing a git pull using project access tokens on gitlab and containers let me have a copy of git which does not have my ssh keys in it.

This is somewhat of an edge case though, for a server deployment, yes you shouldn't rely on anything changed inside the container and should use volume mounts or modify the image.

Re: Containers are tents

#70

Post by brian_cunnie »

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.

> 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 of a container ecosystem to run the DNS server.

Post reply on HN