Make it easier to use your own app
-
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.
-
@MooCloud_Matt said in Make it easier to use your own app:
@girish
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)
-
@ekevu123 said in Make it easier to use your own app:
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.
-
@jdaviescoates
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.
-
@ekevu123
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.
-
@MooCloud_Matt said in Make it easier to use your own app:
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
-
we use Gilab CI/CD, but even n8n can be used as a ci/cd if you want to use no code.