21–30 of 111 posts
Holy cow, the unit test case is fantastic.
Compare this with vagrant
Since vagrant spins up full VMs, which need to boot, etc. it's slower. Spinning up VMs with vagrant, in my experience, takes tens of seconds to minutes. Launching an docker app in a container takes a few seconds (allegedly... I've never actually tried it myself).
Docker doesn't add a whole lot over what basic Linux containers (lxc and vserver) have offered for years. Having said that, the main benefit to Docker is a change in viewpoint from "virtual machine" to "application". Docker aims to make applications portably deployable to any Docker-machine. Since Docker uses lxc (aka Linux containers), it helps to understand a little how containers are different from other virtualiz…
Containers are not virtual. Containers aren't emulating anything or translating anything. They let your partition out system and network resources as you see fit (or to protect users from abusing each other) without running kernels within kernels and other performance killing hokum.
[1] dotCloud don't actually yet recommend running Docker in production, but if you did...
[2] This was part of what Mailgun (part of Rackspace) said in their presentation at the Docker workshop in SF today.
Holy cow, the unit test case is fantastic.
With Team Foundation Server you can set up a build that ramps up Hyper-V instances with build results.
Sure it is all Microsoft stuff, but the concept is nothing new.
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
- 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 a convoluted confusing
mess of additional layers of complexity.
- LXC is already used in many real-world
applications for operational software
everyday.
Earlier quoted context omitted.
Containers are not virtual. Containers aren't emulating anything or translating anything. They let your partition out system and network resources as you see fit (or to protect users from abusing each other) without running kernels within kernels and other performance killing hokum.
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…
I thought docker just makes creating, deploying and managing LXC "enabled" applications easier. Do they add anything to the LXC ecosystem other than the online sharing of containers?
Does github add anything to git other than a multi-tennant gitweb with a prettier interface? git: worth nothing. github: worth a billion dollars.
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.
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 with other best practices, like apparmor/grsec/selinux, network lockdown, active monitoring, running things as non-root etc.) but it's not mandatory.
Here's our latest overview of container security: http://blog.docker.io/2013/08/containers-docker-how-secure-a...