4 ms·

Will the MS bits be open-source? Will it be in Go?

nickstinemates 12y ago
> Will the MS bits be open-source? 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.
- tmzt 12y ago
  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?
  - deleted 12y ago
    [deleted]
  - nickstinemates 12y ago
    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? It has not.
  - johngossman 12y ago
    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_virtualization 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.
    - benjarrell 12y ago
      Can you compare this to AppV?
      - lstamour 12y ago
        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/app-v-on-named-kernel-object-virtualization-a-k-a-the-vobjects-subsystem.aspx 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-yu.pdf https://www.usenix.org/legacy/events/vee06/full_papers/p24-y...
- johngossman 12y ago
  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.
  - Rapzid 12y ago
    Which is a .Net language, just saying.
    - BuckRogers 12y ago
      Of course. It will be in C#. Far too much work to be done on Go's Window's support to use it, and no advantage to do so.
      - Rapzid 12y ago
        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?

> Will the MS bits be open-source? 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.

tmzt 12y ago
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?
- deleted 12y ago
  [deleted]
- nickstinemates 12y ago
  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? It has not.
- johngossman 12y ago
  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_virtualization 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.
  - benjarrell 12y ago
    Can you compare this to AppV?
    - lstamour 12y ago
      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/app-v-on-named-kernel-object-virtualization-a-k-a-the-vobjects-subsystem.aspx 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-yu.pdf https://www.usenix.org/legacy/events/vee06/full_papers/p24-y...
johngossman 12y ago
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.
- Rapzid 12y ago
  Which is a .Net language, just saying.
  - BuckRogers 12y ago
    Of course. It will be in C#. Far too much work to be done on Go's Window's support to use it, and no advantage to do so.
    - Rapzid 12y ago
      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?