principledockerMinor
Docker vs Virtualisation
Viewed 0 times
dockervirtualisationstackoverflow
Problem
I am trying to understand the underlining architecture of Docker. The diagram that's been shown everywhere claims that in contrast with Virtualisation technologies such as "VirtualBox", Docker uses the OS of the host directly and only ships the applications together with dependencies such as libraries etc. Now, from what I can see in Docker, every image includes an OS. It starts with a
FROM tag. Isn't this contradictory to what's been claimed? Please advise.Solution
First, Docker is just a company. =)
There are two methods of isolating things,
For all intents and purposes, methods that do not isolate the kernel are called "containerization", while those that do are called "virtualization". In industry almost 100% of the use cases of "containerization" refer to Linux Containerization. It's for the most part correct to say that containers are a Linux thing. One more point of confusion, many non-Linux systems that support "native" containerization do so with a virtual machines which means that you have the native kernel (like Darwin/BSD) running on the host, and a Linux kernel running in a virtual machine which hosts just the container environment. As a rule of thumb,
It's not true that just because something does not virtualize the kernel, that it's not isolated from the host. While it's true Linux containers are just processes, and thus,
Containerized processes must
As a last point, just to drive it home, because
Then we tend to say any process on Linux that makes use of namespaces is running in a container, moreso if it's using cgroups.
As a final point, typically when you hear "Docker Image" people mean an OCI Compliant Image, which is what everyone uses.
When you see
In a dockerfile, what you're actually saying is that you want to in git-parlance clone a working set of stuff and build on top of it. This stuff does not include a kernel. But it will include everything else because you will not have access to the system's stuff. (The container is in a different namespace and isolated). For example, a container must include a copy of glibc if needed, and a container of Debian must include apt and other Debian based utilities that constitute a "core" system.
There are two methods of isolating things,
- Methods that isolate the kernel.
- Methods that do not isolate the kernel.
For all intents and purposes, methods that do not isolate the kernel are called "containerization", while those that do are called "virtualization". In industry almost 100% of the use cases of "containerization" refer to Linux Containerization. It's for the most part correct to say that containers are a Linux thing. One more point of confusion, many non-Linux systems that support "native" containerization do so with a virtual machines which means that you have the native kernel (like Darwin/BSD) running on the host, and a Linux kernel running in a virtual machine which hosts just the container environment. As a rule of thumb,
- Containerization is always less secure: vulnerable to kernel-level exploits.
- Containerization is always faster: less context switching and hypervisor overhead.
It's not true that just because something does not virtualize the kernel, that it's not isolated from the host. While it's true Linux containers are just processes, and thus,
- Visible from the host
- Subject to any kernel level resource optimizations, like memory deduplication
Containerized processes must
- Run in a different namespaces which, barring a kernel-level exploit, isolate them from other process on the machine
- (Usually) run in isolated cgroups subject to different quotas and limits.
As a last point, just to drive it home, because
- Containerization typically refers to the implementation in Linux.
- Linux has no native concept of containerization itself, only providing cgroups (resource control) and namespaces (isolation)
- A container is just a native process
Then we tend to say any process on Linux that makes use of namespaces is running in a container, moreso if it's using cgroups.
As a final point, typically when you hear "Docker Image" people mean an OCI Compliant Image, which is what everyone uses.
When you see
FROM In a dockerfile, what you're actually saying is that you want to in git-parlance clone a working set of stuff and build on top of it. This stuff does not include a kernel. But it will include everything else because you will not have access to the system's stuff. (The container is in a different namespace and isolated). For example, a container must include a copy of glibc if needed, and a container of Debian must include apt and other Debian based utilities that constitute a "core" system.
Code Snippets
FROM <os-image>Context
StackExchange DevOps Q#15825, answer score: 7
Revisions (0)
No revisions yet.