Make it easier to use your own app
Is there a way to potentially make it easier to install your own application?
For now, this is it: https://docs.cloudron.io/packaging/tutorial/
I think it could make Cloudron more attractive if it was easier to run basically any piece of code on it. Updating it is still difficult, for example.
There is enough basic information on how to package apps for Cloudron. This is not reinventing the wheel since packing apps with Docker is out there for a long time and there is no "easy" way since this is already very comfortable. I'm neither a developer nor a real programmer but with my knowledge as admin and some docker and ops skills, I was able to pack apps for Cloudron. The Cloudron base image with its addons together with the build service app makes this easier then ever before.
@ekevu123 it's certainly subjective, but relatively easy is definitely achievable. Just needs practice.
Deploying to Cloudron I mean.
Can't comment on any app - that depends on the code.
But packaging is fairly straightforward with a little practice.
Anything/everything in IT is complex when you are not familiar, and easy when you are.
I don't mind the process itself, but two improvements would certainly help:
- If I can give access to a maintainer for only one app and it doesn't require server access to install it. So, if I could install something like an empty app in Cloudron and then have someone else figure things out in the terminal.
- If updates could be implemented easier. By easier I mean: ideally, by taking the code from a repository, for example.
I think the big deal is just read only fs.
Been able to select directory to be R+W and not just App/data can be a good idea on the simplify packaging for Cloudron.
But that would break how Cloudron works, making apps much less secure, and much harder to maintain ( backups, updates, migrations)
If I can give access to a maintainer for only one app and it doesn't require server access to install it. So, if I could install something like an empty app in Cloudron and then have someone else figure things out in the terminal.
That actually already works, but is mainly useful for static/php apps. You can add an "operator" to an app. This operator then has access to the logs, files manager and terminal for the given app.
I'm not on the same idea, if you can specify in the manifest the directories that are writable(or better where a volume should be mounted), you can back them up as you do with /app/data.
and the same for updates and migration, updates are managed by the start script or by including the new code directly in the image, this will not change is exactly the same as now, and is secure as now, because you still have all the FS lock, just some directory will be writable, and they are specified in the manifest.
And we have proof that it works because the compose specification is easy to use and easy to set up a backup of the volume mounted on the container.
You can limit what a user can do with the operator role, and update the app using a custom docker image, with the API and a Rest Client or the Cloudron CLI(that work flawlessly with a CI/CD).
You should follow the idea of updating the image and not the software inside of it, when you containerize any app for cloudron, because they are the same principle applied to any docker install.
As I suggested, you could just set up a CI CD, and provide access to the GIT repo + the operator access to cloudron for reading logs and access the terminal, to your developer.
This allows you to update the app, keeping the advantage of cloudron for stability, security, and backup, ... and having that extra flexibility that you are asking for.
I know that is not what you expect as an answer, but cloudron is built with the idea of using an opinionated layout(for easy maintenance and stability), for DIY a solution, maybe Portainer is a better fit for the flexibility that it offers.
and update the app
Ah, right. I was not considering that the user could use the cli with the operator role to update the app, but that would of course make sense.
And +1 for the ci/cd approach. Here it would not even matter what capabilities operators have for updating apps, since you could have one "global" token stored in your ci for pipelines to make use of.
Personally I am using Drone as my Cloudron based CI, the source for my instance is at https://github.com/fbartels/cloudron-drone-app