Staging environment for custom apps

[ekevu123]

When I want to update a custom app but make sure there's no deployment-related issue, I have too choices on Cloudron:

• Update my app, hope for the best and revert immediately using backup (easy, but causes 1-2 minutes of downtime)
• Create a second app for staging only, test it there, and if needed, push again to production

Suggestion: Introduce a staging environment for custom apps

1. Under the hood, this is another custom app in cloudron, but the UI treats it differently
2. I install it using cloudron update --staging for my app
3. I can reach it under a staging domain
4. If I am happy, I can push a button (or run Cloudron CLI) to direct traffic to the new app instead of the previous one. Ideally, staging becomes production and old production gets deleted to reduce downtime, but I haven't thought this through.

Benefits of this approach over the current one:

1. I don't have to create two apps for the same thing, because logically, this is one app in different states
2. Hopefully, this approach could reduce downtime

[robi]

Even if the UI did this as one App, under the hood it's still two completely different containers, environments and apps.

[ekevu123]

Yes, but that doesn't matter much, there could be some UI and CLI shortcuts implemented around it.

[humptydumpty]

The whole switching thing sounds unnecessary. Why not have a "sync" button to keep the staging site up-to-date with the production site for future testing?

[scooke]

Naaah. If you want to use custom apps there are lots of options built just for that for you to have fun with (easypanel, runtipi, yunohost, etc.). Cloudron is for Cloudron-prepped apps; they admire the tinkerer mindset and graciously leave it open for those who can tinker to do so. I don't think they need to formalize/code-alize this option any more than they have.

I just noticed there isn't a downvote option.

[robi]

CCAI is good for staging

[humptydumpty]

@scooke the feature request is valid for CR packaged apps too. I know I would use it with my WP sites. It would be great if I could simply sync the production and the dev sites as needed whether it’s for testing a new update before rolling it out, updating the site content, or applying a new theme. A simple overwrite will do even if it’s done from a backup and not from the live site. That’s still many steps less than going thru a new app install > import from a backup workflow.

[ekevu123]

@scooke said in Staging environment for custom apps:

Naaah. If you want to use custom apps there are lots of options built just for that for you to have fun with (easypanel, runtipi, yunohost, etc.). Cloudron is for Cloudron-prepped apps; they admire the tinkerer mindset and graciously leave it open for those who can tinker to do so. I don't think they need to formalize/code-alize this option any more than they have.

I just noticed there isn't a downvote option.

For me, the purpose of cloudron is to let me run popular open-source apps next to my own ones without the need of an additional server. If that's a minority opinion around here, I gladly retract my suggestion, but I don't think just saying "I wouldn't benefit from this feature" is a reason for not letting others have it.

@humptydumpty said in Staging environment for custom apps:

The whole switching thing sounds unnecessary. Why not have a "sync" button to keep the staging site up-to-date with the production site for future testing?

I am with you here. Let's see it more as an open discussion how staging vs. production could be simplified (if needed).

[timconsidine]

I only partially understand the problem here.
Whichever way you look at it, there has to be 2 containers.
I don’t often have the need, but when I do, I install the staging app to ‘zzz.domain.tld’ and when I am happy it’s ready, I change the production deployment ‘app.domain.tld’ to ‘vXX.domain.tld’ and change ‘zzz.domain.tld’ to ‘app.domain.tld’. Staging is now live and I can archive or uninstall the previous version.
No re-pushing of images or apps.
Change of url much faster.

I don’t see that writing an interface around this process is worth the effort, but hey, if that’s what others want, I have no beef with that.
I just think there are higher priority wish list items.

[scooke]

Along the same lines as @timconsidine 's input, there is already a Docker app, which can be used to deploy the app in progress, and then use his suggested mode to move it to production; or restore to the production domain from a backup of the dev app.

So, I'm not on Staff, I can only go by what the website says and what I've read on the Forums, and if this drives your business away @ekevu123 ... Sorry Cloudron team! But the website says, "Complete solution for running apps on your own server", not, "Complete solution for running your own apps on a server". Like I said, there are other options that are more openly and purposefully built for that (and suck, unless you are a top dev). Cloudron lets me run apps, which I've chosen from the ones they've prepared, on my own server. I could see that the Introduction section of https://docs.cloudron.io/ could make one think that "apps" means ANY app, but it more directly means the apps in the app store.

On the home page of Cloudron there is one text, "Users can use the dashboard to access their apps." which again could be understood to mean ANY APP, but then further down we read "We put great effort into our app packages" which makes it clear that the apps are prepped BY Cloudron. So, your assertion that "the purpose of cloudron is to let me run popular open-source apps next to my own ones without the need of an additional server."* is not correct. You could say, "the power of cloudron allows me to run popular open-source apps next to my own ones without the need of an additional server and with the help from the Forum."* but like I said, this is a community-appreciated ability generated by the goodwill of the Cloudron team. There have been many who assume that whatever they want should be allowed, squeezed in, coded for, and to a surprising degree Cloudron devs really listen and implements some of these.

You really don't need to retract anything. You suggested something, some others suggested alternatives, I suggested it wasn't needed. This is all discussion about Cloudron. If the Cloudron Team wants to add this stuff, I won't stop them... but the amount of work they already do to have gotten us all this far, and keeping things stable, just to add a fringe request which ppl think will be "simple" "logical", just some shortcuts... oh man, much much more than that is involved to keep the Cloudron system as good and secure as it is. And different apps will need different approaches for a staging level, dbs, backups, domains, proxies or not, visible or not, email or not, Now the Cloudron Team is coding solutions for these apps, something the app's developers should be doing!

*I don't get the deal about the need for an additional server. Do you mean you run a server with Cloudron on it, AND a second (or more) server with the apps that Cloudron doesn't have, or the dev apps you have, and you wish you didn't need that second server? I myself have 3 additional servers running apps that Cloudron doesn't have. Some of the apps are on the App Wishlist; I understand why they haven't prepped them. I am excited by the prospect that I could prep them (but I lack the dev chops). Such is life.

[humptydumpty]

@timconsidine the staging site is persistent as it’ll always be used to test updates or any changes before deployment. Having two apps/containers is not an issue but I’d like to have a faster way to sync between the two. A selection box to sync a to b or vice versa will do. In the back end is it’s achieved by relying on the latest backup, that’s fine too. This request is definitely in the advanced category right beside high availability. But we know the staff’s opinion on HA so yeah i don’t see this gaining any traction either. One can hope though.

[nebulon]

I am not 100% sure what the proposed solution here is, but sounds like a simple shell script wrapper around the cloudron cli achieves that already?

Essentially this would be:

1. backup prod app
2. clone from prod backup to staging
3. update stating app instance
4. test
5. if test is good, update the prod app

Is there anything missing from this?

[humptydumpty]

@nebulon spot on. Your shell ui proposal flew over my head but yeah in essence I’m looking for a shortcut/speed enhancement.

[ekevu123]

@timconsidine If you use the cloudron database add-on, the data wouldn't be transferred this way.

@nebulon said in Staging environment for custom apps:

I am not 100% sure what the proposed solution here is, but sounds like a simple shell script wrapper around the cloudron cli achieves that already?

Essentially this would be:

1. backup prod app
2. clone from prod backup to staging
3. update stating app instance
4. test
5. if test is good, update the prod app

Is there anything missing from this?

I can't say for sure, I kind of wanted to start a discussion first and see if other users have the same problem.

[timconsidine]

@ekevu123 I think we have a different understanding of staging.
No point in testing an app before promotion without real data.

[ekevu123]

@timconsidine said in Staging environment for custom apps:

@ekevu123 I think we have a different understanding of staging.
No point in testing an app before promotion without real data.

Sure. I assumed you wanted to say that you install a second app, and then swap domains between the original and second app, which would mean that the second app without the data becomes production.

Maybe I misunderstood?