Open bvanskiver opened 5 months ago
@bvanskiver, this is a Windows container limitation, not Amazon ECS specifically.
Windows Server doesn't support running process isolation (container) built on a Windows Server 2019 build version (17763) to run on a Windows Server 2022 build version (20348) and vice versa. Due to this limitation, you won't be able to change the OS version of the task.
@marciogmorales does this mean that a service instance is only able to support task definitions and images with the same version of Windows that was specified initially when the service was created and there is no way, because of Windows limitations, to deploy a Windows 2022 task definition and image to a service that has been running Windows 2019 task definitions and images? These would be new deployments and new tasks, but within the same ECS Service instance. Is this because a Windows Host Container is used to host the tasks within the ECS Service on Fargate?
Your service can host multiple tasks with different OS version, meaning service A can balance traffic for task A (Windows Server 2019) and task B (Windows Server 2022), however, as task definitions are immutable you can't change an existing task, instead you need to create a new one or a new version of the existing one.
The Windows container image needs to match the OS version selected on the task.
@marciogmorales thanks - from my testing (and an AWS Support ticket confirms it), I cannot run anything other than Windows 2019 images in my service, even if a new Task Definition version specifies the same version of Windows that is in the new image. I have proven that I can use the image and task definition in a difference ECS Fargate service or just as an independent task in a cluster, but I cannot run a Windows 2022 image and task definition version within a service that has been running Windows 2019 images. If this is possible through steps that are not obvious or documented, I'd be happy to attempt them.
I'm not trying to change an existing task, I'm trying to spin up new Windows 2022 tasks (with properly configured task definition and images) in a service that either currently or has run Windows 2019 tasks.
These services are several months old, if their age matters for any reason. I don't know the parameters of the test, but AWS Support was able to replicate my experience outside of my environment.
@marciogmorales thanks - from my testing (and an AWS Support ticket confirms it), I cannot run anything other than Windows 2019 images in my service, even if a new Task Definition version specifies the same version of Windows that is in the new image. I have proven that I can use the image and task definition in a difference ECS Fargate service or just as an independent task in a cluster, but I cannot run a Windows 2022 image and task definition version within a service that has been running Windows 2019 images. If this is possible through steps that are not obvious or documented, I'd be happy to attempt them.
I'm not trying to change an existing task, I'm trying to spin up new Windows 2022 tasks (with properly configured task definition and images) in a service that either currently or has run Windows 2019 tasks.
These services are several months old, if their age matters for any reason. I don't know the parameters of the test, but AWS Support was able to replicate my experience outside of my environment.
Was AWS Support able to provide any more insight? I am having the same issue.
Community Note
Tell us about your request Allow for Windows Fargate container platform family version to be upgraded in place.
Which service(s) is this request for? Fargate, ECS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? I recently tried to change an ECS Fargate service from Windows Server 2019 Core to Windows Server 2022 Core and the deployment of the task definition with the new version failed to start any tasks and I had to rollback to a different task definition with the older platform specified.
Are you currently working around this issue? We paused our upgrade for now, but will need to delete and re-create the services if we proceed without this issue resolved.