What happens when you click INSTALL?

[saikarthik]

Curious: what actually happens when you click on INSTALL on an app from the app store? Is it a docker-compose up? or something else to run the docker container?

I work with Kubernetes at my day job, and we use Helm charts to deploy pods (helps with complicated apps). We can also use the Kubernetes manifest yaml file to deploy a pod.

Wonder how Cloudron handles it. Just curious what the best practice is with Docker without Kubernetes for deployments.

[BrutalBirdie]

@saikarthik

I also never asked this question and took it more or less for granted.
Could we get a "behind the scenes" style look at it?

If I remember correctly @Lonk knows quite a lot about that.

ofc @nebulon or @girish could give some insight.

Still it's all in Gitlab and no secret.

[girish]

In the spirit of just showing you the way instead of walking it with you (ha ha, i am being lazy here), this file should give you lots of info - https://git.cloudron.io/cloudron/box/-/blob/master/src/apptask.js

You can follow along the various app related "tasks" from here - https://git.cloudron.io/cloudron/box/-/blob/master/src/apptask.js#L1025

[robi]

As far as I understand the Ubuntu base image is used to insert the packaged app image which was modified to work from a read only filesystem + special plugin configurations for integration with things like LDAP and proxy Auth.

[saikarthik]

From my understanding:

Cloudron is based on node.js and uses the npm package Dockerode: https://github.com/apocas/dockerode

Dockerode uses the Docker API: https://docs.docker.com/engine/api/v1.37/

[jdaviescoates]

This is covered to some extent in this video presentation by @girish

https://videos.cloudron.io/videos/watch/206fc4b7-9641-4453-8be0-67450f2574b1

Here are the relevant parts of my notes on that:

@jdaviescoates said in How does Cloudron work? What does it do? etc :

== App Lifecycle ==

Install
-- Configure DNS
-- Downloads docker image and manifest file from the Cloudron app store
-- Sets up addons
-- Logrotate, Collect (stats about the app, how much CPU, memory it using etc), Firewall
-- Runs the docker container
--- Dynamic configuration (giving the app db credentials, SMTP credentials to send email, e.g. for WordPress it creates the wp-config.php file with all the relevant credentials)
-- Gets SSL certificates from LetsEncrypt (and set-up reverse proxy, i.e. when blog.domain.com is visited forward to this container)

Updates
-- Read only and stateless app containers (all apps are read only - apps cannot write to their file system, if they could then users could add all sorts of random files and it wouldn't be possible to update smoothly, the code cannot be modified. This means when there is an update we can just throw away the old container and get in the new container. So where does the app write stuff it needs to? We let the app write in 3 locations 1) /tmp for temporary files 2) /run which contains runtime files which an app needs to communication across various processes, 3) app/data/ where the app will put images, files uploaded etc - everything in app data is part of the backup, /tmp and /run is not backed up)
-- Rolling updates
-- Signed releases
-- Selenium based tests (test that everything actually still works)