Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?
-
@luckow No - the point is the apps we are needing cannot be packaged for Cloudron at-all as it is. The main ones are multi-container apps. There's many apps where discussion has acknowledged they need add-on apps within apps, and then they cannot progress until that is a feature.
In the meantime, we could have been packaging way more apps, just without all the integration features, but in a way that they would at least be working and demonstrate-able for then showing exactly what they can do and what they would need from extending CLoudron's full-integration app packaging framework to allow for.
-
@micmc Nothing to do with having every app under the sun - this is about having apps that are otherwise impossible to package for Cloudron - so likely there is not a single instance of what they offer. We'll package a lot more Cloudron apps - but we don't have time to negotiate all the things Cloudron needs to be allowed or extended to do, we just need to have an environment that lets us get on and focus on the packaging. This does that, that's why I'm suggesting it.
-
@eddowding That's an option for motivating packaging, but it ads admin overhead IMHO. The issue we have is that we literally can't package so many apps due to Cloudron restrictions that having VM Container Apps would solve, and then speed up demonstration of the needs to extend Cloudron's native app packaging framework.
-
-
@micmc I agree, as I've commented somewhere above.
The packaging documentation is good, but doesn't particularly help new packagers on their journey.
We need more examples, walkthroughs, even boilerplates.
I understand that's quite a burden for busy staff.
I'm going to knock up a wiki, but welcome contributions.
Especially with the right answers !To kick it off :
https://forum.cloudron.io/topic/7087/packaging-own-apps-what-guidance-do-you-want -
@robi I just noticed this while exploring
Any thoughts on impact / future ?
-
@timconsidine said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:
@robi total newbie to sysbox here.
Is it a case of run sysbox on Ubuntu, then run Cloudron in one sysbox container and <a.n.other.docker.app> in another sysbox container ?No, much simpler and more elegant. (that is also possible though)
Run Cloudron, install sysbox, configure docker to use sysbox instead of runc (default runtime), done.
Now all new containers benefit from the advancements of sysbox along side any others already running.
Of course this can be added to Cloudron as a selective option upon app install from the App store as well as support running non-packaged apps from Git* hubs or Docker container hubs.
This keeps the server/VM looking like bare metal as much as possible. From there you can play other VM encapsulation schemes as you normally would.
Check the previous threads on Sysbox where docker-in-docker and Cloudron-in-Cloudron are discussed.
-
@timconsidine said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:
@robi I just noticed this while exploring
Any thoughts on impact / future ?
OH MY GOODNESS!
This is great news, thanks for finding it!
Congrats to @Rodny-Molina and Ceasar.This further solidifies the sysbox ideas, implementation and product as a key part of Dockers mission.
Good on the Docker team to see this and bring them in-house. Sysbox is here to stay.
Long live Sysbox.
-
@timconsidine said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:
Oh, didn't know! Wonder if we will see a 1.0 soon then.
-
OK, so it seems we have both interest in this - and an understanding that it's a capability that significantly lowers the barrier to entry for having apps created — albeit without all the Cloudron integration features — although I think Location could still work, Email is usually easy to configure manually, and it gets apps to being at least self-hosting testable a lot faster for proof-of-concept research & development.
@girish I honestly think this Nestybox as an App feature will save you a LOT of time from app packaging, because we'll all be able to get a lot more done faster this way, and submit them for commissioning as full citizens when time, appetite and functionality of the Docker alone way of packaging is more desirable.
-
@robi said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:
@timconsidine said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:
@robi I just noticed this while exploring
Any thoughts on impact / future ?
This further solidifies the sysbox ideas, implementation and product as a key part of Dockers mission.
I was going to point it out and let you know, and boom. Yes, and this system sounds much more as a solution and clarifies what was intended and proposed by Marcus @marcusquinn to address the actual concern to being able to run certain apps that potentially could 'never' run under Cloudron because of its own infrastructure.
The sysbox reminds me of the Qubes OS which is also recommended (E. Snowden) as the most secure desktop OS today because it runs every app in its own container.
-
@micmc Nice! I've not seen that one before, might fire up an instance to explore. Also reminds me of Firefox Containers with the multi-coloured window frames.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@marcusquinn said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:
@micmc Nice! I've not seen that one before, might fire up an instance to explore. Also reminds me of Firefox Containers with the multi-coloured window frames.
Cool, Let us know more. I was about to try it on a local machine.
-
@micmc Also just spotted https://www.whonix.org - be interesting to try that once it (Virtualbox) works on ARM / Mac M1 chips.
-
FWIW, when I looked at cloudron.io, there is no mention of being able to (possibly) package any app I want and run it. There is a specific offer of running production ready apps. So, I pay for and support what Cloudron offers; I've never paid for the Wishlist.
Ever since the Wishlist started, I've watched with keen interest. But I've also viewed it as just that, a wishlist. I found it quite generous of the Cloudron team to even openly offer the chance of user-demanded apps. On the other similar platforms (Caprover, Yunohost, even FLAP, but less so as FLAP has a strict app offering), there is the potential for anyone to package any app they want... but if you've tried those you will know that the chances those apps launching, much less working after an update, are very low! So, the fact the Cloudron has actually listened to User wishes (along with the awesome help of many Users) and packaged apps is incredible.
I think I get the allure of KVM images/VM Containers. I imagine that would be a ton of work to rework every currently functioning app into such a format. I also feel like this would turn Cloudron into more of an actual Enterprise-oriented company, rather than one that caters to users like me. Mostly because Wordpress, Ghost, Nextcloud, most of the chat apps, heck, even Mautic, Odoo and SOGo don't need the techiness of a KVM image to just be used. The sort of apps that would benefit from this are probably apps I don't really need, or would use*. And if those ignore the built-in LDAP and email services... well, that ain't Cloudron anymore (for me!)
@marcusquinn I'm curious which apps you are thinking about that are currently impossible to package for Cloudron. For example, I was checking out https://www.egroupware.org/en/download and they have already gone the Container route. There are a few LMSes too, whose names I don't recall at the moment, who seem to prefer a Container approach rather than just a docker-compose container approach.
-
@scooke I suppose anything I feel the courage to ask for or suggest I'm seeing value potential for Cloudron the company and the users as well, otherwise we'd just do these things silently ourselves, as we mostly have to now.
Personally, I see Cloudron as the best framework for time-efficient and repeatable, therefore scaleable, web app dev-ops — ultimately resulting in lower costs and barriers to entry for the community to get to try and use almost any open-source web app.
This post is in-line with that (perhaps optimistic) vision.
Effectively, what I'm asking for here is just one app.
We might even be able to get this commissioned from our own development time and contribute it, I've not dug deeper yet, but, ultimately, @girish and @nebulon know their platform better than anyone, including the gotchyas and vision, so I feel it beneficial to at least discuss openly first, see what the interest, appetite and potential collaboration could be.
In the Cloudron App Store, there are a few apps marked as "Unstable", and that's a similar state of; "it's available with warnings and disclaimers regarding stability or completeness".
Perhaps this would then spawn a section of apps that could be flagged "Testing" or "Development" or "Unsupported" or something like that.
I'll see what capacity we have to work on this, but it also might just be that it's not as complicated as it might sound, and it could be a big time-saver for @girish and @nebulon too, so maybe they will have a better vantage point for how to approach it?
Nextybox website also appears to do a good job of explaining the concept, and reasoning for it's existence, and I might finally understand why @robi has been championing this cause for so long on various threads too:
For interest, @vladimir-d has already packages ZorinOS for us locally as a full Desktop OS as a Cloudron app, so we are very active in R&D for these sorts of potentials, and I'm hoping these sorts of developments help attract more developers to Cloudron for the greater benefits of community development.
-
Just as an experiment, I thought I will document why we create our own image when I package Rallly. A disclaimer: I just chose this app because I was looking into packaging that. We will add different app upstream images as we package them.
Reference upstream Dockerfile and composer file
Notes:
- The DATABASE_URL and NEXT_PUBLIC_BASE_URL are args for the Dockerfile. These are not run time args but build time args. This means one must build a custom docker image for each installation. Also, for each location change.
- The Dockerfile is not pinned to any specific app version. So, you get whatever. This applies not just to app code but also all the deps.
- The SECRET_PASSWORD is not generated per instance.
- Looks like this is intended to be used with the compose file and not Dockerfile directly. When used with compose file, it won't use Cloudron's addons unless we create our own compose file. Have to figure this one out.
- Looks like we have to build during deploy.
- Since it's based on some alpine image, this also breaks many of our tooling. Like the web terminal and file manager. These images are so minimal they don't have any utilities for debugging/editing.
-
M marcusquinn referenced this topic on
-
@girish I guess you could still have Docker within an LXC container. So all that stuff would work the same, but you'd have a separate OS identity, so just one docker container per LXC containers.
I'm just thinking how to enable creating apps for Simple Login, Firezone and similar, where you don't want to share ports or services with other Cloudron apps, but also they are small enough that a separate VPS, or running Proxmox, would be overkill, since resource needs would be minimal.
