Upcoming Deprecation of Windows Server Containers AMIs

[kichik]

https://github.com/CloudSnorkel/cdk-github-runners/blob/a18a7d7374bcf319efc8fd6ec78d794170f0b3ed/src/providers/image-builders/ami.ts#L176

Hello,

You are receiving this message because your account has been identified as using one of the Windows Server Amazon Machine Images (AMIs) with support for containers, listed below.

Windows_Server-2016-English-Core-Containers Windows_Server-2016-English-Full-Containers Windows_Server-2016-English-Core-ContainersLatest Windows_Server-2016-English-Full-ContainersLatest Windows_Server-2019-English-Core-ContainersLatest Windows_Server-2019-English-Full-ContainersLatest Windows_Server-2022-English-Core-ContainersLatest Windows_Server-2022-English-Full-ContainersLatest

These Windows Server Containers and ContainersLatest AMIs will not receive new versions after April 14, 2023. These images include the Docker Enterprise Edition (Docker EE) runtime. Following Mirantis' acquisition of Docker, Docker EE has been renamed Mirantis Container Runtime (MCR) and has moved to a paid model. Docker EE has not received updates since October 2022, and will no longer receive regular updates. Older versions of these images will remain available through the remainder of their lifecycle, ending in August 2023.

For continued access to Windows Server AMIs that include Docker, we recommend using ECS Optimized[1] or EKS Optimized[2] Windows Server AMIs which include Docker Community Edition. If you wish to continue using Mirantis Container Runtime (formerly Docker EE), you can purchase licensing from Mirantis[3] and use EC2 Image Builder[4] to build and patch custom images with your desired configuration.

If you have any questions or concerns, please contact AWS Support [5].

[1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-windows-ami-versions.html [2] https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-versions-windows.html [3] https://www.mirantis.com/docker-engine-enterprise-support/ [4] https://aws.amazon.com/image-builder/ [5] https://aws.amazon.com/support

Sincerely, Amazon Web Services

Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message was produced and distributed by Amazon Web Services Inc., 410 Terry Ave. North, Seattle, WA 98109-5210

---

Reference: https://phd.aws.amazon.com/phd/home?region=us-east-1#/event-log?eventID=arn:aws:health:us-east-1::event/EC2/AWS_EC2_OPERATIONAL_NOTIFICATION/AWS_EC2_OPERATIONAL_NOTIFICATION_46989eb043de7613011d6f0d3702f937a5daf8eda0b0a767cd940f0286004617&eventTab=details

[RichiCoder1]

Switching over to the ECS optimized (as I think it's a bit more minimal than the EKS version) and having the builder instead use https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-custom-ami.html I think makes sense?

[kichik]

Yeah that's the current plan. Just need to test it out first. This is meant for Windows containers, so we need to make sure that image fits. I also want to test using normal image as I believe we are installing Docker ourselves anyway.

[RichiCoder1]

I believe we are installing Docker ourselves anyway.

From my reading, the ECS/EKS images should still have docker installed, just a different runtime it sounds like. Moby instead of Mirantis (Docker EE). Worth verifying though, and happy to help!

[kichik]

Would you be able to change that line to use both ECS variant and vanilla variable and then make sure the integration test still works? The image builder installs Docker and the integration test makes sure Docker works. The only question left is which base image we would need. If both work, then we need to figure out if using the ECS optimized image has any benefits.

I originally chose this parent AMI because I thought Windows had to have containers enabled for Docker to work. But I may be thinking of old Docker for Windows requirements. The Docker installer we use may already set everything up.

[RichiCoder1]

Would you be able to change that line to use both ECS variant and vanilla variable and then make sure the integration test still works?

I can give it a try!

then we need to figure out if using the ECS optimized image has any benefits.

I think ECS will win just because it's docker + ecs-agent, while EKS is docker + a bunch of different k8s components and CSI setup.

I originally chose this parent AMI because I thought Windows had to have containers enabled for Docker to work. But I may be thinking of old Docker for Windows requirements. The Docker installer we use may already set everything up.

So, I nerd sniped myself in digging.

Long story short this is the up-to-date image builder component for EKS. For some reason it looks like there isn't one ECS just yet, only the base AMIs. If you dig into the component, it looks like to setup docker it manually copying over the windows docker binaries (docker, dockerd) then manually registering them as well as installing the containers windows feature.

So it may be possibly to do this with a normal base image and entirely skip the ECS/EKS amis, but it also might be more work. The EKS image also sets up containerd but I can't tell if if that's required or an EKS only step.

Edit: It looks like just copying the binaries and enabling containers only gets you windows containers. If that's acceptable, that's an option. ContainerD is required for linux container support and has a much more complicated setup.

Add-DockerRuntime.ps1

``` <# .SYNOPSIS Adds the dependencies for Docker Daemon on the supported Windows Releases. #> Param ( [Parameter(Mandatory=$false)] [ValidateNotNullOrEmpty()] [switch]$Validate ) $ErrorActionPreference = 'Stop' #Constants $DockerBinPath = ${ENV:ProgramFiles} + "\Docker" $persistedPaths = [Environment]::GetEnvironmentVariable('Path', [EnvironmentVariableTarget]::Machine) $persistedPathsSplit = [Environment]::GetEnvironmentVariable('Path', [EnvironmentVariableTarget]::Machine) -split ';' if (-not $Validate) { # Validate that Dockerd bin exists if (!(Test-Path -path "$DockerBinPath\dockerd.exe")) { throw "$DockerBinPath\dockerd.exe not found, exiting build" } # Add docker binary to path if ($persistedPathsSplit -notcontains $DockerBinPath) { [Environment]::SetEnvironmentVariable("PATH", $persistedPaths + ";$DockerBinPath", [EnvironmentVariableTarget]::Machine) Write-Host "Machine Path Env updated to contain: $DockerBinPath" # Add to user path variable $env:PATH = $env:PATH + ";$DockerBinPath" } else { Write-Host "$DockerBinPath already exists in Path statement" } # Register docker service dockerd --register-service # In order to run Windows containers, this feature needs to be enabled, host will be restarted in the next build stage Enable-WindowsOptionalFeature -Online -FeatureName containers -All -NoRestart } else { # Validate that dockerd service is running. [string]$status = (Get-Service docker).Status Write-Host ('docker Service Status: {0}' -f $status) if ($status -ne 'Running') { throw "docker service not in running state" } } ```

[kichik]

Doing it manually will also let us support not installing Docker properly as requested in #215.

I misspoke when I said we support Windows containers. It's actually undefined behavior right now. I think it's Linux containers, but I can't quickly check due to #253. Maybe we want to offer both options as separate components here:

https://github.com/CloudSnorkel/cdk-github-runners/blob/a18a7d7374bcf319efc8fd6ec78d794170f0b3ed/src/providers/image-builders/windows-components.ts#L101-L119

[RichiCoder1]

Oh! For some reason I thought docker desktop didn't behave properly on Windows AMIs in AWS. If it does, that's a heck of a lot simpler. All you have to do then (afaik) is just install the containers and hyper-v features before running the docker desktop installer. (Might require a reboot)