Run any Docker Container on Cloudron

[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.