Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I'll admit it took me a while to realise that Docker containers aren't magical apparatuses that can run software. They are just an OS running like a VM. Yes there's differences but I really wish learning resources began with that.

I think a lot of it has to do with the experts accidentally talking past beginners, missing a lot of the basics before getting into teaching abstractions.

It also reminds me of the feeling I'm experiencing now about learning Elasticsearch. I'm amazed just how few JSON examples I can find online for the API. It was amazing how much it helped for a peer to say, "an index is a table, a document is a record and it's kind of like monogdb."

Furthermore this all reminds me of wrong atomic models in high school. Please just teach me a really simple but wrong explanation then slowly work out the details.

View on HN

My maybe cynical view on this is twofold:

1. For software, open source or not, that is driven by a commercial company, it is often not in their best interest to tell people what it actually is, that they are selling. They care more about conversion rates than educating. E.g. notice how the docker.com website doesn't seem to explain at all what these "Docker containers" are, instead throw around phrases the marketing department came up with: "Docker is the de facto developer standard for building and sharing apps that enable simplicity, agility and choice [...]".

Doesn't mean the tech is good or bad. It can just make it obnoxious to sift trough the propaganda to get the info you want/need.

2. There are plenty of developers that can't be bothered to obtain a deeper understanding of the things they are working with, beyond the getting started tutorial. Which is fine in the beginning, but eventually one should get past that.

> "Docker is the de facto developer standard for building and sharing apps that enable simplicity, agility and choice [...]".

You're right. It's only slightly better than zombo.com (https://html5zombo.com/)

For a less cynical view that says pretty much the same: They want to tell people what's the software usef for / what do they gain from using the software, and not internal details.

Would you prefer to know what docker containers are, or what they provide? For example would you rather the first explanation started "Containers allow you to run applications in an environment with its own filesystem and network, isolated from the resources of the main system", or "Containers are a standardised abstraction layer over linux namespaces and resource use restrictions, with common interfaces for network and volume management"? And would you stop using containers if they provided the same benefits, but technically in a different way?

>They are just an OS running like a VM.

This is exactly what Docker containers AREN'T.

Don't think of containers like tiny VMs. Think of them as processes with additional isolation from each other.

A VM is a good way to logically think about the containers, and I’m sure it’s the way the vast majority of people first think about them.

Under the hood they are simply a process isolated with namespaces, but their behavior on the outside feels like getting a VM.

But docker containers don't run their own kernel, which is a huge difference to a VM.

My point is that most people don’t even really know that’s how a VM works. They just think of a VM as a fresh sandbox where they can install and run stuff without deleting somebody else’s files or programs.

I'm hearing a repeated theme in your comments that people don't know much about how anything works, and that's supposedly OK. That's actually not OK. :)

No, that's how learning curves work. Until we can Matrix beam info into our skulljack, humans will spend a notrivial amount of time having to make do with using things while not fully understanding how they work.

Unless one is 31337-rockstar-ninja-IQ150-programmer, the uptake of new skills is painful and takes time. The pedagogical process is important. It's totally OK to not know how anything works as long as you acknowledge that and are willing to learn.

I totally agree. That wasn’t the sentiment I was responding to, which sounded more like “nobody knows how that works, and they don’t really need to, so why are you wasting their time explaining how it actually works?”

Neither does the JVM. Never a good idea to cling onto text-book definitions in this cloud industry full of buzz words.

It is never a good idea to not understand what you're doing, especially when the boundaries of who does what are moving around.

I'm mostly an ops person in outlook, although I was a programmer for over a decade and write my share of code. The software-ization of infra is a good thing; unlike some ops folks, I don't find it threatening, I find it cool.

What I find dismaying is some of the horrific stuff I catch before it gets to production, and what I do find threatening in a different way is worrying about what I miss.

Moving OS-level dependency management in to dockerfiles? Great! How are you scanning that against CVEs? If you don't know you're not running a different kernel, I have a sneaking suspicion you're... not. And so on down the list of traditional ops practices I frequently discover developers had no idea even happened.

So?

There is nowhere in the docker-noob's workflow where the huge distinction between a docker container instance and a super light VM actually matters.

Source: I knew nearly nothing about docker a year ago. And now I'm one of my company's go-to people for docker questions. The pain is still fresh in my mind and I see noob-pain every day :)

Why not correct the misinformation then? Docker is nothing like a VM. It uses cgroups to reserve resources like CPU, memory, etc, and namespaces to isolate containers and their respective processes. VM applications will have to emulate hardware, so the kernel running under VM is able to enumerate hardware devices. Virtual machine emulates a computer with a full ISA.

You are describing the specific technical details about how Docker containers are implemented. The analogy to VMs comes from the observation that VMs virtualize the hardware while containers virtualize the operating system.

> The analogy to VMs comes from the observation that VMs virtualize the hardware while containers virtualize the operating system.

Aaaand that off-the-cuff statement clears up the difference between them that I've been missing for months. Containers really do just look like a VM, if you don't know the implementation details and are just using them.

> Virtual machine emulates a computer with a full ISA.

You probably didn’t mean that they literally emulate an instruction set, because most modern hypervisors don’t emulate most instructions.

I wouldn't describe it this way if your goal is to correct misinformation. VMs can definitely pass through real hardware instead of emulation. (most often used for GPUs and network cards) And docker containers can use emulated hardware. (from the app's point of view) Normal processes can run emulated hardware via user-mode linux.

The idea of a VM is so messy these days, it's best to define what kind of VM are you talking about first. (language? system? foreign hardware?)

> Think of them as processes with additional isolation from each other.

That's true, but as VMs also isolate processes from each other, this can confuse others. Let's be more exact:

A VM = isolated kernel and userspace.

- Advantages: security

- Disadvantages: speed

A container = isolated userspace only. Shared kernel.

- Advantages: speed, size

- Disadvantages: security

Both can have pre-created images to avoid the problem of recreating workspace. Docker did not invent orchestration.

> - Disadvantages: speed

Nuh? Of starting, sure. Of running? A margin of error.

Running an app inside a container on bare metal is way faster than running an app in a VM on bare metal.

- Containers in this case: userspace on kernel on hardware

- VMs in this case: userspace on kernel on virtual hardware on kernel on hardware.

There are very fast VMs (the Firecracker MIcroVM) but they're not in popular use.

You are hopelessly out of date. VMs are not Xen with emulation. Neither are they the original VMware. Nor are they QEMU without acceleration.

VMs are qemu-system-x86_64 -machine accel=kvm or whatever is the platform specific way to run a VM under a hypervisor. This has been the case since hypervisors showed up on the scene, aka right after what was the predecessor of Virtuozzo

Xen was never an emulator. That's technically incorrect. Not does the definition of VM change because of hardware acceleration. That's also technically incorrect.

It should have been VMware with emulation, not Xen. You are correct

The overhead of running a VM absolutely changes depending on whether it is a type 1 hypervisor or a type 2 hypervisor or if the runner/monitor supports acceleration.

You can run a VM with QEMU without accel=kvm and it will be dog slow. Try it.

I know re qemu and hypervisor types. VMware was never an emulator, but TBH we agree more than we disagree - have a good weekend

speed, possibly, possibly not.

For CPU/memory, yes.

For network, possibly (lots of iptables re-writes)

for disk, not so much, docker(depending on what driver you have) suffers from write amplification.

If we were just talking about namespaces alone, I'd agree. As it's commonly used, though, Docker containers often contain a whole distro userspace too. (But sure, you're typically only starting one process with the container.)

It's like saying interfaces are classes without implementation.

Except they feel for all intents and purposes like tiny VMs.

If I gave a pre-Docker era engineer two terminals, one host, one in a container, they'd probably quickly figure out they are on the same physical machine. But unless they were super savvy at some very specific stuff, they'd probably conclude it was just a VM.

Every dev I've introduced to docker workflows basically treat it like a vm. The only ones that didn't already had experience with cgroups/chroot and related tools.

It's honestly better to think of Docker as "VM, but actually you use the same kernel" than "processes that are isolated".

Other poster compared it to electron models. Yes, "balls in orbits" is wrong, but kids are already familiar with planetary orbits, and that mental model works until basically Organic Chem II.

"OS running like a VM" is a wrong summary. Containers are collection of namespaces. Docker manages (starts , stops etc) these containers. It also provides an easy gateway into readymade container images.

I think Waterluvian's point was that _before_ you start talking about things like containers, namespaces, images and so on, you need to explain the basics. Depending on the previous knowledge, your summary may or may not make sense. If you don't know what containers, namespaces or images mean here (basically, you haven't seen docker before), then your summary makes no sense.

If you're a programmer, you most probably have heard about OSes and VMs before, one way or another. Then, the analogy is a bit easier for the beginner to understand. Hence the "slightly wrong but somehow still manages to be a bit informative"-summary Waterluvian gave can teach the beginner the first steps.

Yeah. I'm getting a lot of "no it's not that". And surely this failing is on my end. But I'd learn better with an approach of "yes it's like a VM in these ways. But then it's different in these ways..."

Maybe it's just me. I love teaching and learning by starting with a common but wrong model and learning piece by piece what's different until its an evolved, more accurate model.

So it's an OS though right? Like Ubuntu is running, chugging along like Ubuntu does. And is it sitting on top of some virtual hardware interface to simulate IO?

> And is it sitting on top of some virtual hardware interface to simulate IO?

Not really, no. Software in a container directly talks to the kernel of the host using the normal APIs the kernel provides. A container does not contain a kernel!

No, this is absolutely wrong. Docker containers don't contain a kernel or any init system. They are simply Linux processes that are isolated from each other using a few native features of Linux.

Okay awesome. So then why is my base image called Ubuntu 18.04? It sounds like theres an OS there. That's why I intuitively assemble a model of there being an OS. Not that I'm asking you to explain, but that I wish educational content could start from a common place and explore why it's different.

Depends what you mean by OS. There isn’t a kernel but there is an entire user space with an init process, so the GNU part of GNU/Linux.

Different Linux distributions ship with various package managers / other userspace tooling. But they all run on top of the Linux kernel. I can see how having a base image called "Ubuntu 18.04" might make it seem like there's an entire OS running in the container but that's not the case. Check out this Ubuntu base image Dockerfile https://github.com/tianon/docker-brew-ubuntu-core/blob/bcdd3..., you can see that it's throwing a tarball for the root filesystem into the container (and some Docker-specific stuff), nothing crazy.

The kernel is a tiny, insignificant part of what makes Ubuntu Ubuntu.

Running an Ubuntu user land on top of some generic other Linux kernel will for almost all practical purposes feel the same as running real Ubuntu.

Ubuntu is just a collection of software. The most important piece of software in that collection is the Linux kernel.

That kernel is what is shared between different containers. You can have 5 copies of Ubuntu (or Debian, or Mint) in separate containers, but they're all using the same kernel. This is what makes containers much more efficient than multiple full VMs.

In your example, the docker image makes a certain presumption - the presumption is that the OS that the host is going to run is Ubuntu-ish and 18.x generation-ish and probably runs on a 64bit amd_64. So unless your code is very complicated, then probably by pulling Ubuntu 18.04 libraries and setting some linker rules things are going to work on most systems.

Still most images are based on distros because it's so convenient. Apart from software written in Go that is usually shipped as images based on "scratch". I think there should be simpler building blocks for assembling images thatn complete distro images. For instance when you create an Nginx image it could just contain the Nginx binaries and the libraries they are linked with.

No, not at all.

They are just applications running on top of the very same kernel you would run any application from.

The kernel just provides enough layers of separation on the necessary structures.

There's plenty of material on it; if interested I'd suggest to start to study by kernel namespaces as @mav3rik pointed out.

Just goes to show how lying about concepts never helps your understanding.

It's an exactly correct summary from a user's point of view and the fact that everyone says it's wrong is just confusing people. Virtual Machine is a concept and doesn't have or require a technical definition. The fact that Docker doesn't require a hypervisor is completely irrelevant to everyone who isn't working the core Docker platform. Containers provide a layer of indirection that imitates a completely separate and distinct operating system on top of a host OS. That's a VM to the eyes every developer who just needs to run Linux operations from OSX or Windows.

The distinction is relevant to me for the simple reason that I can run “top” from a normal shell and see what’s going on in all my containers, attach debuggers to them, etc.

To confuse things even further, Docker on OSX and Windows actually does use a fully-fledged VM that the containers run on.

Truly understanding the Linux kernel namespacing features that Docker is built on certainly takes more effort to learn, but I disagree that it's irrelevant to anyone not working at Docker. Understanding your tools makes you a better developer, and allows you to understand what is and isn't possible.

> "OS running like a VM" is a wrong summary.

I think it is a fair summary, because the implications of running in Docker are often the same as running a real VM.

To exemplify, a common mistake is to run a server as the entrypoint of the docker container. The server will then run as PID 1, with all the implications and responsibilities an init process has. This causes a lot of subtile and annoying problems.

The container is running on the same kernel as the host. That is not the case with a VM.

Well, not if you use Docker on Windows or Mac. But these are technicalities that don't matter that much.

Unless you are writing kernel drivers or you need to tweak certain kernel parameters, running in a Docker container is very much as running in a VM. With the same responsibilities, e.g., setting up an init process.

A CVE on your host kernel affects your container. Not your VM. So yes it does "matter much".

Reply on news.ycombinator.com