4

I'm trying to deploy an ASP.NET web app to an Azure Container Instance, but I get this error:

New-AzureRmContainerGroup : The OS version of image 'bwcontainercr.azurecr.io/azurecontainertest:v1' is not supported.

Here are the steps to reproduce it:

File, New, Project, ASP .NET Web Application (.NET Framework)

Using .NET Framework 4.6.1

Type is MVC

Checked Enable Docker Support

Dockerfile contains

FROM microsoft/aspnet:4.7.1-windowsservercore-1709
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .

I can press F5 and it runs in a local docker container with no issues.

I use this PowerShell to deploy to Azure.

Connect-AzureRmAccount
New-AzureRmResourceGroup -Name "bwcontainertestrg"-Location "EastUS"
$registry = New-AzureRMContainerRegistry -ResourceGroupName "bwcontainertestrg" -Name "bwcontainercr" -EnableAdminUser -Sku Basic
$creds = Get-AzureRmContainerRegistryCredential -Registry $registry
$creds.Password | docker login $registry.LoginServer -u $creds.Username --password-stdin
$image = $registry.LoginServer + "/" + "azurecontainertest:v1"
docker tag "azurecontainertest:dev" $image
docker push $image
$secpasswd = ConvertTo-SecureString $creds.Password -AsPlainText -Force
$pscred = New-Object System.Management.Automation.PSCredential($creds.Username, $secpasswd)
$dnsname = "bwcontainertest-" + (Get-Random -Maximum 99999)
New-AzureRmContainerGroup -ResourceGroup "bwcontainertestrg" -Name "bwcontainertestcg" -Image $image -RegistryCredential $pscred -Cpu 1 -MemoryInGB 1 -DnsNameLabel $dnsname -OsType Windows

It gives me the error above. It seems the base image is not compatible with Azure Container Instances. If I try to deploy it directly I get the same error

New-AzureRmContainerGroup -ResourceGroup bwContainerRG -Name "bwcontainertest-1709cg" -Image microsoft/aspnet:4.7.1-windowsservercore-1709 -RegistryCredential $pscred -Cpu 1 -MemoryInGB 1 -DnsNameLabel "bwcontainertest-1709" -OsType Windows

New-AzureRmContainerGroup : The OS version of image 'microsoft/aspnet:4.7.1-windowsservercore-1709' is not supported.

This is bad, since this image is what it uses when you add docker support in VS.

I've tried a number of different images. This one deploys by itself without my app.

New-AzureRmContainerGroup -ResourceGroup bwContainerRG -Name "bwcontainertest-corecg" -Image microsoft/aspnet:4.7.1-windowsservercore -RegistryCredential $pscred -Cpu 1 -MemoryInGB 1 -DnsNameLabel "bwcontainertest-core" -OsType Windows

So I referenced that image in my app. It builds and runs in a container on my local machine.

I deploy this and it succeeds. But when I go to the URL it gives me a 403 error.

What am I missing here?

TIA, Bill Wolohan

Community
  • 1
  • 1
bwolohan
  • 344
  • 2
  • 15

3 Answers3

1

I had the same issue, ACI does not seem to be able to run all containers, only ones based on Windows 2016 (something to do with that being the host) so any Nanoserver based ones (the 1709 tells us that is what you are using) just don't work.

Here is the one paragraph I have found from Microsoft about it:

https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting#image-version-not-supported

Image version not supported

If you specify an image that Azure Container Instances cannot support, an ImageVersionNotSupported error is returned. The value of the error is The version of image '{0}' is not supported., and currently applies to Windows 1709 images. To mitigate this issue, use an LTS Windows image. Support for Windows 1709 images is underway.

Below is a working dockerfile that uses windowsservercore as the base image, so it will run on Azure Container Instances, but it also installs .NET Core 2.0 Runtime on that base image, so your core app will run.

You do need to download the dotnetcore installer from https://www.microsoft.com/net/download/dotnet-core/runtime-2.0.0 and add it to the root of your project, then set its Properties to have a build action of Content, that way it will get copied to the Docker container while its building it so it can be installed, but don't worry, it then gets deleted before the image is completed, so your image will not grow by much:

FROM microsoft/windowsservercore AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0-nanoserver-1709 AS build
WORKDIR /src
COPY mysolution.sln ./
COPY myproject/myproject.csproj myproject/
RUN dotnet restore -nowarn:msb3202,nu1503
COPY . .
WORKDIR /src/myproject
RUN dotnet build -c Release -o /app

FROM build AS publish
RUN dotnet publish -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .

#Install .NET Core
RUN dotnet-runtime-2.0.0-win-x64.exe /quiet /install

#Tidy up by removing the installer
RUN Del dotnet-runtime-2.0.0-win-x64.exe

ENTRYPOINT ["dotnet", "myproject.dll"]
Daniel Bailey
  • 159
  • 2
  • 7
  • This dockerfile DOES create a Windows Container NOT Linux and I have it running in Azure Container Instances. My website spins up an ACI when it gets a file in, the container does some processing then the Windows container deletes itself. Much cheaper than keeping a VM running all the time. – Daniel Bailey Jun 03 '18 at 10:31
  • This is EXACTLY why I HATE Docker and I HATE Cloud. None of this garbage is documented anywhere. Why would Microsoft have images that they can't freaking run??? I wasted a few hours downloading the 1709 image and now I'm wasting a few hours downloading the LTS image and who knows if that'll work or what other problems I'll run into. Microsoft Azure has such poor support for Windows. Weird since Microsoft built Windows. – SledgeHammer Jul 10 '18 at 17:33
  • Thank you for the answer. After adding lines about exe file I get an error: `Service '...' failed to build: The command 'cmd /S /C dotnet-runtime-2.0.6-win-x64.exe /quiet /install' returned a non-zero code: 1.` Do you know what can be a reason? – psfinaki Jul 11 '18 at 15:47
  • 1
    I have added another answer which should help you @psfinaki – Daniel Bailey Jul 12 '18 at 08:11
1

Read the other answers about which base image to use, then come back here for the most efficient way of making your dotnet core container.

If you are having trouble getting the dotnet core runtime to install, you don't need to. You could set the publish to include all the dlls it needs so it is in standalone mode, then you don't need dotnet core installed at all.

I find that makes a smaller container image. Here is a working Dockerfile, the main difference is the lines:

RUN dotnet build -r win10-x64 -c Release -o /app
RUN dotnet publish -c Release -r win10-x64 -o /app

which forces it to only be built for win10-x64. 

FROM microsoft/windowsservercore AS base
WORKDIR /app

FROM microsoft/aspnetcore-build:2.0-nanoserver-1709 AS build
WORKDIR /src
COPY mySolution.sln ./
COPY myProject/myProject.csproj myProject/
RUN dotnet restore -nowarn:msb3202,nu1503
COPY . .
WORKDIR /src/myProject
RUN dotnet build -r win10-x64 -c Release -o /app

FROM build AS publish
RUN dotnet publish -c Release -r win10-x64 -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT [ "powershell.exe", "c:\\app\\init.ps1" ]

Then, because standalone mode in core creates an actual exe file instead of a portable dll, you need to have that ENTRYPOINT line on the bottom of the Dockerfile, and also create a powershell script, called init.ps1 which only needs one line in it, and the & at the beginning is important:

& "c:\app\myProject.exe"

Also set the ps1 file to be Content, so it gets copied to the root of your published folder.

With this your container should be smaller than ever before, and also will actually run!

Daniel Bailey
  • 159
  • 2
  • 7
  • Well, even though the container was created, I got the same "image not supported" error when trying to run it in ACI. However, thanks to this answer I have finally realized that **the cause is the base image** (yeah, you write it everywhere, it is just me). So now I got things working by switching to _microsoft/dotnet-framework:4.7.1-windowsservercore-ltsc2016_. Kudos! – psfinaki Jul 12 '18 at 16:04
  • That is excellent well done. Do let us know if you find a way of making your containers start any faster in ACI, 5 mins is not unusual but if you spin up a base image without any code in it, you can get one in 20 seconds, so the part where ACI downloads your container from the registry is holding us all up. its the cheapest way of getting lots of cores for a short period though so I love it. – Daniel Bailey Jul 12 '18 at 20:33
  • Update - Nano Server support has been [added](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting#cached-windows-images)! – psfinaki Jul 25 '18 at 13:46
  • `To ensure the fastest Windows container startup time, use one of the three most recent versions of the following two images as the base image: Windows Server 2016 (LTS only), Windows Server 2016 Nano Server` – psfinaki Jul 25 '18 at 13:47
0

A rep from Microsoft told me that Azure Container Instances do not support Windows Containers. This is something they are working on, but it's not available yet. I can't find any documentation that states this, but it appears to be true. I'm reading all kinds of stuff that says you can take your existing applications and run them in a container, but what they don't tell you is that, at least right now, you have to use Azure Service Fabric. It's the only way to run Windows Containers in Azure.

bwolohan
  • 344
  • 2
  • 15