Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

Cloudron Forum

Apps | Demo | Docs | Install

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

Scheduled Pinned Locked Moved App Packaging & Development
8 Posts 3 Posters 238 Views
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • LonkleL Offline
    LonkleL Offline
    Lonkle
    wrote on last edited by
    #1

    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).

    murgeroM 1 Reply Last reply
    0
  • girishG Offline
    girishG Offline
    girish Staff
    wrote on last edited by girish
    #2

    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).

    LonkleL 2 Replies Last reply
    0
  • murgeroM Offline
    murgeroM Offline
    murgero App Dev
    replied to Lonkle on last edited by
    #3

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

    --
    https://urgero.org
    ~ Professional Nerd. Freelance Programmer. ~
    Matrix: @murgero:urgero.org

    LonkleL 1 Reply Last reply
    0
  • LonkleL Offline
    LonkleL Offline
    Lonkle
    replied to girish on last edited by
    #4

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

    1 Reply Last reply
    1
  • LonkleL Offline
    LonkleL Offline
    Lonkle
    replied to murgero on last edited by
    #5

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

    murgeroM 1 Reply Last reply
    1
  • murgeroM Offline
    murgeroM Offline
    murgero App Dev
    replied to Lonkle on last edited by
    #6

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

    --
    https://urgero.org
    ~ Professional Nerd. Freelance Programmer. ~
    Matrix: @murgero:urgero.org

    LonkleL 1 Reply Last reply
    0
  • LonkleL Offline
    LonkleL Offline
    Lonkle
    replied to murgero on last edited by
    #7

    @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).

    1 Reply Last reply
    0
  • LonkleL Offline
    LonkleL Offline
    Lonkle
    replied to girish on last edited by
    #8

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

    1 Reply Last reply
    1

  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Login

  • Don't have an account? Register

  • Login or register to search.