Docker Now Part Of Red Hat OpenShift
techcrunch.com
techcrunch.com
Who is pushing this thing? Why does anyone even care about it? Does anyone even know what a Linux container is?
Judging by the number of times "when will Docker support Windows containers?" has been asked... no.
- Process isolation: http://msdn.microsoft.com/en-us/library/2bh4z9hs.aspx
- Network isolation: http://msdn.microsoft.com/en-us/library/windows/apps/hh77053...
- Disks:
-- Mounting volumes: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
-- NTFS provides something like copy-on-write (part of a union file system) via "Single Instance Storage" http://en.wikipedia.org/wiki/NTFS , http://www.neowin.net/news/microsoft-details-how-windows-8-w...
-- VHD "differencing disks": http://msdn.microsoft.com/en-us/magazine/dd569754.aspx, http://technet.microsoft.com/en-us/library/cc720381(v=ws.10)...
...or just use colinux: http://www.colinux.org/ "that allows it to run cooperatively alongside another operating system on a single machine. For instance, it allows one to freely run Linux on Windows 2000/XP/Vista/7, without using a commercial PC virtualization software such as VMware, in a way which is much more optimal than using any general purpose PC virtualization software. In its current condition, it allows us to run the KNOPPIX Japanese Edition on Windows."
Honestly if I was/am going to hitch my cart to LXC I'd probably be going the libvirt-lxc route so I'd be dealing with something of an actual standard.
Edit: I suppose one reason people might prefer Docker over libvirt would be no XML blegh, but it's honestly not that bad.
It is great to see that many of Docker's ideas are being implemented upstream; e.g. LXC added support for BtrFS snapshots shortly after Docker launched. Sounds like OpenShift is considering which Docker ideas belong in their platform.
It can sometimes be hard to work with upstream projects, who often have a different world-view. I do like the idea of releasing a "sacrificial lamb" project that is a demonstration of your ideas, even if long-term all the ideas belong upstream (i.e. LXC in the case of Docker).
This argument to me achieves only the opposite, it makes me never want to consider whatever option it defends.
It is pretty dang clear to me how to create it.
Kudos to the dotCloud guys for being willing to drop docker's weirder dependencies (e.g. AUFS)
In any case, aufs will come back as an optional storage backend in a future version. It still has a few advantages over device-mapper - increased memory sharing for example.
Just my 2c.
Again I'm not an expert in "kernel politics" (you could even say I know nothing about them).
Somewhat recently there was some traction with a version of her patches that looked somewhat close to being merged, but it might have also been dropped.
How does this relate to Docker? I knew nothing about containers and was first introduced to them by Docker. So I started off using Docker seeing what I could do with it. When I got frustrated, I started looking at the core components of Docker which lead me to lxc.
So yeah - it has bugs. But it is opening up a "whole new world" to some people.
I like this: Using LXC directly is like using a (pointer, length) struct in C. Using Docker is like using an array-slice in Go. They're not that far apart, but they're on different levels of abstraction, and come with different guarantees (even if those guarantees might not, in practice, be enforced yet.)
> Docker [...] doesn't [...] clean up after itself properly when you CTRL+C it.
Sorry about that. It looks like nobody reported this issue yet. Would you mind filing a bug report on the github repo? Feel free to join the #docker channel on Freenode and we'll be happy to help you out.
> Does anyone even know what a Linux container is?
Yes.
This is basically just expanding our current abilities to include areas where we didn't have great support before.
The goal is to have Docker running on all linux platforms, so that everyone can use it regardless of their distro choice.
1) Docker 0.7 will run on vanilla kernels out of the box. This means virtually all distros will be supported. It also means wider support for hosting providers which don't allow custom kernels (Google Compute Engine for example).
2) Future versions of Docker will optionally support some of the technology used by Red Hat - most prominently libvirt-lxc and selinux.
The more places you can use Docker, the more useful it is :) So we have no intention of locking it into a single distro or paas.
[1] https://fedoraproject.org/wiki/Features/SVirt_Mandatory_Acce...
What I mean, regardless of how we actually implement, is having an elegant way to deploy containers in environments where the sysadmin relies on SELinux contexts and labels to implement security.
My main question is whether this will require users to create a fixed-size filesystem for each container up front, like you would have to do if you were using LVM snapshots directly.
The best place to follow progress on this is to track docker-dev (https://groups.google.com/forum/#!forum/docker-dev) and the #docker-dev irc channel.
- it will be thinly provisioned (i.e. it can be 10G or 100G but still use only a few MB on disk if it's essentially empty, like a sparse file), - it can be grown easily.
On the one hand, it's a bit less convenient because you have to care about the disk usage.
On the other hand, it's great because a single container can't eat up all your precious disk space (and if you want to run some public/semi-public stuff that's quasi mandatory).
If you want to check the current code, you can look here: https://github.com/alexlarsson/docker/tree/device-mapper3
I think the idea of unionfs should be in a kernel.
I don't know how good aufs is (nor do I care really), but if it's not in mainline/upstream then it'll never be taken seriously.
If you ask me to start building custom kernels to support your stuff, then I'm not going to like you. :-)