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.

[robi]

What do you guys think of a special Docker-in-Docker App packaged for the App Store that is configured for running with the sysbox-runc and has a predefined range of 20 ports enabled so any vanilla docker containers deployed within can be reached from the host.

All-in-one Cloudron + vanilla docker testing & packaging environment in an App that conforms to packaging and maintainability standards.

Thoughts @girish ?

[girish]

@robi while possible, I think we need to extend our packaging format a lot of figure out how backup/restore/automatic configuration of db,auth,mail etc is going to work. It really is a different product/focus.

[scooke]

@girish PLUS, counting on any dev or dev group to have their Dockerized setup standard enough for anyone to just plop it into an env and give it a try is hopeful thinking. There are TOO many variables involved, even in something like Docker which is supposed to mitigate these variables.

[robi]

@girish I would think everything there would stay the same, just leverage everything you already have.

Besides, anything running in DinD would be dev/test/external apps not production App Store apps.

So no your responsibility.

Just like Surfer.. you maintain it, but not any code that runs in /app/data/public

[DualOSWinWiz]

I have another ubuntu instance with portainer and by internal ip i use cloudron app proxy and even for extra security i put cloudroon sso oauth on top of it i even use wazhu, supabas and many other so instead of having nginx reverse proxy manager seperately i use cloudron

[girish]

@robi yeah, might be interesting. Happy to test things out if someone can do a prototype package.