Containers articles

Simplifying gMSA for Windows Containers on AKS: Open-Source Tooling Now Available

natashapolito — Thu, 23 Apr 2026 22:11:32 GMT

We’re excited to announce that the Windows Containers AKS gMSA tooling is now publicly available on our GitHub repo (Microsoft/Windows-Containers-AKS-gMSA): Windows-Containers-AKS-gMSA.

This open-source repository provides tooling to simplify configuring Group Managed Service Accounts (gMSA) for Windows containers running on Azure Kubernetes Service (AKS)—making it easier to containerize and run Active Directory–dependent applications in Kubernetes.

Many enterprises rely on Windows applications that integrate with Active Directory (AD) for authentication and authorization. As these workloads move to AKS using Windows containers, it’s critical that they continue to securely support AD‑based authentication. This tooling helps organizations modernize to containers while maintaining trusted identity and authorization workflows built on Active Directory.

Who this is for

This tooling is intended for:

Teams modernizing existing AD-dependent Windows applications

Customers running Windows containers on AKS who require Kerberos or Integrated Windows Authentication

Platform and infrastructure teams looking to standardize gMSA setup across environments

Anyone evaluating whether gMSA is the right fit for their Windows container scenarios

If you’re running workloads that depend on Active Directory and want to bring them to AKS with minimal refactoring, this repository can serve as a starting point for validating gMSA in your environment.

Why gMSA on AKS matters

Windows containers are a natural fit for modernizing existing IIS, .NET Framework, and other AD-integrated applications with minimal code changes. However, containers themselves can’t be domain joined, which historically made AD authentication challenging in containerized environments.

With gMSA support on AKS, Windows containers can securely authenticate to Active Directory without requiring domain-joined nodes, instead relying on the AKS host to perform authentication on the application’s behalf. This enables:

Secure AD authentication for Windows containers

Easier cluster scaling and upgrades

Reduced operational overhead compared to domain-joined node models with no changes to the AD infrastructure required

While platform support exists, configuring gMSA on AKS still involves multiple moving parts—including AKS, Active Directory, Azure Key Vault, and credential specifications. This tooling is intended to help streamline that setup by reducing manual configuration across these components.

What’s in the repository

The Windows-Containers-AKS-gMSA repository provides a PowerShell module and supporting scripts designed to simplify the end-to-end setup of gMSA for Windows containers on AKS.

Key highlights include:

A PowerShell module to help configure an AKS cluster for gMSA usage

Automation to reduce manual setup across Azure, AD, and AKS components

Documentation and troubleshooting guidance for prerequisites and common pitfalls

A trial/validation setup to help stand up a test environment for gMSA on AKS

The goal is to lower the barrier to entry and make it easier for teams to experiment with—and ultimately adopt—gMSA for their Windows container workloads.

Getting started

To get started, visit the GitHub repository and review the README and documentation:

https://github.com/microsoft/Windows-Containers-AKS-gMSA

You’ll find:

Environment and prerequisite requirements

Instructions for importing and using the PowerShell module

Guidance for validating your setup in a non-production environment

For the official documentation, please visit Use gMSA on Azure Kubernetes service in Windows containers | Microsoft Learn.

Open source and community feedback

By making this repository public, we’re inviting the community to explore, experiment, and provide feedback. While this tooling is designed to simplify setup, it’s important to review the documentation carefully and validate configurations in test environments before production use.

We welcome issues and feedback, suggestions for improvements, and any contributions that help improve reliability, clarity, or usability.

What’s next

This release is part of our continued effort to improve the experience of running Windows containers on AKS—particularly for customers modernizing existing Windows Server workloads that depend on Active Directory.

We look forward to hearing how you’re using gMSA on AKS and where we can continue to improve the setup and deployment experience.

Announcing Log Monitor v2.2.0 Release Candidate

Bob_Sira — Wed, 15 Apr 2026 23:50:34 GMT

We are excited to announce the release candidate for Log Monitor v2.2.0, now available on GitHub: LogMonitor v2.2.0

Log Monitor is an open-source tool that enables Windows containers to surface logs from multiple sources, Event Log, ETW providers, and log files, directly to the container's stdout, making them visible to container orchestrators like Kubernetes and Azure Container Apps.

What's New in v2.2.0

Replaced Boost.JSON with nlohmann/json

The most significant change in this release is the replacement of the Boost.JSON library with nlohmann/json, a lightweight, header-only C++ JSON library. This change:

Removes the heavy Boost dependency, reducing build complexity
Simplifies the vcpkg dependency management
Maintains full backward compatibility with existing configuration files

New AKS + IIS Example

We've added a complete end-to-end example for running Log Monitor with IIS on Azure Kubernetes Service (AKS), including deployment manifests and step-by-step documentation. This makes it easier to get started with log monitoring in production Kubernetes environments.

Bug Fixes

This release also includes a number of important bug fixes to the configuration file parser:

eventFormatMultiLine now correctly defaults to true when not specified in the config
waitInSeconds for File log sources is now correctly parsed (previously always used the 300s default)
Optional channel level now correctly defaults to Error when omitted, instead of causing a parse failure
Invalid log sources in a config file are now skipped gracefully — valid sources in the same file continue to be processed
Fixed a path traversal vulnerability in the /Config command-line argument
Reduced unnecessary error log noise for ERROR_NOT_SUPPORTED cases

Upgrading from v2.1.x

Upgrading to v2.2.0 is a drop-in replacement — no changes to your configuration files are required. The config file format is identical to v2.1.x.

To upgrade:

Replace LogMonitor.exe with the v2.2.0 binary in your container image
Run your existing LogMonitorConfig.json as-is — no edits needed
Test your container to confirm logs are still flowing as expected

If you were building from source, see the updated build instructions below — the build system has changed and the output path is different from v2.1.x.

Building from Source

The build system has been updated from a standalone Visual Studio solution to a CMake + vcpkg workflow. A single script handles everything:

.\build.cmd

This will automatically:

Clone vcpkg into the repo root
Bootstrap vcpkg and install nlohmann-json (downloaded on first run)
Configure the project with CMake using Visual Studio 2022
Build LogMonitor.exe and LogMonitorTests.dll in Release configuration

Prerequisites: Visual Studio 2022 with the C++ workload and Git must be on your PATH. No other dependencies need to be installed manually.

Output locations

Artifact	Path
LogMonitor.exe	LogMonitor\build\Release\LogMonitor.exe
LogMonitorTests.dll	LogMonitor\build\Release\LogMonitorTests.dll

Note for upgraders: In v2.1.x the binary was placed at LogMonitor\x64\Release\LogMonitor.exe. If you have a Dockerfile or CI script that copies the binary by path, update it to the new location above.

Example Configuration

Here is a basic LogMonitorConfig.json that monitors Windows Event Log, an ETW provider, and a log file — covering the three source types Log Monitor supports:

{
  "LogConfig": {
    "sources": [
      {
        "type": "EventLog",
        "startAtOldestRecord": false,
        "eventFormatMultiLine": false,
        "channels": [
          { "name": "System", "level": "Error" },
          { "name": "Application", "level": "Warning" }
        ]
      },
      {
        "type": "File",
        "directory": "C:\\inetpub\\logs\\LogFiles",
        "filter": "*.log",
        "includeSubdirectories": true,
        "waitInSeconds": 5
      },
      {
        "type": "ETW",
        "eventFormatMultiLine": false,
        "providers": [
          {
            "providerName": "IIS: WWW Server",
            "providerGuid": "{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}",
            "level": "5"
          }
        ]
      }
    ]
  }
}

This config is a great starting point. Drop it alongside LogMonitor.exe in your container image and adjust the channels, file paths, and ETW providers to match your application.

Improvements to CI/CD Pipelines

We've updated both the Azure DevOps and GitHub Actions SDL compliance pipelines to correctly install nlohmann/json via vcpkg before building, ensuring reliable builds across all CI environments.

Getting Started

You can download the release binaries in the repository.

To get started with Log Monitor, check out the documentation and the new IIS + AKS example.

Feedback

We'd love to hear from you! If you run into any issues or have suggestions, please open an issue on GitHub.

Announcing Public Preview of Window Server 2025 on Azure Kubernetes Service

Akarsh — Tue, 18 Nov 2025 19:28:49 GMT

We are excited to announce the public preview of Windows Server 2025 support on Azure Kubernetes Service (AKS) - delivering the latest security, performance, and compatibility improvements for our customers. You can now deploy node pools running Windows Server 2025 alongside those running Windows Server 2022, Azure Linux, and Ubuntu. With the new Windows container portability functionality introduced in Windows Server 2025, you can also run your Windows Server 2022-based containers on Windows Server 2025.

Enhanced Container Portability and Flexibility

Windows Server 2025 introduces expanded container portability functionality, allowing Windows Server 2022-based containers to run seamlessly on Windows Server 2025. This builds on previous improvements to Windows Containers, where user and kernel interaction decoupling enables existing container images to run on a newer host OS. Customers benefit from faster upgrades to container hosts without needing to update container images in parallel, resulting in greater flexibility and portability. This allows you to take advantage of improved security and performance while maintaining compatibility with existing workloads. For more information on version compatibility, see here.

Nano Server: Lightweight, Efficient, and Now More Capable

Earlier this year, we announced that Windows Server 2025 Nano Server - our most lightweight container image - now supports a broader range of applications, including 32-bit apps that previously required Server Core. With new Feature on Demand (FoD) support, customers can include only the specific functionality needed, keeping images lean and efficient. This enables you to move select applications to Nano Server based on Windows Server 2025 while keeping others on Windows Server 2022 within the same node pools. The result is maximized density, lower cost of goods sold (COGS), and streamlined operations. For details on using FoD support in Nano Server, see here.

GPU Acceleration for Modern Workloads
Windows Server 2025 adds support for running CUDA-enabled workloads directly inside Windows containers. This enables customers to leverage GPU acceleration for compute-intensive applications such as AI inference, data processing, and simulation, all while maintaining the same container portability and upgrade flexibility described above.

Getting Started

To preview Windows Server 2025, customers can create a new node pool with --os-sku set to Windows2025. This is supported on Kubernetes version 1.32 and above. Our documentation provides instructions on creating your first Windows Server 2025 node pool.

As always, your feedback is invaluable in shaping the future of Windows Server Containers. We encourage you to share your experiences and insights through the Windows Container GitHub Community.

Discover the New Era of Windows Server 2025 Nano Server Containers

Akarsh — Mon, 23 Jun 2025 16:06:16 GMT

Overview

Today, we’re excited to announce a new era of Windows Server containers with more powerful Windows Server 2025 Nano Server containers. Windows Server containers have long been a go-to solution for delivering lightweight, scalable applications. However, users working with Nano Server containers have traditionally faced a trade-off between efficiency and functionality. While Nano Server’s minimal footprint made it ideal for resource-constrained environments, it lacked key features required by modern applications. In this blog, we explore how the Windows Server 2025 Nano Server container addresses these challenges, bringing a new level of flexibility and functionality with the introduction of Features on Demand (FoD) support for Nano Server containers.

When Efficiency Limits Functionality: Overcoming Nano Server’s Trade-Offs

Nano Server was designed with a singular focus: maximum efficiency through a minimal footprint (typically around 175MB compressed). This approach reduces resource consumption, minimizes attack surfaces, and accelerates deployment.

However, such minimalism comes with trade-offs. When an application requires functionality not included in the Nano Server image—such as 32-bit (WoW64) application support, IIS components, or PowerShell—users have traditionally had to switch to the larger Windows Server Core container image. Although Server Core offers broader compatibility, it does so at the expense of a significantly larger size (around 2GB compressed and potentially growing with updates).

These limitations made Nano Server less suitable for workloads that demand additional features or legacy compatibility, despite its impressive performance and efficiency.

Introducing Features on Demand (FoD) Support

To overcome Nano Server's limitations without compromising its hallmark lightweight design, Windows Server 2025 introduces Features on Demand (FoD) support for Nano Server containers. FoD offers a dynamic approach to container image management, allowing developers to include only the specific capabilities they need—such as 32-bit (WoW64) application support—during the container build process. By avoiding the need to bundle all features into a single pre-installed image, this model preserves the minimal footprint of Nano Server while enabling broader application compatibility.

The underlying technology not only resolves current compatibility challenges but also lays the groundwork for future innovations in Windows containers. As the platform evolves, FoD will enable new roles and capabilities, empowering users to incorporate only what is necessary, maintain optimized images, and unlock greater flexibility with future releases.

Key Benefits of Features on Demand

Reduced Image Footprint and Faster Pull Times: By excluding optional features from the base image, the initial download and storage size remain minimal, leading to quicker pull times and faster deployment.
Enhanced Density and Performance: Smaller images consume less memory and disk space, allowing a higher density of containers to run on the same infrastructure, which improves overall application performance.
Granular Control Over Features: Users can precisely select and add only the specific components their applications need, resulting in highly tailored and optimized container images. This also improves security by reducing the attack surface.
Cost Optimization: Maintaining smaller image sizes by including only the necessary features can lead to tangible cost savings in cloud environments.

Addressing 32-bit Application Support

Through this investment, we’ve also addressed one of the most significant limitations of the original Nano Server container image: its inability to run 32-bit applications. This limitation arose from the deliberate design choice to minimize the image footprint, as supporting 32-bit applications requires additional libraries and components. With Windows Server 2025, users can now optionally add the necessary components for running 32-bit applications to the Nano Server container image as needed. This provides a more optimized approach compared to relying on the larger, monolithic Server Core image for all workloads, making Nano Server a viable option for a wider range of applications, including those with legacy dependencies.

Integration and Use Cases

The Features on Demand (FoD) capability in Windows Server 2025 Nano Server containers leverages the existing Windows FoD infrastructure. It utilizes tools like Deployment Image Servicing and Management (DISM) and PowerShell cmdlets to manage the installation and removal of optional features in Windows images. For containerized environments, these tools interact with the container runtime to seamlessly add necessary feature packages to the Nano Server base image.

In addition to enabling 32-bit application support, FoD also allows for the inclusion of specialized server roles or features that were previously unavailable in Nano Server. These include minimal IIS components for hosting web applications or specific networking functionalities.

Features on Demand for Nano Server Containers

Feature Name	Capability Name (Example)	Description	Use Case
32-bit Application Compatibility	Microsoft.NanoServer.Datacenter.WOWSupport	Enables running 32-bit applications.	Running legacy applications in a lightweight container.
Windows Management Instrumentation (WMI)	Microsoft.NanoServer.WinMgmt	Enables basic WMI functionality.	Obtain data through queries and enumerations.
Minimal IIS Components	Microsoft.NanoServer.IIS	Enables basic web server functionality.	Hosting lightweight web applications.

Getting Started with FoD Support in Nano Server

Ready to try Features on Demand with the Windows Server 2025 Nano Server image? Here’s how to get started:

Prepare the environment — Ensure that the Windows container host is properly configured and ready for building containers.
Create an installation script — Write a batch file containing the DISM commands to install the required FoDs. In this example, the script installs Microsoft.NanoServer.Datacenter.WOWSupport to enable WOW64 support. Save the file as install_wowsupport.cmd:

@echo off REM FoDs such as Microsoft.NanoServer.Datacenter.WOWSupport will trigger a request for reboot. REM For those FoDs, DISM will exit with 3010 which must be handled to prevent the batch from exiting with a non-zero status. REM Additionally we must supply the /NoRestart argument to suppress the reboot prompt. DISM /Online /Add-Capability /CapabilityName:Microsoft.NanoServer.Datacenter.WOWSupport /NoRestart if errorlevel 3010 ( echo The specified optional feature requested a reboot which was suppressed. exit /b 0 )

NOTE:

The FoD name used with the /CapabilityName parameter should match one of the available options which can be obtained using DISM from inside the Nano Server container.
Access to Windows Update is required for the Nano Server container to download and install the specified FoD.

3. Update the Dockerfile — The following Dockerfile example adds the batch script and installs the specified FoD during the container build process:

FROM mcr.microsoft.com/windows/nanoserver:ltsc2025 WORKDIR /install COPY install_wowsupport.cmd . RUN install_wowsupport.cmd # Download tools to be used for the sample workload RUN curl -L https://download.sysinternals.com/files/PSTools.zip > PSTools.zip RUN mkdir pstools RUN tar -xf PSTools.zip -C pstools

4. Build and tag the container image — Use the following command to build the container image and apply a custom tag:

docker build -t <newname:tag> .

5. Validate using a 32-bit sample workload — Create and run a new container from the updated image to verify that the configuration is correct. In this example, validation is done by running the 32-bit version of the Sysinternals PSInfo tool (downloaded in step 3) using the following command to observe Nano Server’s WOW64 support:

PsInfo.exe -accepteula

Closing

With the introduction of Features on Demand in Windows Server 2025 Nano Server containers, users now have the best of both worlds: a minimal footprint with the flexibility to add only the features needed for their specific workloads. This innovation marks a significant leap forward, delivering enhanced app compatibility, all while retaining Nano Server’s efficiency. And this is just the beginning—FoD unlocks exciting possibilities for the future of Windows containers.

As always, your feedback is invaluable in shaping the future of Windows Containers. We encourage you to share your experiences and insights through the Windows Container GitHub Community.

New survey - Windows Server application survey!

ViniciusApolinario — Tue, 21 Jan 2025 17:00:00 GMT

Happy new year everyone!

With the new year, it's time to make plans and goals for the new cycle. At Microsoft, we're always planning for what's ahead, what we want to accomplish, and how can we delight our customers. That planning and the resulting prioritization is based on what we hear from our customers. So, from time to time we publish surveys to get a broader sense of what customers are thinking, how our products can help them succeed, and make sure we align our goals.

Today, I'm here to ask for your input - we just released a new survey focused on understanding how customers approach Windows Server application modernization.

This survey is focused on understanding how customers approach modernization of Windows Server apps, what are the challenges, how they think about the modernization process, what spins up the process, etc. This is of immeasurable value to us and will help us prioritize the work for the coming years.

To answer the survey, please access: https://aka.ms/WSAppModSurvey.

Feel free to share the link above with anyone and thank you in advance for your support!

Public Preview of the Windows Server Annual Channel for Containers on Azure Kubernetes Service

riyapatel — Tue, 09 Jul 2024 18:37:29 GMT

Today, we are excited to announce the public preview for the Windows Server Annual Channel for Containers on Azure Kubernetes Service (AKS). The annual channel delivers a more agile and portable experience for our partners and customers in an accelerated annual cadence.

What's New:

Portability

As mentioned last year, a large component of the benefits that the first edition of the annual channel brings is portability. With the addition of a new stable application binary interface (ABI) for user and kernel interaction, the user and kernel components of the system are decoupled, allowing for the components to be updated and maintained separately. This allows for older container images to run on a newer host OS, dampening the need for updating infrastructure and container images before updating the host. This means Windows Server 2022 container images can be run on the Annual Channel for Containers host.

Faster Innovation

The annual channel will be a completely optional upgrade for our customers, but one that drives faster innovation and higher quality for our customers. By providing an annual update to the container host, customers can now get performance, security and reliability improvements on a yearly-cadence basis versus a three-year cadence basis. In addition, the Windows Server Annual Channel for Containers will receive the same servicing as the current three-year Windows Server releases. This will not only allow users to consistently be on the best performing version of our container hosts but also ease the load when it comes time to migrate to newer versions.

How to get started:

To upgrade your Windows Server 2022 clusters to the Windows Server Annual Channel for Containers, customers will need to create a new node pool with the new “Windows Annual Channel” OS SKU.

Supported on nodepools running Kubernetes 1.28 and above, this page walks through detailed instructions on how to upgrade existing Windows Server 2022 nodepools as well as create your first Windows Server Annual Channel for Containers nodepool.

Getting Started - Build a Basic Hello World Image with BuildKit and Windows Containers

lucillexiong — Mon, 25 Mar 2024 23:31:11 GMT

We’ve recently announced the release of experimental Windows Containers support in BuildKit v0.13.0. Developers can now benefit from improved performance and caching by building Windows Container images with BuildKit instead of docker build. This guide will follow the documentation where we will discuss the necessary prerequisites, setting up BuildKit, and how to build a basic Windows image with BuildKit. For feedback and issues, please file a ticket here tagged with area/windows.

The platform requirements are listed below. In our scenario, we will be running a nanoserver:ltsc2022 base image with amd64.

Architecture: amd64
Supported OS: Windows Server 2019, Windows Server 2022, Windows 11.
Base images: servercore:ltsc2019, servercore:ltsc2022, nanoserver:ltsc2022. See the compatibility map here.

Setup

1. Start up a PowerShell terminal in admin privilege mode. Run the following command to ensure the Containers feature is enabled. If you see RestartNeeded as True on your setup, restart your machine and reopen an Administrator PowerShell terminal. Otherwise, continue to the next step.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V, Containers -All

2. Run the following script to install the latest containerd release. If you have containerd already installed, skip the script below and run Start-Service containerd to start the containerd service. Note: containerd v1.7.7+ is required.

# If containerd previously installed run: Stop-Service containerd # Download and extract desired containerd Windows binaries $Version="1.7.14" # update to your preferred version curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz tar.exe xvf .\containerd-windows-amd64.tar.gz # Copy and configure Copy-Item -Path ".\bin" -Destination "$Env:ProgramFiles\containerd" -Recurse -Container:$false -Force cd $Env:ProgramFiles\containerd\ .\containerd.exe config default | Out-File config.toml -Encoding ascii # Copy Copy-Item -Path .\bin\* -Destination (New-Item -Type Directory $Env:ProgramFiles\containerd -Force) -Recurse -Force # add the binaries (containerd.exe, ctr.exe) in $env:Path $Path = [Environment]::GetEnvironmentVariable("PATH", "Machine") + [IO.Path]::PathSeparator + "$Env:ProgramFiles\containerd" [Environment]::SetEnvironmentVariable( "Path", $Path, "Machine") # reload path, so you don't have to open a new PS terminal later if needed $Env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User") # configure containerd.exe config default | Out-File $Env:ProgramFiles\containerd\config.toml -Encoding ascii # Review the configuration. Depending on setup you may want to adjust: # - the sandbox_image (Kubernetes pause image) # - cni bin_dir and conf_dir locations Get-Content $Env:ProgramFiles\containerd\config.toml # Register and start service containerd.exe --register-service Start-Service containerd

3. Run the following script to download and extract the latest BuildKit release.

$version = "v0.13.0" # specify the release version, v0.13+ $arch = "amd64" # arm64 binary available too curl.exe -LO https://github.com/moby/buildkit/releases/download/$version/buildkit-$version.windows-$arch.tar.gz # there could be another `.\bin` directory from containerd instructions # you can move those mv bin bin2 tar.exe xvf .\buildkit-$version.windows-$arch.tar.gz ## x bin/ ## x bin/buildctl.exe ## x bin/buildkitd.exe

4. Next, run the following commands to setup the BuildKit binaries.

# after the binaries are extracted in the bin directory # move them to an appropriate path in your $Env:PATH directories or: Copy-Item -Path ".\bin" -Destination "$Env:ProgramFiles\buildkit" -Recurse -Force # add `buildkitd.exe` and `buildctl.exe` binaries in the $Env:PATH $Path = [Environment]::GetEnvironmentVariable("PATH", "Machine") + ` [IO.Path]::PathSeparator + "$Env:ProgramFiles\buildkit" [Environment]::SetEnvironmentVariable( "Path", $Path, "Machine") $Env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + ` [System.Environment]::GetEnvironmentVariable("Path","User")

5. Run buildkit.exe. You should expect to see something as follows:

6. To test if your setup is good, open another admin PowerShell terminal and run a buildctl command such as the one below

buildctl debug info

Build Hello World Image

We will be building a simple hello world image as shown by the Dockerfile below.

1. Run the following commands to create a directory and change directory to sample_dockerfile.

mkdir sample_dockerfile cd sample_dockerfile

2. Run the script below to add the Dockerfile shown above and hello.txt to the sample_dockerfile directory.

Set-Content Dockerfile @" FROM mcr.microsoft.com/windows/nanoserver:ltsc2022 USER ContainerAdministrator COPY hello.txt C:/ RUN echo "Goodbye!" >> hello.txt CMD ["cmd", "/C", "type C:\\hello.txt"] "@ Set-Content hello.txt @" Hello from buildkit! This message shows that your installation appears to be working correctly. "@@

3. If you are utilizing Docker Hub as your registry, make sure to run docker login before running buildctl build.

4. Run buildctl build to build and push your image to your registry.

buildctl build ` --frontend=dockerfile.v0 ` --local context=. \ ` --local dockerfile=. ` --output type=image,name=docker.io/<your_username>/hello-buildkit,push=true

You should see an output like the one below after building and pushing your container image.

Congratulations! You can now create containers with the client (docker run, ctr run, nerdctl run) of your choice.

For more guides, please keep an eye out for additional documentation in the coming months.

Experimental Windows Containers Support for BuildKit Released in v0.13.0

lucillexiong — Mon, 25 Mar 2024 22:19:58 GMT

We are excited to announce that the latest BuildKit release v0.13.0 contains experimental Windows Containers support. BuildKit is a toolkit for converting source code to build artifacts (like container images) in an efficient, expressive, and repeatable manner. Since 2018, Windows Container customers have been asking for Windows support for BuildKit as seen in the BuildKit repo and Windows Containers repo with hundreds of reactions and comments. We have listened to our users and focused resources in the past year to lighting up Windows Containers support on BuildKit.

Previously, there was partial Windows support with buildctl.exe client, but we now have experimental Windows Containers support with buildkit.exe. BuildKit provides many benefits over the traditional Docker build engine including the following:

When possible, BuildKit automatically runs build steps in parallel and allows for parallel multistage builds causing performance improvements in speed.
BuildKit improves on the traditional Docker caching model by optimizing access to local files, tracking changes, and only copying modified files.
BuildKit utilizes commands similar to docker build allowing developers to easily transition over.

How to Get Started with BuildKit

We encourage users to test out the released experimental Windows BuildKit support v0.13.0. To start out, feel free to follow the documentation or companion blog which will walk you through building a simple Windows Containers image with BuildKit. Please file feedback and issues here tagged with area/windows.

Next Steps

In the upcoming months, we will be working towards a stable release for the current supported features including:

adding more integration tests
releasing more documentation and
identifying, accessing, and closing the feature parity gap between Windows and Linux

We recognize with the experimental release that features supported on Linux are not currently supported on Windows. We have identified some areas to explore and test as follows:

Image outputs: There are image outputs supported by Linux that may not work on Windows that need to be tested and assessed. These include exporting an image to multiple registries, checking if keys for image output are supported, and testing multi-platform image building support.
OCI worker support: On Linux, there is an option to run BuildKit with only runc using the OCI worker. Currently, only the containerd worker is supported for Windows.
Building other artifacts: BuildKit can be used to build artifacts beyond container images. Work needs to be done in this area to cross-check if other artifacts such as binaries, libraries, and documentation are also supported on Windows as they are on Linux.
Running buildkitd rootless: Currently, running buildkitd on Windows requires admin privileges. We will be looking into running buildkitd on low privileges aka “rootless”.
Export cache: Investigations need to be done to confirm if specific cache exporters (inline, registry, local, gha (GitHub Actions), 3, azblob) are supported on Windows as well.

We welcome your contributions and feedback in the areas identified above. Please feel free to open a PR or ticket at github.com/moby/buildkit. For the latest conversations on Windows Containers support on BuildKit, please visit the area/windows tag.

Thank You

A big thanks to @gabriel-samfira, @TBBle, @tonistiigi, @AkihiroSuda, @crazy-max, @jedevc, @thaJeztah, @profnandaa, @iankingori, and many other key community members who have contributed to enabling Windows Containers support on BuildKit. In addition, we would also like to thank Windows Container developers who continue to provide valuable feedback and insights.

Please visit the companion blog to build your first Windows Containers image with BuildKit and continue to support us at github.com/moby/buildkit.

Windows GPUs for AKS

NWhitehead — Mon, 18 Mar 2024 22:45:48 GMT

Today we are happy to announce the public preview of Windows on AKS GPU support! This feature aims to provide customers with the options of GPU compute-intensive workloads. A few examples of where a GPU supported node would benefit workloads are video encoding, machine learning, and large simulations. Through this release we hope to increase the parity between Windows and Linux on AKS.

What is it?

GPU support has been accomplished by enabling Windows node pools in AKS to support GPU workloads. This release will support all AKS Windows SKUs releases. As for the GPU support, there will be NVIDIA’s CUDA and GRID drivers. The current architecture installs a specific GPU Driver for each VM size.

Prerequisites/High level Call outs for Enabling GPU Support

Workload and driver compatibility are essential to deploying Windows nodes with GPU support. Please verify the workload is compatible with the driver installed to the VM Size.

VM Size	Driver Type
NC series	CUDA
NV, ND	GRID

Required For Setup

Kubernetes version 1.29.0 or greater is required for set up.
Updating an existing Windows node pool to GPU isn’t supported.
For AKS node pools, we recommend a minimum size of Standard_NC6s_v3.
The NVv4 series (based on AMD GPUs) aren't supported on AKS.

Optional Opt Out of Configuration

Customer can opt out of auto driver installation by using:

--skip-gpu-driver-install flag

In Closing

To get started you can follow a detailed guide to show step-by-step instructions here.

We would love to hear your feedback and suggestions on this new feature. Thank you for using Windows on AKS. We hope you enjoy using GPU supported nodes.

Announcing the 3-year retirement of Windows Server 2022 on Azure Kubernetes Service

riyapatel — Fri, 15 Mar 2024 18:22:06 GMT

Windows Server 2025 and the Windows Server Annual Channel, offer a comprehensive array of enhanced features, heightened security measures, and improved overall performance, and with image portability customers can now run Windows Server 2022 based containers on these new versions. To maximize the experience for customers, not only will Windows Server 2025/Annual Channel provide the most efficient versions of Windows Server yet, but also streamline the upgrade process. In pursuit of an enhanced user experience and an unwavering commitment to safety and reliability, we will be retiring Windows Server 2022 on Azure Kubernetes Service (AKS) in 3-years time.

What does this mean for me?

Windows Server 2022 will be retiring on AKS in March 2027. You should prepare to upgrade to a supported Windows Server version before March 2027.

How can I upgrade my Windows nodepools?

You can follow the Windows Server OS migration process outlined in the AKS documentation to upgrade to Windows Server 2025 or Annual Channel when they’re released on AKS. Portability is key feature available for Windows Server 2025/Annual Channel and onwards, the host and container image no longer need to be upgraded in tandem, older images can now work on newer hosts (ex. running Windows Server 2022 image on Windows Server 2025 host).

Kubernetes version 1.34 will be the final version where Windows Server 2022 is supported on AKS. When Kubernetes version 1.34 is at the end of life on AKS, Windows Server 2022 will no longer be supported. Upgrades to Kubernetes 1.35 on AKS will be blocked if there are any remaining Windows Server 2022 node pools in the cluster.

Windows Server 2025 on AKS and will offer numerous advantages and enhancements. At a high level, Windows Server 2025 introduces enhanced performance and reliability and improved networking support, including density improvements. Learn more about Windows Server 2025 from our recent announcements at Containers - Microsoft Community Hub.

Our commitment centers on customer satisfaction and success, guiding our efforts to provide ample resources and time for upgrading to our premier operating system. Our aim is to simplify the upgrade process, enabling customers to fully leverage the benefits of Windows Server 2025/Annual Channel.

Zero-trust Security for Windows Container-based application with Calico

NWhitehead — Thu, 29 Feb 2024 20:09:06 GMT

Hello, we would like to feature our partners from Tigera Calico that we teamed up with to co-author a blog on Zero-Trust security for Windows container-based applications with Calico. Below are the names of the partners that co-authored the blog.

Dhiraj Sehgal Jen Luther Thomas

Enterprises are increasingly integrating Windows containers into their Kubernetes workflow and much like Linux containers they are looking to strengthen their Windows container based application’s security posture by explicitly authorizing and verifying every communication request and minimizing trust assumptions. Zero-trust workload security restricts communication between pods and services at a very fine-grained level, resulting in multiple benefits that include:

Enhanced Security: Ensures each pod has limited and authorized communication access, preventing potential threats from spreading across the cluster.
Compliance: Achieves compliance requirements by enforcing strict access controls and data isolation.
Isolation of Sensitive Data: Isolates sensitive data from other less sensitive workloads to reduce the risk of unauthorized access.
Workload Communication Visibility: Provides better visibility into workload-workload communication and security gaps, including network security policies.

As the number of Windows container-based workloads and associated pods running in the cluster grows, building security posture requires zero-trust workload access security with the following:

Egress access controls: Secure access from individual pods running Linux or windows containerized workloads in a Kubernetes cluster to external resources, including cloud services, databases, and 3rd-party APIs.
DNS Policies: Enforce DNS policies at the source pod so that fully qualified domain names (FQDN/DNS) can be used to allow access from a pod or set of pods (via label selector) to external resources—eliminating the need for a firewall rule or equivalent.
Global and Namespaced Network Sets: Automatically update access controls for all IPs described by the CIDR notation using IP subnet/CIDR in security policies.
Identity-Aware Microsegmentation: Segment workloads using workload identities to achieve workload isolation and limit lateral communication.
Application-Layer Policy: Apply security controls at the application level to secure pod-to-pod traffic, including HTTP methods and URL paths. Eliminate the operational complexity of deploying an additional service mesh.

Let's go through an example to build zero-trust security for the demo application Online Boutique (previously known as Hipster Shop), an 11 microservice demo application, in a Azure Kubernetes Service environment and connected to Calico Cloud. After Online Boutique is deployed, the associated microservices, including RecommendationService and ProductCatalogService, as shown below, are monitored for breakdown, timeouts, and slow performance.

The deployment looks like this:

Figure: Online Boutique microservices architecture

Zero-trust workload access control for CartService:
We will explore two scenarios to secure CartService that carries products for the checkoutservice after product selection from the Redis database has happened. CartService is powered by an external third-party service. The service needs to be secure and have exclusive access from checkout to prevent tampering with the changes in the cart.

Scenario 1: Building the security policy for CartService
Whether or not the DevOps engineer understands the layout of their microservice architecture or the associated label schema for those workloads, once the application is introduced into the cluster, the team can make use of Calico Cloud’s ‘Recommend a policy’ feature to automatically highlight flows between workloads as seen below:

Policy recommendation will aggregate the metadata of those flows to understand their full context and suggest a policy that allow-lists traffic between cartservice and checkoutservice based explicitly on the port, protocol, and the label’s key-pair value match.

Users then assess the impact of the recommended policy using Preview and/or Stage to observe the effect on traffic without impacting actual traffic flows.

The preview option comes in handy as teams can collectively understand the impact from their respective roles, which can be developer, security, DevOps, or network engineer. DevOps engineer or Developer can enforce their policy after understanding its impact on network flow. Further, they can also download Kubernetes CR YAML and check into their git repo to apply it as part of their code deployment. Even if the environment is rebuilt, the policies being part of code are directly applied to the services.

Once the zero-trust security policy is enforced between trusted workloads of cartservice and checkoutservice, the user can also create a default-deny policy at the end of the namespace to deny unwanted lateral connections.

Scenario 2: How to implement a security policy (if a threat is detected and CartService is vulnerable)
If the CartService is vulnerable due to poor policy design, and an identified threat is able to probe that workload, DevOps can create a quarantine policy to log and deny those flows at the earliest possible stage of the policy tier board in Calico Cloud.

Implement identity-aware microsegmentation for Frontend and ShippingService
Frontend talks to ShippingService, but under organizational rules. Shippingservice is the service that stores all mailing information for all customers. The Frontend purpose is to provide customer login and interact with other services which changes with respect to newer product availability and existing product inventory. Both services have distinct security requirements as they are owned by different teams and contain different levels of confidential information. Let’s simplify it to the next figure, where frontend and backend are in different zones and have controlled communication among them.

Figure 1: Storefront microservices architecture

How to make sure that ‘frontend’ and ‘backend’ microsegmentation happen according to organizational requirements
In this scenario, DevOps can create a zone-based architecture via a security policy similar to traditional firewall solutions. The frontend workload is given a label match of `fw-zone=dmz` (Demilitarized Zone). Any workloads with the DMZ label match can receive ingress traffic from the public internet and can then relay those flows to workloads in a trusted zone (i.e. service-1)
The “trusted” zone is responsible for controlling flows between microservices within that zone, as well as securely allowing traffic to and from the DMZ and ‘restricted’ zones. Team can implement zero trust by only allowing traffic between these pods explicitly, based on label match, port, and protocol. That way, if a new workload is introduced into this namespace, it would need to match all three of the above contexts in order for the packet to be allowed.

Figure 2: Kubernetes insecure flat network design to rogue workloads

Finally, the team implements a “restricted” zone that ensures workloads handling sensitive data, such as databases or log event handlers, are only able to talk to workloads in a trusted zone. This applies to both ingress and egress traffic. Under no circumstance could a rogue workload in our cluster talk to this database, nor could the database interface against any third-party services/APIs. The only way it could talk to any external IP is via this secure zone-based architecture.

Conclusion

Windows on AKS can be extended with partner solutions, just like Linux by utilizing Calico's recommended policies, policy board, and tiering, teams can reduce the attack surface of deployed Windows-based containers in a namespace and implement microsegmentation to prevent lateral movement of threats across different workloads within a namespace to strengthen their application’s security posture.

Try it yourself here in self-paced workshop.

Windows containers in Kubernetes: Automating nodepool management with Calico’s Windows HPC Support

NWhitehead — Thu, 15 Feb 2024 21:52:45 GMT

Hello, we would like to feature our partners from Tigera Calico that we teamed up with to co-author a blog on Host Process Containers with Calico. Below are the names of the partners that co-authored the blog.

Dhiraj Sehgal Reza Ramezanpour

As the landscape of containerized applications evolves, enterprises are increasingly integrating Windows containers into their Kubernetes workflows. These days with the help of cloud services such as Microsoft Azure Kubernetes Service, anyone can build and operate a Kubernetes environment with ease. However, there are a lot of fine-tuning and automation that are involved in preparing your production-ready environment that are done in the background. For example, networking is a huge part of the cloud-native environment, and all aspects of your business in the cloud depend on it.

Project Calico is a networking and security solution for the bare metal and cloud that offers great flexibility for such environments. In this blog, we will focus on how the new release of Calico has leveraged a new a feature of Windows containers, Host Process Containers (HPC) to optimize footprint in your cloud environment. On top of that, we will look at how HPC support makes the life of DevOps administrators easier by offering more control over the host machine in a Windows environment.

The challenge of manual nodepool management

One of the biggest challenges of managing Kubernetes clusters in an unmanaged or on-premise deployment. In a cloud environment like AKS (Azure Kubernetes Service), the cloud provider takes care of many aspects of managing your Kubernetes cluster, making it a seamless and hassle-free experience. However, when it comes to a customized environment where you have control over the node pools, the responsibility of managing and configuring the cluster falls on your shoulders. This can be a bit daunting, especially if you are new to Kubernetes or have limited experience with infrastructure management.

Managing Windows nodepools in such environments can be more challenging than Linux where privileged containers can configure host settings and integrate naturally with Kubernetes, Windows containers previously lacked this capability requiring administrators to use scripts or manual configuration steps outside of Kubernetes. This can be time-consuming and error-prone, especially when scaling your cluster quickly. Additionally, manual nodepool management can be disruptive to application lifecycles.

HPC is similar to a privileged container in Linux, just like privileged containers, HPC containers have the capability to access and make modifications to the host operating system. Silos are similar to namespaces in Linux which allow processes to run in an isolated environment. The following blog post highlights how Windows HPC is used for Calico and what are the benefits of it.

Calico's Windows Host Process Containers

Calico's Windows HPC support released in Calico OS 3.27 automates CNI installation and brings the Calico capabilities to Windows nodepools. This means that Kubernetes administrators can easily install Calico on their environment without having to manually install and configure Calico on each node, similar to Linux-based containers.

Calico's support for Windows HPC feature works by running Calico as a HPC on each node. HPC are a special type of container that has access to the host's filesystem. This allows Calico to install and configure itself on each node without requiring manual intervention from the Kubernetes administrator.

Benefits of automating nodepool management

Automating node pool management with Calico’s support for Windows HPC feature provides a number of benefits for Kubernetes administrators, including:

Reduced operational overhead: Automating nodepool management eliminates the need for Kubernetes administrators to manually install and configure Calico on each node. This frees up their time to focus on other tasks, such as managing Windows container-based applications.
Improved application performance and reliability: By automating node pool management, Kubernetes administrators can reduce the risk of disruptions to application lifecycles. This is because Calico can be installed and configured on new nodes without requiring any downtime for existing applications.
Increased agility and responsiveness to changing business needs: Automating node pool management makes it easier for Kubernetes administrators to scale their clusters up or down as needed. This can help businesses to respond more quickly to changing customer demand and other business needs.
Consistency between Windows and Linux GitOps practices.

How to enable Calico using Windows Host Process container support

For this part, we are going to assume that you have a hybrid Kubernetes cluster in your environment that supports HPC.

HPC support is provided with Kubernetes 1.22 and above, it also requires containerd 1.6+. If you would like to know more about these requirements, click here.

When your cluster is up and running, install the latest Tigera operator:

Use the following installation resource to install Calico for your Windows environment using the HPC feature:

kubectl create -f -<<EOF apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: calicoNetwork: windowsDataplane: HNS ipPools: - blockSize: 26 cidr: 192.168.0.0/16 encapsulation: VXLAN natOutgoing: Enabled nodeSelector: all() --- apiVersion: operator.tigera.io/v1 kind: APIServer metadata: name: default spec: {} EOF

In environments where Calico is used for IP Address Management, you need to disable IPaddress sharing by using the following command:

kubectl patch ipamconfigurations default --type merge --patch='{"spec": {"strictAffinity": true}}'

Conclusion

To sum up, Windows nodes in non-cloud-provider environment used to be hard to install and configure because they did not have privileged containers. However, with HPC now generally available on Kubernetes, users can create containers that can automate the configuration of their node via accessing the host filesystem.

Calico has leveraged this technology to provide a Kubernetes-native way to install and manage networking in your cluster. This means that the management of Windows nodes in a Kubernetes cluster is now fully automated, eliminating the need for administrators to manually configure nodes or containers.

Overall, the adoption of HPC in Kubernetes has transformed the way CNI solutions are installed and managed on Windows nodes, providing a more streamlined and automated approach that enhances the scalability, reliability, and ease of use of Kubernetes clusters.

Please look out for a coming blog covering Zero Trust with Tigera Calico.

Migration and Modernization solutions for Windows-based applications to Azure Kubernetes Services

Fady_Azmy — Tue, 06 Feb 2024 15:20:36 GMT

We’re excited to announce the launch of the Migration and Modernization Solutions page for Windows containers in Azure docs.

Azure Migrate, CAST and UnifyCloud are trusted solutions customers use to help with assessing, migrating and modernizing their applications to Windows containers.

We’ve partnered with each product team to showcase how to modernize the representative legacy eShop applications to Windows containers. The eShop demo provides three sample hypothetical legacy eShop web apps (traditional ASP.NET WebForms and MVC in .NET Framework and an N-Tier app based on a WCF service and a client WinForms desktop app).

We believe these hands-on examples will help you understand the available solutions available for you and make the best-informed decision to assist with your modernization initiatives.

If you are an interested partner or have any feedback about the Migration and Modernization Solutions page for Windows Containers, please let us know in the comments below.

Azure Migrate - Modernizing your .NET apps to Windows containers on Azure Kubernetes Services

anraghun — Wed, 31 Jan 2024 14:36:04 GMT

In this blog, we’ll go over how you can modernize a legacy ASP.NET web app using Azure Migrate and run in on Windows containers on Azure Kubernetes Service. You’ll walk away with an understanding of how to:

Discover your ASP.NET web apps running on-premises
Generate a Business case detailing the TCO comparison of running your apps on-premises vs on Azure and cost savings
Assess the cloud readiness of your apps and generate a migration path
Containerize and re-platform your apps without code changes to AKS

We’ll cover each topic in depth below with technical details, providing you with a step-by-step guide for modernizing your web app.

Azure Migrate Overview

Azure Migrate is the one-stop tool for your migration and modernization journey to Azure. It tackles each phase of the migration journey for infrastructure and workloads – Discovery and inventory, TCO comparison and savings, assessments and migration path recommendations and migration or modernization.

Azure Migrate supports multiple workloads – servers, SQL databases, ASP.NET, Java Tomcat and Spring boot apps. It also provides integration with several ISV offerings.

Azure Migrates provides an end-to-end migration experience for ASP.NET web apps to Windows container targets such as AKS and App Service for containers, doing the heavy lifting for complex tasks at-scale and reducing the amount of manual intervention needed from customers.

Modernize a legacy .NET web forms app to Windows on Azure Kubernetes Service

Background

In this blog, we’ll work with a legacy ASP.NET web forms app called eShop running on a VMware server.

eShop is an internal back office app that employees use to maintain their product catalog. They can add products, edit and delete them.

eShop uses a SQL database to store this data, more details on the architecture as well as the source code can be found here.

Prerequisites

Before starting discovery, you’ll need to create an Azure Migrate project. Follow this quick start guide.

Discover eShop on Azure Migrate

Let’s start by discovering our app on Azure Migrate. To do so, we’ll need to deploy the migrate discovery and assessment appliance for VMware. The appliance can be deployed either using an OVA template or a PowerShell script.

Follow this guide to deploy the appliance with an OVA template. If you wish to instead use the PowerShell script, ignore this section and refer to this article.

Once deployed, the appliance needs to be configured using the appliance configuration manager which is automatically deployed along with the appliance. Appliance configuration involves providing both the hypervisor and guest VM credentials which allows the appliance to discover web apps, SQL servers and other workloads running on servers.

Discovery time depends on many factors such as number of servers, workloads and network bandwidth. Workloads such as web apps and SQL servers may take up to 24 hours to get discovered and reflect on the portal, although it should more likely happen much sooner.

Once discovered, you should be able to see the server and web app on Azure Migrate:

Open Azure Migrate on the Azure portal and select Servers, databases and web apps. You should start seeing the discovered inventory here. Select Servers running web apps.
You should see a list of servers. Click on the Web apps hyperlink for the server containing eShop. This drill down shows the set of web apps running on that server. We can see eShop has been discovered with additional details such as URLs, protocols, connection strings and app directories.

Next, let’s generate a business case.

TCO comparison and Savings

Azure Migrate allows you to generate a business case detailing TCO comparisons, cashflow projections and associated savings. Today, business cases can only be generated at the project level and will surface these insights across all the workloads discovered in that project. It’s essentially a datacenter level operation.

You can generate a business case very easily by following this. Once generated, you’ll see the recommended target for your web apps in the Azure PaaS report. Business case intelligently picks an Azure target based on your migration strategy. It also bubbles up the recommended SKUs for your apps which are also surfaced in Azure Migrate assessments in more detail.

This report has estimated the cost savings by moving your on-prem workloads, including eShop, to Azure Paas. Business case shortens time for business decision makers significantly to give a go/no-go to migrations. Once committed, the buck is passed to the IT admins and cloud architects to come up with a migration plan.

Let’s generate an assessment to make this easier.

Assessing eShop for Azure Kubernetes Service

Azure Migrate allows you to create an assessment for .NET web apps for various targets – Azure App Service code & containers, AKS. An assessment generates the following insights:

The cloud readiness for the assessed apps for each target
Target configuration such as SKU details, mapping apps to target instances (for example, mapping apps to the recommended node pools for AKS)
Associated cost of running these apps on Azure month over month.

Follow this guide to assess ASP.NET web apps for AKS migration. Azure Migrate allows you to configure assessment details such as preferred SKUs (storage optimized, isolation, GPU...), select savings options (reserved instances, Azure savings plan), custom discounts and accordingly provides recommendations and costs.

Here’s the assessment created for eShop.

Let’s unpack this:

We can see the assessed entities are eShop and another web app deployed on the same web server.
We can see that both these apps are ready to migrate, meaning there are no migration warnings or errors.
The monthly cost estimate to run these apps on Azure is ~$228, which includes the cost of AKS standard tier pricing.

You can view the report details by clicking the link below Overview on the left column.

Both the apps are Ready and the report surfaces the recommended node SKU, a 2 core 8 gig Dpds_v5 series. A web app can be Ready with conditions or Not ready. In such cases, the assessment provides migration warnings, errors and remediation steps.

Navigating to the Cost details tab, you see the cost breakdown across the various node pools.

In this case, there are 2 pools recommended, a system node pool and a user node pool to host eShop. With the assessment complete, we can now look at migrating eShop to AKS.

Migrating eShop to Azure Kubernetes Service

Azure Migrate allows containerizing and migrating web apps at scale to AKS. You can follow a step-by-step wizard to provide configurations using which the platform generates key artifacts such as Dockerfiles and Kubernetes manifests, thereby reducing significant time in containerizing your apps. Let’s look at how this happens:

Open Azure Migrate on the Azure portal and select Servers, databases and web apps. In the migration and modernization tool, select Replicate.
On the Specify Intent screen, select ASP.NET web apps, Azure Kubernetes Service (AKS), VMware vSphere as your workload, target and virtualization type respectively. Then select your appliance.
Now, search and select the apps you want to migrate. You can also parameterize and configure connection strings and app directories. Refer to this for more details.
After selecting your apps, select the desired container registry to save the docker files and the AKS cluster to which you want to deploy the apps to.
In the deployment settings, you can specify the image details, ports, replicas and service type for your apps. This information will be used to bootstrap the Dockerfile and Kubernetes manifests. We’re going to leave it to the defaults.
In the advanced settings, you can choose to store your app configurations either as a native Kubernetes secret or on Azure Keyvault. You can also copy app directories to Azure file share. Refer to this for more details.
Review your configurations and start replication.

Azure Migrate will create a replication job for each app selected for migration. The app binaries are copied onto a temporary storage account. The replication job allows you to:

View and edit the Dockerfile and Kubernetes manifests. The dockerfile uses the .NET framework 4.8 on windows server core as the base image. It also downloads the IIS web deploy tool. During the image build the ApplicationArtifacts_Placeholder is replaced with a SAS URI to the storage account containing the replicated binaries. The Entryscript simply unzips the copied binaries and uses web deploy to spin up the site.
Build your container image. The image is then stored in the selected ACR.
Do a test migration. This will deploy the app onto the AKS cluster. You can ensure that it spins up correctly. You can also use the Clean up test migration option to remove the deployed workloads. Typically, you can create the replication job with a test cluster, do a test migration and then change the target settings to point to your production cluster.
Once you’ve tested that the app is working fine, you can select the Migrate option to deploy it onto your production cluster.
The Azure Migrate service authenticates itself to you AKS clusters using its first party managed identity.

After migration, you can visit the AKS cluster on the Azure portal, select Services and ingresses, search and view the service that just got created for your app. Click on the assigned external IP to view your app!

Refer to the official documentation for more granular details around replication job creation and migration.

Conclusion

In this blog, you learnt:

How to discover your ASP.NET web apps hosted on-prem on a VMware server. The appliance allows you to discover your apps at-scale.
Project savings and compare the total cost of ownership from migrating your apps to AKS. An automated business case makes it easier for your business decision maker to confidently commit to Azure.
Create cloud readiness assessment and understand migration blockers as well as the recommended AKS configuration to run your apps.
Finally, containerize and migrate your apps to AKS. Auto-generation of key artifacts such as Dockerfile and Kubernetes manifests allow you to significantly cut down on your migration effort and time.

For more scenarios such as discovery on other stacks such as Hyper-V or bare metal, assessments and migration to App Service and what’s new, checkout our official documentation.

CAST - Modernizing your .NET apps to Windows containers on Azure Kubernetes Services

Fady_Azmy — Tue, 06 Feb 2024 14:23:26 GMT

This blog post has been co-authored by Microsoft and Damien Santé and Emmanuelle Castaings at CAST.

Windows Containers have reached a great level of maturity, allowing customers to run production grade workloads with limited code refactoring. Though, specific compatibility checks are highly recommended for .NET applications, for example, to avoid discovering blockers hidden in source code during the migration, triggering unplanned fixes in urgency, additional time and costs.

To ensure an effective migration, a rapid portfolio analysis using CAST Highlight can be performed. It will automatically provide insights from custom source code, including the list of containerization blockers and indicative effort estimates to remediate. CAST Highlight will also automatically show a path to modernization post containerization leveraging Azure PaaS services. CAST Highlight is an automated solution where hundreds of custom applications can be analyzed within a few days, with no source code disclosed and no intrusion on production systems.

Since 2019, CAST has been working alongside Microsoft to automate the migration and modernization of custom applications for hundreds of clients worldwide, addressing a large variety of old and new languages such as C#, C++, VB.NET, Java, JavaScript, Python, Cobol and more, and various application types among Windows, mainframes, monoliths, databases and others.

This blog will cover the following sections:

CAST Highlight overview
How to use CAST for Windows container apps on AKS
Common containerization blockers, and CAST recommendations
Optimize further and prepare the modernization, using CAST
Illustrative case study on eShop applications & Customer Case Studies

CAST Highlight Overview

CAST Highlight provides a rapid analysis of the entire portfolio of custom applications, bringing data and facts to your modernization journey. CAST Highlight analysis is a rapid 3-steps process scanning hundreds of applications in a week.

CAST Highlight acts as a Control Tower for the tens or hundreds of applications in your portfolio helping you make informed decisions on governance, open-source risk control, greener software, and cloud modernization:

Cloud Maturity: 5Rs segmentation, roadmap to PaaS, containerization and cloud blockers, removal effort estimates
Software Health: resiliency, agility, complexity, technical debt
Open-source risks: security vulnerabilities, obsolescence, legal IP risks
Green Software: code deficiencies, recommendations with respect to industry good practices

CAST + Windows on Azure Kubernetes Service

Get actionable recommendations on containerization blockers

CAST Highlight shines a light on specific Cloud patterns that are blockers for containerization of applications, a subset of our 400+ existing patterns. Those patterns are agnostic to the target container, for instance, if an application is using DLLs, as part of the containerization tasks, the container definition (.dockerfile) should copy these required libraries and execute their registration if needed.

Nota Bene: CAST Highlight will not generate the Dockerfile but recommend the best options to be utilized. See here more details on how to optimize the Dockerfile configuration.

CAST Highlight lists in a dedicated tab all the containerization blockers and related details:

Documentation pop-up for each blocker with rationale, level of criticality, impact on containerization tasks
Technology/language triggering the blocker and number of occurrences in the code (roadblocks)
Estimated remediation effort based on customizable abacus.
At the portfolio level: list of applications where the blocker was found and at application level: list of files where the blocker occurred.

Common containerization blockers, and CAST recommendations

CAST Highlight provides the rationale for each containerization blocker categorized in three types of impact:

Blockers impacting the container only.
Blockers impacting the application code.
Blockers impacting the application architecture.

Blockers impacting the container only.
Registry Settings - Using Windows registry to store Application Settings

The problem: Legacy applications often use Windows registry to store application settings. The good practice consists of avoiding OS-specific storage such as Windows Registry, as in the container the operating system is not guaranteed to be the same.

The solution: CAST Highlight lists all your code files declaring registry dependencies so you can create a .reg file containing all the entries required by the application then edit the Dockerfile to copy it inside the container on creation and add the registry entries.

CAST Highlight detects other blockers that impact the container configuration such as usage of a temporary local file or directory, applications using other configuration files than web configuration, applications using system DLLs or COM Components, etc.

The figure below illustrates the description of the blocker in CAST Highlight with criticality, impact, rationale and references.

Blockers impacting the application code.

Temporary Files - Access to environment variable

The problem: applications accessing environment variables. This blocker impacts the application code, architecture, and the target container.

The solution: CAST Highlight provides the list of files for which an environment variable needs to be set up, so you can ensure it will exist in your container. It also gives the effort estimate to remediate the issue in the code. There are two ways this information can be passed down to the container. You can use the -e option in the run command of your docker container. It is adequate when the number of variables is low. However, as soon as we have more than a handful of variables, it can quickly become cumbersome and error prone. Another option is preferred where you can specify the file where to read values from, called an env_file.

CAST Highlight detects other blockers requiring changes in the application code such as stateful sessions, hardcoded credentials, network IP address (IPV4, IPV6) or unsecure network protocols (HTTP, FTP).

Blockers impacting the application architecture

Security & User Authentication- Using Webform Authentication

The problem: Applications using Webform Authentication which requires that user accounts and passwords be created and managed in a storage such as a database. This mechanism does not offer the flexibility of claims-based authentication and should not be used in Cloud applications. This is blocker which impacts the application architecture and code.

The solution: Use the CAST Highlight output listing all your code files declaring Webform Authentication dependencies. Review the dependencies in each file. Refactor the app to be AD-integrated and leverage Active Directory domain identities to support your authentication scenario. To achieve this, you can configure a Windows container to run with a group Managed Service Account (gMSA), which is a special type of service account introduced in Windows Server 2012 designed to allow multiple computers to share an identity without needing to know its password.

CAST Highlight also detects code performing file or directory manipulation, which creates files or folders on the local file system (C: or 😧 drives), or applications using a middleware application such as asynchronous messaging middleware.

Illustrative case study on eShop applications

This section describes the analysis performed on eShop applications, focusing on a legacy version of the code base (eShopLegacy) and a version that has been modernized (eShopModernized). We then review the results of analysis as it relates to containerization and identify key findings and recommendations.

Repository overview

The eShopModernizing repository contains 6 applications with a total of 91 000 lines of code in mainly C#, ASP.Net and JavaScript languages:

The first group is composed of 3 applications called “eShopLegacy*” containing the code before the containerization.

eShopLegacyMVC is a traditional Web app ASP.NET WebForms and MVC in .NET Framework.
eShopLegacyNTier is an N-Tier app based on a WCF service.
eShopLegacyWebforms is a client WinForms desktop app.

The second group is composed of the modernized version of the above 3 applications after containerization to Windows Containers and Azure Cloud.

Containerization insights

In total, the 6 eShop applications show 5 containerization blockers.

Three blockers impact the container configuration:

Access to environment variable 6 occurrences found in Ruby files.
Using other configuration files than Web configuration 6 occurrences in C# code.
Using connection strings for database connection: 4 occurrences in C# code of eShopModernized* apps.

Two blockers impact the applications architecture found in C# code:

Using file system: 3 occurrences found
Perform File Manipulation: 15 occurrences found.

The figure below illustrates the containerization insights collected by CAST Highlight: in which application, with estimated effort to remediate them, number of occurrences found for each blocker (roadblocks), technology involved and impact (Container only, Architecture, Code).

Remediating those blockers would take roughly:

0.36 person-day effort on the eShopLegacy* applications
0.52 person-day effort on the eShopModernized* applications

The estimated remediation effort only concerns the changes in the code, it must be added to surrounding tasks such as regression testing, project management, etc.

Why addressing the blockers in the code prior to containerization

In summary, we would spend less effort to fix the blockers before migrating the eShopLegacy* applications, compared to the effort spent on remediating the same applications after containerization.

For the eShopCase, the analysis of both versions of the codebase indicates that the best approach would have been to first address the blockers found in the legacy version prior to containerization. This approach required less effort than addressing the blockers after containerization. In fact, additional files were created in the modernized version to accommodate the new platform which added new issues and blockers.

Sample blockers details: “Using direct Database Access through Connection Strings”

Database connection strings are very sensitive data in a Cloud application as they protect access to data storage or other application services. As a result, connection strings must be protected to prevent data theft. It is recommended to store this kind of sensitive data in a secured cloud-based storage such (e.g. Azure Key Vault). This blocker impacts the container configuration, a documentation and references with the patterns detected in the code are available for each of the blockers in CAST Highlight:

This blocker has been found in 2 eShopModernized* applications: eShopModernizedMVCSolution eShopModernizedWebFormsSolution. This blocker was not detected in any Legacy application.

CAST Highlight detects 15 other blockers for containerization, find them all here: doc.casthighlight.com/cloudreadypatterns/ (refer to the ‘Containerization’ column).

Third-Party compliance

Third-party frameworks may not all be supported since Microsoft doesn't specifically certify or support the use of non-Microsoft frameworks on Windows Containers. For each framework, you need to check that the vendor or application supports the policy for Windows containers, a frequent example being dependencies to Crystal Reports.

CAST Highlight makes an inventory of all third-party and open-sources components used by the application, either from dependencies declared in configuration files or directly in the code, or through physical libraries (JARs, DLLs) allowing you in one click to visualize all components used in your application portfolio. CAST Highlight also detects Common Vulnerabilities and Exposures (CVEs), obsolescence and licenses embedded in the 3rd-Party and Open-Sources Software components and generates a Software Bill of Materials.

On eShop applications, a few 3rd-Party frameworks such as ANTLR, autofac, log4net, owin or Pipelines.Sockets may require to use a docker image, a pre-installed SDK or publish a self-contained app including all the dependencies. Additionally, 8 high level CVEs were detected which may require an update to ensure maximum security on the container.

The figure below illustrates the CAST Highlight Software Composition insights including the Bill of Materials.

Modernizing further

Identify “noisy neighbors.”

An additional value of CAST Highlight are insights on the portfolio Health indicating how your applications comply with programming good practices that impact resiliency, agility, complexity or technical debt.

Insights from CAST Highlight can help act proactively to avoid potential “noisy neighbors” in a large application portfolio for which you may not have a precise knowledge of each application.

Applications showing a very low resiliency score in CAST Highlight would need special attention. For example, they may cause memory overflow, which, when containerized, will impact the computing resources consumption on the node. Neighboring containers will suffer unless resource management is enabled thanks to Azure Kubernetes Services through the Set Limits and Set Namespace Quotas directives. Eventually, the orchestrator would terminate the container or the pod, rather than firing another one, resulting into irrelevant additional costs and resources!

The figure below illustrates the application Resiliency by application in CAST Highlight, each application is represented by a bubble.

Modernize towards PaaS.

Once eShop applications are containerized on Windows AKS, it does not mean they are ready for PaaS.

CAST Highlight Portfolio Advisor for Cloud indicates that opportunities for modernization could be considered on eShop applications for an estimated effort of less than 2 person-days, allowing to benefit from Azure Cloud Services such as Azure Storage or Azure Batch. Parallelly, other services could be leveraged immediately such as Azure Monitor.

On eShop Applications, CAST Highlight detected 2 PaaS blockers. Firstly, hardcoded URLs using the HTTP protocol (HTTP/HTTPS) which would need to be replaced by the new resource's URL during the refactoring. Secondly, use of Log4Net for application logs management which should be replaced by Azure Application Insights.

See live here in more details how CAST Highlight helps on the Migration to PaaS journey.

Transform the Architecture Design.

Going further in modernization, eShop applications could be ported to a more modern design on .NET 6 and the legacy UI components such as ASP.NET/MVC could be refactored to Blazor. CAST Imaging helps accelerate such modernization initiatives by providing architecture blueprints of applications and automatically creating a comprehensive knowledge repository.

Application teams are enabled to rapidly discover the as-is architecture design in detail and prepare the transformation project whether refactoring to PaaS, implementing technical improvements, or engaging in a deep re-architecture. See CAST Imaging live here.

Customer Case Studies

Below selected customer cases leveraging CAST for containerization:

Auto tech firm assesses cloud readiness of apps 5x faster with CAST Highlight : The client compared the time it took to manually assess a few well understood apps with CAST Highlight’s automated approach; the latter was five times faster with the same accuracy. CAST Highlight analyzed all 134 apps in under two days and produced insights including the cloud readiness of each app, specific blockers that needed to be remediated within the code par app, per move group, per business unit. CAST Highlight results were crucial for the many apps that did not have dedicated teams. Within five weeks, the client containerized 40 of their apps and developed a plan to complete the process for the rest of the portfolio with recommendations on cloud services that each app could adopt once migrated.
Head of Engineering at Major Asian e-commerce company engaged in containerizing ~300 applications (core and web/micro-services) declared that CAST helped reduce the dependencies identification in code to 3-4 weeks instead of 3-4 months and to 1.5-2 months to execute the migration instead of 3-4 months. CAST helped accelerate the onboarding i.e. shifting-left Annual Recurring Revenue.
Global media firm cuts cloud migration planning time in half with CAST Highlight : Thanks to well-understood apps, average app assessment time was cut in half when using the CAST Highlight's automation versus manual code reviews. They progressed to less familiar apps and the time savings become even more significant: up to 5 times faster with CAST. It also identified nearly 50% of the applications that were good refactoring candidates for PaaS, enabling adoption of a cloud-native approach sooner than expected, even further reducing cloud consumption costs. Ultimately, the architect team was able to focus their efforts on high-value infrastructure and integration initiatives instead of manual code and framework reviews.

Conclusion

Migrating .NET applications on Windows Containers with Azure Kubernetes Service provides significant value but demands preliminary checks, especially for custom applications. CAST products help throughout the journey to Azure, from planning the containerization to the succeeding modernization once on Azure. CAST Highlight provides actionable insights at application and at portfolio level, 2 to 4 times faster than a manual approach, including blockers to be remediated. CAST Highlight acts as a control tower for the portfolio. CAST Imaging offers deep insights into application code, allowing you to confidently execute the modernization acting as a knowledge base of your software.

With CAST and Microsoft Azure as partners on the cloud journey, IT Leaders have the right solutions and expertise to retrieve knowledge of their custom applications, unblock the typical “discovery paralysis” in cloud migrations, then reach the full potential of their applications on Azure with less U-turns, higher responsiveness to business requests and better team efficiency while executing the transformation.

Next steps

For more details on CAST for cloud migration & modernization, please visit https://learn.castsoftware.com/faster-modernization-and-cloud-migration and https://www.castsoftware.com/highlight on CAST Highlight specifically.

If you wish to have your application(s) analyzed on CAST Highlight or CAST Imaging for migration to Azure, you may be eligible to Microsoft-funded CAST analysis through the Microsoft Solution Assessment program. Please contact your Microsoft representative or reach out to CAST on microsoft.contact-me@castsoftware.com.

Alternatively, you can purchase a CAST Highlight SaaS subscription on the Azure Marketplace to run the analysis by your own.

For any questions, please contact microsoft.contact-me@castsoftware.com.

UnifyCloud - Modernizing your .NET apps to Windows containers on Azure Kubernetes Services

Fady_Azmy — Tue, 06 Feb 2024 14:24:39 GMT

This blog post has been co-authored by Microsoft and Mark Erhart and Marc Pinotti from UnifyCloud.

CLOUDATLAS OVERVIEW

UnifyCloud’s CloudAtlas is an end-to-end Azure migration platform that automates and accelerates the assessment, remediation, and migration of applications and associated databases to Azure Kubernetes Services. Using CloudAtlas you can quickly assess your entire application portfolio for migration to Azure and perform automated remediation of most of the required code changes for faster migration to Azure.

Those who are familiar with CloudAtlas may know the application and database modernization functionality as CloudPilot. While the functionality is the same, we now refer to CloudPilot as CloudAtlas Transform and Migrate so that we can focus on all that the CloudAtlas platform can deliver for users.

UnifyCloud has been recognized by Microsoft as a Partner of the Year honoree for four consecutive years for its CloudAtlas platform. CloudAtlas has been utilized in over 3,500 global customer engagements, including over 200 of the Global 500, to assess the largest and most complex application portfolios for modernization and migration to Azure Kubernetes Services using Windows containers.

In this blog we will cover:

Why CloudAtlas?
How to Quickly Modernize to Windows containers on Azure Kubernetes Service with CloudAtlas
- Creating a Project
- Scan the Application Using CloudAtlas
- Evaluating Migration Options
- Application Remediation
- Generating Landing Zones for Seamless Migration
Migration learnings and insights from analyzing more than 4,000 applications
Frequently Asked Questions
Conclusion

WHY CLOUDATLAS

In the past, a major deterrent to digital transformation was the extensive manual effort it required. Considering it takes an average developer 3 days to manually assess 10,000 lines of code to identify required changes¹, manual analysis of even the simplest application portfolios can be time- and cost-prohibitive.

CloudAtlas leverages AI and Machine Learning to automate cloud migration processes, including the assessment of infrastructure, scanning application source code and databases, automating remediation, and automatically generating landing zones.

An example of this automation is CloudAtlas’ static code analysis that scans portfolios of apps, databases, and workloads with millions of lines of code in just minutes – a fraction of the time a manual assessment would require. For example, one portfolio of 574 million lines of code analyzed by CloudAtlas would have required several lifetimes of manual effort for even a quick scan, let alone an assessment that delivered the detail, analytics, insights, and recommendations that CloudAtlas delivered. CloudAtlas delivered this entire analysis in 199 hours.

This analysis provides detailed insights and recommendations to develop a modernization and migration plan with output that includes:

Cloud readiness
Migration options including IaaS, Containers/AKS, and PaaS as part of a 6R analysis that includes details to rehost, refactor, rearchitect, rebuild, and more
Tasks required
Hours of effort
Line of code guidance and on changes required for applications and databases to run effectively in the cloud
Customizable cost estimates.

It does all of this without the source code ever leaving the customer environment and presents the results in a simple to use dashboard, with drilldowns for each component that include the recommendation, reasoning, cost, and alternative approaches.

HOW TO QUICKLY MODERNIZE TO AZURE KUBERNETES SERVICE WITH CLOUDATLAS

CREATE A PROJECT

The process starts by downloading the CloudAtlas Modernize and Migrate tool and creating a project. In this example, we will be walking through a project using the sample eShopModernizing (eShop) app that has hypothetical legacy back office eShop web apps (traditional ASP.NET Web Forms and MVC) created by the .NET team. As noted, with CloudAtlas your source code never leaves your environment or source code repository.

Log into CloudAtlas, and download the CloudAtlas scanning app. Once the scanner is downloaded, start it and create a new project. The CloudAtlas scanner can assess single applications or a portfolio of applications and databases, minimizing processing and saving time in conducting application assessments.

Once your project is created you will need to add your application. In this example, we add the eShop app and indicate the platform, application type and source code location to prepare the application for scanning.

SCAN THE APPLICATION USING CLOUDATLAS

Once the app is added, you will see it in your inventory within the tool. At this point, the app code can be scanned, and metadata collected for analysis by CloudAtlas. Just select the eShop application and click “Scan” to start the analysis.

CloudAtlas can scan millions of lines of code in just minutes, eliminating the need for resource- and time-intensive manual effort. As an example, CloudAtlas has scanned a portfolio of 24 applications and 65 databases comprised of 6.7 million lines of code in just over 2 hours. A thorough manual assessment of this level would have required over 2,000 developer days – more than 5 years – of effort. That level of effort would cost more than $2M in time and resources. Even better, CloudAtlas scans applications and databases at a level of detail and accuracy that is much greater than any manual scan would achieve.

A simple app like this eShop demo app is quickly scanned in just over one minute. In practice, CloudAtlas can scan multiple applications at once.

Once scanned, the metadata for the source code can be viewed and edited prior to uploading to the CloudAtlas SaaS platform to ensure that sensitive or secure elements of the code do not leave your environment or source code repository. This can be achieved because the lightweight CloudAtlas scanner is not connected to the internet and can be run on a Windows PC or VM in your environment. The scanner produces metadata which is stored in an XML file. The XML file is can be reviewed to confirm that no IP, source code, sensitive information, or any other secure data is in the metadata in the XML file. If necessary, sensitive or proprietary information can be masked or deleted.

Once the XML file is reviewed and ready for analysis, it can be uploaded to the CloudAtlas SaaS platform for analysis.

Once uploaded, the eShop app (or any other apps or databases that have been uploaded) will appear in your project portfolio, where you can take further action, including initiating a full CloudAtlas analysis. This is done with the click of the “Analyze” button.

As part of the analysis process, a few pieces of information need to be collected to guide the assessment. This includes a short survey about the app or portfolio to provide additional information that is not available in the source code, including items like global load balancing, presence of PII, and criticality of the application to business operations. If you are unsure of the answers to the questions, selecting “No” provides the most comprehensive list of application remediation recommendations. Indicating the strategic importance of the application informs the recommendation for the type of remediation – rehosting, refactoring, rearchitecting, etc.

If required, the appropriate compliance standards can be selected from a list of more than fifty different global standards for incorporation into the CloudAtlas analysis.

EVALUATING MIGRATION OPTIONS

Once those items are complete, the application is ready to be analyzed by CloudAtlas to provide options, recommendations and guidance for modernization. The CloudAtlas assessment includes a multitude of analytics depending on the app, database or portfolio analyzed for multiple migration scenarios, including migration to Containers, PaaS, VMs, and Power Apps. Analysis includes an overview of all options and the readiness, tasks, effort and cost of each migration option. This allows users to make informed decisions with complete information to migrate with confidence. In this example, we’ll focus on the eShop app and the associated guidance for Windows Container modernization.

Code-level guidance is provided for every option with recommendations, count of changes required, estimated time to remediate, and sizing – a good proxy for complexity – and relative readiness. CloudAtlas also recommends the optimal migration path based on the analysis and business requirements. When you select container assessments, an overview highlights the recommendation, required tasks, hours of effort and cost for approaches with or without .NET to .NET Core conversion. In this example, CloudAtlas has identified the fastest path to modernizing the legacy .NET eShop app is to containerize it to Windows containers on AKS.

App-level guidance highlights the number of components and recommended remediation tasks, breaking those down into four different areas:

Application and Platform Design
Security
Network and Availability
Storage

Task size and level of effort in hours are provided to assist in migration planning. Cost estimates to run in Azure are also provided and can be further customized.

In this example, CloudAtlas estimates that eShop app is 88% container ready, subject to 15 changes (11 small and 4 medium) requiring 58 hours of effort if done manually.

APPLICATION REMEDIATION

Every remediation task is described at a detailed level to guide the effort and instill confidence in the changes to be made. CloudAtlas identifies the category, datapoint and the details of the recommendation including the reason for the change, the code block, the line of code, the file path, the recommended changes, the estimated effort, the migration impact, and authoritative Azure guidance. Where code changes are required, sample replacement code is typically provided.

As an example of the guidance, in this eShop MVC app remediation example, the app uses the InProc mode that stores session state in memory on the Web server which doesn’t allow for scaling because the memory provider isn’t distributed. CloudAtlas recommends that you should consider using either StateServer or SQLServer modes.

CloudAtlas can also accelerate application remediation with automated code changes that significantly reduce manual effort – often by as much as 80%. For every application, CloudAtlas provides an overview of the time savings this automated remediation capability provides.

For the eShop demo application, the readiness is improved from 88% to 91%, reducing manual effort by 25%. This may seem small, but it saves more than a day’s worth of effort for this small demo application.

To provide transparency and instill confidence in the code changes being recommended, every line of code can be reviewed, edited, and approved prior to compilation as part of the automated remediation. This gives users complete control over the automated remediation process.

As part of the automated remediation, CloudAtlas can connect to Azure subscriptions, new or existing landing zones and custom resources to ensure a smooth migration.

GENERATING LANDING ZONES FOR SEAMLESS MIGRATION

Once remediated, the code can be compiled for easy migration. To ensure a seamless migration, a Cloud Adoption Framework Workshop identifies business-specific needs which are incorporated into an automatically generated landing zone designed for the specific workloads being migrated.

Migration can then be implemented by directly connecting to the Azure subscription via CloudAtlas, providing the end-to-end support needed for a successful automated cloud migration to AKS.

MIGRATION INSIGHTS FROM 4,000+ APPLICATIONS

CloudAtlas has assessed over four thousand apps in the past few months, which gives us a great data sample to analyze. From this data, it is clear that many customers would benefit from remediating apps to a modern AKS architecture in a ‘one-step’ migration versus the ‘two step’ “lift and shift to VMs first and modernize later” approach the industry currently recommends.

FREQUENTLY ASKED QUESTIONS

While many questions may arise during a migration assessment, here are a few that we frequently see when considering migration to Azure Kubernetes Services.

Question: What are the key benefits of using AKS for application deployment compared to traditional hosting solutions?

Answer: AKS offers scalability, flexibility, and automated management of containerized applications. It helps optimize resource utilization, ensures high availability, and simplifies the deployment and orchestration of containers. Other AKS benefits include automatic scaling, self-healing, simplified management, and seamless integration with Azure services, enabling a more streamlined and efficient development and deployment process. And CloudAtlas simplifies the process even more, automating much of the process and making sure that your workloads and Azure environment are optimized at deployment and over time.

Question: How does AKS handle security for containerized applications?

Answer: AKS implements robust security features such as network policies, Azure Active Directory integration, role-based access control (RBAC), and it supports Azure Key Vault for secure management. CloudAtlas ensures that these services are provisioned appropriately based on the needs of the business as defined in the modernization assessment.

Question: What considerations should be taken into account when planning migration to AKS?

Answer: Factors to consider include application architecture, data storage, networking, security requirements, and any dependencies on external services. CloudAtlas considers all these factors as part of the assessment of existing infrastructure to develop a well-defined migration plan.

Conclusion – See what CloudAtlas can do for you

CloudAtlas is the only platform in the marketplace that provides a true end-to-end automated cloud migration solution from initial assessment to modernization to migration and optimization. Born in the cloud by former Microsoft employees, CloudAtlas accelerates and facilitates the cloud migration journey to help partners and customers realize and achieve cloud benefits faster, better, and more consistently. CloudAtlas does this for all types of digital transformation, including modernization to AKS. Learn more about CloudAtlas capabilities and AKS modernization in this short demo video.

CloudAtlas is offering a free assessment of an application for modernization and migration to AKS. Submit your information here to be contacted by a UnifyCloud Cloud Architect to get started, or ask your Account Manager at Microsoft about the Solutions Assessment Program.

For more information you can visit www.unifycloud.com or contact us at info@unifycloud.com for questions or comments.

____________

¹ Source: Microsoft IT, as directly related to UnifyCloud personnel, notes that it takes an experienced developer 3 days to manually scan 10,000 lines of code for migration to Azure.

Active Directory and Kubernetes – everything you need to know about gMSA with Windows Containers

Fady_Azmy — Thu, 08 Feb 2024 14:47:09 GMT

Organizations with applications that use Active Directory (AD) for authentication and authorization typically encounter challenges when integrating them in containerized solutions like Azure Kubernetes Services (AKS).

To use AD authentication, you can run your AD-based application on Windows containers with a group Managed Service Account (gMSA). Using Windows containers and gMSA minimizes the changes required which does reduce the cost and time to bring those applications to market.

In this article we’ll look at:

Primer on Windows Containers for legacy applications
Challenges with containerizing AD-based applications
1. Scenario #1 - IIS application with AD integration
2. Scenario #2 - Multi-tier application with AD/Kerberos authentication
Containerizing AD-based apps using gMSA for authentication
1. Scenario #1 (Web Server Scenario)
2. Scenario #2 (Multiple Services in a Container)
When is gMSA not the right solution?
Customer wins with gMSA
How to get started
Frequently asked questions (FAQ)
1. Does gMSA require my Windows node to be domain joined?
2. Do I need to configure plug-ins when running gMSA?
3. Can runAsUserName use a gMSA?
4. What’s the difference between gMSA and Pod Identity?
5. Are there any additional considerations for on-premises Windows container workloads?
6. Can I use gMSA to authenticate with a SQL Server database?
7. Are there any firewall considerations for gMSA on AKS?

Primer on Windows Containers for legacy applications

Windows Server containers, launched in 2016 by Microsoft, are the hero container platform for containerizing legacy IIS apps (such as .NET Framework and .NET Core), Win32, Java and Visual Basic applications because of the minimal code level changes needed.

The latest Windows OS is the Windows Server 2022 containers which is available on AKS, and it provides the latest security and performance improvements and is the recommended OS for Windows node pools on AKS.

We support running Linux and Windows node pools in the same cluster. However, Windows Server 2019 and Windows Server 2022 can't coexist on the same node pool on AKS. You’ll need to create a new node pool to host the new OS version.

You can read about how our customers achieved time and cost savings by migrating their legacy applications to Windows containers on AKS.

Challenges with containerizing AD-based applications

Let’s discuss two popular AD-based application scenarios and their challenges with containerizing.

Scenario #1 - IIS Application with AD Integration

You have an IIS application that uses Active Directory and single sign-on to authenticate and personalize the experience for users.

Typically, this would be accomplished by joining the Windows Server instance hosting IIS to Active Directory and configuring IIS to use the computer or a service account to authenticate.

Scenario 2 - Multi-tier Application with AD/Kerberos Authentication

You have a multi-tier application (e.g. IIS or a data processing app) where the various tiers use AD/Kerberos to authenticate amongst each other. In this situation, you’d normally join the various Windows Server instances hosting these tiers to AD and permission each tier accordingly.

Scenario 1 & 2 containerization challenges.

The challenge with containerizing these two types of applications lies in ensuring consistent identity management and access controls across containers.

Unlike static Windows Server instances, containers can be transient and numerous which is beneficial in scaling up/down quickly and updating your workloads, however it does complicate the configuration and management of identity and access in Active Directory environments. For example:

Dynamic Service Discovery and Configuration: Containers are dynamic and ephemeral, making it challenging to maintain consistent AD configurations.
Secure Credential Management: Managing credentials and sensitive information in a containerized environment is critical.
Automated Container Identity Management: This system should integrate with AD to ensure that each container has the correct identity and access rights, based on its role and function within the application.

Containerizing AD-based apps using gMSA for authentication

Let’s now expand on how you can leverage AD in a container environment with minimal changes. We created gMSA to provide an automated management of service account passwords and separate the AD identity. This allows applications running in a container environment (standalone and managed by Kubernetes) to authenticate with AD by using gMSA.

Any service running as SYSTEM or NETWORK SERVICE will use the Windows Container's identity just like they use the domain-joined host's identity today. This setup eliminates the need to store passwords or certificate private keys in the container image, mitigating the risk of accidental exposure. The container's ability to be redeployed across various environments – development, test, or production – without a rebuild for changing stored passwords or certificates streamlines the operations and ensures a secure consistent user authentication experience across the board.

If we containerize the 2 example app scenarios highlighted previously - (1) IIS Application with AD Integration and (2) Multi-tier Application with AD- we can end up with a Web Server running in a container for the former and multiple services in a container in the latter.

Let’s discuss our options to integrate these applications with AD and run in a single container.

Scenario #1 (Web Server Scenario)

Imagine you have a web server running in a container. This web server needs to access a database on another server. To authenticate and access the database securely, the web server uses the container's gMSA identity which you can do by running it as 'Local System' or 'Network Service'.

Scenario #2 (Multiple Services in a Container)

Suppose you have a container with two services: a file-sharing service and an email service. Both need to authenticate to different network resources using different identities for security reasons. In this case, you can configure your container with multiple gMSAs. Each service in the container can then use a different gMSA to authenticate to its respective network resource.

You can run an IIS app pool, Windows service or console apps as Network Service. For more information on this, you can read the gMSA configuration page on Azure docs.

When is gMSA not the right solution?

There are also situations where your app uses AD but gMSA isn’t the right fit. Here are some scenarios:

AD-based apps that rely on Group Policies.
1. Note: Group policies can be translated to dockerfiles which eliminates the need for group policies.
Application is not dependent on Active Directory authentication
Application using Azure Active Directory (Azure AD), then Azure AD Workload Identity (formerly known as Pod Identity) might be a better fit.

Customer wins with gMSA

We’ve seen customers cut down benefit greatly from leveraging gMSA, and this includes:

Cutting down the effort and time to migrate their apps to K8s
Moving fully to the cloud and saving on-prem infrastructure costs
Delivering a better customer experience through faster developer productivity by standardizing their CI/CD and DevOps practices

How to get started

There are a number of excellent resources to help you set up gMSA for your windows workloads on AKS. Here’s the order of resources we recommend you go through to successfully set up:

Learn how gMSA works:

Learn how to deploy gMSA on AKS

For Azure Kubernetes Service, we created a PowerShell module that configures the multiple components needed, greatly simplifying the process of deploying gMSA on AKS. The usage of this module can be broken down into three parts:

If you don’t want to use the recommended PowerShell module, you can still configure gMSA on AKS by manually deploying all resources and configurations:

Enable Group Managed Service Accounts (GMSA) for your Windows Server nodes on AKS cluster [AKS docs]

Deploy gMSA on AKS Hybrid for on-premises scenarios

gMSA can also be used when containerizing Windows applications in on-premises environments with Azure Kubernetes Services Hybrid, running on Windows Server or Azure Stack HCI:

Configure group Managed Service Accounts (gMSA) for Windows containers with AKS on Azure Stack HCI and Windows Server [AKS Hybrid docs]

Troubleshooting

Finally, once you have gMSA configured but something goes wrong, check out the documentation on how to troubleshoot the environment:

Troubleshoot gMSAs for Windows containers [AKS docs]

Examples and workshops

We’ve also developed workshops to walk you through examples of setting up (1) an ASP.NET app running in an IIS server that is authenticated with gMSA and (2) a minimal IIS configuration which is running a Windows pod authenticated with Active Directory by using gMSA.

Frequently asked questions (FAQ)

Does gMSA require my Windows node to be domain joined?

No this isn’t required. We support gMSA for Windows containers on both domain joined and non-domain joined Windows nodes.

When gMSA for Windows containers was initially introduced, it required the container host to be domain joined, however this limitation has been addressed.

Do I need to configure plug-ins when running gMSA?

When running Windows containers with gMSA on non-domain joined Windows nodes, a plug-in to retrieve the gMSA credentials is needed to implement the Container Credential Guard Interface.

Fortunately, AKS and AKS Hybrid customers don’t need to worry about this implementation as it is native to the Windows nodes on AKS. Customers running Windows containers with gMSA on Windows nodes outside of Azure that are not domain-joined will need to implement a plug-in.

You can consume the Container Credential Guard (CCG) API for your own solution or follow our recommendation to use the Container Credential Guard Azure Key Vault Plugin (CCGAKV Plugin) which the retrieves group managed service account (gMSA) credentials stored in Azure Key Vault to facilitate the domain-join process.

Can runAsUserName use a gMSA?

runAsUsername cannot be a domain user (or any user with a password as we don’t support passing in the password).

The recommended best practice way of using runAsUserName would be to do so in the context of NETWORK SERVICE which would put it in the context of the GMSA.

What’s the difference between gMSA and Pod Identity?

gMSA is for supporting traditional AD-based applications that are being containerized. Pod Identity is intended to support modern applications that take advantage of Entra ID (formerly known as Azure AD) for authentication.

For more information you can read Pod Identity or gMSA? Which one is best for you on Azure Kubernetes Service blog post.

Are there any additional considerations for on-premises Windows container workloads?

Yes. While you don't need to domain join a Windows worker node in AKS on Azure Stack HCI and Windows Server, there are other required configuration steps. These steps include installing the webhook, the custom resource definition (CRD), and the credential spec, as well as enabling role-based access control (RBAC role).

For more information, you can review the Configure group Managed Service Accounts (gMSA) for Windows containers with Azure Kubernetes Service on Azure Stack HCI and Windows Server page.

Can I use gMSA to authenticate with a SQL Server database?

Yes. Applications can use Active Directory gMSA to connect to SQL Server databases using Windows Authentication.

You’ll need to:

Create a gMSA in AD and configure the necessary permissions
Configure gMSA on Azure Kubernetes Service
Create a host Service Principal Names (SPN), MSSQLSvc/hostname, for your gMSA account
Configure the SQL Server for gMSA Authentication, this involves changing the service account in the SQL Server Configuration Manager to the gMSA.

For instructions on creating gMSA with SPNs, you can review the Create a group Managed Service Account section. Additionally, to learn about configuring the SQL Server Configuration to gMSA you can review the Secure AND Easy Service Account Management blog post.

Are there any firewall considerations for gMSA on AKS?

Yes, if your Windows nodes on AKS and DCs run on different networks (or sites) you'll need to open the proper ports for DNS, Kerberos, NetLogo, LDAP and LDAP SSL.

For more details on the ports and scenario you can review the Firewall considerations for gMSA on Azure Kubernetes Service article.

Conclusion

If you’re looking to leverage the benefits of containers or Kubernetes for your applications that rely on Active Directory, you should consider migrating your application to Windows containers and use gMSA to handle your AD authentications.

We’d love to hear your feedback on gMSA for Windows Containers, you can leave an issue on the Windows Container GitHub repository.

Public Preview for Azure Migrate ASP.NET Assessments & Business Case for Windows Containers

anraghun — Mon, 11 Dec 2023 18:47:44 GMT

Today we're excited to announce the public preview of ASP.NET Assessments and the Business Case features for Windows Containers on Azure Kubernetes Services (AKS) and App Service via Azure Migrate.

With these new features, Azure Migrate now provides the following for ASP.NET web apps:

Cloud readiness for AKS, and App Service
A recommended configuration of Node SKUs and Node count (or App Service plan)
The yearly cost savings by running these apps on Azure

These new features add on top of the existing functionality of discovering and migrating .NET web apps which are already in General Availability.

In this blog post, we’ll dive deeper into how you can use the Assessment and Business case features with Azure Kubernetes Services:

Prerequisites
Business Case Overview
Assessment Overview

Prerequisites

To create a business case or an assessment, you first need to create an Azure Migrate project and set up a discovery appliance, allowing you to discover your .NET web apps at-scale.

The key difference between a business case and an assessment is the granularity. Business case reports are generated at a datacenter (migrate project level) whereas an assessment can be generated for select workloads such as ASP.NET web apps.

Business Case Overview

Creating a business case in Azure Migrate provides an auto-generated Total Cost of Ownership (TCO) comparison for all workloads discovered in the migrate project.

Once created, you can see the estimated yearly cost of your web apps on AKS as well as the overall cost comparison on the Azure PaaS report.

The AKS section shows the total cost, distribution of the cost by Node Pools and the total number of apps recommended for AKS (there could be other targets such as App Service recommended for your apps, based on migration strategy).

The cost comparison section compares the TCO between on-prem and Azure across cost categories such as compute, storage, IT labor etc. You can find more information about the Business Case you can refer to Azure Migrate's documentation on this.

Assessment Overview

Creating an assessment for AKS, you see the readiness status of your apps as well as the estimated cost.

As seen below, the report shows the readiness distribution of 5 apps:

2 apps are ready for migration
2 apps have conditions that need addressing
1 app is not ready and requires more significant remediation

The report also projects a cost of $797 to run these apps on AKS, month over month.

For each web app, you can also see the migration warnings or issues if any and get guidance on resolving/mitigating them. A warning is often a minor fix whereas an error typically requires a breaking change.

Finally, the assessment also provides a recommended configuration of the AKS cluster (or App Service plan). The recommendation here provides the system and user node SKUs, respective node counts and the app to node association. In particular, the assessment recommends using a Standard_NV6ads_A10_v5 SKU for the Node pool hosting the web apps.

Similar assessments can be created for Azure App Service (code and containers).

In Closing

To get started, you can find detailed guides for creating and understanding these assessments in our documentation – AKS and App Service. We encourage you to utilize Azure Migrate powered assessments to super charge your app modernization journey to Azure.

Windows Containers on AKS Customer Stories

Fady_Azmy — Fri, 01 Dec 2023 19:02:04 GMT

We have published a new page on Azure to highlight Windows Container customer stories on AKS with M365 (supporting products like Office and Teams), Forza (XBOX Game Studios), Relativity and Duck Creek.

If you are looking for a way to modernize your Windows applications, streamline your development process, and scale your business with Azure, you might be interested in learning how other customers have achieved these goals by using Windows Containers on Azure Kubernetes Service (AKS).

Windows Containers on AKS is a fully managed Kubernetes service that allows you to run your Windows applications alongside Linux applications in the same cluster, with seamless integration and minimal code modifications. Windows Containers on AKS offers a number of benefits, such as:

Reduced infrastructure and operational costs
Improved performance and reliability
Faster and more frequent deployments
Enhanced security and compliance
Simplified management and orchestration

Stay tuned for new stories that will be published soon, featuring customers from new industries and with new scenarios using Windows Containers.

In the meantime, we invite you to check out the Windows Container GitHub repository, where you can find useful resources, documentation, samples, and tools to help you get started. You can also share your feedback, questions, and suggestions with the Windows Container product team and the community of users and experts.

Partner Solutions for Windows applications on Azure Kubernetes Services

Fady_Azmy — Tue, 08 Aug 2023 18:29:14 GMT

Migrating and modernizing Windows-based applications to Azure Kubernetes Services (AKS) is a destination for many customers looking to adopt cloud native principles and benefit from Kubernetes. But how do you find the right tools to deploy, manage, and monitor your Windows containers on AKS? That's why we're excited to announce the launch of the Partner Solution page for Windows Containers, a curated list of solutions from our trusted partners that support Windows containers on AKS.

The Partner Solution page is part of our ecosystem initiative, which aims to empower our customers and partners to realize the benefits of Kubernetes for your Windows-based applications. We've collaborated with leading ISVs in the Kubernetes space to provide solutions that enhance various aspects of the Windows container lifecycle, such as Observability, DevOps, Storage, Security, Networking, and Configuration Management. You can browse the available solutions by category and learn more about their features and benefits.

We also want to make it easier for you to get started with these solutions and see how they work with Windows containers on AKS. That's why we've also created a series of blog posts on Tech Community, where each partner showcases their solution and provides a step-by-step guide on how to use it with Windows containers on AKS.

If you are an interested partner or have any feedback about the Partner Solution page for Windows Containers on AKS, please let us know in the comments below!

Containers articles

Simplifying gMSA for Windows Containers on AKS: Open-Source Tooling Now Available

Who this is for

Why gMSA on AKS matters

What’s in the repository

Getting started

Open source and community feedback

What’s next

Announcing Log Monitor v2.2.0 Release Candidate

What's New in v2.2.0

Replaced Boost.JSON with nlohmann/json

New AKS + IIS Example

Bug Fixes

Upgrading from v2.1.x

Building from Source

Output locations

Example Configuration

Improvements to CI/CD Pipelines

Getting Started

Feedback

Announcing Public Preview of Window Server 2025 on Azure Kubernetes Service

Discover the New Era of Windows Server 2025 Nano Server Containers

Overview

When Efficiency Limits Functionality: Overcoming Nano Server’s Trade-Offs

Introducing Features on Demand (FoD) Support

Key Benefits of Features on Demand

Addressing 32-bit Application Support

Integration and Use Cases

Getting Started with FoD Support in Nano Server

Closing

New survey - Windows Server application survey!

Public Preview of the Windows Server Annual Channel for Containers on Azure Kubernetes Service

Getting Started - Build a Basic Hello World Image with BuildKit and Windows Containers

Setup

Build Hello World Image

Experimental Windows Containers Support for BuildKit Released in v0.13.0

How to Get Started with BuildKit

Next Steps

Thank You

Windows GPUs for AKS

Announcing the 3-year retirement of Windows Server 2022 on Azure Kubernetes Service

What does this mean for me?

How can I upgrade my Windows nodepools?

Zero-trust Security for Windows Container-based application with Calico

Windows containers in Kubernetes: Automating nodepool management with Calico’s Windows HPC Support

Migration and Modernization solutions for Windows-based applications to Azure Kubernetes Services

Azure Migrate - Modernizing your .NET apps to Windows containers on Azure Kubernetes Services

Azure Migrate Overview

Modernize a legacy .NET web forms app to Windows on Azure Kubernetes Service

Background

Prerequisites

Discover eShop on Azure Migrate

TCO comparison and Savings

Assessing eShop for Azure Kubernetes Service

Migrating eShop to Azure Kubernetes Service

Conclusion

CAST - Modernizing your .NET apps to Windows containers on Azure Kubernetes Services

CAST Highlight Overview

CAST + Windows on Azure Kubernetes Service

Get actionable recommendations on containerization blockers

Common containerization blockers, and CAST recommendations

Blockers impacting the container only. Registry Settings - Using Windows registry to store Application Settings

Blockers impacting the application code.

Temporary Files - Access to environment variable

Blockers impacting the application architecture

Security & User Authentication- Using Webform Authentication

Illustrative case study on eShop applications

Repository overview

Containerization insights

Why addressing the blockers in the code prior to containerization

Sample blockers details: “Using direct Database Access through Connection Strings”

Third-Party compliance

Modernizing further

Identify “noisy neighbors.”

Modernize towards PaaS.

Transform the Architecture Design.

Customer Case Studies

Conclusion

Next steps

UnifyCloud - Modernizing your .NET apps to Windows containers on Azure Kubernetes Services

Blockers impacting the container only.
Registry Settings - Using Windows registry to store Application Settings