Closed incomingstick closed 1 month ago
Thanks for reporting! It sounds like we might be slamming the target server a bit - can you try enabling chunked uploads and see if that helps? You can do this by setting the SDK_CONTAINER_REGISTRY_CHUNKED_UPLOAD
environment variable to true
. Another option is to not allow parallel upload of the image layers, instead forcing sequential uploads of each layer. We don't currently expose a variable for controlling that behavior, but I opened https://github.com/dotnet/sdk/pull/32080 to address that.
What kind of registry are you pushing to here? Is it something self-hosted?
Thanks for reporting! It sounds like we might be slamming the target server a bit - can you try enabling chunked uploads and see if that helps? You can do this by setting the
SDK_CONTAINER_REGISTRY_CHUNKED_UPLOAD
environment variable totrue
. Another option is to not allow parallel upload of the image layers, instead forcing sequential uploads of each layer. We don't currently expose a variable for controlling that behavior, but I opened dotnet/sdk#32080 to address that.
Thanks for the reply! I just tested, both locally and via my CI, using the SDK_CONTAINER_REGISTRY_CHUNKED_UPLOAD
environment variable, and unfortunately am still receiving errors. Interestingly, it is a different error when running locally vs via the CI, but in both cases running the docker push
command still uploads successfully.
CI still outputs the same error I noted above, however running locally I receive a slightly different error in the exact same manner (first layer succeeds, fails after that):
Microsoft.NET.Build.Containers.targets(195,5): error CONTAINER1013: Failed to push to the output registry: System.Net.Http.HttpRequestException: Name or service not known (cr.example.com:443)
I find it interesting that, when running locally, the second layer fails with Name or service not known
(which would suggest a DNS issue), but the first layer is still successful. I can confirm things look good resolving the domain name with ping
.
What kind of registry are you pushing to here? Is it something self-hosted?
It is a self-hosted GitLab container registry. The registry is behind a reverse-proxy (for SSL) and accessible via both port 80 (with redirect to 443) and 443. I can manually push and pull from the registry no problem, and all other resources that access the registry work without issue (e.g Docker Swarm, Portainer, etc.).
@incomingstick it looks like registry may be throttling the requests or not responding due to high load.
we added more environment variables to control the upload in this PR: https://github.com/dotnet/sdk/pull/32080
could you please try to use them to disable parallel upload and increase chunk size at your environment?
the daily build of Microsoft.NET.Build.Containers
with this change is available in this feed: https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json
if this doesn't help, could you please collect the network logs when doing publishing (using Fiddler or similar tools) so we can analyze at which step the upload is interrupted.
Thanks
@vlada-shubina I am unable to get the registry to push at all now, using Microsoft.NET.Build.Containers
version 7.0.400-preview.23253.37
.
Before experimenting with the new flags you suggest, I wanted to make sure it would still fail as expected without them, but now it does not successfully upload at all. The only change has been moving from Microsoft.NET.Build.Containers
version 0.4.0
to 7.0.400-preview.23253.37
. I have the following properties related to containers set in my csproj
:
<PropertyGroup>
<WebPublishMethod>container</WebPublishMethod>
<ContainerRegistry>$(REGISTRY)</ContainerRegistry>
<ContainerImageName>$(IMAGE)</ContainerImageName>
<ContainerImageTags>$(TAG)-$(ARCH)</ContainerImageTags>
<ContainerRuntimeIdentifier>linux-$(ARCH)</ContainerRuntimeIdentifier>
</PropertyGroup>
<ItemGroup Label="Docker">
<ContainerEntrypoint Include="dotnet;/app/App.Server.dll" />
<ContainerEnvironmentVariable Include="VERSION" Value="$(TAG)" />
</ItemGroup>
With the env vars set as such:
REGISTRY=cr.example.com
IMAGE=org/app
TAG=0.1.3
ARCH=x64
But now, instead of seeing the first chunk upload happen at all, it fails with the following error:
.nuget/packages/microsoft.net.build.containers/7.0.400-preview.23253.37/build/Microsoft.NET.Build.Containers.targets(195,5): error CONTAINER1013: Failed to push to the output registry: The type initializer for 'Microsoft.NET.Build.Containers.Registry' threw an exception.
Additionally, using the flags you suggest does not change the error I receive now.
This PR will fix the problem: https://github.com/dotnet/sdk/pull/32301, there was a packaging issue with the latest build.
The PR was merged, please so the fix is in. Could you please test it with the newest version? Thank you.
Testing using Microsoft.NET.Build.Containers
version 7.0.400-preview.23305.3
the build no longer fails immediately, however the upload still fails with the error:
Microsoft.NET.Build.Containers.targets(201,5): error CONTAINER1013: Failed to push to the output registry: CONTAINER1006: Too many retries, stopping.
It is able to upload the first layer still, and recognize if the layer is already there, but fails after. In addition to those env vars I noted previously I added the following:
SDK_CONTAINER_REGISTRY_PARALLEL_UPLOAD=false
SDK_CONTAINER_REGISTRY_CHUNKED_UPLOAD=true
SDK_CONTAINER_REGISTRY_CHUNKED_UPLOAD_SIZE_BYTES=1024
I tried SDK_CONTAINER_REGISTRY_CHUNKED_UPLOAD_SIZE_BYTES
with both very small values, such as 1024
and much larger values, such as 131072
, both result in the same error as above. I receive the error with or without the env
vars added in this test.
Closing as this is quite old and we've made several changes to the registry communication since then. Please let us know if there are more issues we can address here.
I am worried this might be the wrong repository, but I am reporting a bug for the Microsoft.NET.Build.Containers package, which lists the source repository here on NuGet (link).
SDK Version: 7.0.203 Package Version: 0.4.0 (also tested 0.3.2)
I am publishing a hosted WASM application as a container using the following command in my CI:
dotnet publish -c Release /t:PublishContainer App/Server/Server.csproj
However, when
<ContainerRegistry>
inServer.csproj
is set to my registry, as an examplecr.example.com
, the publish fails with the following error:It appears to start the upload properly, even completing the first layer, however it fails to start uploading the second layer. If I instead add
cr.example.com
to the<ContainerImageName>
tag inServer.csproj
so it readscr.example.com/org/app
, and then rundocker push -a cr.example.com/org/app
the container is uploaded to the registry without error.While the
Resource temporarily unavailable
error would normally suggest some network issue, the error is consistent when using the<ContainerRegistry>
tag when running both locally and in CI, but always works when uploading via thedocker push
command, both locally and in CI, which suggests to me that something else might be causing issue.