Yes, all containers are backwards compatible, pretty much to the first version.
In general backwards compatibility is a big deal in the Docker project - breaking changes are taken very seriously and we try to avoid them as much as humanly possible. That applies to the container image format, Dockerfile format, remote API and command-line interface. It's also important to preserve portability across drivers. For example different storage drivers (aufs, btrfs, devicemapper etc) don't affect the format of the images they produce.
I don't understand that. Other kernels may offer features that are similar enough to allow one to implement a large part of Docker on top of it. Nowhere in "docker run -i -t ubuntu /bin/bash" does it say something about LXC.
Example in point: Spoon Studio, a very Windowsy application that does, on Windows, something not at all unlike what LXC does [1]. It allows you to add one layer of filesystem (just one, so no commits) over the host OS's filesystem and then run applications inside there, contained very much like how processes are contained inside Docker containers.
If this is possible right now (and actually these guys were around before dotcloud was even founded), then I don't see why at some point Docker couldn't come available on multiple platforms.
(but I might also completely misunderstand some fundamental thing that makes LXC/Docker completely unlike Spoon and friends)
Docker is based heavily on libcontainer (their replacement for LXC), which is based very heavily on kernel namespaces and cgroups. Those features are Linux-specific, and are a very important and fundamental part of what lets Docker containers work. Somebody could totally write another container backend to replace libcontainer that supported the mach kernel or other BSDs or Hurd or whatever, but it would likely require a lot of work (ongoing work, considering the speed at which Docker is changing over time).
That's what I'm saying. I'm really appalled at the amount of downvotes that I'm getting for having the guts to say "Windows" in a Docker thread, but with a gigantic effort, it's totally imaginable to have a Docker-like system on other kernels than Linux. People who can't imagine that are just, well, unimaginative.
> Also, what does "Nowhere in 'docker run -i -t ubuntu /bin/bash' does it say something about LXC." even mean?
I think that the parent was trying to say that the docker interface is not specific to LXC, only the backend implementation is, so there is "nothing" preventing the backend from supporting other kernels that have the requisite features.
That said, the containers would be OS-specific by definition.
I think if people really want something like docker on Windows or MacOSX, they should go out and write themselves one. For docker guys, obviously, they don't find it an attractive market.
Who will run MacOSX in server farms anyway? If you're using Windows already, why not spend more for some fancy virtualization or container like products, say from VMWare?
Mono is more like a different implementation of interesting languages. If you like C#, you can use mono to write and run on Linux. If you want to write Windows programs, you won't use mono.
We actually do support Docker on OSX and Windows :) It just requires a small gateway VM called boot2docker (25MB on disk). It's perfect for development of Linux application on an OSX machine. Typing "docker build" and "docker run" straight from the Mac terminal is pretty magical, you definitely forget there is a VM involved.
The boot2docker devs had made it clear they're not going to add any vbox-specific bits to b2d, but I've been successfully using the ISO linked from this article (which I expect will get updated to 1.1 shortly, or if not there's instructions to build your own):
I agree that "from the distance" it might seem possible to run docker on top of OSX or even Windows, because, you know, it's not only about the LXC but the deltas. This is something that many non-linux people ask me "why not in OSX if it's based on..." and they are right... somehow.
I disagree because we know how different the 3 systems are and we know that they cannot come up with a standard for something as simple as CSS much less they will arrive to define a common "LXC" interface.
It is not about other kernels offering similar features, but kernels having the same common interface. As I said, it would be great, but it won't happen.
Part of the problem is that it would be a significant amount of work to create and continue to support and maintain it, and all it would get you is the ability to run Mac OS applications inside of a container, and there aren't a huge number of users who want to do that. Most likely people would want to run Linux in their Docker containers, and that requires some form of virtualization.
It's very handy for development instances of your apps/services too. Often nicer/faster than using Vagrant if that's your bag.
Something I plugged together recently - a W3C HTML5 validator instance in a Docker container: https://github.com/magnetikonline/dockerhtml5validator proving to be really useful vs. my old method of spinning this all up in a VirtualBox instance.
Servers aren't the only thing Docker is useful for. I made the plunge to isolate a GUI app and its daemons from my desktop (krita was trying to run KDE daemons on my xfce system, grr). Something like that might be useful. Another possibility is nice development servers, so you can run something in close to the same environment on your work computer as your servers.
Because in the typical Docker workflow, developers (who often use OS X) build container images on their computers.
Anyway, boot2docker works really well nowadays. Even individual port forwarding has been eliminated by using a virtual IP address where all exposed ports are available.
Ah. I just assumed that OSX devops tested their work on a linux VM, I didn't realize it was common to build on OSX then deploy to linux production, I'd have guessed that would be pretty error prone.
In the past OSX has actually been a pretty decent server OS. I wouldn't recommend it for that today, but there are still plenty of reasons someone might want it (legacy systems, developer familiarity with OSX from desktop use, some Apple technologies that are useful even outside a GUI, and so on).
