Update on community packages

[girish]

Right, the cloudron registry app can only host private packages. We can possibly look into adding support to make it a public registry as well, but afaik this is complicated. We need private push and public pulls - this is not implemented out of the box by the opensource registry project.

[jdaviescoates]

I think this:

@girish said:

Right, the cloudron registry app can only host private packages. We can possibly look into adding support to make it a public registry as well, but afaik this is complicated. We need private push and public pulls - this is not implemented out of the box by the opensource registry project.

Means this is correct:

@timconsidine said:

or effectively cloudron versions does not support cloudron-hosted registries ?

Right?

[girish]

@jdaviescoates Pretty much, yes.

But it can be used for sharing with friends / sharing with people you trust though. Just give them a docker registry app password and they can put it in their cloudrons and then install via the versions file.

[robi]

So it could be made public with an agreed upon default app password such as 'cloudron'

[timconsidine]

Through my CCAI --> CCAI-P --> CAG journey, I've used Docker Hub for public pulls, and my private registry for dev and non-community projects.

Maybe my bad, but I desperately hoped that Community apps would allow me one registry for minimum workflow / publish discrepancies. But seems not possible.

Not without dev work.

[made with cloudron custom mermaid app]

[robi]

It doesn't seem to make sense to separate the versions file from the source.

Since the architecture requires this for public pulls, it would make sense to have a homegrown vanilla implementation where this is taken care of.

In the case of the private registry, how could this be solved?

1. Exposing a designated source file via a local webserver at a specific path, such as .well-known/ - possibly automated by a script scanning all repos for such files, then linking them to the hosted exposed spot
2. A new addon for this purpose which accomplishes the above, which may be useful to use in other projects that need things for autodiscovery
3. Runner type workflows that work to set something like this up from the source side?
4. Cloudron provided hosting for such packages with self management capabilities?
5. Docker image hints/artifacts that can serve as a versions file???
6. Your turn..

[timconsidine]

@girish does sharing creds / creating users gives full registry access ? Or a user (virtual or real) can be limited to certain repos?

—-
EDIT : the support for Community Apps is awesome.
Thank you again for doing this “non-priority” enhancement.
Totally ok with CloudronVersions.json living in source repo such as git.cloudron.io

But plan seems to break down without easy public docker image (2 registries is good for segregating but cumbersome in practice)

[girish]

@girish does sharing creds / creating users gives full registry access ?

yes, this is why it works only for friends and trusted people.

Maybe I miss something, but cloudron docker registry app and community packages are completely different things/use cases.

• community app is for sharing built images. You generally want to use a public registry like gcs, DO, dockerhub etc. If you want to use a private registry, this is possible if the end user adds the private registry on their server. The public cloud providers have registries which give tokens with read/write and all sorts of access control which can be used for this.

• cloudron docker registry is just an app to store private docker images. sure, we can add a feature to make it support public images, but this is not on the roadmap. In general, selfhosting public docker registry is very expensive network wise and backup wise. GIven the size of docker images, you will quickly run out of network limits. This is why cloudron's own appstore images use dockerhub and is not selfhosted.

[timconsidine]

@girish you're right.
I'll have to rethink strategy.
I was focussed on simplicity, single git platform and single image registry.
But I guess it's gonna have to be separate streams :

• A: community apps : git A plus Dockerhub
• B: other dev : git B plus private image registry
  Apologies if my ambitions for combing have confused the picture/discussion.

[timconsidine]

Stubborn dog-with-a-bone that I am, I did more research, and hopefully this can put to bed my diversion of the thread (sorry), and maybe help others with a similar use case / workflow objective to mine :

• Forgejo (official Cloudron AppStore) provides standard git source code functionality AND it has a built-in container registry functionality
• so no need to consider changes to the official docker registry app for public pulls
• forgejo supports private and public repos (which git.cloudron.io does not)
• forgejo supports public image pulls (like hub.docker.com) but also multiple private containers (hub.docker.com only allows 1)
• I can uninstall docker registry app and gitea/gitlab apps, multiple used for segregating cloudron community work from closed app dev, using Forgejo organization instead.

So the answer for my bandwidth-limited brain of 1 app for (almost) everything seems to be Forgejo (available today, no dev work).

However, @girish made valuable comment that hosting container images is a disk/network usage risk. Even for a small dev footprint like mine, this could be critical (let alone Cloudron scale).

I need to think & test out, but maybe Forgejo actions can automate container push to hub.docker.com, and do automated cleanup in the instance. So from dev point of view it's a single answer (Forgejo) with CI/CD offloading disk/network risks to hub.docker.com (or whatever).