 Hi everyone, my name is Thomas Maurer. I'm a Cloud advocate at Microsoft and I'm here with Vinicius from the Windows Container team to talk about Windows Containers for IT Pros. So Vinicius, why are we here? Well, if you are an IT Pro today, you probably noticed that when you start to learn about containers, a lot of the documentation and a lot of the recipes out there for using containers, they are heavily focused on developers. So one of the concerns we have is as ops folks in IT Pros, they start to work with containers. We want to make sure that they have the documentation and they know how to get started. So that's the reason why we decided to do this. Okay. That's awesome. So let's have a look what a container really is. Cool. Okay. So if you are an IT Pro, you are used to this. You have a rack with multiple servers and then you go and you install the operating system in that specific server. This is what it looks like from the operating system architecture, right? You have your hardware and then on top of that, you have your operating system composed by the kernel and then the application and services running on top of that. In a virtual machine, what you would do is you virtualize everything above the hardware. Now, if you really look into what's happening inside the operating system, you have two levels there. The first one is the user space. User space is where all your applications and all your processes and all your services will be run. The kernel mode or the kernel space is where the operating system action it takes over and instrument everything that is going on in the application level to the hardware itself. So when an application needs to access the memory or the network card, that's what the kernel does. They will operate that for the applications. Again, in a virtual machine, when you virtualize above the hardware, multiple OSs will have those levels and that's the isolation you have between the virtual machines. In a container, what happens here is that we are virtualizing above the kernel, not the hardware. So they are all sharing the kernel. So when you spin up on your container, what you get is you have a virtualized version of the user mode. So you have applications, processes, services running inside that container. If you spin up on your container, you have another isolation for the other application in there. So that's the main difference between a virtual machine in a container. So that's what containers are. They are a virtualization of the operating system. Okay, that's awesome. So I don't need to take care of virtualized hardware or anything, that's basically really a level higher than that. That is correct. The most important thing here is that all your applications, they are isolated from each other, but then a container, you will spin up way faster than a virtual machine. And also when you think about the management, you only manage one operating system itself. Okay, so does that mean like I should move everything to a container? Well, not exactly. Of course, there will be applications where you need more flexibility and you need more control over the operating system. And even sometimes the runtime for the container itself does not allow the application to run. So you still need virtual machines. Now there are other applications that will greatly benefit from containers and the way they spin up very fast. Web applications are one example. The other thing is when you spin up a virtual machine, we have what we call, I'm sorry, when you spin up a container, we have what you call as the scratch space. So everything that the container does, if you don't store in a persistent storage, will be lost when you kill the container. Okay, okay. If you want to actually persistently store that information, you need to find a persistent storage for that container. So web applications and many other applications can greatly benefit from containers, but not everything should be running in a container. You should have applications that will need some flexibility so you can use virtual machines for that. Okay, so that sounds like this could also potentially help me with my 2008 and 2008 R2 migrations. Oh yeah, absolutely. We are very close from the end of support of Windows Server 2008 and 2008 R2. In fact, we have a great Ignite session coming up, explaining how you can take an application that is running in a Windows Server 2008 R2 machine. It's a ASP.NET 3.5 application, and we export that application. We containerize the application and we show the whole process is a breakout session, a lot of good stuff in there. I recommend everybody to go check the session. Okay, now that sounds great. So we talked a lot about containers now. Can you show us something? Yeah, absolutely. So how do we get started with containers? Okay, so in order to get started with containers, just like virtual machines, you need a host or a node that is able to spin up containers just like you have for virtual machines. In order to do that in Windows Server, all you have to do is install the containers role. That will install the containers role as well as the Docker runtime. What the Docker runtime will do as you see the command Docker in here is actually expose all the capabilities of the container platform in a way that you can use and also manage the containers itself. So in order to get started, the first thing you have to do after you install the containers role is to have container images. One thing that everybody working in the container needs to know is that all your containers, they are created based on a container image. Okay, so it's not that I can read that empty container and then install an operating system in it, it really comes from a predefined image. Correct, yeah, in a virtual machine, you would spin up the Hyper-V manager, create a new virtual machine, set up all the configuration and then put an ISO file that you can go and install the operating system. With containers, you already created container base on a base container image. So if you run the Docker image command, you will see that in my case, oops, there you go, you'll see that I have already a few container images in here. This is because I'm using a virtual machine in Azure that already come with these three container images. The Windows, the server core and the nano server, they all serve different purposes, depending on the application that you are going to containerize. The most common for IT pros and ops folks would be the server core one. The reason is this is a regular Windows server core installation. So everything you can do in a server core, actually not exactly everything, let me rephrase that. So almost everything that you can do in a server core installation in a virtual machine, you can probably transport to a server core container image as well. So these are, sorry. Okay, so these are basically images from Microsoft, like the base images you can get, right? These are not something you get from, like wherever you get them from, it's really official Microsoft. Absolutely, in fact, what I have here is the Docker hub, which is probably the central location that you'll be looking for when you get started with containers. The Docker hub is a central location that has a lot of community uploaded container images, but Microsoft is also there. So one example here is the Windows IIS container image that we'll be using in a second. Basically what this is, is a server core installation inside of a container that already has IIS pre-installed. So you don't have to go and install a container based on server core, then you go and you install IIS and then you create another container image based on that container that you just created. We already have the running. If you have a ASP.NET application, we have a container image ready for that. Oh, that's great. So I don't need to spend so much time creating everything by myself. I can really take like pre-created images. Correct, yeah. But for the purpose of learning here, let's go ahead and spin up a container based on this server core container image. Just to briefly explain the other ones that people might be wondering, the Nano server container image is a extremely small container image as you can see in comparison by the size, but it really focused on new application that developers are running and they target from their Visual Studio coding, they target Nano server as the platform for their application. And the windows is a bigger container image that has more features and API surface compared to the server core. So if you have an application that is not running on server core, you can probably try to run that on Windows container image. Okay, that's awesome. Cool. Okay, so let's get started. What I'll do here is I'll change from this PowerShell window to this one just because on this one, we'll be running inside of the container. And from this one, I'll show what's happening on the host. All right. So let's run this one. What I'm doing here is I'm running the Docker run command and the Docker run will basically tell Docker to execute a new container in the start back container. Okay. The rest of the information in there was basically that I said the name of the container that I was spinning up. I'm running a interactive session inside this container which is the dash IT. And then I'm running from the server core container image and I'm running a PowerShell session. So what you see here is that we are inside the container and we are inside of a PowerShell session. So if I type there, for example, you can see that this is a regular Windows server core installation, right? The thing is inside the container, remember that we are abstracting the kernel. We are virtualizing that and we are running a containerized version of the operating system. So it will be a little bit different from the container as from the host. So let's take a look at that. As you can see, I can type there here. I see a very small installation of Windows server core here. I can also look for the C users folder. And if I type there, you'll see that we have a container user and container administrator profiles in here. And if I do the same on the host, you see that I have a different version. So basically what that tells us is that the container has a different file system from the host, right? Okay. So I cannot basically not access files from the host or I cannot like, if I save something, it's like isolated from the host. Correct. Yes. The next thing the containers have that is different from the host is containers have their own view of the registry, right? So if we run the command, just see our path variable here, you see that we have these options listed for us. And if I run the same command from the host, you see that in this one, for example, I have the C program files docker listed as one of the variables in the path. I don't have that inside of the container, right? In fact, I have a different set of configurations in here. That's again, because the container have a different registry when compared to the host, right? The third thing that containers have that is different is the processes that they are running. And this is interesting because if I run, for example, the get process, there you go. I have a number of processes running in the container and if I run the get processes from the host, you see that I have way more. In fact, if I run the get process from the host and I measure it, I have 116. And if I run the same thing from the container, I have only 23 processes running. More importantly, one of the regular processes that we have, process that we have in Windows is the get process and the name of the process is SMSS. And every Windows installation will have, of course, just one instance of the SMSS process. Now, if we go to the host itself and I run the same command, you can see that I have two instances of this process running in here. And the interesting thing is if you look at the ID of this process in the container, it's exactly the same one as in the host, which tells me that the host has some administrative boundaries that he can see inside the container, but the container cannot see from the host. Oh, okay, that's awesome. So I really have, from the host, I have more control. I can see all the things running on the host, but from the container, I'm really isolated and I cannot impact the host or all the containers running next to me. That is correct. And that's what we are looking for. We want to run that application completely isolated from the others. Okay, awesome. So you told me that, okay, every container basically we start is based on image. So can you show me how do I create, for example, my own image? If I want to do, create something like special or like something of my own application in there? Absolutely. So what happens with a virtual machine is when you have a template for the virtual machine, usually as an IT pro, what you would do. You would spin up a virtual machine and then you would configure that virtual machine exactly the way you want the other virtual machines that are based on this one to be, right? So you install your application, you configure the folders, folder structure or files, you copy everything to that virtual machine and then the final part is the good and old sysprep, right? And run sysprep, you turn off the virtual machine, you get the VHD file and then you put it in a place where it's accessible to whoever wants to deploy new virtual machines based on that template, right? With containers will be a little bit different. So we talked about the Docker Hub already, right? The Docker Hub is the place where in the final portion for the virtual machine you would store your VHD, but in this case is the container image. Now, the process to create those container images is a little bit different. You could spin up a container, configure the container you want and then turn that container into a new container image. But the other way to deal with containers is to actually do this declarably. Yeah. What that means is you are going to specify what are the instructions to Docker in a file called Docker file, how to prepare that container image to reflect what you want new containers to be created. Okay, so basically I would take like, okay, let's say this is the container I wanna start with and then I would basically go, instead of doing everything manually, I would basically write it down in that Docker file. In a recipe, yeah. Okay, perfect. And then you basically have that the end, you build that container and you have your new container image basically. Yeah, absolutely. Okay. So let's take a look. Yeah. Okay, so of course, when you are working with a complex application, you would need to see what that application requires in order to work. If it's a ASP.NET application, you have to first install IIS, then you have the IIS parameters that you have to set up in all the dependencies, the features itself. In this case, just for the sake of explaining how building a new container image work, I only have this test file here. And I also have a Docker file. The Docker file is the recipe as I mentioned. And the command that I'm going to use to build a new container image from this Docker file is a Docker build. So let's take a look at the Docker file first. As you can see, the Docker file is a Docker file as the name of the file itself with no extension. I can open with Notepad. You can also use Visual Studio Code. There is an extension for working with Docker with Visual Studio Code, if you are familiar with that. But for regular IT Pro, if you are a little bit intimidated with Visual Studio, just use Notepad. Basically, as I mentioned, everything we're doing here is explaining kind of a declaratively way how to build a container image. So what we are doing is we are telling the Docker file to start from the IIS container image that I previously pulled from the Docker Hub. Then I'm going to say the working directory that we are going to use is the regular init pub www root, right? So every installation of IIS has this folder in here. Now the interesting part about the work there command here is that if this folder doesn't exist, it will create for us. So let's say I have a C-test folder that I want to create. I can just put it in here. And the work there will also start from the C folder. So if you want to specify init pub www root, that's what you would use. And then the copy file basically would say everything from the folder that we are running the command on the host copied to the working directory inside the container. So that's the reason why you only have two dots in here. So from the folder we are from the host to the folder we are inside the container. Okay, so all we are doing here basically, we are like specifying the base image and saying, okay, we want to have an IIS installation already. Correct. We specify the location where we want to work with like the work directory. Correct. And then we say, okay, let's copy these files in that work there. And if you remember in the old days where we used to manage IIS instances and you have a simple HTML file, copying the files to the init pub folder is exactly what you do to have the website running, right? Okay. Okay, so I can close this one. Let's take a look at our folder over here. There you go. So if I type there, you can see that I have two files in there. So now what I'm going to do is I'm going to use the Docker build command. And then I'm going to associate a tag to this image so I can find it later. So test container image. And then I'm specifying the location I'm going to use is exactly the same one that we are right now. So as you can see, this will be actually very fast because we're not exactly running any process inside a container. What we have here is that Iran, the command should use the IIS image. And then from the IIS image, what we did was we are creating a new layer for the container to work with this directory and then copy the files to that specific directory. Okay, that's all. That's how container images are built. And this is very important because the more instructions you have inside the Docker file, the bigger will be your container image. So every command you specify inside the Docker build or the Docker file, this will generate a new layer for your container image. Okay. So there are a set of best practices here. We can talk about this later in another video maybe. But for now, our command ran correctly. So if I run the Docker images again, you see that I now have another image called test container image. And the only difference between this one and this one is that this one has the new folder, the netpub www.root. And then we copy the file to inside that folder. Okay. So basically it's based on that and with all our changes we have, we have now our own image. Okay. Correct. So now, just like with virtual machines, you have the template for your container. Now, the thing is let's create a new container based on this container image. In order to do that, I'm gonna run the same command I ran before, the Docker run. Now, this will be a little bit different than the one before. And the main reason is we have to specify a few things that are different from the previous one. So the first thing I'm gonna do is I'm gonna say dash D because we're going to run detached from this session that we are in PowerShell, which means that we'll run the container and it will run but we are not inside the container. Okay. So basically it runs in the background but we don't need to take care and interact with it. Okay. Exactly. The next thing we need to do is because this is a IIS web server, we need to open the port from the host to map the port inside the container. And HTTP, that's the port 80 from the host mapped to the port 80 of the container. So we are using that here to translate the port from the host to the container. Okay. Now let's give it a name to this container. So I'm gonna call test container. The image that we are going to use is the image that we created before which is test container image. So the syntax here is a little bit different than regular PowerShell but this is pretty much the command you use to create a new container based on the container image that we just created. So you will see that in a matter of seconds we have a new container running, right? So it's really fast to spin up and have the application up and running, right? Yeah. So it's way faster than starting up a VM or like even a physical server, right? Correct. Running an IIS. Yes. Now, of course, what everyone wants to do is actually go and test this to see if it's running or not. So if we run the local host on the port 80 you'll see that we have the application up and running. Now, the most important thing is that we also copied a file to the www root inside the container, right? And that was the test.txt. And you can see that the file was correctly copied to inside the container and the application which is in this case is just a web server is up and running. Okay, that's pretty cool. So I can really pack my application into a container image and then basically just run it and it has done everything for me. We've defined that container file. Exactly. And one thing that we can try, for example, is let's say you wanna run another container. Everything I have to do here is change the port that I'm opening because I can't map the port 80 for two instances of containers. So I'm gonna change 81 in this case, mapping to the port 80 of the container and I'm gonna call container two. It's up and running. There you go. Okay, awesome. So I could run like a couple of IS instances like IS even like servers basically or containers on the same machine with different versions if I wanted to, okay. And if you remember in a regular deployment of a virtual machine you specify, I don't know how much you need for a regular windows deployment with IS three or four gigs or depending on your application. Here we are running in a virtual machine, the same virtual machine, two instances of our website which means that I'm using way less resources from this host. Yeah. Wow, that's awesome. Cool. Could I would say we do the back? If the Docker PS. So one last thing to show is the Docker PS command. So the Docker PS command will show you what are the containers that you have running in a machine. So you see here that I have the test container one, actually no number specified and then a test container two, it shows what is the command that they are running, how long they have been created and the ports that were open to this machine. I'm sorry, to this container. Okay, so that's how we can basically see what containers are running and what I have there. Is there also another way like an IT pro or me managing now these containers? Is there another way to manage these containers instead of just like using the PowerShell or this Docker command line? Absolutely. So one of the tools that IT pros are really familiar with today is Windows Admin Center, right? So what I'm doing here is I'm targeting my container host and I have an extension here called containers. We'll see we enable this extension. So basically what the containers extension shows me is how many containers I have here. It shows me that I have two running, one is stopped probably from before the demo. I have four different images. One is the latest one that I'm using, totaling five in total. How many networks I have, how many volumes I have associated to the container. And then if I wanna check the containers itself, I click the containers tab and then it shows me the containers that I have. You can see that I had a container, task container before we run this. So one of the things that you can do here in the containers tab is to actually go and check what are the containers that are running. You can see the logs from inside of the container. You can see the stats like how much CPU and how much memory that container is using. I can also look into the images that I have. From the images tab, I can see what are the images that we have and you remember that we just created the task container image. And I also have other tools in here like the networks and the volumes that I have associated to this container. So it's actually a visual way to manage the containers you have running in a container host. Okay, that's awesome. I mean, that's like for us, whereas ID pros, we need to operate those container hosts and those container environments. We have a great tool basically to manage those hosts and see what's going on in that way. Okay. Okay, since you've now showed me how basically we can get started with containers, what would I do next? Yeah, so the next step is try it out by yourself. So we have the webpage called aka.ms slash containers and that's where we have all of our documentation. If you wanna try on Windows 10 or if you wanna try on Windows Server, how to get started on downloading the images, how to use the Docker file, how to use Docker build to create your container images. And of course, as an operations person, the next thing you wanna know is, how do I scale from one container to multiple containers? And of course for that you have orchestrators to help with the task. Kubernetes is one option. We have our own service in Azure called Azure Kubernetes Services. It's something else you can look into the documentation. We are looking into improving those tools specifically for IT pros. So if you have recommendations on stuff that we could get better or even in a documentation, let us know we're here to help folks get started and be successful in using containers. Okay, now that sounds great. Thank you for having you. And see you in the next one.