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.

95 comments

  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.

    1. Re:Finally ... by aliquis · · Score: 1

      New file system for 2020? ;)

      Then again Windows did some other things better earlier.

    2. Re:Finally ... by RabidReindeer · · Score: 1

      I too, liked Solaris zones, but Docker does have some essential differences.

      In any event, Docker has the advantage of running under Linux. Solaris isn't as popular as it used to be.

    3. Re:Finally ... by Anonymous Coward · · Score: 0

      LOL get over it mate - Solaris is finished, people who are using it now are either stuck or are too damn stuck in their ways to move to Linux

    4. Re:Finally ... by dimeglio · · Score: 2

      I think it's interesting to see Microsoft continuing to be inspired by Linux. For a while, it was the other way around.

      --
      Views expressed do not necessarily reflect those of the author.
    5. Re:Finally ... by Anonymous Coward · · Score: 1

      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.

      FreeBSD jails user since 2000 [1]: what took you guys so long? :)

      [1] https://www.freebsd.org/releases/4.0R/notes.html

    6. Re:Finally ... by Anonymous Coward · · Score: 0

      ie. We don't care about Solaris and want to make it seem like Windows is ripping off Linux so we don't have to admit that Linux really brings nothing to the table but is just a hobbled together version of real Unix OSs.

    7. Re:Finally ... by Anonymous Coward · · Score: 0

      ICL (English Computer Company, now Fujitsu) in 1980 in an Operating System called George 2 and VME (Virtual Machine Environment) had MAC's, same as zones/docker. I kinda recall Sperry/Univacs having something similar. I'm sure the VM folk at IBM can shed light too.

    8. Re:Finally ... by Anonymous Coward · · Score: 0

      As if container tech was somehow new when Sun did it in 2005. Heck OpenVZ was doing it in linux in 2005 as well https://en.wikipedia.org/wiki/OpenVZ

      Docker is more about the portability and ecosystem around it than the actual container tech (which is just whats built into the Linux kernel)

    9. Re:Finally ... by Anonymous Coward · · Score: 0

      Only people doing this right are Joyent by putting docker inside an lx-branded zone for proper security. Docker's security for a multi-tenant system is a complete pig's ear when used on Linux.

    10. Re:Finally ... by MrDoh! · · Score: 1

      I recall xenix systems with microsoft copyrights all over them before linux was even a glint in anyone's eye. MS has always looked at unix to figure out how to do it right in the end.

      --
      Waiting for an amusing sig.
    11. Re:Finally ... by Anonymous Coward · · Score: 0

      2005? Last I heard FreeBSD jails came out in 2000.

    12. Re:Finally ... by Anonymous Coward · · Score: 0, Offtopic

      Since building a FreeNAS server and using the generic Jails I've lost all desire to figure out Docker or ESXi. Jails does exactly what I need: A separate 'space' to play around in without mucking up my main system.

      It's hosted on ZFS. I can snapshot a jail at any time using the file system (not the virtualization app).

      It also Just Works(tm)

    13. Re:Finally ... by jean-guy69 · · Score: 1

      When you can run Docker inside Solaris Zones..
      And the datacenter is viewed as an elastic Docker host.
      Things start to become interesting..

      Thanks to Joyent Triton

    14. Re:Finally ... by jbolden · · Score: 1

      Well first off moving technology down market is an improvement. All sorts of cool features that are available in mainframes become a big deal when they are introduced for PCs. In specific Zones are more like LXC than Docker. Docker itself has a much wider and more complete ecosystem than Zones ever had.

      The two main things that allowed Linux to displace Solaris,
      1) Lower cost of hardware
      2) It frequently requires less man hours to get X to work on Linux than on Solaris (the ecosystem).

      Moreover the Linux ecosystem is more diverse than the Solaris ecosystem. The comparison (in terms of functionality) for Docker would have been a during the 1980s a Solaris system for running: SCO, Xenix, IRIX, Digital Unix, HPUX, ... applications bundles under Solaris.

    15. Re:Finally ... by armanox · · Score: 1

      Or we actually like stable products that work as advertised. My love for Solaris and IRIX partly comes from how poorly Linux often runs (and some of the nonsense the GNU people spew).

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    16. Re:Finally ... by saleenS281 · · Score: 1

      That's great if you're either:
      A. doing startup type work where you don't necessarily care about an enterprise support agreement so you can use one of the illumos derivatives. And when I say enterprise support agreement, I mean things like having the OS on your storage vendor support matrix/application support matrix/HBA support matrix/etc.

      B. you can tolerate dealing with the devil and using Solaris proper with *shudder* Oracle "support".

      For everyone else, while I agree this is a sad, sad imitation of Zones - at least it's a start.

    17. Re:Finally ... by Anonymous Coward · · Score: 0

      And exploited weeks later. The isolation of docker is no where as good as vm.

    18. Re:Finally ... by Dunkirk · · Score: 1

      I always felt that the domain model was basically a copy of NIS (or yp, depending on your age).

      --
      Acts 17:28, "For in Him we live, and move, and have our being."
  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.

    2. Re:This is a bit misleading by cshay · · Score: 1

      Right, the headline should replace "Docker-like containers" with "Linux-like containers" and then it would be correct.

  3. Leading the pack... by Anonymous Coward · · Score: 0, Funny

    Leading the pack, from behind

    1. Re: Leading the pack... by Anonymous Coward · · Score: 1

      Doggy style

    2. Re: Leading the pack... by jd2112 · · Score: 2

      Like a Pierson's Puppeteer from the 'Ringworld' books by Larry Niven?

      --
      Any insufficiently advanced magic is indistinguishable from technology.
    3. Re: Leading the pack... by Coren22 · · Score: 1

      The Hindmost approves.

      --
      APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
  4. 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: 1, Insightful

      Man, you really know what you're talking about!

      DLL files can be distributed with and loaded from the same directory as EXE files.
      You completely forgot Registry settings, buuuuudddy.

      I got a simple solution! Let's statically link everything and use config files everywhere. That's how things were really done in DOS. Now be honest: you've never actually used DOS, have you?

    3. 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?

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

      And then every single application has to run its own security updates.

    5. Re:Or a simple solution. by Anonymous Coward · · Score: 0

      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?

      As human beings, we are tremendously good at repeating mistakes in the long run. Trust me, it's going to be different this time!

    6. 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
    7. Re:Or a simple solution. by swb · · Score: 1

      I think static linking makes a lot of sense, but you will get a lot of resistance from people who say that it makes patching harder because some vulnerabilities will now require more patching (eg, SSL) because every application will have their own copy.

      I think this is debatable in some ways, because it assumes every security issue affects a shared library and not part of the core executable. It also ignores the applications that merge shared library code or provide a system available function internally (often to avoid weird version mismatches or system incompatibilities). These may or may not even have the vulnerability based on what code was merged.

      I think to some degree some VM "appliances" start to approximate a kind of application virtualization. Several greatly strip a distribution of unused kernel and system components down to the bare minimum necessary to run the application.

      I'm sure some product does this, but it would be interesting to see a virtualization system that could take an application and generate a bootable VM, merging into the VM only the parts of the operating system actually used by the application and resulting in a lighter weight VM that was still standalone and didn't require a specific host OS.

    8. Re:Or a simple solution. by RabidReindeer · · Score: 2

      "It's Simple. All You Have To Do Is..." FacePalm.

      Whether your app is one big monolithic ugly or a sordid collection of shared resources, if you want to toss it around between machines, you still need to "install" it on each machine. Installation means not only the code, but whatever data files need to be set up, config files, database connections and possibly even nastier things. In the Internet era, few apps live in total isolation.

      So it's not so simple.

      What Docker offers is a way of essentially taking a master image of the application's installation - and ONLY the applications's installation - and bouncing it between servers. Docker also supports keeping libraries of these ready-to-go images so that as many instances as you want can be spun up on demand.

      If you'd like a good analogy, think of a traditional OS disk system as a box that you dump multiple applications into. In the traditional way, all the applications might be unrelated and self-contained, but they all went into the box as one big jumble. In Docker, each of those apps might be contained in a completely self-contained bag. You put the bag in the box. If the box gets overloaded, you pull the bag out of the box and put it in another box.

      It's, er, "Simple".

    9. Re:Or a simple solution. by gbjbaanb · · Score: 1

      Actually that was one of the "great new things" for .NET applications - you could deploy your application using the DOS copy command!!! Fantastic...

      except then they added the GAC and the crap in the various .net frameworks folders like installutil etc and now they'vbe come up with a new 'great new thing' to let you deploy your applications using the copy command.. I wait with anticipation for it to get a dependency on hyper-v administration console and various Windows Server features and updates.

    10. Re:Or a simple solution. by Anonymous Coward · · Score: 0

      You have the same issues with Docker containers you know. You still have to set up DB connections, install data, etc, etc. Config files and static data can be put anywhere in both situations, so Docker really doesn't solve much more in the case you supplied. All you're doing is sticking it into a docker image rather than a directory structure.

      What docker really brings is the ability to run up a cluster of application servers, on a real server, without much overhead. This is great when you have a use case for it. Using it to deploy a single app is really quite redundant though, you may as well just tarball everything up if that's all you're doing as you avoid the overhead of the docker image.

      Docker is wonderful, but I'm seeing more and more abuse of it as a silver bullet. Without proper design and architecture, Docker does nothing to help.

    11. 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.
    12. Re:Or a simple solution. by DarkOx · · Score: 2

      This will come to bad end. Its one thing to think about containers and VMs as being their own little hosts and everything, like patching that goes along with that.

      Thinking of them as 'application bundles' will lead a nightmarish security situation. With the exception of applications that don't really handle external data you don't get the isolation from containers or VMs that many people seem to thing you do. Suppose you bundle up your CMS server and all the customizations written for it, it access a backed database, later an RCE in the webserver it uses is discovered. Boom your database is compromised because the attacker can control the web front end. Similarly something like heatbleed could go on exposing users private information long after OpenSSL on the host has been fixed if the bundle is never updated.

      There is not much out there in the way of tooling to do things like large scale patch management on these bundles. As long as we treat containers as little servers and leave the operating system package management things are alright, we have tools.

      Going this route thought is sure to lead to lots of old bad code sitting around out there in unshared-libraries, that never get updated. This will lead to dangerous and frequently surprising consequences I think.

      Oh well you have to update the platform test your app and than re-deploy the bundle. Sure that sounds easy. Oh wait no not really it sounds pretty much like updating a VM or fat-container image and redeploying it, less the shell script the change the host name and network address. All to save a few tens of megabytes by not having to include things like 'bash' on the virtual disk image (which admittedly could/would be a security win; payloads would have to get larger and more detectable as attackers can't 'live off the land'). There are already tones of great tools out there to manage scalable farms of VM or Container servers; if that is your use case.

      I am not saying there is no value to things like docker, if you want to be able to let uses download your video game or something and be confident it run everywhere, that makes some sense. Anything that handles 'data' someone might care about though the old system of shared libraries for all its faults does mean that your app gets bettered hardened SSL when Microsoft pushes a patch to schannel which might be really important depending on what your application is/does.

      Lightweight containers can/will definitely be a good thing, but they are no a one-size fits all solution and suspect people using them to solve the wrong problems will lead to much trouble.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    13. Re:Or a simple solution. by Anonymous Coward · · Score: 0

      FYI that's exactly what Docker does (copy on write) and why it's revolutionary. it's not just jail / zones on Linux. we've had that for a decade with OpenVZ and it's always worked flawlessly.

    14. 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
    15. 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.

    16. Re:Or a simple solution. by jellomizer · · Score: 2

      You are confusing software deployment with coding.
      You can use separate libraries. However they are deployed and connected to your particular instance to your application.

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

      How is having your config file in a config subdirectory off your application so horrible.

      The registry is a bad design. Prone to single point of failure.

      So you want to configure your apache settings go to /usr/apache/etc
      To run the program go to /usr/apache/bin

      You can use proper conventions to prevent a lot of issue that we had in DOS days where the settings were mixed in different areas.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    18. 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.
    19. Re:Or a simple solution. by Junta · · Score: 1

      I would go further and say that while before some projects would feel some pressure to do cleaner packaging and deploy better alongside other applications and into 'OSes', many are starting to say 'here, just take a container' and never fix packaging issues because... container! What is a good workaround for some fundamental limitations has become a crutch to be extraordinarily lazy in packaging.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    20. Re:Or a simple solution. by Anonymous Coward · · Score: 0

      So, no Windows on 16GB tablets?

    21. Re:Or a simple solution. by Anonymous Coward · · Score: 0

      Insightful? How about moronic instead?

    22. Re:Or a simple solution. by meta-monkey · · Score: 1

      I think it depends on at what level the libraries are shared. Not every windows application should come with its own copy of the entire .NET libraries.

      --
      We don't have a state-run media we have a media-run state.
    23. Re:Or a simple solution. by jbengt · · Score: 1

      There are advantages to shared libraries, as others have pointed out, but the GP never said anything about statically linked libraries, let alone recommending them.

    24. Re:Or a simple solution. by goarilla · · Score: 1

      So apt-get is container aware ?

    25. Re:Or a simple solution. by Anonymous Coward · · Score: 0

      "GOTO Considered Priceless," the foundational article for systems management in the 21th century.

    26. Re:Or a simple solution. by ravyne · · Score: 1

      Its not nearly that simple -- LXC and the windows container technology put applications into their own private namespace -- they can't even see other applications or any resources the underlying OS hasn't given the container access to. This isn't just about isolating software dependencies, it allows you to do things like running two apps on the same host OS that might have mutually-exclusive dependencies, or say, to run one version of the app on a newer version of the same library, where in the past you might not have been able to have two versions of that library side-by-side.

      Containers are like virtual machines, except rather than each application needing its own individual VM (and the resource usage that brings along with it), it shares an OS host without giving up the isolation benenfits, and without introducing redundant resource use due to running many Operating Systems. This is important because one of the ways admins might reduce resource usage is to combine applications inside a single traditional VM, and then you start loosing all those isolation benefits and the thing becomes more brittle and difficult to manage. Containers mean that you can isolate individual apps and their specific environment without much overhead at all, which encourages this good practice -- of course you're free, actually, to install multiple apps inside a single container if you choose (I've seen people set up entire desktop environments and remote into them), but for running a web-service, smaller and more isolated is better.

    27. Re:Or a simple solution. by jbolden · · Score: 1

      How is having your config file in a config subdirectory off your application so horrible.
      The registry is a bad design. Prone to single point of failure.

      So you want to configure your apache settings go to /usr/apache/etc
      To run the program go to /usr/apache/bin

      Because configuration isn't often that simple. So I want to change the behavior of a program X that uses PHP on Apache. Are the settings in /usr/apache/etc or /usr/apache/PHP/etc or /usr/PHP/etc or /usr/apache/PHP/X/etc or ....

      See TeX distributions for a good example of where your model leads. TeX is easy to add stuff to but the complexity comes in when you use both X and Y and want to control the interactions.

    28. Re:Or a simple solution. by RabidReindeer · · Score: 1

      You have the same issues with Docker containers you know. You still have to set up DB connections, install data, etc, etc. Config files and static data can be put anywhere in both situations, so Docker really doesn't solve much more in the case you supplied. All you're doing is sticking it into a docker image rather than a directory structure.

      Not entirely. In many apps, there are internal objects and external objects. When the app is installed as a native OS app, the difference is not apparent, so you have a fairly untidy collection of stuff all over the place.

      When I package for docker, I leave most of the app's characteristics internal, and the docker run specs clearly document the external characteristics. At most that's usually config, data, and log volumes and one or 2 ports.

      The difference between a container and just trying to grab everything in a tarball is that A) invariably something important doesn't make it into the tarball and B) the target system may have conflicts with what's in the tarball. For internal resources, all that's tidily collected within the Docker image and hidden by container virtualization. For external resources, I can, if necessary simply remap locations, since I'm not in the habit of making containers use shared external resources. Plus, thanks to container linking, I can often inject certain characteristics from container to container and not even have to worry about their external aspects.

      It's true. No such thing as a Silver Bullet. And any sufficiently-advanced technology can be turned into a screaming nightmare when placed in the hands of incompetents. Done judiciously, however, I find Docker makes for a tidier system, and one that's a lot easier to assure business continuity on.

    29. Re:Or a simple solution. by Anonymous Coward · · Score: 0

      WTF?

      Copy on write is not revolutionary and if enough apps that share the data need to write to it you end up with a ton of wasted memory because now all of the apps have their own copy of it.

    30. Re:Or a simple solution. by Anonymous Coward · · Score: 0

      The shared library is an out of date concept

      That implies he recommends static libs because there are only two options.

      Numbnuts

  5. Yet again by Anonymous Coward · · Score: 1, Insightful

    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.

    1. Re:Yet again by Richard_at_work · · Score: 1, Informative

      You obviously didn't read the article - its Docker for Windows, the main management system for this is Docker, its just using the existing HyperV virtualisation system rather than expending effort porting Dockers virtualisation subsystem to Windows. Portability doesn't really matter here, because of the way Docker works (sharing kernels, virtual filesystems etc) - so you will rather run a Unix container on a Unix host, and a Windows container on a Windows host. The benefit here is that you can manage both using the same system - how Docker accomplishes what it does on each platform is an implementation detail you don't need to know about, its just Docker to you.

    2. 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.

    3. Re:Yet again by Anonymous Coward · · Score: 0

      Actually, Microsoft has had this functionality since they purchased Softricity. in 2006.

    4. Re:Yet again by Anonymous Coward · · Score: 0

      Really? The Linux fanbois spin everything about their pet project and they do it in spades. MS and just about every tech company putting out their own thing is more innovative than all the Linux tallywhacking put together.

    5. Re:Yet again by Anonymous Coward · · Score: 1

      You mean like Linux copied UNIX?
      Like GNU copied UNIX?

      Yeah, those were terrible, terrible ideas. Sharing ideas is bad! Always start from scratch!

    6. Re:Yet again by snowgirl · · Score: 1

      Indeed... Apple didn't make the first MP3 player... they just ended up making a new one that obsoleted all the others with features.

      --
      WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
    7. Re:Yet again by shutdown+-p+now · · Score: 1

      This is actually more than just using Hyper-V. It's extending Hyper-V to offer lightweight containers, like LXC does for Linux.

  6. Re:Or a simple solution + chrootuid by Anonymous Coward · · Score: 0

    Don't forget to use chrootuid.

  7. Re: I can be Trendy too! by Anonymous Coward · · Score: 1

    While I'm not saying MS invented the concept in any way, MS has been public with the container project for years before docker even existed.

    Just look for "Project Drawbridge", they have been changing the windows API since 7 to create a minimum windows image to work in a similar way to docker.

    It was targeted originally at a different problem but it is in fact the same idea to the same problems.

  8. 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?

  9. This is NOT a new technology by CSHARP123 · · Score: 1

    This IS docker for Windows. Misleading headline and article. I like Docker especially after providing support to SELinux.

    1. Re:This is NOT a new technology by Anonymous Coward · · Score: 0

      SELinux: Brought to you by the NSA because they want to keep snoopers out of your system.

  10. Long before... by TheRealMindChild · · Score: 1

    Long before Docker, there was Thinstall/Thinapp

    --

    "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
  11. Re:Is this the beginning of the end for th VM mark by wierd_w · · Score: 1

    virtual machines might still hold a valuable feature in the future, since they would more strongly compartmentalize running code against exploit based escalation of privileges. Using chroot blocks processes from accessing files outside the jail, but does not prevent a running process from attacking the shared kernel space, and gaining access to the real root filesystem. An honest to goodness virtual machine offers additional layers of protection.

    Given the increasing value in gaining unauthorized exclusive access (for criminals anyway-- That includes the spying antics of governments) to systems that host data for many different customers, the incentive to bust such jails and run amok on the server is only going to increase as the bean counters press more and more for "data based economy" models.

    So while less sophisticated jails are faster and easier to deploy, they are also necessarily less secure than a fully blown VM with a full hypervisor monitoring them between them and the real server OS kernel, and thus more vulnerable, and thus more prone to being attacked-- That means that as the "Professional data criminal" element grows, the viability of these less sophisticated jails will diminish, and the viability of more sophisticated (but slower) jails will increase.

  12. Re:Is this the beginning of the end for th VM mark by Anonymous Coward · · Score: 0

    Are you kidding me? You can't imagine a single scenario where you'd like multiple seperate operating systems to run on a single machine?

    I don't want to contaminate my Web server environment with whatever crap I run for other services. I don't want to be forced to use a single FS for root, just because I have different needs for different enviroments.

    I want to know if that system crashes it doesn't take dozens of other unrelated things with it.

    What am I supposed to do with the hundreds of Windows Server installations? It's not a niche case. Multiple servers that run dozens of virtualized Windows Server installations in High Availability or Fail-Over Clustering mode. Roles that should not by best practices or necessity run side by side.

  13. Re: I can be Trendy too! by Anonymous Coward · · Score: 0

    I was trendy back before it was cool.

  14. Re:Is this the beginning of the end for th VM mark by Anonymous Coward · · Score: 0

    You miss the point of VMs. They allow for easy overbooking of hardware. They suck, but the industry loves them because of this.

  15. Re:Is this the beginning of the end for th VM mark by Anonymous Coward · · Score: 0

    A virtual machine is just another piece of software to attack.

  16. Awesome.. by clockwise_music · · Score: 1

    As an ASP.NET developer I am really, really excited about this.

    In the past few years nothing new has come from Microsoft that has really been a big deal. MVC and Razor were great and a pretty big deal, but everything else didn't really affect my day to day job of developing apps.

    Deploying ASP.NET apps has always been a real pain in the neck. Sure, in theory it's as easy as xcopy, but once your apps start growing and your configuration grows it rapidly becomes a bigger thing to maintain. It takes a lot of time, there's lots of stuffing around, it's very fiddly and generally a PITA.

    If I understand it all correctly, being able to package up my application into a sort of "mini vm", that has everything pre-configured, would be absolutely bloody amazing. Having it run on this new "Nano Server" thing sounds fantastic - it doesn't have a GUI or 32 bit support, so in my mind it should be much faster, quicker and much easier for remote administration.

    I've been waiting for this announcement ever since I wrapped my head around ASP.NET vnext, and now that I think I get it, the future is looking cool. Good job MS.

    1. Re:Awesome.. by Richard_at_work · · Score: 1

      Deploying ASP.NET apps has always been a real pain in the neck. Sure, in theory it's as easy as xcopy, but once your apps start growing and your configuration grows it rapidly becomes a bigger thing to maintain. It takes a lot of time, there's lots of stuffing around, it's very fiddly and generally a PITA.
       

      Why aren't you using a build and deployment system? We use Team City and Octopus Deploy to deploy ASP.Net websites, and once its set up (5 minutes for TC, a few minutes for OD) deployment is a zero friction issue - it just works.

    2. Re:Awesome.. by Anonymous Coward · · Score: 0

      +1. TeamCity + Octopus Deploy have rapidly become staple software in our build pipelines. If you want to stay in MSland there's also WebDeploy...

  17. Docker? by Anonymous Coward · · Score: 0

    Is it made of beige twill?

  18. El containero by Anonymous Coward · · Score: 0

    You guys got it wrong: Since popularization of mobile devices and decline sales of pc's, I think MS is trying to explore new markets by improving intermodal transportation. Why not? just look at GE in different fields.

  19. Proper software management by Anonymous Coward · · Score: 0

    I would rather have Windows make proper software management system like most Linux distributions have. One that makes staying upto date easy and removing software easy without leaving mile long trail behind...

  20. Re:Is this the beginning of the end for th VM mark by Anonymous Coward · · Score: 0

    No.

    A VM also allows you to run disparate operating systems. If you are a Linux shop but have a single low-use-but-critical Windows application, you can still run it in a VM. Docker helps with a problem in Linux where you are a Red Hat shop and some one wrote code for Ubuntu that is not portable to Red Hat. It turns out that the versions of bash, glibc, boost, and various other libraries are different (and sometimes incompatible). It also turns out that the locations of configuration files and init scripts are not in the same places or work in the same way (init scripts? upstart? systemd?). So all those issues add up, making docker a handy tool.

    I am not sure if the same kinds of issues happen with Windows server, which tends to have a longer support life. It would probably be more interesting if the Microsoft tool would include desktop and server platforms.

    Additionally, it is often considered a best practice to isolate services into separate VMs. This means that a compromised password on one machine will not own services for your entire network. This security feature is not offered by docker.

  21. Microsoft innovation by sageres · · Score: 1

    I can guarantee you that MS advocates such as Gates and Balmer will be pointing to this technology too (just like others) saying it exemplifies the famous "Microsoft innovation".

    1. Re:Microsoft innovation by Anonymous Coward · · Score: 0

      I can guarantee you that MS advocates such as Gates and Balmer will be pointing to this technology too (just like others) saying it exemplifies the famous "Microsoft innovation".

      Perhaps you should concern yourself with the Microsoft of today and not worry about what people who no longer work at Microsoft think about Microsoft.

    2. Re:Microsoft innovation by Anonymous Coward · · Score: 0

      Gates actually still works at Microsoft. He's chief tech advisor to Satya I believe. Also clearly Board of Directors. With that being said, he isn't really interested in the business politics of Microsoft anymore, he just wants to improve the world with cool stuff. Not so much with the borg anymore it seems.

    3. Re:Microsoft innovation by Anonymous Coward · · Score: 0

      With that being said, he isn't really interested in the business politics of Microsoft anymore, he just wants to improve his net worth by using "philanthropy" to boost companies he invests in.

      FTFY

      You can't stomp over people, lie, cheat, steal, hold the tech sector back for decades and erase it with pseudo-charity.

  22. Urban Dictionary by Anonymous Coward · · Score: 0

    Someone should have looked up Docker on urban dictionary before naming the project. That word doesn't mean what you think it does!

  23. Re: Or opposite with dependency hell by Billly+Gates · · Score: 1

    No updating A will cause B to break. Turn off all Windows updates and freeze time march 2013. We will just hire more mcses to clean infections as they come as this is too critical to break etc.

    One company a coworker interviewed hasn't ran an update in 5 years as it breaks some add on for exchange. They still run XP too???!

    The more pain you make dependencies the greater to resistance to change. Look at IE 6 as an example?

  24. Microsoft Docker © by DougPaulson · · Score: 1

    "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."

    I'm confused, did Microsoft originally develop Docker-based Linux containers and is now cloning the technology to run natively under Windows?

  25. MS already has containerization tech by richrz · · Score: 1

    I'll admit that I'm too lazy to read TFA but I think its portable app tech. With the acquisition of Softricity, Microsoft bought SoftGrid which it rebranded as Microsoft Application Virtualization for windows desktops and TS/RDS, then App-V for Servers. In reality it is COM/DCOM name space virtualization under the covers as I helped develop it. VMWare responded by acquiring Thinstall, nowcThinApp, which is also a portable app tech.

  26. Not "Containers" by fourbadgers · · Score: 1
    This is a bit misleading.

    What microsoft are offering is virtual machines with a cut-down 64bit windows kernel, without the 32bit support, without the user interface and without all the other guff that bloats a normal windows install.

    It's still a VM running on a hypervisor.

    Containers on the other hand all share the same running kernel (linux kernel) and just include different application or systems files. Well at least that's what it has meant for the last few years with lxc, docker and rocket et al.

    1. Re:Not "Containers" by fourbadgers · · Score: 2

      whoops, looks like a was wrong. it looks like nano server (announced same day) is the cut down windows server SKU. while the microsoft containers use the hyper-v engine to enforce isolation but sharing the kernel.

  27. Re:Is this the beginning of the end for th VM mark by Anonymous Coward · · Score: 0

    Who the fuck writes code for a specific distro?

    No one. I can run anything that will compile on Linux on any distro I want.