Why wouldn't cloudron install take into account the private registry

[Lonkle]

This didn't work cloudron install like it does when it's public. Because it was private I had to do this: cloudron install --image docker.io/lonk/xyz:20201014-163709-529ace55b in order for it to work.

Otherwise I'd get the:

repository does not exist or may require 'docker login': denied: requested access to the resource is denied statusCode: 404

error. The Cloudron CLI, why did it need that when it already had all of that info already and the private registry was already set up in settings (hence the second method worked).

[girish]

Ah, this is because in the code we assume that if the registry is not set in the image name, it is a public image from the docker.io registry - https://git.cloudron.io/cloudron/box/-/blob/master/src/docker.js#L112 . Currently, the Cloudron App Store images do not use have the registry name in them (since images are public). If you passed in 'lonk/xxx', code doesn't know if it pass auth info or not. I guess we could "hardcode", the username in the check as well but we also have cloudron, cloudron-dev, cloudron-staging and some other usernames in docker hub.

The fix is easy though: cloudron build --set-repository and then enter docker.io/lonk/xyz (i.e include the docker.io part).

[murgero]

@Lonk on top of what @girish said in his response, make sure you are using the right syntax:

cloudron install --image=username/packageName:version (after setting the registry being used.)

I have not used a private registry before, but I assume that's how it has to be done as that's how the default registry works for me.

[Lonkle]

@girish said in Why wouldn't cloudron install take into account the private registry:

The fix is easy though: cloudron build --set-repository and then enter docker.io/lonk/xyz (i.e include the docker.io part).

That worked , including the domain name when setting the repository name definitely used my private credentials. I did that and was able to cloudron update without putting in the image directly.

I do have to say, though, that I never would have figured that out so I could continue the:
cloudron build
cloudron update
build flow even with a private registry (which is such a great build flow). I'm honestly surprised that when Cloudron gets the code back may require 'docker login': denied: requested access to the resource is denied statusCode: 404 why it wouldn't assume docker.io authentication should be tried before giving up with the error just to make it more intuitive.

[Lonkle]

@murgero Both private and public registries don't need the --image option. cloudron build asks you the repo which you enter, then the cloudron-cli remembers that for the session. Then you can type cloudron install and cloudron update in that same terminal window and it'll continue to use the same repository, no needing to type the image or version ever. It's a really great dev flow. Hats off to the Cloudron CLI.

[murgero]

@Lonk Nice, I've always used the default repo or my docker-hub so never had to switch to a private repo before. Very good information, thanks!

[Lonkle]

@murgero I'm only using a private registry right now to hide a token I'm using for an in-development web app. I've exclusively used public before and cloudron build / install / update works perfectly on public repos by default as well in case you thought the flow was only for private repos (I couldn't tell from your reply and wanted you to know you can use that same flow with cloudron remembering the repo for the whole session).

[Lonkle]

@girish said in Why wouldn't cloudron install take into account the private registry:

Ah, this is because in the code we assume that if the registry is not set in the image name, it is a public image from the docker.io registry - https://git.cloudron.io/cloudron/box/-/blob/master/src/docker.js#L112 . Currently, the Cloudron App Store images do not use have the registry name in them (since images are public). If you passed in 'lonk/xxx', code doesn't know if it pass auth info or not. I guess we could "hardcode", the username in the check as well but we also have cloudron, cloudron-dev, cloudron-staging and some other usernames in docker hub.

The fix is easy though: cloudron build --set-repository and then enter docker.io/lonk/xyz (i.e include the docker.io part).

Though this solution worked perfectly for me, it was not intuitive. And you did bring up an interesting point. I have two accounts on Docker Hub myself (one for production, one for staging). Could Cloudron support multiple users in the Cloudron Private Registry page? In case some of the projects end up being private?

As for determining if and when to use credentials to pick up a private Docker registry based on the name of the username / base and if the script can find a public registry with that info, if not fall back to authenticated.

I think that wouldn't be a hard edit for your Build Service, let me see if I can make it as a proof of concept.