I suspect they meant it runs natively in that it’s an aarch64 binary. It’s still running a VM under the hood because docker is really just a nice frontend to a bunch of Linux kernel features.
I can’t remember exactly what all the pieces are. However, I believe its a combination of
cgroups: process isolation which is why you can see docker processes in ps/top/etc but you can’t for vms. I believe this is also what gets you the ability to run cross distro images since the isolation ensures the correct shared objects are loaded
network namespaces: how they handle generating the isolated network stack per process
some additional mount magic that I don’t know what its called.
My understanding is that all of the neat properties of docker are actuall part of the kernel, docker (and podman and other container runtimes) are mostly just packing them together to achieve the desired properties of “containers”.
It makes it very easy to define the environment and conditions in which a process is run, and completely isolate it from the rest of the system. The environment includes all the other software installed in said isolated environment. Since you have complete isolation you can install all the software that comes with what we think if as a linux “distribution”, which means you can do something like run a docker container that is “ubuntu” or “debian” on a “CentOS” or whatever distribution.
When you start a Dockerfile with the statement FROM ubuntu:version_tag you are more or less saying “I want to run a process in an environment that includes all of the3 software that would ship with this specific version of ubuntu”
A linux distro == Kernel + “user land” (maybe not the correct terminology). A docker container is the “user land” or “distro” + whatever you’re wanting to run, but the Kernel is the host system.
I’ll also say that folks say pretty nonchalantly deride Docker and other tools as if it’s just “easy” to set these things up with “just linux” and Docker is something akin to syntax sugar. I suspect many of these folks don’t make software for a living, or at least don’t work at significant scale. It might be easy to create an isolated process, it’s absurd to say that Docker (or Podman, etc…) doesn’t add value. The reproducibility, layering, builders, orchestration, repos, etc… are all build on top of the features that allow isolation. None of that stuff existed before docker/other container build/deploy tools.
Note: I’m not a Linux SME, but I am a software dev who uses Docker every day — I am likely oversimplifying some things here, but this is a better and more accurate oversimplification than “docker is like a VM”, which is a helpful heuristic when you first learn it, but ultimately wrong
M1 is just worse arm. Since most people use x86_64 instead of arm, docker had to emulate that architecture and therefore had performance issues. Now you’ve got arm specific images that don’t require that hardware emulation layer, and so work a lot better.
Since that didn’t solve the Linux kernel requirement, it’s still running a VM to provide it.
Try limiting it down to 2GB (there is an option in the Docker Desktop app). Before I discovered this option, the VM was normally eating 3-4GB of my memory.
Does docker really spin up a VM to run containers?
Yes, under windows and osx at least.
Is that still true? I use Linux but my coworker said docker runs natively now on the M1s but maybe he was making it up
Maybe they just meant that it runs ARM binaries instead of running on Rosetta 2.
I suspect they meant it runs natively in that it’s an aarch64 binary. It’s still running a VM under the hood because docker is really just a nice frontend to a bunch of Linux kernel features.
What does it do anyway? I know there’s lxc in the kernel and Docker not using it, doing it’s own thing, but not much else.
I can’t remember exactly what all the pieces are. However, I believe its a combination of
My understanding is that all of the neat properties of docker are actuall part of the kernel, docker (and podman and other container runtimes) are mostly just packing them together to achieve the desired properties of “containers”.
It makes it very easy to define the environment and conditions in which a process is run, and completely isolate it from the rest of the system. The environment includes all the other software installed in said isolated environment. Since you have complete isolation you can install all the software that comes with what we think if as a linux “distribution”, which means you can do something like run a docker container that is “ubuntu” or “debian” on a “CentOS” or whatever distribution.
When you start a
Dockerfilewith the statementFROM ubuntu:version_tagyou are more or less saying “I want to run a process in an environment that includes all of the3 software that would ship with this specific version of ubuntu”A linux distro == Kernel + “user land” (maybe not the correct terminology). A docker container is the “user land” or “distro” + whatever you’re wanting to run, but the Kernel is the host system.
I found this pretty helpful in explaining it: https://earthly.dev/blog/chroot/
I’ll also say that folks say pretty nonchalantly deride Docker and other tools as if it’s just “easy” to set these things up with “just linux” and Docker is something akin to syntax sugar. I suspect many of these folks don’t make software for a living, or at least don’t work at significant scale. It might be easy to create an isolated process, it’s absurd to say that Docker (or Podman, etc…) doesn’t add value. The reproducibility, layering, builders, orchestration, repos, etc… are all build on top of the features that allow isolation. None of that stuff existed before docker/other container build/deploy tools.
Note: I’m not a Linux SME, but I am a software dev who uses Docker every day — I am likely oversimplifying some things here, but this is a better and more accurate oversimplification than “docker is like a VM”, which is a helpful heuristic when you first learn it, but ultimately wrong
Whoah, thanks! Saved, i’ll read it later.
Docker requires the Linux kernel to work.
M1 is just worse arm. Since most people use x86_64 instead of arm, docker had to emulate that architecture and therefore had performance issues. Now you’ve got arm specific images that don’t require that hardware emulation layer, and so work a lot better.
Since that didn’t solve the Linux kernel requirement, it’s still running a VM to provide it.
Not making it up, but possibly confused. OCI containers are built on Linux-only technologies.
So that’s why it’s so memory hungry…
Try limiting it down to 2GB (there is an option in the Docker Desktop app). Before I discovered this option, the VM was normally eating 3-4GB of my memory.
On macos it does