5 ms·

> Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. can you go into a little more depth? my understanding of a VM is tha

> Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. can you go into a little more depth? my understanding of a VM is that it installs the OS in a dedicated memory partition, and allocates hardware resources separately from that of the host machine, such that resource contention between host and VM never happens. the VM allocated resources just go dark for the host machine while the VM is running. what is a lower level than that? I've understood containers to be thin wrappers around VMs, which would make them higher level, not lower level. do I have this wrong?

tracker1 10y ago
Containers aren't VMs... they're more of a sandboxed model of execution with a virtual network/disk abstraction. But lower/higher you are right, VM is probably lower-level abstraction of an entire system. But a container can be a single executable, it doesn't have to be an entire OS structure. For example, a lot of the go app containers are just the single executable by itself as a default. Many will rely on a debian/ubuntu base as they want other systems to work. This is mainly because of shared environments/libraries that some non-dockerized systems need, but isn't a requirement.
NikolaeVarius 10y ago
I'm doing a bit of a simplification here so please someone correct me if I'm not saying this correctly Every single instance of a VM has its own Kernel. When a VM boots up, it gets allocated a portion of hardware and boots up a kernel and allocates memory to itself. VMs each are isolated from each other in that they don't share resources and each VM is free to do whatever it wants to do with the hardware it is given. Like you said, to the host machine, that hardware is no longer available for any other VM to use. For Containers, they all live on a SINGLE kernel. They share resources across each other and the Kernel handles the multiple processes much like it would handle any other multithreaded process. If you have 3 VMs that all require a specific set of resources to run an application, you need 3x that hardware. This is not true for containers. You can get away with less because the containers will share the resources that the kernel as access to. I call them "lower level" in the sense that they do so much less than VMs. You CAN use containers as a VM in that a container can boot an entire Kernel, but generally you don't do this.
- user5994461 10y ago
  VMs share resources from the host: disk, network, memory. Just like a container shares resources from the host. Containers re-use the running Operating System from the host, it saves memory but it can only run a single OS. A VM can run any operating system, and each VM runs its OS independently. VMs are memory intensive, there is a base 100-500MB to pay to run any VM because of the independent OS. (Note that the advanced VM managers have evolved to have memory deduplication and COW across VMs.) Containers exist to save memory. That was the critical pain at the time they came to existence. Memory was expensive, it was a major problem when you wanted to run 10 hello world applications as 10 separate VMs.
  - ec109685 10y ago
    Containers give the OS the ability to optimally schedule processes among them. VMs are black boxes to the hypervisor, limiting its ability to optimize.
    - user5994461 10y ago
      The hypervisor has processes inside the VMs. It has limited control but it is far from blind.
novembermike 10y ago
Basically, a VM pretends it has a cpu and a disk and ram, a container pretends that it has a root directory and ports and all of that stuff. Like always it's a leaky abstraction and isn't usually sufficient for security purposes (ie. two containers on the same system might be able to talk to each other if you abuse the system) but it's good enough for most purposes and provides much better resource utilization than a bunch of VMs.
SFJulie 10y ago
old way: one chroot per user and quota (including ulimit) per user new way: limits handled with cgroups security with namespace related to user's profile. namespace can do syscall limitations, and also offer unique network access per users. Roughly simplified. freebsd jails where known as glass jails that would eventually break, LXC/docker are the same except they hav'nt broke yet at the price of more complexity. They will all dramatically break when people will have figured the trick in 5 years. Simple solution : understand the problem and fix it. Actual solution: throw more complexity and obfuscation at the problem claiming users are THE problem. Companies and devops don't care, they have a future of at least 10 years in fat paychecks and stock options.
- koffiezet 10y ago
  > They will all dramatically break when people will have figured the trick in 5 years. VM's hypervisors have also seen bugs/exploits to gain hypervisor access, and yet they're still here. These things have been fixed, and people did not stop using them. Also, I don't really see the "more complexity and obfuscation" thrown at "the problem", can you enlighten me?
  - SFJulie 10y ago
    Old ways: you trust a person. And You check. New ways: you create very complex sets of syscalls permissions that can be fine tuned by using a Role Based Accounting or any Auth/Profile Framework. The idea is that you got rid of the risk of mischief/compromission by containing the code and people by delegating trust to external stuff : companies, datacenters, external servers, an OS you don't own. But for delegating you use software to delegate en masse :) However, now, your surface of attack is so big that it's impossible to do a full audit of your perimeter. And people focus on code/practices/network. You have delegated a lot. For the sake of discussion what can be the next cost efficient approach for attack with that much smoke? The downside of containers is the physical geographical increase of the perimeter to defend, and for SV to develop their beautiful code, a lot of workers (cleaning personal, transporter, electricians, construction workers, firemen) that are required in the physical world and are so impoverished that they are becoming a vulnerability. Keep It simple, always attack where the costs are less. Bribing a man today to access a physically a server, a router is less expensive than writing an exploit. The obvious problem in the containers is the idea you can trust layers you should not. Maybe, your container runs in a datacenter where a worker infected a printer with a connected cam from home because he is to poor to afford a printer? Maybe from there you can compromise a router, and have a MITM on a VLAN used between 2 servers? Who knows? But how can you know if you cannot check?

tracker1 10y ago

Containers aren't VMs... they're more of a sandboxed model of execution with a virtual network/disk abstraction. But lower/higher you are right, VM is probably lower-level abstraction of an entire system. But a container can be a single executable, it doesn't have to be an entire OS structure. For example, a lot of the go app containers are just the single executable by itself as a default. Many will rely on a debian/ubuntu base as they want other systems to work. This is mainly because of shared environments/libraries that some non-dockerized systems need, but isn't a requirement.

NikolaeVarius 10y ago

I'm doing a bit of a simplification here so please someone correct me if I'm not saying this correctly Every single instance of a VM has its own Kernel. When a VM boots up, it gets allocated a portion of hardware and boots up a kernel and allocates memory to itself. VMs each are isolated from each other in that they don't share resources and each VM is free to do whatever it wants to do with the hardware it is given. Like you said, to the host machine, that hardware is no longer available for any other VM to use. For Containers, they all live on a SINGLE kernel. They share resources across each other and the Kernel handles the multiple processes much like it would handle any other multithreaded process. If you have 3 VMs that all require a specific set of resources to run an application, you need 3x that hardware. This is not true for containers. You can get away with less because the containers will share the resources that the kernel as access to. I call them "lower level" in the sense that they do so much less than VMs. You CAN use containers as a VM in that a container can boot an entire Kernel, but generally you don't do this.

user5994461 10y ago
VMs share resources from the host: disk, network, memory. Just like a container shares resources from the host. Containers re-use the running Operating System from the host, it saves memory but it can only run a single OS. A VM can run any operating system, and each VM runs its OS independently. VMs are memory intensive, there is a base 100-500MB to pay to run any VM because of the independent OS. (Note that the advanced VM managers have evolved to have memory deduplication and COW across VMs.) Containers exist to save memory. That was the critical pain at the time they came to existence. Memory was expensive, it was a major problem when you wanted to run 10 hello world applications as 10 separate VMs.
- ec109685 10y ago
  Containers give the OS the ability to optimally schedule processes among them. VMs are black boxes to the hypervisor, limiting its ability to optimize.
  - user5994461 10y ago
    The hypervisor has processes inside the VMs. It has limited control but it is far from blind.

novembermike 10y ago

Basically, a VM pretends it has a cpu and a disk and ram, a container pretends that it has a root directory and ports and all of that stuff. Like always it's a leaky abstraction and isn't usually sufficient for security purposes (ie. two containers on the same system might be able to talk to each other if you abuse the system) but it's good enough for most purposes and provides much better resource utilization than a bunch of VMs.

SFJulie 10y ago

old way: one chroot per user and quota (including ulimit) per user new way: limits handled with cgroups security with namespace related to user's profile. namespace can do syscall limitations, and also offer unique network access per users. Roughly simplified. freebsd jails where known as glass jails that would eventually break, LXC/docker are the same except they hav'nt broke yet at the price of more complexity. They will all dramatically break when people will have figured the trick in 5 years. Simple solution : understand the problem and fix it. Actual solution: throw more complexity and obfuscation at the problem claiming users are THE problem. Companies and devops don't care, they have a future of at least 10 years in fat paychecks and stock options.

koffiezet 10y ago
> They will all dramatically break when people will have figured the trick in 5 years. VM's hypervisors have also seen bugs/exploits to gain hypervisor access, and yet they're still here. These things have been fixed, and people did not stop using them. Also, I don't really see the "more complexity and obfuscation" thrown at "the problem", can you enlighten me?
- SFJulie 10y ago
  Old ways: you trust a person. And You check. New ways: you create very complex sets of syscalls permissions that can be fine tuned by using a Role Based Accounting or any Auth/Profile Framework. The idea is that you got rid of the risk of mischief/compromission by containing the code and people by delegating trust to external stuff : companies, datacenters, external servers, an OS you don't own. But for delegating you use software to delegate en masse :) However, now, your surface of attack is so big that it's impossible to do a full audit of your perimeter. And people focus on code/practices/network. You have delegated a lot. For the sake of discussion what can be the next cost efficient approach for attack with that much smoke? The downside of containers is the physical geographical increase of the perimeter to defend, and for SV to develop their beautiful code, a lot of workers (cleaning personal, transporter, electricians, construction workers, firemen) that are required in the physical world and are so impoverished that they are becoming a vulnerability. Keep It simple, always attack where the costs are less. Bribing a man today to access a physically a server, a router is less expensive than writing an exploit. The obvious problem in the containers is the idea you can trust layers you should not. Maybe, your container runs in a datacenter where a worker infected a printer with a connected cam from home because he is to poor to afford a printer? Maybe from there you can compromise a router, and have a MITM on a VLAN used between 2 servers? Who knows? But how can you know if you cannot check?