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.
Sorry if this is obvious somewhere, but i have to ask: Will this allow me on windows to pull a linux-based image (ubuntu for example) and run it on the windows platform or pull a windows based image and run it on the linux docker platform host?
Right... what the problem was is that you started seeing people get confused about running Linux containers on Windows and vice-versa. Hence all the questions around that... I guess that wasn't as clear from the announcement as it could have been. One of the main reasons is probably that the people that have been using Docker are Linux folks and aren't necessarily as familiar with deploying Windows-based applications.
I'm still unclear as to whether the linux apps can be deployed to a docker engine running on a windows host, and, vice-versa, whether docker windows containers can be run on a linux host. The announcement seemed to be clear that both of these are the goal. But your GP post https://news.ycombinator.com/item?id=8458603 causes me to doubt.
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.
No, you will not be able to deploy a Linux app onto a Windows container, or vice-versa.
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 believe from this post of yours that I have misunderstood the announcement,
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?
We understand it, but its really hard to explain briefly. So many people assume Docker==Linux Containers. Throw in virtual machines and start talking about running a Linux app in a Docker container in HyperV on Windows and it only really works with pictures. And that's before you talk about multiple containers running across a public cloud provider. Demos will help.
Ah okay thanks. The partnership sounds great and I know it's really freaking challenging but I hope in the future to see:
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.
The use case for our startup is: we have lots of compute and graphics intensive services being created and tested on Macs by developers, targeted for Linux Docker instances in the cloud. It would be nice to be able to run these same containers natively on OS X rather than requiring developers to bring up a local hypervisor (e.g. VirtualBox) and a local virtual Linux instance). This would help with both dev and test. Additionally, sometimes our engineers would like to be able to run compute jobs locally and merge the results back into the cloud based system.
That sounds like a difficult proposition without your target being able to run Mac binaries.
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 think you're interpreting his words too literally. Nothing that gets deployed to a QA/staging/production system should be built on a developer's workstation in the first place, those specific containers need to come off a build server. The binaries on the developer's workstation would be built on/for OS X, and the binaries in QA/staging/production on the (Linux) build server for (Linux) targets.
> 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!
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.
I second the opinion regarding OSX servers; not only is Xserve long dead but the "server" component of OSX is an application that bundles mostly open source applications with a GUI, if I'm not mistaken?
This appears to be aimed at SOHO users and not racks and racks of servers in a data centre.
Is there a public roadmap for currently planned features? I know there was discussion to make Docker more community driven, but I'm not sure if that went anywhere?
I'm also a bit confused. Let me give you a specific scenario. I have a windows .net application that works with windows 8 (no gui - some server side stuff). Can I package this up as a container and run this on a linux machine that has docker?
That is not currently a goal. It's the goal that you can tell docker - run this application, and it will find (or create!) a suitable host to run it on.
It's definitely not a wrapper around boot2docker. It's the kernel work etc. to enable native Windows containers running on Windows Server. No VMs need apply. That said, we're also working with Docker on the future of the boot2docker concept so that it easy to work with Linux-based Docker images from a Windows laptop, but that's just tuning the experience.
Excuse the ignorance, since I'm fairly new to Docker. I'm excited about what Docker allows for during development. Will this partnership eventually lead to being able to run containers on my Windows workstation without needing Ubuntu running in a VM?
No - if technical cooperation with a huge company slowed us down, we'd be dead in the water. We've partnered with IBM, Google, Red Hat, VMWare.. lots of big names, lots of great ambition.
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.
Nick is right. Our default answer will be to use Go to be consistent with the rest of the Docker project. But we'll use whatever language is right for that part of the project.
Exactly. I'm a firm believer that if you're doing orchestration/automation on Windows and you're not using .Net based technologies, you'll wish you were eventually(coming from a HEAVY Chef on Windows user). Plus, there's Powershell modules to consider, and Powershell is .Net based.. And just the general ecosystem to consider, especially Azure itself. And etc, and etc. Though some F# wouldn't be a bad choice, I suspect the prevalence of C# will win out.
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?
Can you comment at this point about what containerization on Windows will look like. A tree of processes, a lighter, file-based HyperV, or something else? What effect will this have on the filesystem layout? Will native ACLs be supported or mapping to Unix permissions?
Has a timeline for initial code in github been announced?
John Gossman from Microsoft here. Windows Server containers use the approach sometimes called Operating System Virtualization, just like Linux containers, Jails, etc.. The Wikipedia article is a pretty good summary: http://en.wikipedia.org/wiki/Operating_system%E2%80%93level_...
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.
I'll take a stab at it (no relation to Microsoft). As described in the following link, App-V does streaming of client app code from a server, appears very client-oriented. The technology behind it might not be, though: http://blogs.technet.com/b/gladiatormsft/archive/2013/11/05/... (describes the registry key with exceptions to the underlying namespacing of handles, I think?) This appears to be called Named Kernel Object Virtualization (a.k.a. the VObjects Subsystem) from the title of the post. But again, client-side oriented. I expect Docker integration to be server-side oriented code for this. Oh and if anyone's saying Microsoft's late to the party, there have been similar attempts on Windows platforms since at least 2006 using such techniques: https://www.usenix.org/legacy/events/vee06/full_papers/p24-y...
Disclaimer: I am not speaking for Microsoft here, but my understanding of the facts that have been released.
> 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?
I don't know that Apple would ever feel that pressure. They really just don't cater to developers, if you look at the issues with the Mac App Store for an example.
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.
I really hope the Microsoft partnership does put some pressure on Apple to provide this support as well. But it just feels like something that isn't really their style. While having software components appear like "just another container" is great for developers, its very anti-Apple. They don't view the iphone as "just another smartphone". Everything Apple is standout/special in some way. I hope I am wrong though because I love Docker and would welcome this with open arms.
I suspect that you'd still need a Windows Server license to start off with. It may or may not need a VM under the hood, but that's a MS thing to figure out. They certainly couldn't license a container the same way as a full Windows VM or bare metal install.
Id expect that since the idea is having your windows container running on a windows host, that each version of windows server will have a "this edition allows X number of containers" limit. This would line up with how they treat VMs. Lets hope the number is 5x the current VM limits.
I thought the whole point of containerization was that you ran apps in a container, but the container doesn't contain an operating system. (You have several containers on one instance of the OS, not several VMs, each with its own OS. That's how it works in Linux, anyway.)
