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.

Comments

Finally ...

[nbvb]

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.

Re:Finally ...

[dimeglio]

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

This is a bit misleading

[silviuc]

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

Re:This is a bit misleading

[Richard_at_work]

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.

Or a simple solution.

[jellomizer]

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

Re:Or a simple solution.

[NoNonAlphaCharsHere]

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

Re:Or a simple solution.

[Anonymous Coward]

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?

Re:Or a simple solution.

[Anonymous Coward]

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

Re:Or a simple solution.

[Misagon]

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.

Re:Or a simple solution.

[RabidReindeer]

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

Re:Or a simple solution.

[serviscope_minor]

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.

Re:Or a simple solution.

[DarkOx]

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.

Re:Or a simple solution.

[DarkOx]

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.

Re:Or a simple solution.

[organgtool]

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.

Re:Or a simple solution.

[jellomizer]

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.

Re:Or a simple solution.

[jellomizer]

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.

Is this the beginning of the end for th VM market?

[Viol8]

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?

Re:Yet again

[RabidReindeer]

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.

Re: Leading the pack...

[jd2112]

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

Re:Not "Containers"

[fourbadgers]

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.