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 virtualization.<p>Conceptually, they are similar to Linux's chroots or FreeBSD's jails, which offer process isolation. Basically, they work with a lightweight virtual machine instead of a single process. Containers have lower overhead - they are virtualizing on the operating system level. Other virtualization technologies like Xen and KVM work on the CPU level, and provide a fully virtualized hardware setup to the virtual machine[s].
I recently wrote an article that covers some of this ground: <a href="http://www.sitepoint.com/docker-for-rubyists/" rel="nofollow">http://www.sitepoint.com/docker-for-rubyists/</a><p>The basic idea behind Docker is that you don't have to create another operating system in order to just separate your processes from each other. This leads to containers being much more lightweight than virtual machines but also significantly less powerful (i.e. powerful as in ability to do something, not in terms of performance) in some areas.
I've been having trouble figuring out the value-add of using Docker over Ubuntu's built-in LXC functionality [1].<p>[1] <a href="https://help.ubuntu.com/12.04/serverguide/lxc.html" rel="nofollow">https://help.ubuntu.com/12.04/serverguide/lxc.html</a>
I Would love to migrate 50+ KVM VMs to LXC-Containers, but there seem to be some problems left with security[1][2].
I cant wait to get my hands on Docker, but I lack the SELinux knowledge to secure everything the 'proper' way.<p>Is LXC (and therefore Docker) really ready for Production yet?<p>Edit: Formatting.<p>---<p>[1] <a href="http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/" rel="nofollow">http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/</a><p>[2] <a href="https://blog.flameeyes.eu/2010/06/lxc-and-why-it-s-not-prime-time-yet" rel="nofollow">https://blog.flameeyes.eu/2010/06/lxc-and-why-it-s-not-prime...</a>
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 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.)
One of the issues I found with contributing to open source is the time it takes to get a build environment up and running. Since different people face different kind of issues and projects usually lack an exhaustive documentation, I've always felt adding a light weight image of the build environment could help. I hope in future Docker or similar projects pave the way for it.
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?
I wonder how Microsoft's Drawbridge OS (<a href="http://research.microsoft.com/en-us/projects/drawbridge/" rel="nofollow">http://research.microsoft.com/en-us/projects/drawbridge/</a>) will compare to LXC, and the Docker APIs? Currently Drawbridge looks like it's lacking adoption, and doesn't seem to be widely available. Regardless, the container model looks like it solves a lot of PaaS security issues without the overhead of VMs (Iaas).
Ha! Crazy to see a question I asked 5 months ago pop up on Hacker News.<p>The docker.io team has said that they don't consider it to be production ready [0]. Has anyone experienced any major problems? Anyone using it in production?<p>[0] <a href="http://blog.docker.io/2013/08/getting-to-docker-1-0/" rel="nofollow">http://blog.docker.io/2013/08/getting-to-docker-1-0/</a>