3 ms·

The comments about the init process are true. It makes sense to run a proper PID1 system here such as runit. I'd argue with the rest of the post. The problem i

by xal 13y ago

The comments about the init process are true. It makes sense to run a proper PID1 system here such as runit. I'd argue with the rest of the post. The problem is that phusion makes the common mistake of thinking of containers as faster VMs. That's fine, this is where almost everyone starts when first looking at Docker paradigm. A good rule of thumb is: If you feel like your container should have Cron[1] or SSH[2], you are trying to build a VM not a container. VMs are something that you run a few of on a particular computer. Containers are something that you will run thousands or tens of thousands on a single server. They are a lot more lightweight and loading them up with VM cruft doesn't help there. [1] Cron: use the cron of the outer machine with docker run [2] SSH: use lxc attach

tinco 13y ago
I am not sure whether it is a common mistake to see containers as faster VMs. The way we use Docker at Phusion is on one side as sandboxed environments to run our integration tests in, and on the other side as isolated containers to run long running services in (like apps, databases) to lessen administrative overhead. Both use cases work best in an environment that's as much as a fully functional OS as possible. Anyway, what's wrong with using containers as ultra light weight VMs, isn't the whole idea of the recent VM upmarch to use VMs as application containers? As long as you keep in mind that the security of LXC hasn't been thoroughly battle test yet, I think it's a fine idea to use docker to build light weight VMs.
- ori_b 13y ago
  The reason that you want a VM is because it reduces the attack surface for a process, and sandboxes it effectively. The administrative overhead gets cut down because you can more easily snapshot it, and reduces crosstalk between components. It removes access to data that other processes should not have access to, in a way that is tedious and difficult to do with file system permissions. It removes the ability to communicate with services running on localhost, increasing security that way. And so on. Containers do the same thing, without the overhead of a VM. The advantage of a VM in administrative overhead isn't because it's a VM, but because it has restricted access. Tossing in all the other crap that a VM has into a container because "it's like a VM" is simply cargo cult programming.
  - tinco 13y ago
    No one is tossing crap into containers because "it's like a VM". Maybe you should pay attention before calling other people cargo cult programmers. Also, security is not the main reason people use VMs, if it was virtualization would not have been so popular.
  - mateuszf 13y ago
    The difference is that although containers may have the same function as VMS they also are crazy fast. I don't see anything wrong with using them as VMS.
  - coldtea 13y ago
    >The reason that you want a VM is because it reduces the attack surface for a process, and sandboxes it effectively. Well, that's why you want a container too. From an operations standpoint VMs are just heavyweight containers.
FooBarWidget 13y ago
I disagree with running cron outside the Docker container. One of the reasons for using Docker is to lower deployment pain. The moment you use cron on the host machine you've introduced yet another moving part, and yet another dependency that must be installed on the host. I also disagree that there is a mistake here involving thinking of containers as faster VMs. Yes, you can think them of applications, but the fact is still that there is a whole operating system running inside the container, and that many apps rely on cron and other stuff. Given that crond is so small and lightweight, and that a lot of people don't know what depends on cron and what not, I think it's better to turn it on by default. If you know for sure that you don't use cron, you can still turn it off. Remember, the goal of baseimage-docker is to provide a base image that is correct for most people, especially people who are not intimately familiar with the Unix system model. Lxc-attach, although it works, has several problems: * You are doing things outside Docker so you won't be able to track it (logs, attach, etc). Also, docker might use LXC right now, but there is no warranty it will do so forever. For example, what if you're using Docker on OS X? No lxc-attach there. * It does not allow you to limit access. What if you want to give a person only access to a specific container? You can do that with SSH through the use of keys. * lxc-attach has caveats with --elevated-privileges, documented in the man page.
- zimbatm 13y ago
  Just run another container that runs cron. In regards of lxc-attach: this is a command that docker should expose to allow network operations. Even with baseimage-docker you won't be able to track it because all you can do is attach/log sshd. Also how do all these SSH keys and ports on a single host ?
rdtsc 13y ago
Well they are both, it is a weaker VM as far as capabilities, but also have more ability than a single isolated OS process. There is no need to blackbox the concept un-necessarily. It is an LXC container, read about LXC containers, its capabilities and restrictions. If you are building at core of your infrastructure don't trust simplistic mental analogies from HN. Then Docker works on top of that. Read about what Docker adds or restricts on top of the base LXC containers. I also think Docker is a little too wishy washy in their marketing and there are enough people who get confused about what exactly is going on underneath. From the slides "More technical explanations: Run everywhere, regardless of kernel version [+], regardless of host distro, physical or virtual, cloud or not [o] [+] kernel version must be 2.6.32+ [o] container and host architecture must match. " No mention of LXC containers, and that is a "technical" description. Why not just put a mention of the underlying core technology? It might change tomorrow sure and just update.
- pekk 13y ago
  They do mention LXC on their site. It isn't necessary to harp on it everywhere. I don't see that people are confused about what is going on. I thought it was clear that Docker intended to abstract some of the platform-specific details like using LXC, and focus on making a standard interface for encapsulating and managing services. I find it misleading to talk like Docker is just LXC, or a shell script for running LXC, with no contribution of its own.
  - rdtsc 13y ago
    > I don't see that people are confused about what is going on. I can see it in these discussions and in personal conversations. Yeah one can say "their fault didn't read docs". > They do mention LXC on their site. Where? Click on "Learn More". Switch through slides, get to "Technical Details", nothing there. Click on "The whole story". In a 10-20 page "super-detailed" technical explanation it is mentioned twice in passing. > I thought it was clear that Docker intended to abstract some of the platform-specific details like using LXC Clear to you and me, not clear to quite a few people. > and focus on making a standard interface for encapsulating and managing services. And that is my beef with it, selling complete black boxes and then have people wonder if there are unicorns inside, is it a VM, is it a container... If they just mentioned exactly that their technology is based on it would make it easier. Are they afraid they'll get sued by LXC creators? I don't understand why go to great lengths beating around the bush about it. > I find it misleading to talk like Docker is just LXC I think it is even more misleading to not talk about the core underlying technology and then say what they add on top of it.
coldtea 13y ago
>Containers are something that you will run thousands or tens of thousands on a single server. Citation needed. Who'd run "thousands of containers" on a single server? Some VPS service? I don't think Docker is meant to be used like those use Xen and the like.

by xal 13y ago

tinco 13y ago

I am not sure whether it is a common mistake to see containers as faster VMs. The way we use Docker at Phusion is on one side as sandboxed environments to run our integration tests in, and on the other side as isolated containers to run long running services in (like apps, databases) to lessen administrative overhead. Both use cases work best in an environment that's as much as a fully functional OS as possible. Anyway, what's wrong with using containers as ultra light weight VMs, isn't the whole idea of the recent VM upmarch to use VMs as application containers? As long as you keep in mind that the security of LXC hasn't been thoroughly battle test yet, I think it's a fine idea to use docker to build light weight VMs.

ori_b 13y ago
The reason that you want a VM is because it reduces the attack surface for a process, and sandboxes it effectively. The administrative overhead gets cut down because you can more easily snapshot it, and reduces crosstalk between components. It removes access to data that other processes should not have access to, in a way that is tedious and difficult to do with file system permissions. It removes the ability to communicate with services running on localhost, increasing security that way. And so on. Containers do the same thing, without the overhead of a VM. The advantage of a VM in administrative overhead isn't because it's a VM, but because it has restricted access. Tossing in all the other crap that a VM has into a container because "it's like a VM" is simply cargo cult programming.
- tinco 13y ago
  No one is tossing crap into containers because "it's like a VM". Maybe you should pay attention before calling other people cargo cult programmers. Also, security is not the main reason people use VMs, if it was virtualization would not have been so popular.
- mateuszf 13y ago
  The difference is that although containers may have the same function as VMS they also are crazy fast. I don't see anything wrong with using them as VMS.
- coldtea 13y ago
  >The reason that you want a VM is because it reduces the attack surface for a process, and sandboxes it effectively. Well, that's why you want a container too. From an operations standpoint VMs are just heavyweight containers.

FooBarWidget 13y ago

I disagree with running cron outside the Docker container. One of the reasons for using Docker is to lower deployment pain. The moment you use cron on the host machine you've introduced yet another moving part, and yet another dependency that must be installed on the host. I also disagree that there is a mistake here involving thinking of containers as faster VMs. Yes, you can think them of applications, but the fact is still that there is a whole operating system running inside the container, and that many apps rely on cron and other stuff. Given that crond is so small and lightweight, and that a lot of people don't know what depends on cron and what not, I think it's better to turn it on by default. If you know for sure that you don't use cron, you can still turn it off. Remember, the goal of baseimage-docker is to provide a base image that is correct for most people, especially people who are not intimately familiar with the Unix system model. Lxc-attach, although it works, has several problems: * You are doing things outside Docker so you won't be able to track it (logs, attach, etc). Also, docker might use LXC right now, but there is no warranty it will do so forever. For example, what if you're using Docker on OS X? No lxc-attach there. * It does not allow you to limit access. What if you want to give a person only access to a specific container? You can do that with SSH through the use of keys. * lxc-attach has caveats with --elevated-privileges, documented in the man page.

zimbatm 13y ago
Just run another container that runs cron. In regards of lxc-attach: this is a command that docker should expose to allow network operations. Even with baseimage-docker you won't be able to track it because all you can do is attach/log sshd. Also how do all these SSH keys and ports on a single host ?

rdtsc 13y ago

Well they are both, it is a weaker VM as far as capabilities, but also have more ability than a single isolated OS process. There is no need to blackbox the concept un-necessarily. It is an LXC container, read about LXC containers, its capabilities and restrictions. If you are building at core of your infrastructure don't trust simplistic mental analogies from HN. Then Docker works on top of that. Read about what Docker adds or restricts on top of the base LXC containers. I also think Docker is a little too wishy washy in their marketing and there are enough people who get confused about what exactly is going on underneath. From the slides "More technical explanations: Run everywhere, regardless of kernel version [+], regardless of host distro, physical or virtual, cloud or not [o] [+] kernel version must be 2.6.32+ [o] container and host architecture must match. " No mention of LXC containers, and that is a "technical" description. Why not just put a mention of the underlying core technology? It might change tomorrow sure and just update.

pekk 13y ago
They do mention LXC on their site. It isn't necessary to harp on it everywhere. I don't see that people are confused about what is going on. I thought it was clear that Docker intended to abstract some of the platform-specific details like using LXC, and focus on making a standard interface for encapsulating and managing services. I find it misleading to talk like Docker is just LXC, or a shell script for running LXC, with no contribution of its own.
- rdtsc 13y ago
  > I don't see that people are confused about what is going on. I can see it in these discussions and in personal conversations. Yeah one can say "their fault didn't read docs". > They do mention LXC on their site. Where? Click on "Learn More". Switch through slides, get to "Technical Details", nothing there. Click on "The whole story". In a 10-20 page "super-detailed" technical explanation it is mentioned twice in passing. > I thought it was clear that Docker intended to abstract some of the platform-specific details like using LXC Clear to you and me, not clear to quite a few people. > and focus on making a standard interface for encapsulating and managing services. And that is my beef with it, selling complete black boxes and then have people wonder if there are unicorns inside, is it a VM, is it a container... If they just mentioned exactly that their technology is based on it would make it easier. Are they afraid they'll get sued by LXC creators? I don't understand why go to great lengths beating around the bush about it. > I find it misleading to talk like Docker is just LXC I think it is even more misleading to not talk about the core underlying technology and then say what they add on top of it.

coldtea 13y ago

>Containers are something that you will run thousands or tens of thousands on a single server. Citation needed. Who'd run "thousands of containers" on a single server? Some VPS service? I don't think Docker is meant to be used like those use Xen and the like.