3 ms·
> 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 all
by shykes 13y ago
> 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 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-are-they/ http://blog.docker.io/2013/08/containers-docker-how-secure-a...
- mtam 13y agoHow about OS patching? If I am running hundreds of different containers and I need to patch the OS (let's say upgrade the kernel or a driver), will I affect hundreds of applications at once? If so this will be a problem for several shops. 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 https://github.com/globocom/docker-cluster) is about?
- lotyrin 13y agoOS updates (updates to files inside containers) would be on a per-container basis. Kernel upgrades would affect all of the containers running under that kernel (machine or VM) at the same time. Though, if you wanted to be super cautious, you could upgrade kernel on an empty container host (quite easy if virtualized) and migrate containers to it and test them on an individual basis.