The private registry is kind of another topic and already supported by it via editing the config file as well as setting the repo name of the image accordingly on build.
To have custom private builds make sense, this all needs to be handled within cloudron with no external networking required. Right?
And no, this is the topic of this post.
It is supported via config (good), but not available via cloudron. (feedback loop is broken)
I think there are two different use cases:
- Push images to docker hub. This makes sense when you want the image to be downloaded by many people.
- Push your custom app docker images (may not even be cloudron related). For this, a custom registry makes sense.
Hopefully, I can get around to finishing up @mario 's great work on the docker registry app sometime next week. Once that is done, it's just a matter of pointing the build service app to this registry. I have to look in more closely but maybe it even makes sense to bundle the docker registry into the app itself. It seems like a lightweight go app.
@robi I think if someone wants to build custom apps, editing a config file should not be a show-stopper for them. Otherwise, they're not gonna get far with their custom app...
Plus, it's documented very clearly, and you can do it with the web-terminal / file-manager, so IMO cloudron makes it really easy.
I could also add that this is only for the build service, you could always just build the apps locally. Or that docker.io is indeed a 3rd party service, but so is npm, so are ubuntu software repositories, so are a ton of other 3rd party services. That's not a reason to "blacklist" it from anything cloudron-related.
However, a registry as a cloudron app would indeed be very useful.
@mehdi we're not on the same page here.
Girish has it right.
it's not about editing config files or specifying a registry, it's about the inability to follow the documentation when one can't use a public registry.
That is exactly what I am proposing having a bundled registry with the build app which go hand in hand.
I thought it would be more obvious than my initial post ;-/
I understand what @robi wants since it gives the best UX. Just install something, and it's all integrated and working out of the box.
That said, I am still on the fence on what is the best approach to do this because a standalone registry is useful for many cases. Now the question is how much "pain" it is for an end user to configure other apps like build service, the docker registry ui, portus, gitlab etc to use this registry. In all likelihood, my opinion won't matter and it will be dictated by how these apps are designed There is also the case that if we put in docker registry into each app, someone will come and ask to have a shared registry that can be used across all these apps
Since we're self-hosting here, I'm seeing the default being a push to the local registry with a push button option to also push publicly.
There is also the case that if we put in docker registry into each app, someone will come and ask to have a shared registry that can be used across all these apps
each app? we only need 1. build app or registry app.
it can be used by any local app making it shared among all self-hosted apps.
I don't see a reason for anguish.
I'm with @robi on this one. At the moment I'm running my own docker-registry for app development on a virtual machine which I made somewhat maintainable over time, but it would be great if even that part could be handled by Cloudron as well.
An app which just runs the registry alongside the build server, of which I put the credentials in each Cloudron that gets apps pushed from it or something like that. I haven't checked out the thing @mario made, but it sounds something I might be interested in.
Edit: this probably really is an edge case, because most of the users are happy with the apps from the store, but if you do custom work for customers (especially if it's more than one), you would want an easy to set up, self-hosted docker registry that's password protected (which mine isn't at the moment, but all my apps are hosted on Cloudrons gitlab anyways).
I'm in strong agreement with @robi and @msbt, I'm working on a custom app and using Cloudron as a stripped down much cheaper alternative to AWS for hosting and a private docker registry is the last missing puzzle piece since I don't want to publish the image in a public Docker registry. A Cloudron private docker registry would be greatly appreciated and I'd be happy to pitch in with testing from a Github Actions CI use case or local publishing.