Run any Docker Container on Cloudron

[robi]

Cloudron is very opinionated when it comes to how it runs and packages apps. That's part of why we love it.

To make it easier to try out apps from Dockerhub before they are packaged, I thought about installing and using a modified version of CapRover, Portainer or FLAP (thanks @scooke) with just enough features enabled to manage docker and not interfere with Cloudron.

However, since their intent is to manage the server much like Cloudron, there will be lots to modify to pair it down.

It would be less modification to have Cloudron manage that as vanilla Apps not in the App Store yet still installable from any container registry.

This would speed up App packaging and dev testing of existing vanilla apps and scratch many an itch without having to run a separate system.

@staff
How difficult would it be as a new feature?

Would it be better to strip down FLAP or another container manager to run alongside Cloudron?

Discuss.

[timconsidine]

@robi very interesting thought : well the headline at least !

I fear the amount of work involved which takes @staff away from further developing cloudron, and more importantly the risk to cloudron stability of trying to put another system "alongside" in some ways.
The stability of my cloudron instance is valuable to me, so I wouldn't want it to be at risk through some architecture change or integration of another 'eco-system'.

BUT ... given that a container is a container, maybe the risk of a supporting a "bare isolated container" (e.g. docker run blah blah or docker-compose up -d) outside of cloudron email, backup, volumes, domain/dns might be acceptable to all.

I have a CapRover instance and like some parts of its approach, but I find many apps packaged for CapRover just don't work. Demonstrates the importance of 'opinionated packaging'.

I'd probably lean more towards a Portainer type approach, which seems a lot more robust than CapRover. A Cloutainer perhaps

But heck, what do I know.
Certainly interested how more expert techs see viability of this idea, which is a good one.

[nebulon]

We do feel the pressure to run vanilla Docker images Also we keep questioning some bits of why we have this opinionated approach.

Either way though, I am not sure I see the huge benefit of trying to fit something like caprover into Cloudron as such, given how simple it should be to run a docker image on a plain VPS, outside of Cloudron for testing out an app. If this is too hard, I am not sure if we can solve this by essentially providing the same thing to run such images, just with additional side-effects, the original docker image might not expect. I feel this will cause a lot of trouble later in data migration and we would have to somehow figure out backup/restore of the whole containers.

[girish]

Is there a reason why someone cannot spin up a VPS and run docker directly for testing purposes? (it's what we do ourselves). The Cloudron experience only exists because it's packaged a certain way. Without it, one has to provision databases, figure what to backup etc. It's also a big security risk - docker containers often runs as root and running random things can compromise your existing apps.

[timconsidine]

@girish I have a separate "MyDocker" VPS for testing/playing and for 'live' apps which are not yet/never going to make it into Cloudron. I like this because I like to keep my Cloudron VPS pure.

It's not a good answer to your question, but I suspect many will answer they want to avoid the cost of a 2nd VPS. But I should not put words in mouths.

If the Cloudron experience would be at risk from 'unmanaged' docker deployments, I gladly accept the cost of a 2nd VPS and accept keeping Cloudron pure.

[robi]

@girish Cost and complexity is a thing, from domain integration to simply wanting to use your existing server you pay resources for to run an additional app or two.

The assumption backups are needed is false.

Yet, if we take the time to revisit an old idea of additional VM like isolation via Nestybox, (which is a single line code change) we may have our cake and eat it too, with backups at no extra work.

Personally I don't care for any of the benefits of the packaged apps for the unpackaged ones, unless they're no effort as a side-effect of the implementation.

The only thing I can think of we might need more of is control over nginx rev proxy settings and mappings.