6 ms·

>They are just an OS running like a VM. This is exactly what Docker containers AREN'T. Don't think of containers like tiny VMs. Think of them as processes wit

>They are just an OS running like a VM. This is exactly what Docker containers AREN'T. Don't think of containers like tiny VMs. Think of them as processes with additional isolation from each other.

3fe9a03ccd14ca5 7y ago
A VM is a good way to logically think about the containers, and I’m sure it’s the way the vast majority of people first think about them. Under the hood they are simply a process isolated with namespaces, but their behavior on the outside feels like getting a VM.
- FartyMcFarter 7y ago
  But docker containers don't run their own kernel, which is a huge difference to a VM.
  - 3fe9a03ccd14ca5 7y ago
    My point is that most people don’t even really know that’s how a VM works. They just think of a VM as a fresh sandbox where they can install and run stuff without deleting somebody else’s files or programs.
    - wrs 7y ago
      I'm hearing a repeated theme in your comments that people don't know much about how anything works, and that's supposedly OK. That's actually not OK. :)
      - kortex 7y ago
        No, that's how learning curves work. Until we can Matrix beam info into our skulljack, humans will spend a notrivial amount of time having to make do with using things while not fully understanding how they work. Unless one is 31337-rockstar-ninja-IQ150-programmer, the uptake of new skills is painful and takes time. The pedagogical process is important. It's totally OK to not know how anything works as long as you acknowledge that and are willing to learn.
        wrs 7y ago
        I totally agree. That wasn’t the sentiment I was responding to, which sounded more like “nobody knows how that works, and they don’t really need to, so why are you wasting their time explaining how it actually works?”
  - ignoramous 7y ago
    Neither does the JVM. Never a good idea to cling onto text-book definitions in this cloud industry full of buzz words.
    - _jal 7y ago
      It is never a good idea to not understand what you're doing, especially when the boundaries of who does what are moving around. I'm mostly an ops person in outlook, although I was a programmer for over a decade and write my share of code. The software-ization of infra is a good thing; unlike some ops folks, I don't find it threatening, I find it cool. What I find dismaying is some of the horrific stuff I catch before it gets to production, and what I do find threatening in a different way is worrying about what I miss. Moving OS-level dependency management in to dockerfiles? Great! How are you scanning that against CVEs? If you don't know you're not running a different kernel, I have a sneaking suspicion you're... not. And so on down the list of traditional ops practices I frequently discover developers had no idea even happened.
  - kortex 7y ago
    So? There is nowhere in the docker-noob's workflow where the huge distinction between a docker container instance and a super light VM actually matters. Source: I knew nearly nothing about docker a year ago. And now I'm one of my company's go-to people for docker questions. The pain is still fresh in my mind and I see noob-pain every day :)
- deleted 7y ago
  [deleted]
- 0x8BADF00D 7y ago
  Why not correct the misinformation then? Docker is nothing like a VM. It uses cgroups to reserve resources like CPU, memory, etc, and namespaces to isolate containers and their respective processes. VM applications will have to emulate hardware, so the kernel running under VM is able to enumerate hardware devices. Virtual machine emulates a computer with a full ISA.
  - osipov 7y ago
    You are describing the specific technical details about how Docker containers are implemented. The analogy to VMs comes from the observation that VMs virtualize the hardware while containers virtualize the operating system.
    - deleted 7y ago
      [deleted]
    - Izkata 7y ago
      > The analogy to VMs comes from the observation that VMs virtualize the hardware while containers virtualize the operating system. Aaaand that off-the-cuff statement clears up the difference between them that I've been missing for months. Containers really do just look like a VM, if you don't know the implementation details and are just using them.
  - mr_toad 7y ago
    > Virtual machine emulates a computer with a full ISA. You probably didn’t mean that they literally emulate an instruction set, because most modern hypervisors don’t emulate most instructions.
  - viraptor 7y ago
    I wouldn't describe it this way if your goal is to correct misinformation. VMs can definitely pass through real hardware instead of emulation. (most often used for GPUs and network cards) And docker containers can use emulated hardware. (from the app's point of view) Normal processes can run emulated hardware via user-mode linux. The idea of a VM is so messy these days, it's best to define what kind of VM are you talking about first. (language? system? foreign hardware?)
nailer 7y ago
> Think of them as processes with additional isolation from each other. That's true, but as VMs also isolate processes from each other, this can confuse others. Let's be more exact: A VM = isolated kernel and userspace. - Advantages: security - Disadvantages: speed A container = isolated userspace only. Shared kernel. - Advantages: speed, size - Disadvantages: security Both can have pre-created images to avoid the problem of recreating workspace. Docker did not invent orchestration.
- notyourday 7y ago
  > - Disadvantages: speed Nuh? Of starting, sure. Of running? A margin of error.
  - nailer 7y ago
    Running an app inside a container on bare metal is way faster than running an app in a VM on bare metal. - Containers in this case: userspace on kernel on hardware - VMs in this case: userspace on kernel on virtual hardware on kernel on hardware. There are very fast VMs (the Firecracker MIcroVM) but they're not in popular use.
    - notyourday 7y ago
      You are hopelessly out of date. VMs are not Xen with emulation. Neither are they the original VMware. Nor are they QEMU without acceleration. VMs are qemu-system-x86_64 -machine accel=kvm or whatever is the platform specific way to run a VM under a hypervisor. This has been the case since hypervisors showed up on the scene, aka right after what was the predecessor of Virtuozzo
      - nailer 7y ago
        Xen was never an emulator. That's technically incorrect. Not does the definition of VM change because of hardware acceleration. That's also technically incorrect.
ryukafalz 7y ago
If we were just talking about namespaces alone, I'd agree. As it's commonly used, though, Docker containers often contain a whole distro userspace too. (But sure, you're typically only starting one process with the container.)
deleted 7y ago
[deleted]
k__ 7y ago
It's like saying interfaces are classes without implementation.
kortex 7y ago
Except they feel for all intents and purposes like tiny VMs. If I gave a pre-Docker era engineer two terminals, one host, one in a container, they'd probably quickly figure out they are on the same physical machine. But unless they were super savvy at some very specific stuff, they'd probably conclude it was just a VM. Every dev I've introduced to docker workflows basically treat it like a vm. The only ones that didn't already had experience with cgroups/chroot and related tools. It's honestly better to think of Docker as "VM, but actually you use the same kernel" than "processes that are isolated". Other poster compared it to electron models. Yes, "balls in orbits" is wrong, but kids are already familiar with planetary orbits, and that mental model works until basically Organic Chem II.

>They are just an OS running like a VM. This is exactly what Docker containers AREN'T. Don't think of containers like tiny VMs. Think of them as processes with additional isolation from each other.

3fe9a03ccd14ca5 7y ago

A VM is a good way to logically think about the containers, and I’m sure it’s the way the vast majority of people first think about them. Under the hood they are simply a process isolated with namespaces, but their behavior on the outside feels like getting a VM.

FartyMcFarter 7y ago
But docker containers don't run their own kernel, which is a huge difference to a VM.
- 3fe9a03ccd14ca5 7y ago
  My point is that most people don’t even really know that’s how a VM works. They just think of a VM as a fresh sandbox where they can install and run stuff without deleting somebody else’s files or programs.
  - wrs 7y ago
    I'm hearing a repeated theme in your comments that people don't know much about how anything works, and that's supposedly OK. That's actually not OK. :)
    - kortex 7y ago
      No, that's how learning curves work. Until we can Matrix beam info into our skulljack, humans will spend a notrivial amount of time having to make do with using things while not fully understanding how they work. Unless one is 31337-rockstar-ninja-IQ150-programmer, the uptake of new skills is painful and takes time. The pedagogical process is important. It's totally OK to not know how anything works as long as you acknowledge that and are willing to learn.
      - wrs 7y ago
        I totally agree. That wasn’t the sentiment I was responding to, which sounded more like “nobody knows how that works, and they don’t really need to, so why are you wasting their time explaining how it actually works?”
- ignoramous 7y ago
  Neither does the JVM. Never a good idea to cling onto text-book definitions in this cloud industry full of buzz words.
  - _jal 7y ago
    It is never a good idea to not understand what you're doing, especially when the boundaries of who does what are moving around. I'm mostly an ops person in outlook, although I was a programmer for over a decade and write my share of code. The software-ization of infra is a good thing; unlike some ops folks, I don't find it threatening, I find it cool. What I find dismaying is some of the horrific stuff I catch before it gets to production, and what I do find threatening in a different way is worrying about what I miss. Moving OS-level dependency management in to dockerfiles? Great! How are you scanning that against CVEs? If you don't know you're not running a different kernel, I have a sneaking suspicion you're... not. And so on down the list of traditional ops practices I frequently discover developers had no idea even happened.
- kortex 7y ago
  So? There is nowhere in the docker-noob's workflow where the huge distinction between a docker container instance and a super light VM actually matters. Source: I knew nearly nothing about docker a year ago. And now I'm one of my company's go-to people for docker questions. The pain is still fresh in my mind and I see noob-pain every day :)
deleted 7y ago
[deleted]
0x8BADF00D 7y ago
Why not correct the misinformation then? Docker is nothing like a VM. It uses cgroups to reserve resources like CPU, memory, etc, and namespaces to isolate containers and their respective processes. VM applications will have to emulate hardware, so the kernel running under VM is able to enumerate hardware devices. Virtual machine emulates a computer with a full ISA.
- osipov 7y ago
  You are describing the specific technical details about how Docker containers are implemented. The analogy to VMs comes from the observation that VMs virtualize the hardware while containers virtualize the operating system.
  - deleted 7y ago
    [deleted]
  - Izkata 7y ago
    > The analogy to VMs comes from the observation that VMs virtualize the hardware while containers virtualize the operating system. Aaaand that off-the-cuff statement clears up the difference between them that I've been missing for months. Containers really do just look like a VM, if you don't know the implementation details and are just using them.
- mr_toad 7y ago
  > Virtual machine emulates a computer with a full ISA. You probably didn’t mean that they literally emulate an instruction set, because most modern hypervisors don’t emulate most instructions.
- viraptor 7y ago
  I wouldn't describe it this way if your goal is to correct misinformation. VMs can definitely pass through real hardware instead of emulation. (most often used for GPUs and network cards) And docker containers can use emulated hardware. (from the app's point of view) Normal processes can run emulated hardware via user-mode linux. The idea of a VM is so messy these days, it's best to define what kind of VM are you talking about first. (language? system? foreign hardware?)

nailer 7y ago

> Think of them as processes with additional isolation from each other. That's true, but as VMs also isolate processes from each other, this can confuse others. Let's be more exact: A VM = isolated kernel and userspace. - Advantages: security - Disadvantages: speed A container = isolated userspace only. Shared kernel. - Advantages: speed, size - Disadvantages: security Both can have pre-created images to avoid the problem of recreating workspace. Docker did not invent orchestration.

notyourday 7y ago
> - Disadvantages: speed Nuh? Of starting, sure. Of running? A margin of error.
- nailer 7y ago
  Running an app inside a container on bare metal is way faster than running an app in a VM on bare metal. - Containers in this case: userspace on kernel on hardware - VMs in this case: userspace on kernel on virtual hardware on kernel on hardware. There are very fast VMs (the Firecracker MIcroVM) but they're not in popular use.
  - notyourday 7y ago
    You are hopelessly out of date. VMs are not Xen with emulation. Neither are they the original VMware. Nor are they QEMU without acceleration. VMs are qemu-system-x86_64 -machine accel=kvm or whatever is the platform specific way to run a VM under a hypervisor. This has been the case since hypervisors showed up on the scene, aka right after what was the predecessor of Virtuozzo
    - nailer 7y ago
      Xen was never an emulator. That's technically incorrect. Not does the definition of VM change because of hardware acceleration. That's also technically incorrect.

ryukafalz 7y ago

If we were just talking about namespaces alone, I'd agree. As it's commonly used, though, Docker containers often contain a whole distro userspace too. (But sure, you're typically only starting one process with the container.)

deleted 7y ago

[deleted]

k__ 7y ago

It's like saying interfaces are classes without implementation.

kortex 7y ago

Except they feel for all intents and purposes like tiny VMs. If I gave a pre-Docker era engineer two terminals, one host, one in a container, they'd probably quickly figure out they are on the same physical machine. But unless they were super savvy at some very specific stuff, they'd probably conclude it was just a VM. Every dev I've introduced to docker workflows basically treat it like a vm. The only ones that didn't already had experience with cgroups/chroot and related tools. It's honestly better to think of Docker as "VM, but actually you use the same kernel" than "processes that are isolated". Other poster compared it to electron models. Yes, "balls in orbits" is wrong, but kids are already familiar with planetary orbits, and that mental model works until basically Organic Chem II.