microsoft / DockerTools

Tools For Docker, including Visual Studio Provisioning and Publishing
Other
175 stars 26 forks source link

Docker push to "Other Docker Container Registry" fails because of port in tag #312

Closed LunicLynx closed 1 month ago

LunicLynx commented 2 years ago

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:

image

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.

anvillan commented 2 years 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

LunicLynx commented 2 years ago

Hey Tony, first thanks for your response. I will answer your questions first and then try to clear up a missunderstanding.

  1. https://[url].com
  2. Yes
  3. 
    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"?>

Custom true https://[url].com [user] latest ContainerRegistry Release Any CPU xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ``` BUT i don't think this info is important. The docker image is tagged with the port and that is not correct: `docker image ls` output ``` REPOSITORY TAG IMAGE ID CREATED SIZE [url].com:443/[name] latest xxxxxxxxxxxx 17 minutes ago 222MB ----------^^^ ``` If i run the command: ``` docker push [url].com:443/[name] ``` i get the same error as in VS: `unknown: Not Found` if i re-tag the image without the port and run: ``` docker tag xxxxx [url].com/[name] docker push [url].com/[name] ``` It works. The error was reported here as well: https://developercommunity.visualstudio.com/t/problem-when-publish-image-docker-to-private-regis/1053219 NOTE: all [url].com don't include the protocol (http / https) if not directly stated.
anvillan commented 2 years ago

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
LunicLynx commented 2 years ago

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

anvillan commented 2 years ago

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.

LunicLynx commented 2 years ago

Hey Tony,

sounds great. :)

Thank you for considering it!

evanmoak commented 1 year ago

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.

LunicLynx commented 1 year ago

No it wasn't.* I pushed the image manually via console after build.

dbreshears commented 1 year ago

@evanmoak . Thanks for bringing up. This is now fixed internally and should release in a few weeks as part of 17.5 Preview 1

dbreshears commented 1 year ago

@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 commented 1 year ago

@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?

dbreshears commented 1 year ago

@evanmoak , thanks for the reminder. We are continuing to look into this and should have more information soon.

dbreshears commented 1 year ago

@evanmoak. A fix for this is queued up again for 17.5 Preview 3.

evanmoak commented 1 year ago

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!