Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?

marcusquinn

@girish Yes, they certainly are all different, and Cloudron certain is my favoured tool for production instances management.

However, there seems to be a universally acknowledged issue in the bar for entry for apps being packaged is so high, that the wish list grows faster than apps are packaged. So what do we do?

Some more confident system admins can fire up new small VPS/VM instances and try installing those unpackaged apps using their official Docker Compose scripts, and anyone else just has to wait or find an alternative.

I'm trying to find a way to reduce the barrier to entry for that next-best alternative.

Maybe I can ask the question a different way...

How do you suggest a Cloudron subscriber gets to use any apps on the wish list that aren't packaged or don't have any available packagers in the immediate future?

My whole technology career is based on figuring out how to get out of technology traps, so what's the next-best alternative here?

Would having Cloudron able to fire up and manage KVM containers solve this? Kinda like a multi-cloudron but on a single Cloudron server? Kinda like Cockpit offers.

girish

@marcusquinn said in Why Cloudron's Docker only? How about KVM containers with generic Docker Compose scripts?:

Some more confident system admins can fire up new small VPS/VM instances and try installing those unpackaged apps using their official Docker Compose scripts, and anyone else just has to wait or find an alternative.

To explore this a bit more... Generally, those docker compose files are "one liners" which you run and "hope for the best". They also make best sense to run in a separate VPS and not part of Cloudron itself since nothing there is shared with Cloudron anyway (the compose files bring their own database containers etc). Given that, why try to force fit Cloudron into all this?

Backups - it's best to take VM backups for such deployments. Cloudron's backup mechanism is only possible because apps are packaged in a specific way.

Restore - has to be done using the VM snapshot above.

Certs/Domain - this has to be done manually. I think some of those containers even support certbot integration etc.

User management - it won't integrate and we have to teach people about LDAP.

Email - it won't integrate and we have to teach people how to configure email sending inside the app.

Updates - it's not possible to provide a generic update strategy given that backup/restore itself doesn't work within Cloudron.

Cron jobs, services, nginx configuration, security configuration etc - Hopefully, they are part of the compose (?) Who should look into all this - we take this responsibility right now.

Support - if an app doesn't install or update, I am not sure what we (cloudron team) can do.

If you look at it, the above is exactly what Cloudron tries to solve. Atleast, I cannot see how this can be solved by deploying generic compose scripts.

marcusquinn

@girish Sorry, I think with Ubuntu it might be LXD, but the same concept:

That's kinda why I'm thinking VM containers. Effectively separate VMs but without the duplication of core files, resources and OS setup time. Cockpit is perhaps the best example to compare the idea, followed by Proxmox.

If I want to trial 15 apps that offer a Docker Compose one-liner, maybe 10 of them I might get lucky with working on a VM, but why would I want 15 VPSs to trial that, when I could just have one versatile parent Cloudron giving me the economies of scale for management time in that I only have one master OS to oversee maintenance of.

Email - I accept that it means no automated email management, it's no big deal doing that manually in most apps.

LDAP - I think may be accessible with manual setups, in the same way we're already doing with apps hosted on separate VPSs, Cloudron as an LDAP master for multiple servers is a big plus for us, even if we have to do the work on the other apps not fully packaged as Cloudron apps yet.

Updates - I expect re-running the Docker Compose setup script usually takes care of that.

Really I guess I'm asking for a VM container App. So you're supporting that, but not what is done with it, in exactly the same way you're supporting any other app but not what we do with them.

I don't know enough about SysBox that Rob is a champion of, maybe that's an option, maybe not depending on how standard or not it might be to Ubuntu.

I'm just trying to take advantage from existing resources, and how else are we going to get more apps without dedicated app packaging and custom feature requests being approved for multi-container apps?

marcusquinn

If you consider QNAP a prosumer self-hosting device, and Cloudron relatively similar in mission and accessibility, then perhaps their Container Station app helps demonstrate an equivalent offering:

marcusquinn

Interesting read on the subject: https://www.reddit.com/r/linux/comments/7pxa1s/does_anyone_use_lxd_canonicals_linux_container/

timconsidine

@marcusquinn I totally get the sentiment behind the topic headline.
Personally I am torn :

Cloudron is such a fantastic platform with many benefits, the 2 main ones being ease of use and stability.
So of course any passionate user will want to do more on the platform.
The moment Cloudron 'loosens' its strict platform boundaries, there is almost inevitable risk to both ease of use and stability.

On balance (although it's a fine 60:40 balance) I tend to support keeping Cloudron's platform boundaries strict.

But how then to address the natural desire of passionate users to do more?
That's the conundrum.

a non-answer is to do all the "other stuff" on another VPS.
I and many others have 2nd, 3rd and 4th VPS (MyDocker, MyCaprover, MyScratchBox).
It may be the best solution, but I understand it's not an answer really to the question.
a better answer might be to encourage and facilitate custom apps
(more tutorials, maybe more hand-holding through the forum).
That removes the burden on Cloudron support. It's custom --> it's not supported beyond general advice.
I think broadening the use of custom apps built within Cloudron's guidelines might be the partial solution.
Although clearly not a full one.
[ASIDE : I was initially terrified about tackling custom apps. It sure can be complex for complex apps. But there is a lot that can be done on simple apps with basic skills.]

Also the maintenance burden becomes bigger quite quickly.
I have approx 100 deployed apps on my Cloudron and about 10 each on a Docker VPS and a Caprover VPS.
The ratio of my maintenance time is of the order of 10:50:40 (Cloudron:MyDocker:MyCapRover).
That is ridiculous really when the apps are 100:10:10.
There is a big warning there!

A side consideration of supporting docker run xxx and docker-compose up -d type of apps is something like Portainer quickly becomes essential.

I think I might spin up a 2-app throwaway Cloudron and experiment with LXD/LXC for docker run and docker-compose up. But other more competent people will have more valid opinions on the wisdom of this.

Hope that's not a useless ramble.

MooCloud_Matt

Maybe I join too late on this discussion, but from what I understand the bid issue is flexibility vs cloudron ideals of Easy, Safe(backup) and it just works.

Probably expanding the Manifest specification and openly allowing the file format to be also used externally from cloudron can help its spread, and increasing the 3* party apps.

So these 2 changes could help:

If CloudronManifest is an open standard, like Docker Compose based on the https://compose-spec.io/. Other dev could build a CLI tool to install the app based on it. And provide the community the ability to trust this format to be in the future use outside cloudron if cloudron changes its idea on supporting its community or gets sold.
Improving the Manifest with the introduction of more than 3 directories now available, allowing the dev to set if a directory is writable and if the directory needs to be backup.
with the list of directories, that need to be backup available on the manifest file, backups can be standardized and at the same time is easy and more convenient to containerize apps for cloudron.

marcusquinn

The main issues we have are:

We can get an app running same-day with all we need on a separate VPS, but it could be a week of trial & error and blockers with Cloudron limitations. After losing so much time already, the time and will to then try and negotiate through the blockers is diminished.
Many apps are multiple Docker-containers or need services that Cloudron monopolises or would just work with a VM container.
Why not? What really is the harm in adding this generic feature that's already there in the required Ubuntu core OS layer anyway?
I believe that without scaling the number of staff, packagers and developers of Cloudron, it's only a matter of time that a competitive alternative will take on these things and make Cloudron a stale relic in comparison. The app packaging bottleneck is a real bandwidth problem that seems to have slowed more over time as the developer time is split with feature priorities and maintenance. Even if the negotiation weren't extra work for convincing the gatekeepers for features or allowances, we're very, very centralised in dependancies right now, that does mean a wish list of more and more apps that have ample demand but no sign of ever being packaged at the current rate. This at-least eases that quagmire somewhat.

fbartels

LXC is certainly a nice tool, I am using wherever possible. But instead of starting lxc containers on a Cloudron host, I would rather do it the other way around and have one of my LXCs a Cloudron container (at some point I have to try how well Cloundron runs on ZFS).

Plus I do see challenges on the networking side, like what if you want to run an app on e.g. port 25, 110, 143, 443, 993, 995, ... Ideally you will want to have a dedicated ip per vm.

But I do agree that some sort of integration of external servers into Cloudron would be neat. Maybe a little agent sitting on external servers and establishing a private network with the Cloudron server. This agent could then expose the Cloudron usermanagement to the external server and allow easy use of Cloudron as the mail relay. Bonus points for direct integration into the Cloudron Dashboard for running webapplications. Maybe a simplified healthcheck and monitoring could be possible from the Cloudron host as well.

MooCloud_Matt

@marcusquinn
Partially is solvable using the additional docker container feature in Cloudron, that one to have a specific database.
I really think that most feature would be solve if we add a more open and robust manifest, like multiple volume support (in the manifest).
Maybe a script that is executed before a backup snapshot is taken, so you have the option to stop the app and dump your db.
Managing VM is difficult and to do it reliable it's better to use specific kernels modules, so i think that for that we can still use other software.
But LXC is born to be different from Docker:
LXC is 1 container == 1 OS
Docker container (still Linux container) == 1 Service/app.

girish

@marcusquinn said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:

We can get an app running same-day with all we need on a separate VPS, but it could be a week of trial & error and blockers with Cloudron limitations. After losing so much time already, the time and will to then try and negotiate through the blockers is diminished.

Just to be on the same page. So we have an external app which user somehow installed and willing to manage. The question is how we can integrate this with Cloudron?

So, to expand on https://forum.cloudron.io/topic/7076/shortcut-app what we really need is: user creates 'External app' and can choose user management as always. The icon appears but also LDAP and Email connectivity instructions that user can plug in to the external app. Maybe it can also act as a reverse proxy so that it can do healthcheck as well as manage certs. The external app only needs to have some firewall rule to allow connections from Cloudron itself.

marcusquinn

@girish That's all up to the user to do manually if they wish. It's just a VM Container, what happens within it is no different to what would happen on a separate VPS, we just don't want dozens of VPSs for the time and cost when we can have just one meaty server sharing resources.

Referencing https://forum.cloudron.io/topic/7076/shortcut-app might just be confusing matters.

This post is about Cloudron offering what Cockpit and Container Station offers. Kinda like Surfer - it's just a generic app for static sites and files, this VM App would be the same concept, just a blank canvas app for making VM containers.

marcusquinn

@MooCloud_Matt Yup, 1 OS, within which would be its own Docker instance and all other services. Run a Docker Compose script for a new app, and see what happens. Or we could just sit here hoping that some arbitrary app might get packaged before 2032 or death by too many VPSs to manage, whichever comes first.

girish

@marcusquinn said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:

It's just a VM Container, what happens within it is no different to what would happen on a separate VPS

The VM containers concept (like kata containers) works only in hypervisors/bare metal servers (which QNAP/Synology are since you purchase hardware). You cannot create VM containers in Cloud VMs.

I think this is what sysbox solves, but I don't have much experience with that.

For Cloud VMs, we are stuck with creating additional VMs for proper isolation.

marcusquinn

@girish My understanding is that limitation is only nesting KVM containers, which is what the cloud VPSs mostly seem to be anyway. Anecdotally, we have Proxmox running on a Hetzner Dedicated VPS and can create container VMs within that, I'm not sure why, but it's one way of cracking things, albeit without any Cloudron maintenance benefits.

timconsidine

@girish as I understand the thread's initial post suggestion, it is not about external apps hosted elsewhere and accessible from Cloudron dashboard.
It's about having an additional "environment" where users can more easily deploy their apps without them being in the Cloudron App Store and meeting the requirements for that.

That sounds to me like having a Portainer-like capability as a top-level app, or a Caprover-like ability to facilitate deployment of apps which are bog-standard docker run xxx or docker-compose.

As regards the latter, I've looked at self-deploying in Caprover and Dokku (self-hosted Heroku), and it's far from as simple as it seems.
Maybe it's a comfort thing but I prefer the Cloudron self-build/self-deploy approach.
So please nobody take these comments as supportive of a Caprover/Dokku facility in Cloudron.
I think it's a swamp which will suck precious resource.

A Portainer-like facility seems to me more stable and robust.

Maybe it's a question of being able to have Cloudron and Portainer running on the same (big) VPS without them affecting each other.
I'm not technical to know if that's viable.
But I think that is what is being asked for, or a way of delivering what is being asked for.

I should probably shut up now

girish

@timconsidine said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:

@girish as I understand the thread's initial post suggestion, it is not about external apps hosted elsewhere and accessible from Cloudron dashboard.

Got it I might have gotten side tracked. I guess it comes to whether we can somehow use upstream images and deploy them on Cloudron. Or atleast make packages using upstream images instead of building our own.

This is certainly worthwhile investigating. We just had a call discussing this now and we will take the top 5 upvoted apps and see if we can come up with something generic.

girish

@marcusquinn said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:

Anecdotally, we have Proxmox running on a Hetzner Dedicated VPS and can create container VMs within that, I'm not sure why

Proxmox is a hypervisor, so it can create and manage VMs.

d19dotca

@girish I think (my two cents anyways) part of the issue may be the lack of tutorials / concrete guides with straight-forward examples of how to package apps which is leading to an ever-growing list of app requests faster than we can package them. I know I've had a few apps I wanted to tackle packaging to learn and train myself, but the lack of resources (and lack of time on my part) is a bit of a hindrance.

So I'd like to propose one aspect of a possible solution... eventually divert some resources into coming up with a neat playground / well documented area for how to package apps and even a few example walkthroughs (i.e. how were popular apps like Invoice Ninja and WordPress packaged, Umami, etc). I know we can get through the Git and see it ourselves but I think a bit of hand-holding such as a written or video walkthrough on how it was packaged (i.e. what was the starter template, and how each step progressed) would be awesome. I know it'd help me at least and presumably others. I know some of the steps are documented and there's some template apps to work off of, but I think it could still be made easier by having some detailed walkthrough guides with popular examples.:-)

That way more people could contribute easier to the app packaging process to fit Docker-ized apps inside of Cloudron's ecosystem.

luckow

Oh nerds. A lot of technical thoughts

Please allow me: 2 steps back.
What is the intent of the original question? Is it a general frustration with the lack of time between an app request and a Cloudron app release (like a child waiting for Christmas)? Is the intent to have more things to play with or to compete with other apps in the same category? Is there a real need for a missing "business related" app?

Are we really missing some applications? And if so, how could we get a clear overview of the missing categories? Do we really need a third or fourth web analytics or RSS reader app in the App Store? And if so, why? IMHO, the answer should not be: because we can.

How can we find out if an app from the app wish list is worth investing time to package it as a Cloudron app with all the benefits we need as a reliable app for our daily work?

To try out apps, I have a dedicated VPS for Docker containers. I usually follow the installation instructions in the Github repository and can usually try the app after a short time. My experience is: after a short time I run into some issues where I decide that reading the announcement and playing with the app contradicts my own expectations. But sometimes I like what I get. One of my recent discoveries was Gitpod. After spending more time with Gitpod, I realized that it's not a perfect fit for Cloudron because it's very dynamic (and resource hungry) when you share the new tool with your teammates. The same goes for BigBlueButton, which is on the app wish list, but it's not worth investing time in packaging.

For me, Cloudron massively reduces my personal time spent on business critical applications. Kind of a "fire and forget." To be fair, most of the time I spend on new applications is configuring the tool, documenting it, and explaining it to my teammates. Once that's done, I forget about it until the next major release comes out, and I have to invest time to get an idea of the new features. But all that crap about updates, backups, reliability .... That's why I decided to subscribe (to pay people for their work).

Have you ever looked into a random docker.hub image? Have you ever looked into updating a random image? In my opinion, sometimes things go wrong, and sometimes they don't. So I know that mission-critical apps take time to understand, plan, and maintain. With that in mind, I've decided not to put some "cool new kid" on the app wish list. I invest time to get an idea of whether the app is worth investing time to package as a Cloudron app.

Maybe we should create a new forum category "cool new kids" where we can showcase new apps we've heard about. From there, we can invest some time (as a community) to find out if the app is worth investing time to package as a business critical app (aka Cloudron app)

micmc

@d19dotca said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:

So I'd like to propose one aspect of a possible solution... eventually divert some resources into coming up with a neat playground / well documented area for how to package apps and even a few example walkthroughs

I know it'd help me at least and presumably others. I know some of the steps are documented and there's some template apps to work off of, but I think it could still be made easier by having some detailed walkthrough guides with popular examples.:-)

That way more people could contribute easier to the app packaging process to fit Docker-ized apps inside of Cloudron's ecosystem.

I agree, from there I'd certainly contribute to package apps myself too. It's the same thing for me, the lack of time to dig deeper to figure this out with little information. I've been administrating and managing web server for 2 decades, and started to master docker and cloud technologies on top of that about 5 years back, and I'm always on the fence of getting onto try to package apps for Cloudron, however for the same reasons mentioned, when I try to get onto it then too much question pop and I've to postpone the try because of lack of time to play to figure it all.

micmc

@luckow said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:

Oh nerds. A lot of technical thoughts

Maybe we should create a new forum category "cool new kids" where we can showcase new apps we've heard about. From there, we can invest some time (as a community) to find out if the app is worth investing time to package as a business critical app (aka Cloudron app)

That's a good idea and maybe that would help put aside not only the "cool new kid" to take a look at, but also that 10th RSS reader which the new Cloudron user who just comes in, wish to have on his Cloudron because it's the one he knows and prefer. Indeed, we don't need 5 packs of each good apps out there so then we should concentrate on getting at least one good app, preferably the best one available, for each of the category we'd consider an asset to put on Cloudron that would enhance the offer.

robi

@girish said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:

I think this is what sysbox solves, but I don't have much experience with that.

Yes, it takes 10m or so to try it out.

We can circle back with @Rodny-Molina if needed.

eddowding

One solution might be to have a marketplace / bounty space.

1] Packages have a crowdfunded bounty behind them. Want it built? Chip in £50.

But this has a disincentive to speed, since why build for £5 when you can wait a few months for frustration to mount, and build for £500?

2] Have a month "pay per app" fee for apps which is Pay What You Want with a minimum of £1/m until a reasonable fee has been reached.

Some blend of that (see also opencollective.com) seems like it might make a viable solution.

marcusquinn

@girish It's a lot about speed of research before development.

As an example, we just got OpenDroneMap running the same day on a separate VPS with the Docker Compose scripts.

Doing the same thing with Cloudron would be impossible due to the multiple Docker Containers it relies upon.

With some cooperation we could package it for Cloudron - but we just don't have the week of head-banging time to add to developments, even if we can convince you to make allowances for all of this app's needs, we need to have something working and move on to the next thing.

With what I'm suggesting, we can have a VM (LXD or equivalent) container app up and running the same day, just as with any separate VPS, and we can share that.

I can't see a downside, and it's just using features that Ubuntu already offers.

We'll also help with any port-conflicts feedback or anything else that might cause issues in using the same VPS.

You have allies here, we just don't have all we need available from Cloudron, and any time we lose in battling things that won't work quickly, is time away from the additional app packaging we could be helping with for the overall cause.

marcusquinn

@d19dotca This only helps for apps that will work with Cloudron as-is. Our main issue is apps that require changes to Cloudron itself, they are literally impossible to package with current restrictions. I understand the restrictions, and their reasons, but they are real blockers, so we know before we have started that we will fail, so all effort then goes into separate VPSs, which is of no benefit to this ecosystem, and those VPSs can't benefit from any of this ecosystem either.

marcusquinn

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

marcusquinn

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

marcusquinn

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

timconsidine

@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 ?

timconsidine

@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

timconsidine

@robi I just noticed this while exploring

https://www.docker.com/blog/docker-advances-container-isolation-and-workloads-with-acquisition-of-nestybox/

Any thoughts on impact / future ?

robi

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

robi

@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

https://www.docker.com/blog/docker-advances-container-isolation-and-workloads-with-acquisition-of-nestybox/

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.

girish

@timconsidine said in Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?:

https://www.docker.com/blog/docker-advances-container-isolation-and-workloads-with-acquisition-of-nestybox/

Oh, didn't know! Wonder if we will see a 1.0 soon then.

marcusquinn

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.

micmc

@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

https://www.docker.com/blog/docker-advances-container-isolation-and-workloads-with-acquisition-of-nestybox/

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.

marcusquinn

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

micmc

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

marcusquinn

@micmc Also just spotted https://www.whonix.org - be interesting to try that once it (Virtualbox) works on ARM / Mac M1 chips.

scooke

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.

marcusquinn

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

girish

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.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Why Cloudron's Docker only? How about VM containers with generic Docker Compose scripts?s?

OH MY GOODNESS!