Set up a staging server

That is kind of the point of the setup above; it is super useful to have the staging server pointing at the same bucket as this makes it much easier to keep them in sync.

However, you don’t want it contributing any backups automatically (or deleting any) - hence these is turned off by these settings:

Agree that the CDN needs to be turned off for your staging site. I haven’t messed with that myself, but once you work how to do that please do update / add to the wiki in the OP.

2 Likes

Thanks, Nathan. I saw mention of S3 backups making things easier but a backup is different to the site assets so I wasn’t sure.

I’ve already turned off backups and emails so all good there. I’ll get on with pointing the staging server to the existing bucket and make sure it isn’t using the CDN.

1 Like

Sharing backups is really nice because it makes it easy to copy your production database to staging.

2 Likes

I plan to create a mirror of my production Discourse by using the rsync method.

I have a couple of other web sites which integrate with Discourse, so having the dev/test versions of those sites being able to hit and interact with a dev/test/staging version of Discourse would be ideal.

Therefore I would only power it on when needed, and I would restore a database backup of my PROD on to my STAGING periodically - not daily and maybe as little as once per month.

If I do this, how do I stop it changing some settings back when I do the database restore? :thinking:

These for example, would be invaluable:

Is there a way I could restore a database backup and then maybe manually apply some settings before starting Discourse? Any other ideas, suggestions, gotchas? :thinking:

If you keep backups on S3 and configure that via ENV variables, then you can pretty easily spin up a new site that can restore that backup. Just spin up a new VM, clone discourse, copy the yml, rebuild and restore. You can override settings in the database with ENV variables as in the quote in your post.

3 Likes

Perfect, it sounds almost too easy :smiley:

2 Likes

Am I missing a step? I’m pretty sure this worked a year ago or so. But now, while it does populate, it doesn’t add any Topics or posts beyond the About the Category… has something changed?

When I tried it just now, it created group and user records, but when creating categories failed with

ActiveRecord::RecordInvalid: Validation failed: Category Name has already been taken (ActiveRecord::RecordInvalid)

It seems like it should be smart enough not to try to create a category with an existing name.

Mine was not an empty site, however. There is also a dev:repopulate task, which first wipes the database.

1 Like

Thank you Jay! Here’s a screen showing what I tried… It looks like I need to be in “development environment”. How do I enter that?

I ended up restoring an old backup from one of my discourse instances where I had previously used this method to populate. I had to do this, but it worked.

There’s a thing you have to do to be able to drop the database. If you do the db:drop rake task it’ll tell you what it is. So I guess you’d need to sv stop unicorn and then drop, create, and migrate the database before running the task. Or that’s the next thing I would try, but you’ve got another solution…

1 Like

14 posts were split to a new topic: Change server to a 2-container setup

I’m trying to seed test data on my staging server, but I get an error:

rake aborted!
Database commands are only supported in development environment

This is on a multisite setup, so the commands I’m running are:

./launcher enter web_only
ALLOW_DEV_POPULATE=1 bundle install
RAILS_DB=instance-x ALLOW_DEV_POPULATE=1 rake dev:populate

Which I’ve been using without issues so far, but now I get this error. Can I set an environment variable to allow database commands in production?