Entries:
Comments:
Discussions:

Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

PerfectPhase PerfectPhase "This is not war, this is pest control!" - Dalek to Cyberman
  • Window container support on client

    I note that Beta-5 removes the dependency on mono

    https://github.com/aspnet/aspnet-docker/blob/master/coreclr-1.0.0-beta5-11624/Dockerfile

     

  • Window container support on client

    @Bass: Not surprising as no one outside MS has Windows container support at the moment :)

  • Window container support on client

    @cbae: agreed, I would have thought as a general rule you'll run a single hypervisor type, be that Hyper-V, VMware, Xen, whatever, which will host VMs running Server Core for Windows containers or CoreOS for Linux, for example.

  • Window container support on client

    , cbae wrote

    *snip*

    What does "written against" mean? Inventing terms again?

    If you want to be understood, you should be more careful in your choice of words.

     

    Win32 is an API, you write in a programming language and program against an API, simples.

  • Window container support on client

    , cbae wrote

    But having Windows containers run on a Linux VM means that you won't have to spin up another Windows VM and pay the compute hours just to host a small subset of your application infrastructure that depends on Windows. Likewise, if you're primarily a Windows shop, being able to run Linux containers from a Windows VM means you won't have to spin up an entire Linux VM because you want run some NoSQL database runs only on Linux.

    It's really not that difficult to understand the motivations.

    No that's wrong

    Hypervisor (optional) -> Container Host -> Container

    The hypervisor can be Windows or Linux, but the Container Host OS has to match the container type, Windows Containers on Windows, Linux on Linux.

    If you have a dontnet application running on coreCLR and you want to deploy this to a Linux container host then that's a Linux container not a windows container, so there is no windows OS licence involved.

    If Microsoft decide to license the number of containers running on a host, like they've done for windows VMs on a Hyper-V node, they might as well just throw in the towel and go home now.

     

     

  • Window container support on client

    , fanbaby wrote

    In any case, it makes little sense to deploy windows container to a Windows VM running under Linux vs deploying to a windows server directly.

    'In the real world' you'd be using something like a Mesosphere cluster to scale out and deploy the containers, which would send each kind to their native host types anyway.

    The whole windows on Linux, Linux on windows is only really interesting from a dev point of view anyway.

  • Window container support on client

    @kettch:Yep, there is nothing special about writing to a container, you just write platform independent code in you project and rely on platform specific containers below you to bring in the platform specific versions of the required runtimes.  Your build system just spits out a container per OS, with the correct container layers built in.  Assuming you have platform agnostic code of course.

     

  • Window container support on client

    @TexasToast: @kettch: What's this container abstraction you speak of?

    My understanding is containers comprises just the application and its dependencies. It runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers while benefiting from resource isolation.  As I understand it there is no special container API inside the container.

     

  • Too much gloom here lately, even for my taste ;-)

    , kettch wrote

    @BitFlipperThis video indicates that UAP now provides non-Async methods. File system access is specifically mentioned.

    Yep, they said while you should use the aync methods as a default, they are putting back no-async methods to make porting easier.  Same with Ex methods, they're adding non-Ex versions back for back compat.

    There was talk about adding Roslyn code analysis rules that would push you to the async methods if you choice to enable it.

  • Window container support on client

    @ketch: Is this what you where thinking of?  http://channel9.msdn.com/Events/Build/2015/KEY01 (22:00)

    In that case he built an ASP.NET 5 app (i.e. cross platform CoreCLR) which he built into a container on windows and ran on a windows server.

    When he re-targeted it against Linux, the docker tools for VS rebuilt the container as a native Linux container on the Linux VM he had deployed on Azure; the container is actually built and packaged on the VM, not the machine running VS.  It was the same app, but it was not the same container.