Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

> Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today).

At the risk of nitpicking, docker images aren't the equivalent of VM images, as they don't include a kernel.

View on HN

This isn't nitpicking at all, it's an important distinction!

Docker is not virtualization, it's just an abstraction that makes some Linux process isolation features easier to manage.

It also allows you to bundle whatever dependencies you have in the same bundle, but that is not the same as having a VM.

Linux containers and equivalent technologies are virtualisation (specifically OS virtualisation[1]), just not a VM. Hardware virtualisation (VMs) isn't the only kind of virtualisation that exists.

[1]: https://en.wikipedia.org/wiki/Operating_system-level_virtual...

By that logic, processes are arguably virtualisation too. They do after all use virtual memory.

Threads, processes and containers exist on a continuum.

The key is that "containers" don't actually exist -- they're just processes running under a variety of different namespaces.

It's true that Docker isn't a first-class abstraction at the level of the Linux kernel, but BSD has jails, and Solaris has Zones. This is important in some respects, but I don't see that it informs things here. Containers are still 'a thing' regardless of how they're implemented.

Curious to learn more about how jails + zones are implemented. In Linux land, I find the notion that containers are a coherent abstraction really hinders developers from understanding how their application is deployed.

Indeed they are! The notion that each process has its separate address space is called virtual memory for that reason.

See also cgroups: while this feature is used by the container run times, it predates Docker, and can be used standalone with normal processes.

Indeed. I made a website for testing npm packages inside a cgroup/unshared "container" - about 6 months before docker came out.

If only I had realised that could have been useful for more than testing npm packages...

OCI “docker” containers are at this point are a description of a process. How it’s realized is up to the implementor. runc realizes the container with kernel namespaceing and runv realizes the container with hardware virtualization.

Both if implemented to spec will be logically equivalent and drop-in replacements for one another.

I don't know if that is the most important reason it is not equivalent. It also doesn't have any system processes; there is no systemd, sshd, no crond, etc. It doesn't need its own firewall rules configured or its own security managed. I could go on but I think you already get the point.

Indeed - essentially, a container is a glorified chroot with a few (important) bells and whistles attached to it.

I agree with the other commentor, this is an important distinction. It has no hypervisor and is really just a normal process using standard kernel features: cgroups (resource limiting) and namespaces (resource isolation). It's really not so different to chroot.

Reply on news.ycombinator.com