Closed LunicLynx closed 1 month ago
Hi, @LunicLynx
Thanks for reaching out. I would like to ask you some questions and gather some information.
First, I can confirm that when VS IDE publishes to docker, the formed URL indeed includes the port 443. This is because, by default, we use HTTP over TLS (HTTPS) which assigns that as the default port value.
I tried the described scenario and it worked for me deploying to an Azure Container Registry, with and without the port (I made an internal modification to the code for the latter).
I'd like to know with more detail what you are experiencing.
Note: the answer(s)/information you provide, please make sure to remove any private/sensitive information, replacing it with some placeholder to keep its correctness; e.g.
<RegistryUrl>https://realAzureContainer.azurecr.io</RegistryUrl> --> <RegistryUrl>https://container.azurecr.io</RegistryUrl>
Questions: 1 - What is the RegistryUrl value you have in your publish profile (.pubxml)? 2 - The Container Registry you are deploying to, does it support HTTP over TLS (is 443 port enabled)? 3 - What is the error message you see when the publish process fails?
Info: 4 - Could you please share your publish profile (.pubxml)?
Thanks, Tony
Hey Tony, first thanks for your response. I will answer your questions first and then try to clear up a missunderstanding.
Running the docker.exe login command failed.
WARNING! Using --password via the CLI is insecure. Use --password-stdin.Error response from daemon: login attempt to https://[url].com:443/v2/ failed with status: 404 Not Found
A diagnostic log has been written to the following location: "C:\Users[user]\AppData\Local\Temp\tmp8399.tmp"
4.
<?xml version="1.0" encoding="utf-8"?>
Thanks for the quick response and the detailed explanation.
Now it is clearer the scenario. I see that the port is added to the tag name. This is caused by the same reason I explained in my previous entry where the port is taken from the scheme defined for the RegistryURL value.
I tried running the same command as you did, having the port included in the tag, and it worked for me:
D:\docker push awebappcontainer20211019150031.azurecr.io:443/awebappcontainer
Using default tag: latest
The push refers to repository [awebappcontainer20211019150031.azurecr.io:443/awebappcontainer]
9d0920a90ae7: Pushed
5f70bf18a086: Pushed
a00ffc53ceec: Pushed
d22f1b721cb0: Pushed
05c2210a0ded: Pushed
fcb3a39200e9: Pushed
9203d67ebc1c: Pushed
e81bff2725db: Pushed
latest: digest: sha256:259204d281132df86b41c83c158b47e1efb0d9345783486388a185e9bccebeb1 size: 1995
D:\docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
awebappcontainer20211019150031.azurecr.io:443/awebappcontainer latest 641fbf52b3cf 16 minutes ago 210MB
...
Could it be the error is related to the Docker Desktop/CLI version you are using? I am using this one:
D:\docker --version
Docker version 20.10.8, build 3967b7d
Hey Tony,
i'm using the same docker version aswell.
Docker version 20.10.8, build 3967b7d
I think it could be related to the registry we are using. But even though it does work in your case i still think the port should not be in the Tag.
Other images:
REPOSITORY TAG IMAGE ID CREATED SIZE
mcr.microsoft.com/dotnet/aspnet 6.0 980c8f80fc21 7 days ago 208MB
k8s.gcr.io/echoserver 1.4 a90209bb39e3 5 years ago 140MB
Aren't tagged with the port either. And besides, i explicitly don't want the port to be there. I don't think that the port is relevant to identify an image.
I would send you a PR but that part of the tooling seems to be closed source. If you don't want to change the current behavior, would it be possible to introduce an option to not include the port in the image name?
Otherwise the publish functionality in VS is of no use to me.
Any help, tips, are appreciated, Florian
Hey, Florian
Understood. I agree that the port certainly could not be included in the image name.
I consult with the WebTools team (and the Containers team) to provide a reasonable solution for a case like this.
Thanks for following up. I will let you know what we decided and work and any items derived from it.
Hey Tony,
sounds great. :)
Thank you for considering it!
Was this issue ever resolved? I am having the same issue pushing to GitHub Container Registry ghcr.io it appends ghcr.io:443 which gives a 404 not found error.
We are not using Azure which appears to be the only available documentation on publishing to Docker registries from Visual Studio.
No it wasn't.* I pushed the image manually via console after build.
@evanmoak . Thanks for bringing up. This is now fixed internally and should release in a few weeks as part of 17.5 Preview 1
@evanmoak. Looks like we ran into a regression when testing this fix and need to reset my last comment. Will let you know when have a resolution
@evanmoak. Looks like we ran into a regression when testing this fix and need to reset my last comment. Will let you know when have a resolution
Thanks for looking into it. Has there been any update into testing this solution?
@evanmoak , thanks for the reminder. We are continuing to look into this and should have more information soon.
@evanmoak. A fix for this is queued up again for 17.5 Preview 3.
Hey Devin! I just noticed the launch of 17.5 Preview 3. I tried out the publish tools to "Other Container Registry" and used ghcr.io and the published worked as expected! VS tagged the image properly and completed the publish.
Thank you so much for your work on this and constant updates!
Hello,
in VS 2022 Preview 5.
Currently if i push to
Other Docker Container Registry
the tooling appends the scheme port to the container image tag.Which then fails on push:
I tried to locate the offending line of code in the nuget package, but wasn't able to find it.
Im using version 1.11.1 of the Nuget Package
microsoft.visualstudio.azure.containers.tools.targets
.Help would be greatly appreciated.