Nick Stinemates @ Docker here. I run BD/Tech Alliances. A lot of blood and sweat went in to this one! I'm here to answer any questions you may have about the announcement, the details, or anything about Docker.
You can do this today with boot2docker (running a linux VM behind the scenes)
> pull a windows based image and run it on the linux docker platform host?
I suppose the opposite of what I said could be true using something like KVM, but not a use case we are seeing a lot of right now.
The goal is:
Package your Windows app in a docker container, use same tooling you would otherwise use to deploy to a docker engine running on a Windows host
Package your Linux app in a docker container, use same tooling you would otherwise use to deploy to a docker engine running on a Linux host.
Is there a missing comma in each sentence of the goal? It seems like there should be one after "use" or after "engine":
1) [after "use"] Package [on a Windows client] your Windows app in a docker container, use same tooling you would otherwise use [on a linux client], to deploy to a docker engine running on a Windows host Package [on a Windows client] your Linux app in a docker container, use same tooling you would otherwise use [on a linux client], to deploy to a docker engine running on a Linux host.
2) [after "use"] Package your Windows app in a docker container, use same tooling you would otherwise use to deploy to a docker engine [running on Windows or Linux], running [the packaging step] on a Windows host Package your Linux app in a docker container, use same tooling you would otherwise use to deploy to a docker engine [running on Windows or Linux], running [the packaging step] on a Linux host.
I added the implications I understood to highlight the difference the comma placement makes. If there is no comma it's pretty ambiguous / confusing to me on which platform the docker engine is running. I believe from this post of yours that I have misunderstood the announcement, and that windows apps will be able to be made into docker containers that can only run on windows docker engines.
Containers share a kernel, this would make it impossible. However, with things like boot2docker (25MB Linux distro), this makes it really leight-weight/easy to deploy into a VM and run that way.
I'm sorry to hear that, we will work to do better.
> and that windows apps will be able to be made into docker containers that can only run on windows docker engines.
This is correct. There's also a thread on how, to the user of docker who just wants to `docker run` something, the distinction doesn't really matter in the end
Package your Windows app in a docker container, use same tooling you would otherwise use to deploy to a docker engine running on a Linux host and vice versa? If not initially is that an ultimate goal?
There are no current goals to make Linux executables run natively in windows and vice versa.
"Docker will be able to use either Windows Server or Linux with the same growing Docker ecosystem of users, applications and tools." (emphasis mine)
"bringing together Windows Server and Linux"
"making available some of the best images for Windows Server and Linux."
http://news.microsoft.com/2014/10/15/DockerPR/
Of course, it's hard to talk definitively about something that doesn't exist yet.
UPDATE: It makes more sense after reading this comment: https://news.ycombinator.com/item?id=8460164
1. Native Mac OS X support (so Mac Apps can also be in containers) 2. Being able to mix container operating systems with other host operating systems.
If that ever happens then operating systems and their versions would pretty much no longer matter; you could run anything anywhere without compatibility issues. I feel like this is something that has to eventually happen no matter what I'm just always curious what form(s) it will take.
Are there Mac servers out there you want to run apps on? Or just consumer apps you want to run on your mac? Curious about the use case!
> Being able to mix container operating systems with other host operating systems.
VMs are that abstraction today. I think we can do better going forward, but still a lot to do with what we currently have planned.
Having some sort of translation that's not a VM as a part of the distribution mechanism doesn't make much sense, and breaking the portability of Docker comes at a significant cost.
I struggle to see how to make that work cleanly.
Maybe they haven't but I feel like Apple has abandoned the Mac OS X Server so no apps at least for me in that case but I think consumer apps would be a pretty cool use case.
> VMs are that abstraction today. I think we can do better going forward, but still a lot to do with what we currently have planned.
Roger; thanks!
This appears to be aimed at SOHO users and not racks and racks of servers in a data centre.
I saw this... https://www.docker.com/community/governance/ but couldn't find any more information...
The first DGAB meeting is on 10/28, where we will propose a different way of working based on all of the feedback.
Stay tuned. We'll have a lot on this in the upcoming weeks.
ETA? :)
This could be huge for DR.
The MS-bits they're contributing to the Docker project will be contributed in the same way everyone does - under the Apache 2 License, in the open, etc.
> Will it be in Go?
It will be contributed in the main docker repo - github.com/docker/docker
As a result, it will be a community/maintainer decision what language it's written in, but obviously we're heavily biased toward Go.
Just makes this "partnership" a bit more, complicated? Or at least, not what it seems on the surface. If the containers aren't compatible between Linux and Windows, and the tooling will end up .Net in the long run(which I firmly believe), then the only common ground will be some semblance of API compatibility?
They are process based. They do not depend on HyperV and can run on Windows Server on bare metal or inside any hypervisor or cloud.
> Can you comment at this point about what containerization on Windows will look like.
I cannot directly.
> A tree of processes, a lighter, file-based HyperV, or something else?
HyperV integration will exist (and is currently being worked on in the open for Docker) but the technology is fundamental to Windows, like hyper-v. As far as I am aware, not a hyper-v decendant.
> What effect will this have on the filesystem layout?
Each container will have its own.
> Will native ACLs be supported or mapping to Unix permissions?
Can't comment on these details, sorry!
> Has a timeline for initial code in github been announced?
It has not.
Will Docker be shipped as a part of a Windows Component & a paid service from MSFT?
http://www.microsoft.com/en-us/windows/enterprise/products-a...
That said, it would allow for a more consistent developer experience for application/server development towards how things are deployed with containers on Linux. The biggest advantage OSX really has is that you get a clean UI for when you are simply a user, and a unix environment with the same tooling you use to build applications that will be deployed on Linux.
My true hope for this, was actually to see something beyond boot2linux. And, oh I really wish that HP didn't disable the virtualization support on their lower-end desktops (what I'm currently stuck with at work). VMWare workstation is really the only option for me, and running Ubuntu under that for *nix dev/testing.
Yes!
> How will that work?
The same way it works now. Find an image you want to run, and docker run it.
Why, let's open they are unlimited. :)
I'll be honest and say I don't have an answer. However, we're working on derive one and you'll know as soon as we do.