5 ms·

"OS running like a VM" is a wrong summary. Containers are collection of namespaces. Docker manages (starts , stops etc) these containers. It also provides an ea

"OS running like a VM" is a wrong summary. Containers are collection of namespaces. Docker manages (starts , stops etc) these containers. It also provides an easy gateway into readymade container images.

capableweb 7y ago
I think Waterluvian's point was that _before_ you start talking about things like containers, namespaces, images and so on, you need to explain the basics. Depending on the previous knowledge, your summary may or may not make sense. If you don't know what containers, namespaces or images mean here (basically, you haven't seen docker before), then your summary makes no sense. If you're a programmer, you most probably have heard about OSes and VMs before, one way or another. Then, the analogy is a bit easier for the beginner to understand. Hence the "slightly wrong but somehow still manages to be a bit informative"-summary Waterluvian gave can teach the beginner the first steps.
- Waterluvian 7y ago
  Yeah. I'm getting a lot of "no it's not that". And surely this failing is on my end. But I'd learn better with an approach of "yes it's like a VM in these ways. But then it's different in these ways..." Maybe it's just me. I love teaching and learning by starting with a common but wrong model and learning piece by piece what's different until its an evolved, more accurate model.
Waterluvian 7y ago
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?
- detaro 7y ago
  > 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!
- dharmab 7y ago
  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.
  - Waterluvian 7y ago
    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.
    - akvadrako 7y ago
      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.
    - sammnaser 7y ago
      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/bcdd3818e932eda677301ae5d81c80e010793c91/bionic/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.
    - umanwizard 7y ago
      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.
    - bspammer 7y ago
      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.
- brutal_boi 7y ago
  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.
- mav3rick 7y ago
  Just goes to show how lying about concepts never helps your understanding.
tootie 7y ago
It's an exactly correct summary from a user's point of view and the fact that everyone says it's wrong is just confusing people. Virtual Machine is a concept and doesn't have or require a technical definition. The fact that Docker doesn't require a hypervisor is completely irrelevant to everyone who isn't working the core Docker platform. Containers provide a layer of indirection that imitates a completely separate and distinct operating system on top of a host OS. That's a VM to the eyes every developer who just needs to run Linux operations from OSX or Windows.
- umanwizard 7y ago
  The distinction is relevant to me for the simple reason that I can run “top” from a normal shell and see what’s going on in all my containers, attach debuggers to them, etc.
- bspammer 7y ago
  To confuse things even further, Docker on OSX and Windows actually does use a fully-fledged VM that the containers run on. Truly understanding the Linux kernel namespacing features that Docker is built on certainly takes more effort to learn, but I disagree that it's irrelevant to anyone not working at Docker. Understanding your tools makes you a better developer, and allows you to understand what is and isn't possible.
seppel 7y ago
> "OS running like a VM" is a wrong summary. I think it is a fair summary, because the implications of running in Docker are often the same as running a real VM. To exemplify, a common mistake is to run a server as the entrypoint of the docker container. The server will then run as PID 1, with all the implications and responsibilities an init process has. This causes a lot of subtile and annoying problems.
- mav3rick 7y ago
  The container is running on the same kernel as the host. That is not the case with a VM.
  - seppel 7y ago
    Well, not if you use Docker on Windows or Mac. But these are technicalities that don't matter that much. Unless you are writing kernel drivers or you need to tweak certain kernel parameters, running in a Docker container is very much as running in a VM. With the same responsibilities, e.g., setting up an init process.
    - mav3rick 7y ago
      A CVE on your host kernel affects your container. Not your VM. So yes it does "matter much".

capableweb 7y ago

I think Waterluvian's point was that _before_ you start talking about things like containers, namespaces, images and so on, you need to explain the basics. Depending on the previous knowledge, your summary may or may not make sense. If you don't know what containers, namespaces or images mean here (basically, you haven't seen docker before), then your summary makes no sense. If you're a programmer, you most probably have heard about OSes and VMs before, one way or another. Then, the analogy is a bit easier for the beginner to understand. Hence the "slightly wrong but somehow still manages to be a bit informative"-summary Waterluvian gave can teach the beginner the first steps.

Waterluvian 7y ago
Yeah. I'm getting a lot of "no it's not that". And surely this failing is on my end. But I'd learn better with an approach of "yes it's like a VM in these ways. But then it's different in these ways..." Maybe it's just me. I love teaching and learning by starting with a common but wrong model and learning piece by piece what's different until its an evolved, more accurate model.

Waterluvian 7y ago

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?

detaro 7y ago
> 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!
dharmab 7y ago
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.
- Waterluvian 7y ago
  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.
  - akvadrako 7y ago
    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.
  - sammnaser 7y ago
    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/bcdd3818e932eda677301ae5d81c80e010793c91/bionic/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.
  - umanwizard 7y ago
    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.
  - bspammer 7y ago
    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.
brutal_boi 7y ago
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.
mav3rick 7y ago
Just goes to show how lying about concepts never helps your understanding.

tootie 7y ago

It's an exactly correct summary from a user's point of view and the fact that everyone says it's wrong is just confusing people. Virtual Machine is a concept and doesn't have or require a technical definition. The fact that Docker doesn't require a hypervisor is completely irrelevant to everyone who isn't working the core Docker platform. Containers provide a layer of indirection that imitates a completely separate and distinct operating system on top of a host OS. That's a VM to the eyes every developer who just needs to run Linux operations from OSX or Windows.

umanwizard 7y ago
The distinction is relevant to me for the simple reason that I can run “top” from a normal shell and see what’s going on in all my containers, attach debuggers to them, etc.
bspammer 7y ago
To confuse things even further, Docker on OSX and Windows actually does use a fully-fledged VM that the containers run on. Truly understanding the Linux kernel namespacing features that Docker is built on certainly takes more effort to learn, but I disagree that it's irrelevant to anyone not working at Docker. Understanding your tools makes you a better developer, and allows you to understand what is and isn't possible.

seppel 7y ago

> "OS running like a VM" is a wrong summary. I think it is a fair summary, because the implications of running in Docker are often the same as running a real VM. To exemplify, a common mistake is to run a server as the entrypoint of the docker container. The server will then run as PID 1, with all the implications and responsibilities an init process has. This causes a lot of subtile and annoying problems.

mav3rick 7y ago
The container is running on the same kernel as the host. That is not the case with a VM.
- seppel 7y ago
  Well, not if you use Docker on Windows or Mac. But these are technicalities that don't matter that much. Unless you are writing kernel drivers or you need to tweak certain kernel parameters, running in a Docker container is very much as running in a VM. With the same responsibilities, e.g., setting up an init process.
  - mav3rick 7y ago
    A CVE on your host kernel affects your container. Not your VM. So yes it does "matter much".