Previously we announced that the support story for the Mirantis Container Runtime (formerly Docker EE) on Windows will be transitioning to Mirantis Inc. in September 2022. We would like to supplement this announcement with a reminder that in accordance with the transition, both the DockerMsftProvider API and the "Windows Server with containers" images published by Microsoft on the Azure Gallery will be deprecated. Communications on this subject have been sent to all Azure subscription owners impacted by this transition over the past year, this post serves as a public reminder of this change.
Again, you should have been contacted already where applicable, but if you are using one of these images in the Azure Marketplace you will be impacted:
After September 22nd 2022, Microsoft will remove all versions of these images from the gallery. Going forward, you will have the following options:
Each of these methods are provided as an option to make this as smooth of a transition as possible for you. The following sections will detail the pros and cons of each option. For customers using Windows containers in Service Fabric, Service Fabric only supports Mirantis Container Runtime as a configuration, which would require a Mirantis entitlement for scaling, upgrades, or support(see Mirantis Virtual Machine Image).
There are four things to keep in mind when considering the above options. It is up to your organization to decide which aspect you want to optimize around:
AKS and AKS-HCI are fully managed services with lower management overhead than what you are used to with custom deployments. Support for the container runtime is included within the AKS and AKS-HCI services under your Azure subscription.
The initial engineering cost here is considerable, as it may require rearchitecting your application to work within the Kubernetes paradigm, however, the reduced management workload that results lowers your long-term maintenance and support requirements.
Mirantis will be maintaining their own Virtual Machine image in replacement for the images listed prior. This would theoretically offer the lowest engineering cost, as it only requires a change in the Marketplace Virtual Machine image tag and a rebuild of your existing Virtual Machine scale sets. The cost here comes from the fact that the support contract with Mirantis is no longer included with your Windows server license, and you must get support directly from Mirantis. The cost of the license is included in the cost of the Azure Marketplace image. For tips on installing the Mirantis Container Runtime alongside the additional support costs, please visit the Mirantis site: Start Mirantis Container Runtime on Windows Server | Mirantis. Note: this is true for general Mirantis Container Runtime usage, including building your own Virtual Machine image. We will soon be publishing public documentation in concert with Mirantis on how to use the Mirantis Virtual Machine image.
Azure Image Builder can be more complex to implement and there are more steps involved. Additionally, while the Image Builder service is free, you must pay for the compute, storage, and networking usage associated with the build process (additional details here). The benefit to using Image Builder is that the configuration is done during a build time and would not have any effect on your workload at runtime; when the Virtual Machine scale set instantiates a new Virtual Machine from your custom image, the image will have already been prepped so no time must be spent here and it will be immediately ready to run containers (one of the key benefits of using the now-deprecated 'Windows Server with containers' images). Follow this tutorial to get started in building your own Virtual Machine images on Azure.
Should you opt for Custom Script Extensions, it is quicker to implement, and the cost is only in the nominal price to store the script in Azure or GitHub. However, the script may only execute after a Virtual Machine has been provisioned, so you must budget for additional time being spent to properly prep the Virtual Machine at scale-out time.
To install the Docker CE / Moby runtime yourself, please use this script. If you want to suggest changes to this script please make a PR here Windows-Containers/helpful_tools at Main · microsoft/Windows-Containers (github.com). For a full guide on installation please head to Prep Windows operating system containers | Microsoft Docs.
Docker Community Edition (CE) and Moby are one and the same, this script uses the Docker CE binaries built and produced by Docker Inc.
Post 22nd Sept 2022 Service Fabric customers using the "with containers" Virtual Machine images may face service disruptions as Microsoft will remove the "with container" Virtual Machine images from the Azure image gallery. The Virtual Machine image unavailability would lead to the failure of Virtual Machine lifecycle management operations such as scale out, re-image, and service healing for Azure Service Fabric (SF) node types based specifically on these Virtual Machine images.
All impacted customers must upgrade the SKU utilized within your Azure Virtual Machine Scale Set for SF clusters.
Currently, Service Fabric only supports Mirantis Container Runtime (MCR) to run containerized workloads on Service Fabric. Customers need to acquire a license from Mirantis to use MCR and have the following options:
Scenario: Customers use the Virtual Machine image provided by Mirantis
The Mirantis Virtual Machine image has the MCR prebaked into the Virtual Machine image and is available in the Azure gallery. We recommend using this Virtual Machine image for customers who want to continue running containerized workloads on SF. Customers should follow the guidance of scale up a node type to do the node SKU upgrade.
Scenario: Customers do not want to use the Mirantis Virtual Machine image
Customers can provision the MCR runtime in a standard Virtual Machine image by executing the following steps:
Step 2: Enable Automatic OS image upgrades on Azure Virtual Machine Scale Set.
Scenario: Customers want to use a container runtime other than MCR
Currently, SF only supports MCR, and is in the process of certifying Moby (Docker CE).
Customers who are not running containerized workloads but using "with container" Virtual Machine images should choose between OS SKU in-place upgrade or OS SKU upgrade. We recommend using OS SKU upgrade as it ensures service availability during the migration process.
If you're impacted by these changes, have read this guide, and would like additional guidance from the Windows Containers product team, you can reach us at github/Windows-Containers. You can also reach out to Mirantis (firstname.lastname@example.org) who can help you with your decision making.
Links provided herein will take you to a third-party website and are provided for convenience only. Third-party websites are subject to the third-party's terms and privacy statements.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.