

Containers: Docker, Windows and Trends - runesoerensen
http://azure.microsoft.com/blog/2015/08/17/containers-docker-windows-and-trends/

======
runesoerensen
Considering the timing of this blog post, it's probably "warmup" for the
release of Windows Server 2016 Technical Preview 3 (10.0.10514) expected later
this week[1].

It also seems that MSFT made the new preview available for public download
just a few hours ago[2], along with a new docker client[3].

A couple of PowerShell scripts for setting up container hosts were also
uploaded earlier today[4] (which was where I found the VM and docker client
links. Use at your own risk :-))

[1] [http://www.winbeta.org/news/windows-
server-2016-build-1051x-...](http://www.winbeta.org/news/windows-
server-2016-build-1051x-coming-next-week)

[2]
[http://download.microsoft.com/download/F/B/A/FBAAEE1A-3AF2-4...](http://download.microsoft.com/download/F/B/A/FBAAEE1A-3AF2-4ED7-8CD9-50FF91BA72B4/CBaseOs_th2_release_10514.0.150808-1529_amd64fre_ServerDatacenterCore_en-
us.wim)

[3] [http://aka.ms/ContainerTools](http://aka.ms/ContainerTools)

[4] [https://github.com/Microsoft/Virtualization-
Documentation/bl...](https://github.com/Microsoft/Virtualization-
Documentation/blob/master/windows-server-container-tools/New-
ContainerHost/New-ContainerHost.ps1)

------
moviuro
What actually is the point of Microsoft helping docker? They tell that
"""Linux containers require Linux APIs from the host kernel and Windows Server
Containers require the Windows APIs of a host Windows kernel, so you cannot
run Linux containers on a Windows Server host or a Windows Server Container on
a Linux host."""

So why help docker? can't they just create their docker-like software for
Windows Containers? What is the point of sharing the same client if what you
can do with it depends on the platform you use?

EDIT: instead of just downvoting me, an explanation would be welcome

~~~
Sanddancer
Because sharing the same client is still useful, even if they're different
platforms. For example, being able to use the same application to control
systems that run on Linux as well as Windows without needing to duplicate a
lot of logic in a lot of places. Additionally, I can see cross-platform
programs as potentially being possible through the right combination of well
laid out containers, and usage of file associations/binfmt_misc in proper
doses. So settling on the docker api does make sense for ms, because a
balkanized server ecosystem just leads to frustration and people less
interested in your platform.

------
bmir-alum-007
It's a good thing CloudVolumes (aka SnapVolumes, basically VM-side volume
unioning for VDI and server app containers a-la Softricity) sold to VMware
when they did about 2 years ago. The core idea of app executables and
libraries as opaque, read-only containers which can be shared at the
enterprise scale is a good abstraction for many reasons including security and
dedupe.

------
m0dest
It sounds like:

• Docker is really cool! Everyone is talking about Docker!

• We at Microsoft like Docker, too! (But Docker obviously screws us pretty
hard, since the whole ecosystem is built around the Linux kernel. Windows
isn't great at this type of isolation.)

• We don't like being left out of the Docker container party, so we're going
to create _two_ things that are Almost As Good As Docker Containers!

• (1) A new package format, "Windows Server Containers," that we're calling a
container, even though it doesn't actually offer containment. Containers can
mess with other containers.

• (2) The same old Windows Server virtual machines, but we're going to call
them "Hyper-V Containers." Yeah, they're just VMs. Separate kernels in memory
and all of that.

• We know neither of these offer what you wanted. But good news! You can use
the same container format for _both_ of these new almost-a-container systems.

Yikes.

~~~
sciurus
Your summary of #1 is uncharitable. Although we don't know the technical
details of what Microsoft has actually implemented, their description of
Window Server Containers applies equally well to containers on Linux.

"While the sharing of the kernel enables fast start-up and efficient packing,
Windows Server Containers share the OS with the host and each other. The
amount of shared data and APIs means that there may be ways, whether by design
or because of an implementation flaw in the namespace isolation or resource
governance, for an application to escape out of its container or deny service
to the host or other containers. Local elevation of privilege vulnerabilities
that operating system vendors patch is an example of a flaw that an
application could leverage. Thus, Windows Server Containers are great for
scenarios where the OS trusts the applications that will be hosted on it, and
all the applications also trust each other."

~~~
CSDude
I am not trying to be a downer, I already wait Windows containers for my work,
we are planning to build a project out of it, however there is a difference:
When a Docker container on a Linux host was able to escape the container,
(around 0.8) it was considered a huge security vulnerability, but this text
from MS is like they already accept there will be vulnerabilities because
"they designed wrong" or "implemented wrong", this does not give a confidence
to run untrusted containers, and that's why they implemented HyperV containers
as well.

~~~
useerup
They accept that there is _less_ resource isolation in a plain container
compared to a virtual machine container.

With a plain container, any OS process that you see _is_ the common host OS
process - it is just projected into your container. Compromising the process
is compromising the the process for all containers.

For security purposes there's a big difference between starting with access to
everything and then trying to reign in processes, access, resources etc
compared to starting with hardware isolation and then _allowing_ some
functions (e.g. management) to cross.

Microsoft is completely correct on this: Containers are _not_ security
boundaries. A security boundary would require very few access points with very
specific security policies. That is not containers.

Hyper-V virtual machines, on the other hand, enjoy hardware level isolation
and starts from the other end: Anything that should cross the VM boundary has
to be explicitly allowed, as opposed to OS virtualization where anything is
allowed until the projection disallows it.

For instance, a container could try to delay processing of callbacks from the
kernel processes. It is the same process as the others containers, and a
single malicious container could very well starve the others for resources.

Both have their uses. Plain containers offer higher density but less
isolation, Hyper-V (or any other VM technology) containers offer lower density
but higher isolation.

------
ldaj
What OS's will this docker.exe (3) work on? It does not run on Windows 10.

------
MichaelGG
Well, over a decade late to this party, but seems like they're being dragged
forward.

~~~
vezzy-fnord
Linux was pretty late to the party itself short of heavyweight solutions like
Linux-VServer and OpenVZ which require patched kernels.

As with most everything related to virtualization, IBM did it first.

~~~
dnm
I remember using VM/CMS in school, in 1981:
[https://en.wikipedia.org/wiki/VM_%28operating_system%29](https://en.wikipedia.org/wiki/VM_%28operating_system%29)

How much is really new?

~~~
stephengillie
Everything new is old already.

------
shocks
[https://webcache.googleusercontent.com/search?q=cache:vBD2z2...](https://webcache.googleusercontent.com/search?q=cache:vBD2z2A8NsgJ:azure.microsoft.com/blog/2015/08/17/containers-
docker-windows-and-trends/+&cd=1&hl=en&ct=clnk&gl=uk)

I'm getting an error.

