How updates work?

[nebulon]

App updates are isolated to the app instances. So if a new app update is published (essentially a new docker image + maybe updated cloudronmanifest) then the old container is deleted and replaced with a new container from the new image. That new container will be setup and configured with the addons specified in the manifest. Addons are for example databases, see https://cloudron.io/documentation/custom-apps/addons/
But also a data folder, when localstorage addon is used will be mounted at /app/data

The app has to be packaged in a way to pickup the addon (eg database) credentials dynamically. Those may or may not change during app restarts.

This is one of the reasons we have addons in the first place. The platform can managed associated databases and knows how to backup and restore a database (postgres, mongo, mysql, .. all do it differently)

Now as far as I understand your case, you set out to package databases on your own and then maybe package other apps which will be setup to use those database instances. This however will break in various ways. One is the mentioned backup/restore. Think about an app update which fails midway during database/table migration. Now you want to restore to the previous version and thus also the database has to be restored properly as it might be in some unknown state. This is why those things have to be tied together. Another breakage could arise from the fact, that the database instance might be relocated to another domain, in which case the app has to be reconfigured/restarted automatically.

Generally if some other database engine is required, which is not available as an addon, then it has to be part of the app instance itself. This is a lot more trickier though if a backup of such a database requires code to be run to dump tables or such prior to a backup.

[girish]

@roru2k20 said in How updates work?:

I hope I don't get on your nerves with my amateur bungling ;-),

Not a problem at all. In fact, I think it's helping us create valuable content and also helping us figure what kind of tutorials we need to create for new comers. Thanks and please don't hesitate to ask!

[roru2k20]

@nebulon Thanks!!!

I think my question came out wrong. My question aimed to understand the different files in a package.

My first three apps was only a test, if I can package installable apps with easy configuration and thought Database server was relatively easy for me. Some beginning problems, but possible for me.

Now I would like to go up to next level and pack Shopware. A more complexity app.

Did you mean that Cloudron make a backup from all data, cleanup old version, install the new version and afterwards it restore the old Database to the new Version?

[nebulon]

From the view of an app packages it can viewed as this. For practical purposes the platform skips a few steps to speed things up, but essentially yes the whole app data is saved, then everything torn down and then rebuilt with new version and old saved data.

This then just means that a regular app restore flow behaves the same way only with other saved data.

[ultraviolet]

What are the commands to update an app?

In my testing I am trying to update my own package a fresh container pulls the new version, but, when trying to update the current image or prod app it does not take the new version of the app code.

[girish]

@ultraviolet I guess you want cloudron update --app xx ?

[d19dotca]

@girish am I right in understanding that when updating a custom app we have to do it per app. In other words, it's different than when Cloudron team pushes a new WordPress app update for example and how it then applies to all apps using that same image, in the case of custom apps we have to deploy manually to each app using that custom image? Or have I misunderstood?

[mehdi]

@d19dotca Yes that's right. And this system is quite useful actually, when you want to test the new version of your app on once instance before deploying it to the others.

[d19dotca]

@mehdi Darn. Thank you for confirming though. I can see how that's be useful in some circumstances, but if I made a custom Wordpress app (which I'm considering doing, been on the backburner though), I wouldn't want to have to manually update 18+ app instances of that image one at a time.

I'd have hoped for the same behaviour as happens when Cloudron pushes out app updates. In such a case, a new image would be pushed, but it wouldn't auto-update until the scheduled time in Cloudron, giving me plenty of time to manually apply the updates as needed on a few test sites first, and the rest can be auto-updated per the schedule. That'd be how I'd love to see it work in the future.

[mehdi]

@d19dotca I disagree with you. I think the current behaviour is just fine. If you need to regularly push a custom-app update to 18+ instances, it's really easy to write a script that does it in one line, in just a few minutes.

[d19dotca]

@mehdi To be clear, I agree that it’s “just fine” too. It works and it gets the job done. That’s the main thing after all - that it works.

I just would have expected the behaviours to match between when we deploy a custom app update and when the Cloudron teams deploys an app update, if nothing more than for consistency sake. That would be my preference too.

I’m really happy with how app updates work when pushed from the Cloudron team, and I see no reason why we shouldn’t have that same capability. I’d love to execute my custom app updates in the same manner. Maybe there can even be a switch in the CLI for whether to make all apps aware of the updated image or just one app so we can get the best of both worlds.

You don’t necessarily have to agree, just giving my two cents on what I’d like to see and why.

[Lonkle]

@d19dotca I definitely see a case for making it optional especially because then it helps those of us who want to build our apps for the Cloudron App Store to test updates out and have them deploy exactly the same as official App Store apps.