 Okay, I think we can start Hello everyone and welcome to the session about Windows containers This is where we'll be talking about some new cool features that are coming in Windows Server 2016 I'm Vlad Ivanov. I'm a technical lead for Cloud Foundry at Hewlett Packard Enterprise Hey, I'm Stefan Schneider. I'm a software developer at HPE Both Stephanie and I have been involved with Cloud Foundry for about five years We were a part of a startup called the Huda Software that's now part of Hewlett Packard Enterprise We developed the first DEA for Windows If anyone is not aware the DEAs were the elastic runtime for Cloud Foundry before Diego was a thing So we're now continuing that work to bring Windows to the Cloud Foundry ecosystem and we're trying to add support for native Windows containers for Diego and The team that we're a part of also maintains the Visual Studio tools and the .NET SDK that have just graduated from incubation From the Cloud Foundry incubator So I'm going to the major mechanisms that the current garden windows is using to create some kind of isolation between processes or applications So the current implementation for garden is for Windows 2012 R2 only It is a best effort implementation with some known isolation risks So for every app instance or container there is a dedicated user with low privileges Processes run under the low privilege account to prevent system-wide modifications in the Windows app system Thus applications cannot install new system components or affect system-wide configs Now to keep track of what is running inside Windows Prevent fork bombs and enforce some type of memory restrictions Processes are further isolated by Windows job objects But job objects are not bulletproof There is at least one method to escape a job object using Windows console processes and Also because Windows memory management is very complicated It is hard to enforce all type of memory quotas. For example, it does not count memory math files For network access control garden windows will dynamically create Windows firewall rules To block outbound access based on Cloud Foundry security group rules But still apps will Will use the same network adapter and IP address of the Windows host Also another limitation of Windows firewalls is that the rules do not apply to local holes or any internal traffic inside the host So hopefully I convinced that the current implementation is a best effort and If there's something better, we should consider it Yeah, so like you just saw there is a lot of duct tape involved into creating the current implementation for For Windows on Cloud Foundry. Basically, there's no there are no real containers So what does Windows server 2016 bring actual containers? It has native support for it We have hyper V containers, which are isolated kernels Those are containers that actually lightweight VMs But we also have shared kernel containers and those are the ones those are the kind that we care about and These are the ones that are that we are going to be focusing on this talk So having actual containers means we need something like chroot and Microsoft has made available to root file systems so far as a full Windows 2016 server and also the much smaller new nano server so These two images will give users more choice and of course the new nano server will probably Help out with application density a lot And finally, you know, you get network isolation like Stephie mentioned Network isolation can get very tricky But using the new net driver capabilities on Windows 2016 each container gets its own IP IP address from an internal private subnet This is very similar to it's equivalent to Network namespaces on on Linux So these are the are the things that will make Windows support for Cloud Foundry truly a first-class citizen and we're really excited to work on new integration So this is their architecture of Windows 2016 Diego cell Before I go on to details I want to mention that Windows 2016 is GA as of this week So As a small intro to Cloud Foundry architecture the Diego scheduler The Diego schedules and runs Cloud Foundry applications on Diego cells So application that are pushed to Cloud Foundry will eventually end up running on a Linux Diego cell or Windows Diego cell The Diego components are marked in green here The first one is a rep which is a representative or agent for the Windows machine in the Diego cluster Thus The second one is metron which is an agent for Logurgator which forwards app logs and metrics and The third one is console agent which provides services covering between the ego components Then we have garden windows Which is designed for Windows 2016 Is the local service that provides a rest like API consumed by the rep to manage containers and run processes and At below garden windows, there is the compute service also known as host compute service or HCS Is a brand new Windows API in 2016 that provides the capabilities to create native containers in Windows I'm going to give a small overview of the communication flow between components So when a Cloud Foundry app is started First the rep will receive the request to run the app Then the rep will instruct Garden to set up the container and start the app and after that garden will invoke the compute service API to create native windows containers and run processes inside and In the meantime rep will stream the standard out and standard error to Mitron from containers So the only new component in this architecture Is the garden service? This is why it's marked in orange The rep and Mitron console are compiled from the same code as their Linux counterparts Some details about garden So to create the garden service with a new Windows 2016 native containers We had to implement a completely new garden back-end in Golang for the garden server The new garden back-end has to connect to the compute service API to create the actual containers and run the processes Now to interact with a compute service API. We use the HCS team go library from Microsoft Which is also used in Docker demon implementation for Windows for For implementation. We also try to reuse as much code available From the Cloud Foundry community or that Microsoft has contributed to Docker One example the Diego health check used in our Implementation is the same the same one as the Linux counterpart Which means that we're using less workarounds when working with Windows, which is a great thing Now also we have as a support For Windows 2016 Which means that CF SSH to a Cloud Foundry app for Windows works This is very useful when debugging running applications We use for this Cloud Foundry's Diego SSH server, which is returning go with some additional changes to use the WinPTI As a background WinPTI is an open-source project that brings PTIs to Windows and will translate between Windows console actions to a TTY stream usable by an SSH client Also, this will enable features like history, type completion, control-z and so on so Buildpacks we recognize that buildpacks are an important part of of Cloud Foundry and In the Linux world they offer a very easy way to add new capabilities to the platform and they also serve as kind of an An extension point that a customer can use So we we want to bring this part of buildpacks to to Windows as well And given that the goal is to have feature parity with Linux Buildpacks are definitely a part of our part of our efforts so the POC that you're about to see demoed has full support for buildpacks and This means that You'll be able to use IS the IS build back the exe build pack that are already available and working using the WinDEA the the DEA for Windows implementation that I mentioned at the beginning of the talk and With containers Windows buildpacks can become much more interesting You could have a build pack that actually that they can actually run Windows services or Scheduled tasks, so the ability to have an actual contained system Will open up buildpacks for for Windows in a much nicer way Now a small demo with Windows 2016 Let me close this better so This is a local deployment. So everything is on my Mac here This is a Bosch light and This is the second the third VM is actual Windows 2016 So if I do Bosch target, I'm just going to show you that I'm targeted to Bosch light deployments So this is the actual CF version 242 all right, so this is running Now for the CF target and targeted here to the API Bosch light calm Let's check the CF stacks first So there is a new stack now Windows 2016 Let's check the build packs So we have here two new build packs for Windows one is the XC build pack and the other one is IS 8 build pack right Let me check if this is clean all right. I don't have any app So I'm going to push here an XC application which is actually a go app We just Serves a basic HTTP request with hi. I am a standalone lab. I have here the actual executable compile already and there is run.bat Which actually is the entry point that the build back will use for auto detection So now to push this I just CF push XCF for the app name stack Windows 2016 All right, so this is uploading You can see that the all the build packs were downloaded and it was pretty fast because The rep will cache these build packs and notice that logs are streaming as well. Yeah, and there you have a staging complete the build pack was auto detected and We have an URL Let's try the URL And it's working Now let's see the SSH feature So we just have to CF SSH an app name like any other Linux application So we are inside the container Let's see system information So here you see that it's Windows Server 2016 technical preview 5 Right This actually works. Okay, like the terminal won't bounce won't Yeah Clear screen also work. Let's go to power shell We can also get the windows those Features if we want to inspect what's inside the container and also because we have Administrative access we can also like installing features if we want to install windows feature and for example Let's just say telnet client just to have something very fast So partial progress bar is also working and Yeah feature install complete and we have telnet Now let's see Our process tree here inside a container This is how the actual process tree looks inside Windows container there are extra services running for each container and Here we can see our app I'm just going to just stop this process process name and web app and Now we can see after three seconds the health check will kick in from Diego and This app will get recreated And we can still check that the app was up and running after Diego restarted so So this was the demo for an actual executable app. I'm also going to show you an ASP.net app So for this I'm going to start another development box where I have visual studio So here I have ASP.net app is Opened in visual studio It's a sample app from the template. It just has some It just has some Some nugget package installed so that we can push this app So for this we right-click on the app. I'll select publish to cloud foundry Select our Bosch light target Yes, we are happy with Diego Oregon space Next let's call it web app. We we're just going live auto detect here Select windows 2016 stack I'm going to change the URL Yes, we want Bosch light URL Next you don't want services We're good to go so finish We're going to see the output logs Here in the output pane These are actually coming from the MS build tasks This are same as CF logs You can see it should be done This is a bit of verbose but the push operation finished and now let's just browse the app to see Here we have the web app. We can see here the detected build pack was as 8 which was automatically Now it's viewing browser The first hit takes a bit longer to initialize the dot net Yep, there we go. So this is the actual app push to windows 2016 Let me also show you the inside of the actual windows 2016 cell How the process tree looks there So I'm going to RDP inside Right, so this is the actual cell. It's taken the preview 5 This is a normal server here, we have the metron server service that I described a console This is the actual garden implementation Rep here and at the end We have our two containers One is this web app and here is the second one So we can see that we have our ISP dot net here in a hostable web core Now let's just try to terminate the map and After a while we can see that the whole container will get destroyed and recreated by by Diego The health checks truth kicking. Yep did and now it's just recreated and And Yes, we have the new process for a speed.net and You can check the app that That it's working again take some time for the first hit And that's it. It works again Yeah, I guess that concludes the demo Let me switch back to the slides So what's next? We still have many things to do we would also like to support the docker application lifecycle as well We think that having both app life cycles build packs and docker Available for Windows would be would be great Then we would want Security groups to work on Windows the same way they work on Linux You can imagine that the operator experience would be much greater if if they if the if the Operator could use the same tools for Linux as they do for Windows to set up these things And then of course supporting more than one root file system We're currently using the full windows 2016 root file system using the nano server one would be great To be give you a comparison the nano server image is about 450 megs The full windows one is five gigs So great improvement there And then finally Resource enforcement the POC in the demo that you just saw doesn't do resource enforcement on Or on memory or CPU So we would like to enable those as well And of course if if you have any suggestions, we're happy to learn about them To to make this thing this thing better and Contributors are welcome. We're planning to open source all of this work Like if you mentioned it's a it's basically a back in implementation for garden. So please keep an eye out for this It's not difficult to stand up basically you just use an existing Bosch light deployment and then there are Packer scripts available that allow you to create a Windows image for vagrant that you just end up and you have your your Your development environment Yeah, we're going to open source it So please keep refreshing that page Yeah So that concludes the talk if there are any questions Yes, please go ahead The question was how are we relating this to the greenhouse project? Well, it's it's similar in a way that greenhouse just uses a Garden back end as well So we're all sharing the same code for for the most part the rep is the same the metron is the same All the things are essentially the same except for the for the back and implementation of garden so if you think about it, it's Like 90% same thing Any any other questions great? Oh? Try this out I think there are evaluation images for Windows a server So you can you can download that? Can you so if we tried? Oh, have you ever tried no, but I think you should work fine Just config but no Okay, thank you very much