<p>run <code>uname -r</code> inside a docker image and then on your base os, you'll notice it's the same kernel</p>
<pre><code>bash-4.4# uname -r
3.10.0-1160.59.1.el7.x86_64
bash-4.4# exit
[petturn@h-mybox-2 ~]$ uname -r
3.10.0-1160.59.1.el7.x86_64
</code></pre>
<p>that's probably the biggest distinction between virtualization and containerization.   A virtual machine is running it's own kernel, a container runs inside the space of your base OS. You see the processes and everything.  What neither of them can (or should) be able to do is interact with the base OS.</p>
<p>When you build a container &quot;from ubuntu&quot; or whatever, I believe that has more to do with specifying the toolchains you're building from.</p>
<p>If you build a container &quot;from scratch&quot; (I've never <a href="https://linuxhint.com/create_docker_image_from_scratch/" rel="nofollow noreferrer">tried this</a>, but it seems like fun), I think that'd become apparent!</p>

CC BY-SA 4.0
2022-04-20T18:45:50.583Z
It's somewhat common to deploy go and Rust in Distroless, which is like scratch but with SSL certs and a few other files that POSIX requires. Keep your image size under 10 MB.
Evan Carroll
CC BY-SA 4.0
2022-04-20T14:31:20.787Z
2022-04-20T14:31:20.787Z
Peter Turner
<p>First, Docker is just a company. =)</p>
<p>There are two methods of isolating things,</p>
<ul>
<li>Methods that isolate the kernel.</li>
<li>Methods that do not isolate the kernel.</li>
</ul>
<p>For all intents and purposes, methods that do not isolate the kernel are called &quot;containerization&quot;, while those that do are called &quot;virtualization&quot;. In industry almost 100% of the use cases of &quot;containerization&quot; 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 &quot;native&quot; 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,</p>
<ul>
<li>Containerization is always less secure: vulnerable to kernel-level exploits.</li>
<li>Containerization is always faster: less context switching and hypervisor overhead.</li>
</ul>
<p>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 <em>just</em> processes, and thus,</p>
<ul>
<li>Visible from the host</li>
<li>Subject to any kernel level resource optimizations, like memory deduplication</li>
</ul>
<p>Containerized processes must</p>
<ul>
<li>Run in a different namespaces which, barring a kernel-level exploit, isolate them from other process on the machine</li>
<li>(Usually) run in isolated cgroups subject to different quotas and limits.</li>
</ul>
<p>As a last point, just to drive it home, because</p>
<ul>
<li>Containerization typically refers to the implementation in Linux.</li>
<li>Linux has no native concept of containerization itself, only providing cgroups (resource control) and namespaces (isolation)</li>
<li>A container is just a native process</li>
</ul>
<p>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.</p>
<p>As a final point, typically when you hear &quot;Docker Image&quot; people mean an OCI Compliant Image, which is what everyone uses.</p>
<hr />
<p>When you see</p>
<pre><code>FROM &lt;os-image&gt;
</code></pre>
<p>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 <strong>everything</strong> 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 &quot;core&quot; system.</p>

CC BY-SA 4.0
2022-04-20T18:02:55.613Z
2022-05-04T23:15:55.917Z
2022-05-04T23:15:55.917Z
Evan Carroll
<p>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 &quot;VirtualBox&quot;, 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 <code>FROM &lt;os-image&gt;</code> tag. Isn't this contradictory to what's been claimed? Please advise.</p>

CC BY-SA 4.0
2022-04-20T14:45:53.557Z
I believe that if you reframe the question a bit, you might get more insight from the answers you get here. when you declare an upstream in a docker file, it is an _image_, not an _OS_. so reframe from `FROM <os-image>` to `FROM <image>`. The OS concept has disappeared. You find upstream images that _look_ like OS's, because that's what people have been comfortable with. They are instead just a bunch of files in a tarball. In order to run, they need a kernel to create a userspace for them. More BSD jail than VM.
Bruce Becker
CC BY-SA 4.0
2022-04-26T18:21:57.903Z
Running a full Ubuntu or other usable OS in a container is common yet regrettable practice.  These containers eat more memory and so take longer to start and more resources in production.  If you only have one or two so what, but when you have thousands this can add up to lots of wasted money.
chicks
<docker><containers><virtualization>
Docker vs Virtualisation
Mike M
# Docker vs Virtualisation

(Asked by: username_0 on 2022-04-20)

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.

**Tags:** docker, containers, virtualization

> **Comments:**
> **username_1**: I believe that if you reframe the question a bit, you might get more insight from the answers you get here. when you declare an upstream in a docker file, it is an _image_, not an _OS_. so reframe from `FROM <os-image>` to `FROM <image>`. The OS concept has disappeared. You find upstream images that _look_ like OS's, because that's what people have been comfortable with. They are instead just a bunch of files in a tarball. In order to run, they need a kernel to create a userspace for them. More BSD jail than VM.  
> **username_2**: Running a full Ubuntu or other usable OS in a container is common yet regrettable practice.  These containers eat more memory and so take longer to start and more resources in production.  If you only have one or two so what, but when you have thousands this can add up to lots of wasted money.  

---

## 2 answers

### Answer by username_4 on 2022-04-20. Score: 7 | Accepted answer

First, Docker is just a company. =)
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.


---

### Answer by username_3 on 2022-04-20. Score: 0

run uname -r inside a docker image and then on your base os, you'll notice it's the same kernel
bash-4.4# uname -r
3.10.0-1160.59.1.el7.x86_64
bash-4.4# exit
[petturn@h-mybox-2 ~]$ uname -r
3.10.0-1160.59.1.el7.x86_64

that's probably the biggest distinction between virtualization and containerization.   A virtual machine is running it's own kernel, a container runs inside the space of your base OS. You see the processes and everything.  What neither of them can (or should) be able to do is interact with the base OS.
When you build a container "from ubuntu" or whatever, I believe that has more to do with specifying the toolchains you're building from.
If you build a container "from scratch" (I've never tried this, but it seems like fun), I think that'd become apparent!

> **Comments:**
> **username_4**: It's somewhat common to deploy go and Rust in Distroless, which is like scratch but with SSL certs and a few other files that POSIX requires. Keep your image size under 10 MB.  

---

