Everything you need to know about containerizing existing apps on Windows
It’s been almost 7 years since we released the first version of Windows containers on Windows Server 2016. I was there to watch the launch and remember even the early adopter versions. So much has changed since then. However, there’s one thing customers have asked since then that we haven’t really addressed in writing – A complete guide on what can be containerized on Windows containers.Using WSL 2 on Windows Server 2022 to run Linux containers
Windows Subsystem for Linux 2 (WSL 2) is one of the most popular features for developers on Windows 10 and 11. It has recently been made available on Windows Server 2022. With this addition, you can now run Linux containers on WSL 2 on Windows Server 2022 for development and testing purposes.How to change the user account for Windows Containers
Containers in general are seen as a turnkey solution to run applications. Once the app has been finalized, you expect the container to run the same way regardless of the environment. However, just like any other platform, there are some important aspects that need to change between development and production – especially when it comes to identity and security. By default, Windows containers run with a user account called ContainerAdmintrator which has admin access inside the container instance. If compromised, this container instance will allow an attacker to take control over shared resources – such as, but not limited to, mounted volumes. For that reason, whenever running on multi-tenant or least privileged environments we recommend to use the ContainerUser profile.5 tips for IIS on containers: #1 SSL certificate lifecycle management
Today, my colleague Amy Colyer and I are starting a new blog series based on our talk at Microsoft Ignite 2022. In the session we covered 5 tips for containerizing IIS applications with Windows containers. On that 45-minute session, we covered the management challenges on IIS that customers face today and how Windows containers and Azure Kubernetes Services can help with IT Ops practices. In this blog series, we will explore these tips in more detail. We will go over the management challenges, how Windows containers and other Azure services can help, and how to implement these in detail.Windows Server Summit Wrap Up
I was truly blown away by the content and collaboration for this event. This community is truly AMAZING, we had MVPs, Intel, Product Managers and Engineers all share their knowledge and experience. Here I am sharing the big take-aways and links to drill down into the specific subject at hand5 tips for IIS on containers: #5 Container and Node OS upgrade
When we presented this topic at Microsoft Ignite earlier this year, I asked the audience in the room the regular question we ask: How many of you are running Windows Server 2012 in your environment? Note that I’m not even asking about Windows Server 2008. Windows Server 2012 is already out of support. And more – if you’re not paying attention, Windows Server 2016 is already out of mainstream support! If you haven’t already, you should really start planning your upgrades. The problem is: Upgrading from old versions is hard. It’s a manual process that requires you to validate the all the components required for your app to work on the new OS version. And more: everything we covered in the previous posts on this blog series are reasons to make the upgrade process harder – making sure you manage the SSL certificates, multiple websites on a single server, hardcoded configurations, and scaling up and down. All of these just complicate the process, but if you’ve been following along and checking on how Windows Containers can help with IIS deployments, you now know how to avoid these pitfalls. Because we addressed the previous items, we’ll show how upgrading to the latest OS version is much easier with Windows containers and Azure Kubernetes Service.5 tips for IIS on containers: Bonus – IIS remote management
While the intent with the Microsoft Ignite session and this blog series was to provide 5 tips for running IIS workloads on Windows containers, we could not leave this one out – so here’s a bonus blog post for you! Many times when containerizing an existing application with Windows containers, you’ll get caught on the process of writing a Docker file, to then build a container image, to then run a new container, to then test if the application work… and if it fails, you have to start all over: re-write your Docker file, then build a container image, then run a new container, then test if the application work. Depending on how complex your application is structured, this will be a tedious process. To solve that, sometimes all you need is to open the IIS MMC console and check how the configuration of your website is showing up. However, the IIS remote management is not available on Windows containers. Since this is just an additional feature, all you have to do is to enable it. Before we get started though, keep in mind this is something you can use while developing/testing your application. This should not be used in production.Containers Basics: Providing Persistent Storage to Containers
One of the main differences you will notice when comparing containers with Virtual Machines (VMs) is that containers use an ephemeral storage by default. What that means is that containers use what we call as “scratch space” and this data is not persisted. So how do we present persistent storage to a container to ensure that new containers can always write to a place it can recover in case something happens to that container instance? There are a few ways you can solve this which we will cover in this post.5 tips for IIS on containers: #3 Hardcoded configuration
We’re getting into the third topic of our blog post series about IIS on Windows containers. In case you missed, check out the blog on SSL certificate lifecycle management and IIS app pools and websites. Today, we’re covering hardcoded configurations on IIS. This blog post covers the concept on IIS, but the idea is that any type of workload going into a container and running at scale on a Kubernetes environment should follow these best practices.
