Hacker News Reader

Comment by Waterluvian | Hacker News Reader

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?

View on HN

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.

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

Reply on news.ycombinator.com