How I Fixed the “CannotPullContainer” When Running .NET on ECS Fargate (And Made My Docker Image Multi-Platform with Buildx)

#docker #aws #ecs #serverless

I deployed my .NET app to ECS Fargate, and Docker hit me with a platform error I didn't even know existed."

In this post, I am sharing my personal experience to debug this issue, a deep dive into docker dependency on the OS architectures, on which it's been running on , and a fix that every DevOps engineer should know.

Summary

If you've hit the error:

CannotPullContainerError: pull image manifest has been retried 7 time(s): image manifest. does not container description matching platform 'linux/amd64'

You're likely trying to run a Docker image built for one architecture (say, ARM64) on a platform that only supports another (like AMD64 or Windows). Here's how I ran into this error while deploying a .NET Core app on AWS Fargate, and how I fixed it by building a multi-platform Docker image.

The Night of Murder

I was casually deploying a .NET Core application to my ECS Fargate cluster, sipping coffee… when suddenly "CannotPullContainerError" struck.

"pull image manifest has been retried 7 time(s): image manifest does not contain descriptor matching platform 'linux/amd64'"

My first reaction?
"Well, this night just is going to be long"

Debugging the Beast

The clue was hiding in plain sight: 'linux/amd64' in the error message.

It was yelling at me:

"Hey buddy! I'm trying to run your image, but I can't find the right OS/kernel architecture to match it!"

That's when i focused on architecture point

The Dockerfile I Used

Here's the super basic Dockerfile I used to containerize the app:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /builds
COPY . ./
RUN dotnet publish -c Release -o output

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
# copy all the build files form the build stage
COPY --from=build /builds/output ./
EXPOSE 8190
ENTRYPOINT ["dotnet", "poc-dockerised-application.dll"]

Looks good, right? But here's where I messed up…

Platform ≠ Platform

The base image mcr.microsoft.com/dotnet/sdk:8.0 is not automatically built for all platforms.

In my case, I was running this on a Windows-based system or trying to deploy on a Fargate host expecting a specific architecture (linux/amd64), while the image may have been for arm64.

How to Check Docker Image Architectures

Use this command to inspect what platforms an image supports:

docker buildx imagetools inspect mcr.microsoft.com/dotnet/sdk:8.0

You'll see output listing supported platforms like:

linux/amd64
linux/arm64
windows/amd64

If your platform isn't listed. Well, tough luck. Docker won't run it.

But What Even Is a Platform in Docker?

A Docker "platform" is basically the combo of:

OS (like Linux or Windows) CPU architecture (like amd64 or arm64)

Think of it as the compatibility handshake between your image and the machine it runs on. If the handshake fails → boom, the error I got.

How to Check Your Own Machine's Architecture

Run:

uname -m

Example outputs:

x86_64 = amd64
aarch64 = arm64

The Fix: Build a Multi-Platform Docker Image

Once I realized the architecture mismatch, I knew I had two options:

Use an image that matches the platform (e.g., linux/amd64)
Or better yet, build a multi-platform image that works everywhere

Here's how I did it with Docker Buildx:

docker buildx build --platform linux/amd64,linux/arm64 -t my-dotnet-app:multi .

Now, your image is a universal soldier now!

Key Takeaways

Docker images are platform-specific unless explicitly built otherwise
ECS Fargate uses linux/amd64 unless you provision ARM-specific infra
Always check what platforms your base image supports
Use docker buildx to build for multiple platforms in one go
Architecture mismatches are sneaky - but easy to fix when you know where to look