Cloudron Forum

@timconsidine Yes, this is what I run today and it has worked really, really well ... integrates nicely with Gitlab. But the deprecation the Gitlab folks have in mind for 3rd party registries is a worry (https://docs.gitlab.com/administration/packages/container_registry/#use-an-external-container-registry-with-gitlab-as-an-auth-endpoint). There's talk about them doing a hard deprecation which I'm taking to mean would stop it working completely rather than just being unsupported as today

I'm prompted to look at this since I migrated my Gitlab to another Cloudron instance and the registry seems to be the only bit not working currently (not unexpected as I haven't changed/re-configured anything for it or migrated the Docker Registry). The Gitlab folks want to deprecate external container registries anyway so the ideal situation here would be to enable their "native" container registry. Looking at the instructions this is a non-trivial piece of work as the registry for a self compiled Gitlab instance requires another docker container to run it and a bunch of configuration. From a Cloudron perspective I think the team would have to look at:

• Do you offer the registry as an application in its own right? i.e. install it on its own sub-domain, potentially configure the appropriate Gitlab app with the details or publish the required config as an install note that you or I apply to gitlab.yml
• Do you offer the registry as something you add-on to Gitlab (either at install time or as an option afterwards)? This probably hides complexity from you or I but there's probably more work on the packaging side to get it to work. Maybe you install it anyway as part of a standard install and leave it turned off by default ...

One other option is to introduce Harbor as that's exposed in Gitlab as a 3rd party integration. However glancing at it, it's non trivial to setup and I think girish had similar thoughts https://forum.cloudron.io/post/19194

@girish Thank you .. you've had a busy morning

@doodlemania2 That's a nice thing to do - helps a lot in the early days of a new instance

Thanks for looking into this and apologies for not following up - need to check my notification settings. (also work has been really busy so no mental energy for looking at my outside interests!)

I'm getting errors about the Java heap space fairly regularly (see sample below). They appear to take the Metabase app down. I had previously pushed the memory up on <my cloudron>/#/app/d00ef8b7-e3a6-43e3-8c3c-73d822c1fded/resources to 3GB but the container doesn't appear to hit that. A quick scan of Metabase docs seems to indicate there's an assumption the JVM will sensibly allocate memory but I'm wondering if it's not doing that under Docker operating conditions? I can't see an obvious way of passing in a Java option to explicitly set the heap size. Anyone else hit an issue like this? (I don't think I'm running anything too heavy in Metabase)

2020-11-02T16:02:01.000Z 2020-11-02 16:01:56,367 WARN strategy.EatWhatYouKill ::
2020-11-02T16:02:01.000Z java.lang.OutOfMemoryError: Java heap space
2020-11-02T16:02:01.000Z Exception in thread "MetabaseScheduler_QuartzSchedulerThread" java.lang.OutOfMemoryError: Java heap space
2020-11-02T16:02:01.000Z 2020-11-02 16:02:01,028 WARN io.ManagedSelector :: java.lang.OutOfMemoryError: Java heap space
2020-11-02T16:02:01.000Z 2020-11-02 16:02:01,089 ERROR sync.util :: Error fingerprinting Table 8 'hars'
2020-11-02T16:02:01.000Z org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend.
2020-11-02T16:02:01.000Z at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:337) ~[metabase.jar:?]
2020-11-02T16:02:01.000Z at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:446) ~[metabase.jar:?]
2020-11-02T16:02:01.000Z at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:370) ~[metabase.jar:?]
2020-11-02T16:02:01.000Z at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:149) ~[metabase.jar:?]

If there's nothing private in it; could you post your /etc/hosts file?

@mehdi I was thinking of nginx as the reverse proxy talking to the high ports. I have something similar in play for my docker containers at home with traefik: A request comes in for https://site.example.com (on 443) and it gets served from a docker container at 172.x.y.z:40000 or some high port number like that

@malvim What comes to mind for me is a reverse proxy - maybe you could get a cheap VPS and run nginx as a reverse proxy (or maybe Caddy). You can probably do it with AWS CloudFront as well

(Edit: I had suggested Cloudflare but when I double checked, I realised you can't set a port in their free products)

Yes, I'm effectively looking for a managed DB on the cheap (CouchDB may come onto my horizon too @atrilahiji - this is an area I'm getting into a bit more lately)

I'll definitely look at your suggestion @girish and I like your lines of thought @nebulon

Nice suggestion @marcusquinn but it's not quite what I'm looking for this time around.

I was having a look at some of the previous questions/discussions around using the mongodb instance that Cloudron itself makes use of. My take away understanding is that there's no intention to expose that instance to end-users. Which I can appreciate.

Having an instance I can access as an end-user came to mind recently. I've returned to my Cloudron instance with the intention of making better use of it: This has led to installing Metabase for a poke around and to access data I have in Atlas. In turn, I've then thought if I start to scale up my Atlas usage I need to start looking at cost and deciding if I should self-host mongodb. I can see why Cloudron wouldn't want to slot into the hosted DB type of role but interested in other folks views.

I'm wondering if there have been any thoughts after a year and a bit on how this has turned out? For example is $30 the right entry price point? (I'm grandfathered into $15 and wouldn't have joined at $30 fwiw). I'm genuinely curious as it's interesting from a startup pricing perspective.

When/If you get a chance I'd love to read more about what you have in mind for the docker addon. Seems like an area with a lot of potential.