Installing custom Apps on Cloudron

[Kubernetes]

Hi there,

as suggested by @robi I tried together with him to find a way to make it easier to deploy a custom App to Cloudron.

As it becomes more complex now, I would like to start to share what we have.

The current idea is to use a surfer App instance to install the Cloudron CLI tool and use a config.yml to provision a custom App to an Cloudron Instance.

It is just shared to get more point of views and ideas from the Cloudron Community!
Here is the shell script that is already working, but still not complete and still in progress!

HOW-TO use this app installer for custom Cloudron Apps

• Create a surfer App instance in your Cloudron instance
• create a sub-folder with File Manager in the surfer app instance
• copy this script (app-installer.sh) to the new created sub-folder of the surfer instance (via File Manager)
• you may need to run dos2unix app-installer.sh
• you should check if you copy & paste the script, that no line breaks are breaking the code (have a look at long lines!)
• copy the CloudronManifest.json and favicon.png to the new created sub-folder
• go to terminal and execute the command: chmod +x app-installer.sh
• execute ./app-installer.sh
• it should create a config.yml file
• provide your details to the config.yml
• execute ./app-installer.sh again to deploy the custom app according to the configuration in config.yml

You will find the app-installer.sh script in Git Repo

A big thanks to @robi for supporting me during the creation of this!

UPDATE: I have updated the How-To and script

[Kubernetes]

I think the export "HOME=/app/data" should be moved outside the Setup() function as it is also needed when running load_config()

[timconsidine]

Great idea.and fresh thinking.
I'm sure there are lots of Cloudron deployments where the owners are not comfortable to deploy a custom app in the traditional way.

Initial thoughts to support this approach :

• a customised Surfer app could be made to cut out some of the manual steps (e.g. create sub-folder, copy app-installer.sh etc)
• some custom packages have extra files, e.g. customised start.sh
• probably need to copy over the LICENCE also, and POSTINSTALL, DESCRIPTION, CHANGELOG
• maybe custom apps should have a deployment.zip so there's only one file to be copied, and app-installer can handle the extract.
• ultimately an easy way to find and download a package's manifest and favicon, or deployment.zip will be appreciated by users of this approach

I wouldn't hesitate to introduce new rules for custom-apps, in order to facilitate the approach of this AppSurfer approach .

[Kubernetes]

@timconsidine Thank you for sharing your thoughts!

The start.sh should be part of the docker image, so there might no need to have it in the deployment package?

Some kind of deployment.zip would be casual to use.

There is another major step, that we need to find an solution for. The app-installer .sh can only install custom Apps that are available at a public Docker Registry or a custom Docker Registry that has been configured in Cloudron before...

[Kubernetes]

We have solved the problem with a public Docker Registry for the moment. If someone wants to volunteer to test the app deployment or want to contribute with Documentation or maybe creating a Web UI to further easy things... you are welcome!

[timconsidine]

@Kubernetes ah yes, any customised start.sh should be contained already, thanks for the correction.

[timconsidine]

@Kubernetes would like to test or contribute but I am tied for a week, and you're clearly on a roll !
I'll catch up as soon as I can.

[Kubernetes]

I created a Repo in Cloudron GitLab to have the script maintained

[fbartels]

This sounds like a nice imitative.

I think I would piece this together a bit differently. Having a small bash script as the glue that holds it together is fine. But instead of installing the cloudron cli via npm I would just execute is as a docker container. This way you also have more control over versions and don't need to tell people to manually update the cloudron cli.

Instead of asking people to manually download the manifest and favicon, let them supply the url to the git repo of the app. Then you could do a local clone and get these files from the clone. This also opens up the possibility of building the app locally instead of using somebody elses (potentially untrusted) container image. For apps that should still be pulled instead of built you could include a text file with the address of the container instead of having to have your user copy it manually into a file.

The other benefit of putting some of your logic inside of a container is that your could there rely on better tooling instead of parsing yaml files with bash.

I have only had a quick glance at your script and the way it looked to me you need to have one configuration file per app (and also one copy of your script per app?), which will lead to a lot of duplication.

Edit: and for the approach with the surfer app you should make sure to tell people to create these files in a place that is not served to the internet. Else you may expose your API key to the public.

[Kubernetes]

@fbartels said in Installing custom Apps on Cloudron:

But instead of installing the cloudron cli via npm I would just execute is as a docker container.

Not sure if I get the point. How will we call the docker container (with cloudron cli) in that scenario?

Instead of asking people to manually download the manifest and favicon, let them supply the url to the git repo of the app. Then you could do a local clone and get these files from the clone.

I agree, this would help to make it easier.

This also opens up the possibility of building the app locally instead of using somebody elses (potentially untrusted) container image.

The reason why we started with this initiative was that there are people who are not able to build the app locally. People who know how to do that, do not need the discussed approach.

For apps that should still be pulled instead of built you could include a text file with the address of the container instead of having to have your user copy it manually into a file.

Good idea.

The other benefit of putting some of your logic inside of a container is that your could there rely on better tooling instead of parsing yaml files with bash.

In fact it is not really a yaml, it could also be named .txt - I just didn't want to call it .ini as we are with Linux

I have only had a quick glance at your script and the way it looked to me you need to have one configuration file per app (and also one copy of your script per app?), which will lead to a lot of duplication.

Yes, this is right and an issue.

Edit: and for the approach with the surfer app you should make sure to tell people to create these files in a place that is not served to the internet. Else you may expose your API key to the public.

Thanks for the hint, I did add this information to the README.

[fbartels]

@Kubernetes said in Installing custom Apps on Cloudron:

How will we call the docker container (with cloudron cli) in that scenario

You could use the following snippet in a function (but maybe use your own instead of fbartels/cloudron-cli, it certainly needs updating):

docker run \
        --rm -it \
        -u "$(id -u)":"$(id -g)" \
        -v /var/run/docker.sock:/var/run/docker.sock \
        -v "$(pwd)":/code/ \
       -w /code \
        fbartels/cloudron-cli:5.0.0 "$@"

Then you can just call my_function cloudron --help. The command runs in the same dir and with the same user id, as you would have run it on your local system.

@Kubernetes said in Installing custom Apps on Cloudron:

The reason why we started with this initiative was that there are people who are not able to build the app locally

Yes, but the question is "why cant they do that already?". Which piece of knowledge and ability are they missing exact? Wrong platform/os? Missing linux knowledge?

@Kubernetes said in Installing custom Apps on Cloudron:

I just didn't want to call it .ini as we are with Linux

There for sure are also ini files on Linux, but there are a lot of choices. My preferred one would be to call the file config.env and then you could simply source it. But there are probably thousands of ways.

[robi]

@fbartels said in Installing custom Apps on Cloudron:

My preferred one would be to call the file config.env and then you could simply source it.

I agree, that's my preferred choice too, it holds ENV vars

To make this work with an authe'd GUI, the existing Cloudron build service App can be easily modified to support this further.

It already knows to get the API key once you log in, the rest is invoking what the easy-install.sh script does. No Surfer App needed.

[girish]

@Kubernetes just an idea, but if your docker images are public, then you could maintain a version -> image map in an online file somewhere. With that people can skip the whole build step altogether. Of course, they need to trust you about the images but I doubt such people are going to code review your app package source..

[BrutalBirdie]

@Kubernetes That is also what I do for my Cloudron FoundryVTT package: =>
https://github.com/BrutalBirdie/cloudron-foundryvtt

I offer a public pre-build image and a little readme how to build it yourself.

[Kubernetes]

Yeah, I did it similar with the easy-installer script , too. I have put it into the cloudron package template repo ... i may archive the old app installer repo - as it is outdated already

[timconsidine]

The work of this approach is great.
Can't underestimate its importance.

Just thinking out loud, overcoming a user's reluctance/fear/unfamiliarity to use the terminal and execute commands is only really going to be solved by a GUI.
I wonder if that turns out to be the destination.

Equally, if a Cloudron user has successfully got to a terminal on their VPS and been able to execute the cloudron install script, maybe I'm wrong and installation by command line is going to be enough.
After all, it is expected that users can open Terminal or File Manager to adjust config or env files.

If we can get it to a 3 step process, maybe that's enough :

• install "base" or "shell" app from AppStore (e.g. Surfer or LAMP)
• open Terminal and execute wget https://zzzz.yyy/custom-app-install.sh && chmod +x custom-app-install.sh && ./custom-app-install.sh (copy & paste of course)
• close terminal and restart app

Maybe @staff can be persuaded to approve a CustomAppInstaller app in the AppStore which provides a GUI to this.

Again, just thinking out loud.

[timconsidine]

@Kubernetes doh! I missed the part in your repo where the temporary Surfer app can be uninstalled. That's neat !

[robi]

@timconsidine said in Installing custom Apps on Cloudron:

Maybe @staff can be persuaded to approve a CustomAppInstaller app in the AppStore which provides a GUI to this.

There's a FR thread for this here: https://forum.cloudron.io/topic/10987/cloudron-build-service-add-ability-to-to-install-custom-apps

In another thread @girish suggested an even easier way, creating a small modification to the App Store where one can do this.

[Lanhild]

I may have an idea for the easiest way to achieve this. (I don't know if it's been proposed before)

Instead of creating/modifying a dedicated Cloudron app, a simple change could be made to the app store: The ability to add custom sources files.

Just like apt or any other package manager has, we could have source files that contain;

• Links to valid git repositories with app package code
  

Each source files you added could also have applications that use private Docker images, so prompting the user if they want to add a custom registry credentials for this source file would be necessary.

This would then allow to list additional applications in the Cloudron app store that come from these source files, and tag/label them as Custom

You could install them just like officially packaged apps, update, backup, etc.

IMO, sources files would be the most user-friendly way to install custom apps as there'd be no need for the use of Cloudron CLI, as everything would be done through the UI

Let me know what you think about it.

[robi]

@Lanhild Good idea.

It would help to make a PR with the proposed changes to @staff have less questions and coding to do to make it work. That may speed things along.

You may have to ask for access to the repo where the code for it is.