31–40 of 111 posts
I always wanted to ask a question about docker, if the local devel machine is ubuntu 12.04, I can not deploy my docker image build to a 10.04 ubuntu server, right? (Unless you run a 12.04 virtual machine or something.)
I've been having trouble figuring out the value-add of using Docker over Ubuntu's built-in LXC functionality [1]. [1] https://help.ubuntu.com/12.04/serverguide/lxc.html
I also found myself asking this same question, and after careful consideration I ended up choosing LXC over Docker, and here are some reasons why: - LXC works fine on it's own. - Docker has it's own bugs, so you get all of the Docker bugs in addition to potential LXC bugs. - IPTables routing for containers to the outside world isn't that hard to manage. - LXC is simple and straightforward, and by comparison Docker is…
I really don't like giving up the isolation of modern hypervisors, particularly those with Intel virtualization extensions. Docker (and LXC) seems like a huge step backwards for security. I'm sure there are use cases, but I'd never multi-tenant with it.
For "real" multi-tenant systems, I'd want full VMs, but as noted elsewhere, you can run Docker containers inside a VM, and still benefit from sharing resources by carving up a large VM into many smaller, isolated subsets.
We run OpenVz today, but I'm following Docker closely as we plan to migrate to LXC, and then going for Docker might very well be the best alternative.
Earlier quoted context omitted.
Indeed. One way you can use Docker in production[1] is one container per machine: even when you're not using the containers to split resources, the ability to snapshot and move an application and all of its dependencies in a single, lightweight, easily deployed package is very exciting. And because there's no translation etc. happening, running a single container is pretty much identical, performance-wise, to running…
You can actually do the same thing with LXC containers; it is trivial to rsync a snapshot or compressed archive of a snapshot to another host machine and run it there.
Earlier quoted context omitted.
Indeed. One way you can use Docker in production[1] is one container per machine: even when you're not using the containers to split resources, the ability to snapshot and move an application and all of its dependencies in a single, lightweight, easily deployed package is very exciting. And because there's no translation etc. happening, running a single container is pretty much identical, performance-wise, to running…
You can actually do the same thing with LXC containers; it is trivial to rsync a snapshot or compressed archive of a snapshot to another host machine and run it there.
I really don't like giving up the isolation of modern hypervisors, particularly those with Intel virtualization extensions. Docker (and LXC) seems like a huge step backwards for security. I'm sure there are use cases, but I'd never multi-tenant with it.
> I really don't like giving up the isolation of modern hypervisors You don't have to! Think of docker as a unit of software delivery, rather than resource allocation. It's very common to use Docker to either a) deploy only trusted containers on the same machine, or b) deploy only 1 container per machine. There are also cases where linux cgroups and namespaces are an appropriate security mechanism (usually combined w…
How about built-in failover? On a virtualized environment you can run a cluster and the VM will move to another host in case of failure. Does docker support that? Is that what the docker-cluster project (https://github.com/globocom/docker-cluster) is about?
Earlier quoted context omitted.
I also found myself asking this same question, and after careful consideration I ended up choosing LXC over Docker, and here are some reasons why: - LXC works fine on it's own. - Docker has it's own bugs, so you get all of the Docker bugs in addition to potential LXC bugs. - IPTables routing for containers to the outside world isn't that hard to manage. - LXC is simple and straightforward, and by comparison Docker is…
Looks like ShipBuilder has overlap with Docker, if not a direct competitor. A disclaimer wouldn't have hurt in my opinion.
I cite it merely as an example of the sorts of cool things which are possible with LXC.
I've been having trouble figuring out the value-add of using Docker over Ubuntu's built-in LXC functionality [1]. [1] https://help.ubuntu.com/12.04/serverguide/lxc.html
I also found myself asking this same question, and after careful consideration I ended up choosing LXC over Docker, and here are some reasons why: - LXC works fine on it's own. - Docker has it's own bugs, so you get all of the Docker bugs in addition to potential LXC bugs. - IPTables routing for containers to the outside world isn't that hard to manage. - LXC is simple and straightforward, and by comparison Docker is…
Docker = app-focused container API thang built from LXC with a historically strong aufs+ubuntu focus and limited support for more exotic setups
LXC = do anything the hell you want
Holy cow, the unit test case is fantastic.
It is a good example, but I wonder how licensing would treat it. If I'm running hundreds of unit tests, each against a snapshot of my database, and my database is Oracle, they would likely view that as hundreds of instances which would each need a license.
Earlier quoted context omitted.
Indeed. One way you can use Docker in production[1] is one container per machine: even when you're not using the containers to split resources, the ability to snapshot and move an application and all of its dependencies in a single, lightweight, easily deployed package is very exciting. And because there's no translation etc. happening, running a single container is pretty much identical, performance-wise, to running…
You can actually do the same thing with LXC containers; it is trivial to rsync a snapshot or compressed archive of a snapshot to another host machine and run it there.