Slashdot Mirror


Microsoft Creates a Docker-Like Container For Windows

angry tapir writes Hoping to build on the success of Docker-based Linux containers, Microsoft has developed a container technology to run on its Windows Server operating system. The Windows Server Container can be used to package an application so it can be easily moved across different servers. It uses a similar approach to Docker's, in that all the containers running on a single server all share the same operating system kernel, making them smaller and more responsive than standard virtual machines.

13 of 95 comments (clear)

  1. Finally ... by nbvb · · Score: 3, Interesting

    Solaris Zones comes to Windows.

    Welcome to 2005.

    Why am I the only one completely unimpressed with Docker? It feels like a hacked together Solaris to me .... no thanks, I'll take the real deal.

  2. This is a bit misleading by silviuc · · Score: 5, Informative

    Docker is moslty a set of tools to allow simple management of containers. It's not itself a container technology. On Linux, Docker leverages LXC and a bunch of other things. On Windows, the same functionality will be available but using Microsoft's container technology. MS and Docker are actually working on getting the Docker toolset on Windows

    1. Re:This is a bit misleading by Richard_at_work · · Score: 4, Informative

      Yes, this is in actuality Docker for Windows, as this line from the article says:

      Both Windows Server Containers and Hyper-V Containers can be controlled through the Docker engine, allowing administrators to manage both Docker and Microsoft containers in the same environment.

  3. Or a simple solution. by jellomizer · · Score: 4, Insightful

    The is to solve the problem is simple. Keep the apps self contained. No shared libraries or dll.
    To move the package you just move the directory containing the app to an other location.
    Some will say that is how Macs do it. But I would go further and say that is how it was done in DOS.
    The shared library is an out of date concept, while sounds good when storage was expensive, today we are virtualizing full platforms just to prevent version incomparably.
    What may be a little bonus is to give application/process level networking settings so you can just virtual network your app from the OS

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:Or a simple solution. by NoNonAlphaCharsHere · · Score: 5, Funny

      Great idea. I'm going to stop using subroutines, too.

    2. Re:Or a simple solution. by Anonymous Coward · · Score: 4, Insightful

      Yeah, right. Every app has its own copy of OpenSSL. With its own set of vulnerabilities. Thankyouverymuch.

      Why does this "industry" have to repeat every error every 5-10 years? Don't we have memories?

    3. Re:Or a simple solution. by Misagon · · Score: 5, Interesting

      Shared libraries are shared also so that you would be able to update the library without updating all applications that use it.

      By the way, when virtualizing servers you could also create file system instances using a copy-on-write filesystem, in which case you would be able to get self-contained instances with the least amount of copying necessary.
      Under Linux, you could use FUSE to get CoW on top of a underlying filesystem that doesn't support it.

      --
      "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
    4. Re:Or a simple solution. by serviscope_minor · · Score: 4, Insightful

      The is to solve the problem is simple. Keep the apps self contained. No shared libraries or dll.

      That's unnecessary. One look in /opt and I can see plenty of packages which have .so files. They install just fine anywhere.

      The shared library is an out of date concept, while sounds good when storage was expensive, today we are virtualizing full platforms just to prevent version incomparably.

      Nope, they're still a good idea which is why VMs are working on memory deduplication. If every tool on Linux was statically linked, you'd massively bloat the RAM foorptint. It makes sense for programs outside the package manager to be self-contained, but having the managed ones abandon .so files would be a massively regressive step.

      --
      SJW n. One who posts facts.
    5. Re:Or a simple solution. by DarkOx · · Score: 3, Insightful

      No we don't. The hands on votec schools don't teach industry history and if you look at that stack overflow poll from a few days ago it looks like the majority of people only spend about 15 years in software development. So once every 10 years or so the majority of developers are two young to know better when 'hard learned lesson' is called into question by one of the rockstars.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    6. Re:Or a simple solution. by organgtool · · Score: 5, Insightful
      How was this modded insightful?!

      The shared library is an out of date concept

      No, it is used by every major system today for very good reasons.

      Some will say that is how Macs do it

      Macs do have shared libraries - the files have a .dylib file extension.

      sounds good when storage was expensive

      Statically linked apps don't just take up orders of magnitude more storage, but also significantly more memory. Not only that, but a critical security update to one library requires recompiling and redeploying ALL of the apps that use that library.

      today we are virtualizing full platforms just to prevent version incomparably

      There are tons of reasons to virtualize that have nothing to do with version compatibility or network security.

      Since you seem so committed to statically linking apps, I suggest you go through the Linux From Scratch project and statically compile everything. Then, deploy it to an enterprise environment that requires five-nines uptime as well as all security updates. Be sure to set up a video camera so that I can watch with a bug bucket of popcorn.

    7. Re:Or a simple solution. by jellomizer · · Score: 3, Interesting

      Vs. a bunch of people afraid to apply the patch of openSSL in fear that it would break all the applications in one swoop
      of having up Update Open SSL on ever virtual system that is running a different application?

      Compared to a few decades ago. Package update systems have gotten much better.
      So the package system will know that Application A, B, C, D use OpenSSL and there is an open SSLPatch and Application A, B, C, had verififed that it worked, so A,B,C will get the push to fix those parts.

      I stated no Shared Libaries, or DLL... I didn't say we can't use libraries. They are just not shared across the entire OS.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  4. Is this the beginning of the end for th VM market? by Viol8 · · Score: 3, Interesting

    After all, VMs were really only required for Windows where seperation of programs and libraries and process filesystem access restrictions was especially problematic compared to *nix. Now Windows looks like its finally dragged itself into the 1990s could VMs become a solution for niche edge case problems once more?

  5. Re:Yet again by RabidReindeer · · Score: 3, Interesting

    Microsoft copies someone else. In Microsoft language,

    copying==innovation

    To be fair, every company copies to some extent. It's just that nobody spins it as much as Microsoft.

    Before we got all hung up on patents and copyrights, computer software technologies were freely copied/stolen right and left. Often gaining interesting and useful new capabilities in the process.

    Back then, it was common to repeat Newton's quote that he saw further because he stood on the "shoulders of giants". And to sourly observe that programmers more often stood on each other's feet.

    These days, you often have to, lest lawyers descend upon you and pick your bones.

    It's one reason open-source software is now so popular. For whatever illusory protection against indemnification closed-source products might project, the open-source ones at least won't sure you. Unless you violate the basic terms of sharing, anyway.