6 ms·

> Containers are "bare metal" Please explain this use of jargon. Are you saying that a Docker container is "bare metal" in some culture? A VM is bare metal?

> Containers are "bare metal" Please explain this use of jargon. Are you saying that a Docker container is "bare metal" in some culture? A VM is bare metal? What do you mean by container, and bare metal?

m0zg 8y ago
Containers are just namespaces for things within the Linux kernel. Unlike with VMs, you're not running separate instances of the OS, it's all run by just one kernel instance, and that kernel usually runs directly on the hardware, that is, on "bare metal". That "ubuntu" base image you can spin up does not actually run the Ubuntu kernel. As a result, bare metal containers incur none of the "virtualization penalty" that VMs do. Cloud is, in fact, abnormal in terms of how containers are used in that it wraps them into VMs. That's in part because VMs were already there and they simplify provisioning of something that looks like "machines" from the outside, and in part because containers do not offer much in the way of security guarantees (precisely because all containers running on the same host share the kernel), whereas VMs do.
- jhayward 8y ago
  Ah, you're using it to mean "no virtualization". Got it, thanks. I tend to use the term to mean single-tenant, user-supplied OS, non-virtualized myself but I see where you're coming from.
  - richardwhiuk 8y ago
    All of that may be true as well - if the user picks the underlying OS (i.e. kernel) to run the container engine and installs on bare metal, then literally everything you wrote applies.
  - lunchables 8y ago
    My workstation runs multiple processes in multiple namespaces without containers. Is it bare metal? What if I install applications via flatpak? Still bare metal? Now what if I use docker?
- scott_s 8y ago
  It's tempting to say that containers don't have any virtualization costs, but they often do for networking. For some applications, the addition of another networking driver doesn't matter. For others, it does.
  - m0zg 8y ago
    There is no "another networking driver" in containers. It's the same networking driver.
    - scott_s 8y ago
      For standard Docker container deployments, there is. See: https://docs.docker.com/network/ https://docs.docker.com/network/
      - m0zg 8y ago
        That's not a "driver" in the traditional sense, meaning it doesn't talk to the actual hardware directly. It's just a bridge or iptables.
        scott_s 8y ago
        shrug It's additional software in the networking stack, and it has a performance penalty. I think it's fair to call it a "virtualization cost," since you're paying for the container's networking abstraction.
umanwizard 8y ago
I think GP meant in the sense that Docker containers are just normal programs whose instructions are being executed directly by the CPU (just like how my laptop is executing Firefox as I type this) without relying on hardware virtualization features.

m0zg 8y ago

Containers are just namespaces for things within the Linux kernel. Unlike with VMs, you're not running separate instances of the OS, it's all run by just one kernel instance, and that kernel usually runs directly on the hardware, that is, on "bare metal". That "ubuntu" base image you can spin up does not actually run the Ubuntu kernel. As a result, bare metal containers incur none of the "virtualization penalty" that VMs do. Cloud is, in fact, abnormal in terms of how containers are used in that it wraps them into VMs. That's in part because VMs were already there and they simplify provisioning of something that looks like "machines" from the outside, and in part because containers do not offer much in the way of security guarantees (precisely because all containers running on the same host share the kernel), whereas VMs do.

jhayward 8y ago
Ah, you're using it to mean "no virtualization". Got it, thanks. I tend to use the term to mean single-tenant, user-supplied OS, non-virtualized myself but I see where you're coming from.
- richardwhiuk 8y ago
  All of that may be true as well - if the user picks the underlying OS (i.e. kernel) to run the container engine and installs on bare metal, then literally everything you wrote applies.
- lunchables 8y ago
  My workstation runs multiple processes in multiple namespaces without containers. Is it bare metal? What if I install applications via flatpak? Still bare metal? Now what if I use docker?
scott_s 8y ago
It's tempting to say that containers don't have any virtualization costs, but they often do for networking. For some applications, the addition of another networking driver doesn't matter. For others, it does.
- m0zg 8y ago
  There is no "another networking driver" in containers. It's the same networking driver.
  - scott_s 8y ago
    For standard Docker container deployments, there is. See: https://docs.docker.com/network/ https://docs.docker.com/network/
    - m0zg 8y ago
      That's not a "driver" in the traditional sense, meaning it doesn't talk to the actual hardware directly. It's just a bridge or iptables.
      - scott_s 8y ago
        shrug It's additional software in the networking stack, and it has a performance penalty. I think it's fair to call it a "virtualization cost," since you're paying for the container's networking abstraction.

umanwizard 8y ago

I think GP meant in the sense that Docker containers are just normal programs whose instructions are being executed directly by the CPU (just like how my laptop is executing Firefox as I type this) without relying on hardware virtualization features.