I remember running VMs in VMs when I was younger and wondered how far I could go before my computer would implode. Infinite recursion is amazing. Let me rephrase that; infinity is amazing.
After three to four iterations (cannot remember precisely) I couldn't split up my computer its capacities any further to qualify for any decent OS its specifications which could run another VM. Please note that this was years ago, I suggest you should try it!
Unless you want to waste a lot of time installing the nested OS's, like I did, I suggest using pre-installed images you can throw right in.
This is one of the many potential applications of the new "-privileged" flag of Docker. This is very exciting, because it means that we will soon run Docker CI within Docker itself (instead of ad-hoc VMs), among other things!
The big thing for me about the privileged flag is the ability to run VPN software on the containers-- this way, they can talk to each other cross-physical-machine as well as between containers on the same host.
We're on the same page. That's my next hack — an OpenVPN server within Docker. The blog post, Dockerfile, and helper scripts should be out next week :-)
My system uses peer to peer software to synchronize each container's public keys and IP address/port information, as well as a mesh network VPN. This allows me to easily join a new node to the VPN cluster (using ENV variables to specify the port and public address to listen on, which is then used in the Docker container creation) and still have minimal latency between any two nodes.
I'll probably have to write up a post myself describing the system and how Docker is used to create new containers and add it to the cluster.
OpenVPN is only client-server, so I'm currently using tinc[1]. BitTorrent Sync is the software used to synchronize the actual public keys and container IP addresses.
Cgroups and namespaces. Even though some namespaces are nested (typically, the PID namespace) why others don't need to be.
There is nothing special with nesting cgroups and namespaces from the kernel point of view. The interesting part is to work around the little details (as anybody who ran nested LXC containers will know) :-)
Yes, you can do that; I would personally ship the containers separately and provide minimal orchestration. Why? Because if you bundle multiple containers together, they will run on a single host. And if they run on a single host, it's generally easy enough to craft your own ad hoc orchestration.
But if you have multiple containers that require really weird, specific hoops to run together, it's definitely an option!
Note that future versions of Docker will let you ship and manipulate a group of containers as a single object. Currently this is scheduled for 0.8 (October release).
Mostly-unrelated question: could one build a desktop Linux distribution around Docker? Or rather, how difficult would it be? I assume OS X's application sandboxing uses a technology similar to LXC.
CoreOS could be a good starting point, but it's intended for servers so it's very bare bones (and the service discovery stuff might not make much sense)
You could run most essential system components (syslog, ssh, cron...) inside containers, and bind-mount /home when it makes sense. Since those components need elevated privileges, I don't know if containers would be that useful... And then systemd already puts services in cgroups; it's a nice approach (IMHO).
Or you could use containers a bit like virtualenvs. If you're a Python developer familiar with virtualenvwrapper, you probably use mkvirtualenv when you start working on a new project (or on a different setup for an existing project). Containers could be used in a similar manner with some clever wrappers.
It is nice to see, especially because fast moving project is always an enjoyable thing to observer. As a sidenote, to increase overall awareness, FreeBSD has capability for hierarchical Jails (Jails inside of Jails) for a while.
There is Docker within Vagrant, I have a Windows 7 desktop in front of me and all I need to do to enter my CoreOS system is "vagrant up; vagrant ssh" from the git shell.
I don't think there will be direct Docker support for Windows (erm... hrm)
Actually I do remember hearing that docker/lxc was only the beginning, can you be more specific? What virtualization tech in Windows do you want to see Docker containers running in?
There's no reason you can't run CoreOS in qemu or CoreOS in VirtualBox, but all of those things are still coming back to Linux Containers. Did you have an idea of another way?
Would each container run on something like coLinux?
(coLinux is a port of the Linux kernel to run as an ordinary Windows program, so you can run the Linux kernel as a Windows userland program by double-clicking on "linux.exe"; then you can SSH in and mess around, etc)
Are you looking forward to run the Docker CLI in Windows (i.e., being able to use Docker commands from a Windows machine, while the containers run on a remote box), or run the containers themselves on a Windows box?
I wouldn't expect Windows support anytime soon, especially Windows containers running in a Linux host using LXC as the "hypervisor".
Windows containers running in a Windows host is much more likely. Commercial solutions like Virtuozzo Containers offer Windows on Windows support today [1]. Someone could implement a Virtuozzo-for-Windows provider for Docker, but that seems like a long shot.
There is already some support for Gentoo and Archlinux, and if you are willing to use a "foreign" kernel, Red Hat / Fedora / CentOS work as well.
There is some significant work in progress to add compatibility for non-AUFS systems. I don't have an accurate timeline at this point, but expect something (or at least an announcement) at the end of the month!
Just to confirm that we're planning to remove the dependency on aufs for the 0.7 release (late September). As a result docker will run on vanilla linux kernels.
aufs will probably come back as a plugin in a future version.
aufs is great and I wish we could keep it as the default. But the kernel politics are what they are.
Please no :) just rely on us to downvote these people on HN, then you can spare at least some of the readers the pain.
I don't even understand, it's not like it's conversation or even funny, but X in X immediately results in someone announcing their awareness of canonical jokes. "yo dawg i heard you like plays so I put a play in your play to inception the king."
