What's the correct Windows Base Image for ASP.NET Core 2.1 Docker Containers on Azure App Services - windows
I want to create a Docker Image that can be hosted on Azure App Services for Windows. My application is based on ASP.NET Core 2.1 and according to the official list of .NET images images, I should be able to simply use microsoft/dotnet:2.1-aspnetcore-runtime.
I can build the Dockerfile on a Windows machine successfully and was able to run it there without issues. But after uploading it to Docker Hub and setting it as the App Service's Docker Image, I get the following error message:
Cannot run this Operating System/Version in Windows Containers.
Maximum supported OS version is 10.0.14393.9999.
According to the Azure App Services Documentation, it should support the microsoft/dotnet:2.1-aspnetcore-runtime as one of the pre-installed parent images.
When inspecting my Docker Image, I found, that the used image seems to be too new for Azure App Services:
"Architecture": "amd64",
"Os": "windows",
"OsVersion": "10.0.17134.285" <-- too new
After some research, I found in this blog post, that Azure App Services on Windows might only accept microsoft/dotnet:2.1-aspnetcore-runtime-nanoserver-sac2016 image. So I tried to rebuild the Docker Image with these.
This time, the App Service accepted the image, but was unable to start it, throwing the following logs:
02/10/2018 14:15:09.437 ERROR - Site: rothiewindockerdemo - Image pull reported error. Image: robinmanuelthiel/contosomaintenance-api:latest-windows-sac2016. failed to register layer: re-exec error: exit status 1: output: remove \\?\C:\DockerData\windowsfilter\93b716197958ceb58006ff3d978fcb3202f7866d00d6d8d69513cf0478a17a7f\UtilityVM\Files\Windows\servicing\Packages\Microsoft-UtilityVM-Core-Package~31bf3856ad364e35~amd64~~10.0.14393.0.cat: The process cannot access the file because it is being used by another process.
02/10/2018 14:15:09.437 INFO - Site: rothiewindockerdemo - Image: robinmanuelthiel/contosomaintenance-api:latest-windows-sac2016
Custom Registry: https://index.docker.io
02/10/2018 14:15:09.439 ERROR - Site: rothiewindockerdemo - Pull image completed but it was not found locally. Image: robinmanuelthiel/contosomaintenance-api:latest-windows-sac2016
02/10/2018 14:15:09.441 WARNING - Site: rothiewindockerdemo - Attempt 1 to start container was unsuccessful. Maximum attempts: 3.
02/10/2018 14:15:09.568 INFO - Site: rothiewindockerdemo - Purging after container failed to start
02/10/2018 14:15:09.582 INFO - Site: rothiewindockerdemo - Purging pending logs after stopping container
So what is the correct Windows Docker Base Image for ASP.NET Core 2.1 Docker Containers on Azure App Services?
That's my Dockerfile:
#######################################################
# Step 1: Build the application in a container #
#######################################################
# Download the official ASP.NET Core SDK image
# to build the project while creating the docker image
FROM microsoft/dotnet:2.1-sdk as build
WORKDIR /app
# Restore NuGet packages
COPY *.csproj .
RUN dotnet restore
# Copy the rest of the files over
COPY . .
# Build the application
RUN dotnet publish --output /out/ --configuration Release
#######################################################
# Step 2: Run the build outcome in a container #
#######################################################
# Download the official ASP.NET Core Runtime image
# to run the compiled application
FROM microsoft/dotnet:2.1-aspnetcore-runtime
WORKDIR /app
# Open HTTP and HTTPS ports
EXPOSE 80
EXPOSE 443
# Copy the build output from the SDK image
COPY --from=build /out .
# Start the application
ENTRYPOINT ["dotnet", "MyApp.dll"]
The issue lies in the fact that microsoft/dotnet:2.1-aspnetcore-runtime is a multi-architecture base image. This means that Docker build will pick the best architecture for your local machine (the machine where you are building your docker image). I assume that your local machine is Windows 10 April 2018 Update (Version 1803 - Whose build number 17134.407). As of now, we only support images based off of Windows Server 2016 (Version 1709, up to build number 14393.XX).
In order to “force” a specific version, please use this base image instead: microsoft/dotnet:2.1-aspnetcore-runtime-nanoserver-sac2016. You can check all the available tags in https://hub.docker.com/r/microsoft/dotnet/
We will work on calling this out specifically in our documentation.
Is important to mention that Windows Containers on App Service is currently in Preview.
The validation on the portal "Cannot run this Operating System/Version in Windows Containers. Maximum supported OS version is 10.0.14393.9999." is shown because we are running the servers with Windows Server 2016 RS1 and currently can't run containers for RS3+. We are currently working on enabling them, but we don't have an ETA to share at this point.
If the validation passes, it means that the specified image should work fine and the issue you are seeing is not directly related to the image. It is a bug in the platform and it seems similar to the issue reported here: https://github.com/Microsoft/hcsshim/issues/155
We will continue investigating and thanks for reporting the issue
The answer above that was marked as an answer is not correct. It leads you to believe that using microsoft/dotnet:2.1-aspnetcore-runtime-nanoserver-sac2016 will solve your problems, but it won't. I tested this on Azure Container instances, and it does not work.
The solutions is this: when you get OsVersionNotSupported it means that the image was create with windows version that is not supported, and Microsoft currently does not support any SAC versions (SAC is Semi-Annual Channel). So versions like 1709 and 1803 will NOT WORK. Also the "solution" above is not going to work, since it uses that tag of SAC2016.
For all tags that you can use in docker file, go here: https://github.com/dotnet/dotnet-docker/blob/master/TAGS.md
You need to go to https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting and read the section "OS version of image not supported". It clearly states that you need to "...always deploy Windows Server 2016 (LTSC)-based images...".
Related
no matching manifest for windows/amd64 10.0.17134 in the manifest list entries
When I run a command "docker pull mcr.microsoft.com/dotnet/core/aspnet:3.1" to pull dotnet core for docker, i would get the following error message. docker pull mcr.microsoft.com/dotnet/core/aspnet:3.1 3.1: Pulling from dotnet/core/aspnet **no matching manifest for windows/amd64 10.0.17134 in the manifest list entries** My OS is Windows 10 Enterprise. I tried the 'experimental' settings in docker but it did not work. Docker: "no matching manifest for windows/amd64 in the manifest list entries"
The tag you are referencing is known as a manifest tag (also "multi-platform" or "multi-arch" tag). That's a special tag that can be defined which the Docker client will dynamically resolve to an underlying image that matches the platform of your Docker host. So you can use the same tag on a Linux machine with an ARM processor and Docker will attempt to resolve that tag to an image intended for the Linux ARM platform. In your case, you're running this on Windows. Windows has specific requirements around compatibility between the Windows version of the Docker host and Docker container. These requirements are published here: https://learn.microsoft.com/virtualization/windowscontainers/deploy-containers/version-compatibility. The Docker client handles this by attempting to resolve the tag to an image that matches your Windows host version. Your Windows build version is 10.0.17134 which is version 1803. That version went end-of-life (EOL) last November so you should probably get that updated. Because it's EOL, the 3.1 tag had been updated to no longer provide an image that's compatible with 1803. And this is why Docker gives you that error. It's not able to resolve the manifest tag to an underlying image that matches your host version because there is no associated image. If you really wanted this to work, you could use the 3.1-nanoserver-1803 tag instead of 3.1. That tag is platform-specific and not a manifest tag. So Docker doesn't do any resolving like it does with a manifest tag; it just pulls the image directly. But it's not recommended to use that tag because that image hasn't been serviced (1803 is EOL, remember). What you should really be doing is upgrading your host OS to a supported version.
Docker windows version container compatibility
There is one question that doesn't show up in the forums, what which has a reason to be discussed, IMHO: Why isn't it possible to pull or build windows docker images (i.e. nanoserver 2019) on an older host system? On the official site, it is documented, that it is not compatible to run, yes: Version compatibility But, as I said, "to run". I don't need to run that newer windows container image on the older host system, I just want to pull and build it, to distribute it to a compatible system later on. Thus, is there a way to handle this issue that shouldn't be one?
You missed one important thing: Even just do docker build, it will use container, it use container to build not directly on your host machine. Next is the process when docker build: Docker will create a temporary build container from the base image which you mentioned in Dockerfile with FROM. Run all instructions of Dockerfile in above temporary build container. Save the temporary build container as image. So, as you said you have seen Version compatibility for container from microsoft, so now I think you could also see why build also need this, just because it will also create a container(Just this temporary container will be removed after build). UPDATE: The whole story is: YES, in linux, no problem for a old host os to build/run a new os image/container, because host & container just share the same kernel, the rootfs is provided by container itself. BUT, you are talking about windows, from windows official, we could see next: Windows Server 2016 and Windows 10 Anniversary Update (both version 14393) were the first Windows releases that could build and run Windows Server containers. Containers built using these versions can run on newer releases such as Windows Server version 1709, but there are a few things you need to know before you start. As we've been improving the Windows container features, we've had to make some changes that can affect compatibility. Older containers will run the same on newer hosts with Hyper-V isolation, and will use the same (older) kernel version. However, if you want to run a container based on a newer Windows build, it can only run on the newer host build. Above is the reason why old windows os could not run a new windows container. Further more, what I want to say is docker build is just same reason with docker run: docker run $theImageName need to start a container base on the image theImageName, and as microsoft said, the new os container had to use the new features of kernel, so the new container cannot use the old windows host. Remember, container & host will share the same kernel. And, docker build -t xxx . will find the Dockerfile with FROM $baseImageName in it, then start a container base on the image $baseImageName, this container is a temp container. All instructions in Dockerfile will executed in this temp container, not in docker host. And finally, this temp build container will be deleted, so you did not see this temp container. So, as you see, both docker run & docker build will start the container which need to utilize the new windows host's feature, could not use old windows' kernel. This is the limit of microsoft, if you have already understand the limit for docker run on windows, the reason is same of docker build on windows.
Windows Docker API issue for using GitLab-runner
While setting up a Windows CI pipeline from GitLab, I was going through the numerous issues related to the Windows gitlab-runner docker executor that is using an old API (1.18) which Docker no longer accepts. The issue results in the following error messages when the Gitlab/CI tries to connect to the runner: Running with gitlab-runner 11.2.0 (35e8515d) on Windows VS2017 x64 0825d1d7 Using Docker executor with image buildtools2017 ... ERROR: Preparation failed: Error response from daemon: **client version 1.18 is too old.** Minimum supported API version is 1.24, please upgrade your client to a newer version (executor_docker.go:1148:0s) The 'buildtools2017' docker image that is referred to is the Microsoft "official". The image seems to be working and valid for the current (experimental) Docker version I'm using (18.06.1-ce-win74) and for the stable version as well. The issue was described throughout the GitLab wiki. Andrew Leech (?) went so far as to fork and modify the runner so that it would connect properly, and kindly provided his scripts and comments in a blogpost. This seems to give some results: C:\gitlab-runner>gitlab-runner.exe -v Version: 10.8.0~beta.551.g67a6ccc7 Git revision: 67a6ccc7 Git branch: windows-container-executor GO version: go1.9.4 Built: 2018-07-30T08:57:44+00:00 OS/Arch: windows/amd64 The GitLab wiki states that they're waiting until a more stable solution can be released. Currently it's been over one year of broken windows docker runners.. Andrew's blogpost and a link to his gitlab-runner.exe describes actually a different workaround using the PowerShell runner that then starts a Docker instance. All the token info is exposed, I'm not sure how to set it up, and it also seems to rely on an external image with older build tools. It seems the docker runner now connects, but if I undestand correctly, the Gitlab-runner docker runner does not seem to agree on the 'build directory' that is used. The first Gitlab/CI scriptline in my repo is just an echo command, so the error is not about the ci script content, but I'm not sure what it IS about. If anyone with docker fu knows what is going on this would really help me. Using Docker executor with image buildtools2017 ... ERROR: Preparation failed: build directory needs to be absolute and non-root path Cheers,
Docker Container url not accessible through localhost or ip on windows 10/docker CE/.net Core
This is most simple use case for using docker on windows to deploy dotnet core app. I used visual studio 2017 to create a dotnet core api with docker support enabled, the image was created successfully by docker. Also successfully started new container with this image, but when trying to access api at localhost or ip,then api is not responding. For more detail steps follow this url https://github.com/docker/for-win/issues/2230 Windows Version:Windows 10 Enterprise Docker for Windows 18.03.1-ce-win65 (17513)/Channel:Stable Steps: Created Dotnet Core API app in Visual Studio 2017 community. Selected "Enable Docker Support" checkbox. Dotnet Core project Created. Image got created by Docker through dockerfile. Started new Container with command Docker run –it –p 8085:80 coreapidemo:dev API NOT accessible through either localhost or ip http://172.22.236.61:8085/api/values http://172.22.236.61/api/values http://localhost:8085/api/values Update 1: Thanks #edwin for your help,using docker exec -it mycontainer powershell ,i can see that directory c:\app does not contain the neccessary code (aspnetapp.dll) to run app. Then i downloaded image from https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/Dockerfile and started container with it. Then i able to successfully access the app url at http://localhost:8000. This means that the visual studio tooling for docker is not building the image properly.Anyone can help?
Visual Studio 2015 Docker Integration wont attach for debuging
I created a Default .net Core RC2 MVC app using VS 2015. I added Docker Support so I could run and debug it in docker. When I run the project it builds the docker container and starts it. Running the command "docker ps" shows the container running with the correct ports mapped. However I get the following error: The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use NETStandard [version ...] or newer. This might be expected if the target process did not run. Also trying to access the web page returns the following error: [Fiddler] The connection to '10.0.75.2' failed. Error: ConnectionRefused (0x274d). System.Net.Sockets.SocketException No connection could be made because the target machine actively refused it 10.0.75.2:80
Turns out the problem is related to the docker for windows beta I am running. By default it does not let you map volumes. To enable open the docker for window settings: And select Manage shared drives. Select the C drive or drive you have the .Net code stored on and rebuild and deploy the project: