Container publish not functioning in DN8.P2; Worked in DN7

[MarkStega]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I am attempting to publish to a container using a workflow running in github actions. This publish worked in DN7, but fails in DN8.P2 with an error logged of 'The "CreateNewImage" task failed unexpectedly.'

Expected Behavior

I expect the publish to complete successfully

Steps To Reproduce

The steps in the workflow that are pertinent are:

    - name: Docker login
      uses: azure/docker-login@v1
      with:
        login-server: ${{ secrets.REGISTRY_LOGIN_SERVER }}
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - name: Publish, tag, and push DS image
      run: |
        dotnet publish ICEBG.Web.DataServices/ICEBG.Web.DataServices.csproj --os linux --arch x64 --configuration Azure -p:PublishProfile=DefaultContainer -p:Version=${{ env.suffix }} -p:ContainerImageName=${{env.appNameDS}}
        docker tag ${{env.appNameDS}}:${{ env.suffix }} ${{ secrets.REGISTRY_LOGIN_SERVER }}/${{env.appNameDS}}:${{ env.suffix }}
        docker push ${{ secrets.REGISTRY_LOGIN_SERVER }}/${{env.appNameDS}}:${{ env.suffix }}

The failure occurs in the 'dotnet publish' step

The logs show

  ICEBG.Client -> /home/runner/work/ICEBG/ICEBG/ICEBG.Client/bin/Azure/net8.0/ICEBG.Client.dll
  ICEBG.Web.DataServices -> /home/runner/work/ICEBG/ICEBG/ICEBG.Web.DataServices/bin/Azure/net8.0/linux-x64/ICEBG.Web.DataServices.dll
  ICEBG.Web.DataServices -> /home/runner/work/ICEBG/ICEBG/ICEBG.Web.DataServices/bin/Azure/net8.0/linux-x64/publish/
/home/runner/.nuget/packages/microsoft.net.build.containers/0.3.2/build/Microsoft.NET.Build.Containers.targets(114,9): error MSB4018: The "CreateNewImage" task failed unexpectedly. [/home/runner/work/ICEBG/ICEBG/ICEBG.Web.DataServices/ICEBG.Web.DataServices.csproj]
/home/runner/.nuget/packages/microsoft.net.build.containers/0.3.2/build/Microsoft.NET.Build.Containers.targets(114,9): error MSB4018: System.AggregateException: One or more errors occurred. (Response status code does not indicate success: 404 (Not Found).) [/home/runner/work/ICEBG/ICEBG/ICEBG.Web.DataServices/ICEBG.Web.DataServices.csproj]

The repository is open source and available at https://github.com/MarkStega/ICEBG

The full log of the failed run is available at https://github.com/MarkStega/ICEBG/actions/runs/4439861459/jobs/7792909114

Exceptions (if any)

No response

.NET Version

DN8.P2

Anything else?

No response

[adityamandaleeka]

@MichaelSimons @richlander Can you help route this?

[richlander]

This looks like @baronfel

[baronfel]

Yep, we've got an AzDo ticket for this that we recently fixed in dotnet/sdk-container-builds#384. We're going to publish another stable version of the package to NuGet likely this week that will contain this fix.

@MarkStega In the meantime you can fix this in one of two ways:

• Explicitly specify the ContainerBaseImage yourself: <ContainerBaseImage>mcr.microsoft.com/dotnet/aspnet:8.0-preview</ContainerBaseImage>
• Use the nightly builds in the repository as described in this document to use a from-main-branch build that contains the fix.

Apologies for the inconvenience, we were behind in reacting to the new 8.0 tagging scheme.

[MarkStega]

@baronfel Thanks, I added the container base image and all appears well with the build. However, when I deploy the new images to Azure they are not working. I can revert to the DN7 images and they are OK.

Apparently the containers are failing to start:

2023-03-21T14:51:24.997Z INFO  - Attempting to pull image cricebg.azurecr.io/icebg.web.ui.wip:2023-03-21--14-02-33--WIP from VNET.
2023-03-21T15:00:36.335Z INFO  - Attempting to pull image cricebg.azurecr.io/icebg.web.ui.wip:2023-03-21--14-02-33--WIP from VNET.
2023-03-21T15:00:40.535Z INFO  - Image pull for cricebg.azurecr.io/icebg.web.ui.wip:2023-03-21--14-02-33--WIP completed
2023-03-21T15:00:40.565Z INFO  - Starting container for site
2023-03-21T15:00:40.566Z INFO  - docker run -d --expose=80 --name waicebg-ui_1_701a2c4e -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=waICEBG-ui -e WEBSITE_AUTH_ENABLED=False -e PORT=80 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=waicebg-ui.azurewebsites.net -e WEBSITE_INSTANCE_ID=96a2d51f904efa7c927688614d3012fe9385088e413ae5e2dc360b9b5561fe4f -e HTTP_LOGGING_ENABLED=1 -e WEBSITE_USE_DIAGNOSTIC_SERVER=False cricebg.azurecr.io/icebg.web.ui.wip:2023-03-21--14-02-33--WIP  

2023-03-21T15:00:42.897Z INFO  - Initiating warmup request to container waicebg-ui_1_701a2c4e for site waicebg-ui
2023-03-21T15:00:58.059Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 15.1616085 sec
2023-03-21T15:01:13.154Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 30.2564551 sec
2023-03-21T15:01:28.287Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 45.3899587 sec
2023-03-21T15:01:43.393Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 60.4957313 sec
2023-03-21T15:01:58.503Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 75.605468 sec
2023-03-21T15:02:13.596Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 90.6981234 sec
2023-03-21T15:02:28.699Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 105.8018857 sec
2023-03-21T15:02:43.961Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 121.0632214 sec
2023-03-21T15:03:00.970Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 138.0727863 sec
2023-03-21T15:03:16.460Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 153.5623694 sec
2023-03-21T15:03:31.560Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 168.6625733 sec
2023-03-21T15:03:46.652Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 183.7551035 sec
2023-03-21T15:04:01.752Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 198.8547304 sec
2023-03-21T15:04:16.857Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 213.9593815 sec
2023-03-21T15:04:32.503Z INFO  - Waiting for response to warmup request for container waicebg-ui_1_701a2c4e. Elapsed time = 229.6056502 sec
2023-03-21T15:04:33.520Z ERROR - Container waicebg-ui_1_701a2c4e for site waicebg-ui did not start within expected time limit. Elapsed time = 230.6229235 sec
2023-03-21T15:04:33.537Z ERROR - Container waicebg-ui_1_701a2c4e didn't respond to HTTP pings on port: 80, failing site start. See container logs for debugging.
2023-03-21T15:04:33.545Z INFO  - Stopping site waicebg-ui because it failed during startup.

I need to investigate but I am not certain where to turn next as the docker log files are 0 length.

[EDIT] I can run the app locally (non-containerized) with no issues observed.

[baronfel]

@MarkStega from that log it looks like the port used in your app is 80 - in .NET 8 the containers' default ports changed to 8080 (per this change) and I think that's what's causing your startup issue. Try updating your service's config to 8080, or overriding the urls in use. This can be done by explicitly setting the ASPNETCORE_URLS environment variable, or by setting the new ASPNETCORE_HTTP_PORTS or ASPNETCORE_HTTPS_PORTS variables (these latter two only get used when the ASPNETCORE_URLS variable isn't used). You can set container environment variables using the SDK tooling - check the docs for examples on that.

[MarkStega]

@baronfel

Chet,
It was timely that you published your .Net 7 SDK container article. I've updated my project files to use the new tooling. The link that you had to the rootless containers contained exactly what I needed to do in Azure, namely, setting WEBSITES_PORT to 8080 (and then waiting quite a while for it to propagate so that the docker run used that port rather than 80).

I had to laugh though when I looked at your repository's (sdk-container-demo) actions log. I thought it was only me that took many, many revisions to get to a working build :-)

Thanks for the help and keep going on smoothing the direct publish of images from the sdk.

[ghost]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.