Comment by hardwaresofton | Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

Parent Full thread

I think this is how I most commonly recognize someone that is familiar with lxc +/- docker and containerization in general. A firm grasp of the fact that they're just beefy processes, isolated wiht namespaces and cgroups is the best, most succint way to describe docker (without even mentioning the benefits), but it also requires that the hearer knows what namespaces and cgroups are.

If I had to rank understanding in explanations of docker:

1. "Makes your application really portable"/other explanations that only cover the benefits of docker not how it works

2. "Lightweight VMs"

3. "LXC + some other stuff"

4. "processes + namespaces + cgroups (+/- image management tools, etc)"

100% agreed on the point you made, pretty sure docker+swarm and other orchestration efforts have basically lost the competition. Kubernetes just has the mind share, and even better than that -- it's actually good.

Kubernetes also has multiple competing container runtimes all rushing to fit the CRI (Container Runtime Interface). Just some of the stuff out there:

* cri-containerd - https://github.com/containerd/cri-containerd

* runv (hypervisor based) - https://github.com/hyperhq/runv

* clear containers (hypervisor based) - https://github.com/clearcontainers/runtime

* kata containers (hypervisor based, collaboration of runv + clear container) - https://katacontainers.io/

* frakti (combination of runv & docker, enabling switching @ runtime) - https://github.com/kubernetes/frakti

A bunch of the projects are in their infancy, but the CNCF/kubernetes and the community are doing the right thing investing in lots of them, and letting the good ones bubble to the top. I don't run a production kubernetes cluster but I've found cri-containerd to be really easy to use and haven't had any major problems with it, mostly small configuration things.

The last one, frakti, gets me really excited, because it lets you be flexible about which containers run in more protected environments and which don't. Also really exciting is frakti v2 (https://github.com/kubernetes/frakti/tree/containerd-kata), which is kata + containerd.

Kinda feels like I'm I a foreign country and run into someone that speaks my language :). Thanks for the additional info, like frakti, for example...didn't know about that.

Explaining docker is frustrating for me because I was a Unix admin back in the 90's. So, for me, it's pretty easy to see what it is. And, it isn't new. There isn't much it does that Solaris zones or BSD jails, didn't do. And those predate docker by years. Namespaces, cgroups, and pivot_root. That's basically all of it. Kudos to docker for marketing it better.

Explaining it, on the other hand, to a broad audience...

That's sorta true, but the layered-userspace-filesystem support is a pretty big feature that Docker pioneered Linux support for.

Did userspace filesystems/layered filesystem-in-a-box implementations exist before? Sure: from ZFS to squashfs to tar, all the components were around.

But Docker's popularity is due to its integration; not its novelty. By bundling a filesystem-in-a-box abstraction layer with varying degrees of native OS support into something like a mountable artifact/image, hiding the image caching mechanics behind a nice CLI and image-configuration file format (love 'em or hate 'em, Dockerfiles are a phenomenal example of minimalism and convenience: add some meta commands, and everything else is just shell), and integrating all that with the privacy/isolation (namespaces/chroots) and resource management (cgroups/quotas) stuff, Docker made a really, really powerful model of thinking about "containers" as a single concept.

The thought model is Docker's big achievement: other competitors may unseat Docker eventually, but the concept of "container" as a single, unitary thing that's almost like a VM image will stick around, and the more piecemeal understanding of how containers work will be largely unnecessary, and thus save a lot of time for a lot of people.

LXC had most (if not all) of what you're describing, and a long time ago Docker was just a simple wrapper around LXC. A lot of the inspiration for containers came from other operating systems (FreeBSD Jails and Solaris Zones) as well as previous work such as Xen.

I think what made Docker popular was that it was easier for developers to use, with small bits of information like what ports the container wants to listen on and so on. From an administration standpoint, LXC was already more than good enough.

I agree with all of that, but none of it is their intellectual property. It's mostly brand recognition that keeps them afloat.

K8s could easily release a command line clone and unseat docker in fairly short order.

Not dimininishing the value of what the docker folks bundled together and marketed. They did a terrific job. It just isn't very protected.

Yeah I didn't either, until not too long ago but now I'm pretty excited to use it.

As a person who wasn't a linux admin back in the 90s, and doesn't normally hang out on mailing lists, the first time I saw lxc was some random article on lwn.net (I don't hang out there, but they have some super high quality articles), and I definitely didn't put together how much of a difference it was poised to make, or even know why it was a good idea (people were still getting used to vagrant everywhere at the time) -- docker definitely did the community a service by bringing the hype train, if only so that once the hype subsided containers would be here to stay.

As a person who wasn't a linux admin back in the 90s,

Nobody was a Linux admin in the ‘90’s: we ran HP-UX, IRIX, OSF/1 DECUnix (and Ultrix), AIX, Solaris and NetBSD; those were our Linux we grew up on like you grew up on a Linux ISO on your parents’ PC bucket.

I ran a small ISP on a pair of Linux (Slackware probably) boxes, a Livingston Portmaster, a bank of Hayes modems, and a T1 in the mid-90s. So some of us were Linux admins then.

Me too. Maintained a small (100 or so) fleet of Slackware Linux desktops for a support org in the early 90's. Rare, but did exist. Was the install 13 1.44mb floppies? Seems to ring a bell. Lots of waiting for the prompt to switch out the floppy. And a more intimate relationship with "dd", "kermit", etc, than I remember ever encountering again.

Also, whoever wrote x3270. Thank you!

That's crazy: Linux isn't rightly usable even now 20+ years later, and you ran it in mid '90's when it could barely boot a shell reliably. And Slackware no less, which meant dumping tape archives everywhere instead of package management.

Crazy.

We have a 1999 VA Linux box still "in production" (just to see how long it will go, at this point. Nothing mission-critical.)

From outside (I know nothing about zones, jails) it looks like saying Dropbox is not new (in 2007) because rsync was not new.

Look into either. They are pretty much the same thing as docker. It's isn't a superficial similarity.

For example, filed in 2003: https://patents.google.com/patent/US20050021788

I’m about a 1.5

Any good resources you could suggest for learning more about what you describe as the relevant areas?

I want to point out that I'm by no means an expert -- the real experts are the people in the talks that I mentioned, the core contributors to the libraries.

I think a good place to start is those talks (and stuff from any container-centric conferences), along with lots and lots of practice using containers.

In general, I'm pretty sure if you read up on chrooting, processes on linux, process isolation on linux, LXC, then the relevant standards/tools that underly docker like runc (https://github.com/opencontainers/runc), you'll have a pretty deep understanding.

Also, for day-to-day use, I honestly think you can do just light research on the above topics and start using docker and know way more than the average developer. As you use it more and more, you'll gain more intuition, and when you bump up against certain issues, you'll probably gain some intuition as to where things are going wrong (though honestly the toolchains are pretty stable now).

The goal of a lot of these projects is to be so stable you don't have to worry about it, so I don't feel too guilty about it, in the same way I don't feel too guilty about not ever having cache-line-optimized a program in my life.

Reply on news.ycombinator.com