What's coming in Cloudron 3.4
-
We want to focus on making Cloudron more self-serviceable in this release. Core problem is that when something is not working, the Cloudron dashboard is currently not very helpful for the Cloudron superadmin/operator in helping diagnose and fix problems.
- Make the backup task killable. Sometimes backups gets stuck and there is no way to stop/restart it.
- Add a way to monitor health and fix issues related to Cloudron's addons (the databases) and docker.
- The update process does a complete backup and this in turn currently locks up the admin UI. This is purely a UI issue, the Cloudron is actually up and running just fine during an update!
- Keep Dashboard always up. Currently, there is a bit of code in our startup logic which will prevent the dashboard from being accessible if it fails. We are fixing this so that the Cloudron UI will always be available 100%. And even if DNS setup is broken, it will be reachable by IP. (And then you can perform actions to fix the DNS),
- Issues related to very large app data. Currently, there is a way to disable daily backups per app. But an app update or box update still performs a full app backup. We are looking into adding a more flexible backup mechanisms and policies per app. Suggestions are welcome here (but we would strongly prefer not to disable backups of an app entirely).
-
Any roadmap plan for running your own docker containers, even via command line? Hate spinning up another VPS just for bitwarde_rs
-
Would be nice if you could override the global backup settings in the backup dialog of each app, so if you have daily backups set, you could set your nextcloud app to only backup weekly and it will do just that.
Another backup-setting for the box itself would be also nice, to have shorter periods between mail backups, 24 hours might be a bit too long if you have a hdd crash.
-
Great news !!
@girish said in What's coming in Cloudron 3.4:
Add a way to monitor health and fix issues related to Cloudron's addons (the databases) and docker.
Something related to https://forum.cloudron.io/topic/1107/mist-io-cloud-management-platform ?
Like Mist.io/ or portainer.io/ ? -
@saglagla not really related to those, we are adding a view where one can see the addon status, logs, adjust memory limits and be able to restart them if needed. This should allow users to better understand what is happening if something goes wrong and the restart often times resolves issues if an addon gets stuck for whatever reason.
-
Regarding backup, please also have a look at https://forum.cloudron.io/topic/1575/backup-improvements-restic-as-backend. Thanks.
-
-
@FTLAUDMAN We had added some support for running private apps. The doc pages are not ready yet, expect it sometime this week.
-
In an effort to build better monitoring, it would be good to look at supporting existing tooling as well. For example, a Prometheus exporter would allow users to take advantage of the robust feature set offered by Prometheus and Grafana. Or, if Cloudron already stores persisted metrics in a graphite database or something, a way to connect to that from an external server running a monitoring suite would suffice.
-
Yes, Cloudron already runs graphite and collects a lot of metrics, however those are currently only exposed as the graphs view in the dashboard. All this is not exposed directly. There is a rather generic graphs REST API available though, to run queries against graphite, but that is not currently documented. As a matter of fact, I am currently trying to bring back the graphite-web UI for inspection. I will check if there is a possibility on how to maybe expose more in that area.
-
A Prometheus-compatible ,or even better an OpenMetrics endpoint would be fantastic for a much improved monitoring system.
-
Time for some progress updates!
There is now a system menu:
Inside which, there are services list. You can monitor and configure the services:
Backups can now be cancelled. Updates can also be cancelled. Yes, the layout is bit off here but it will be fixed before the release:
Also, we have reworked the email handling for apps a bit to support some use cases. Currently, apps are create a mailbox of their own and one cannot easily access these mailboxes (if someone replied to the email). We have fixed this so that apps can now be associated with any existing mailbox. By default, an address is auto-generated for the app. You can then change this to an existing mailbox which you can access using your credentials. It's also possible now to share the mailbox name across apps.
-
this looks awesome, good job guys!
-
It was also requested to have an option to enable/disable automatic updates on a per-app basis. This was because for some apps like the LAMP app, the code in question might be tightly tied to the PHP version. So, people want to check the changelog before the update. We have added this flag now:
-
Those changes really added up! We decided to roll out what we have as 3.4. The 'big data' issue is moved to 3.5 now.
-
@girish Great work guys!
-
Just a heads up for those who update manually by clicking the update button: the progress bar will get stuck at "Installing ..." at some point. This is normal. This is because of an API change between versions. Just go to
my.<domain>directly and it will work.(also, most people won't hit the above issue since cloudron will auto-update)
-
@girish Curious if the docs about running private apps are available?
-
@girish @FTLAUDMAN
Probably have your hands full with 3.4, but I'd love this as well. It allows us to expand the functionality of Cloudron to fill any holes in our deployment requirements, and eases the pressure on you guys to get apps out.
