Proper Procedure for Upgrading Discourse Docker Container


(Will ) #1

I’m currently running version 1.4.0.beta2 on an AWS-EC2 instance inside of a single Docker container (per instructions found here).

What is the safest way to go about upgrading to version 1.5.0? If something goes wrong is there a quick and easy way to switch back to the previously working version?

From other threads that I have read on the topic, as well as the included README file, it looks like the following is the suggested method of upgrade:

cd /var/discourse
git pull
./launcher rebuild $appname

However, if this were to fail; what would be the quickest/best way to roll back to the previous working version? Should I re-instate my EC2 instance from a snapshot? Is there a way to quickly rebuild the container referencing the old image or image layer?


(Jim DeLaHunt) #2

I’m interested in the answer to this also.

I don’t yet use Discourse. I’m stuck with shared LAMP hosting right now, so I can’t host it. And my community is new and small enough that I don’t want to put out the money for hosted Discourse at the moment.

However, I understand (I think) how packing Discourse as a Docker container makes the first installation easier. I love that I can test a container on a test environment first, before deploying to production. But I also believe it doesn’t make later upgrading and bug fixing any easier. You are essentially upgrading the components of Discourse in situ on the production server.

It’s not possible to deploy the new Docker container of Discourse (and PostgreSQL and Ruby and etc. etc.) to the test environment, then deploy to the production environment while seamlessly migrating the contents of the old database to the new container, right?


#3

You should upgrade from admin/upgrade if at all possible, but I think going up to a new release version requires the git pull. If there’s an error generally a rollback will trigger, but if that fails a sure way to get back in order is to bootstrap a new app.yml on the 1.4 (stable) branch, upload your backup, and restore.


#4

Are you asking if you can take a docker discourse install on one server and migrate it to another? The answer would be yes. Make a backup and restore it to your production rig.


(Jim DeLaHunt) #5

Almost. One level of my question is, is it possible to take an old full docker discourse install in one container, and migrate the data to a new full docker discourse install in a second container, seamlessly?

It looks like this howto: Configure automatic backups for Discourse explains how to do backups and restores from the Discourse admin panel. I think it assumes that the version of Discourse doing the restore is the same as the version which did the backup, however. When upgrading the Discourse install, that assumption doesn’t apply.

And, how brief and seamless is the backup and restore process? Will it be transparent to my users? I suspect the process might take minutes or hours, so I’d have to take the forum offline, right?

The deeper level of my question is, does Docker packaging provide the same benefits when upgrading an existing forum as it does when deploying a new forum? I think the answer is: it’s easy and reliable to deploy the new forum, but you must pay a cost of taking the forum down for a backup/restore, and you have the risk that backup won’t capture some settings or uploaded content from the old forum and you’ll have to clean that up somehow.

Does that deeper question seem clear? Do you have any thoughts?

I’d love to hear from people who have upgraded a production Discourse forum to a Docker-installed new version. What was the experience like?


#6

This all depends on how you go about it. If you’re on a docker install you should be able to upgrade from admin/upgrade, but again I’m not certain you can upgrade all the way from 1.4 to 1.5, it would at the least depend on which branch you’re setup with in your app.yml file. If you go through the admin/upgrade, then the process is seamless. There instance will go into read-only mode, but still be accessible.

Going about it with multiple containers for the same instance, I would think confliction would arise in bootstrapping the second. I might try to spin up a test droplet, and go through a trail run to see what happened. Honestly, though. The easiest approach might be to just wait until you know traffic is at a minimal (like 3am or 3pm if they’re vampires), copy the app.yml, change the shared directory structure, stop the original instance, and bootstrap the new one. Total down time would be about 5 minutes. If there’s any issue stop the new, start the old. Total time out for this kind of roll back would be about 20 seconds.

Oh wait, you’re not even on discourse yet. If you want the least amount of downtime for any kind of upgrade or change in your containers, then just use the separate web and data containers. You have minimal downtime through updates and upgrades.


(Jim DeLaHunt) #7

Thank you for the insights, @webeindustry . I’m not actually adopting Discourse at all yet; my only hosting options for it would cost more marginal dollars than I want to devote to it right now. I’m fundamentally wrapping my mind around the pluses and non-pluses of Docker packaging.

However, your answer might be exactly what the original poster @will224 was looking for.


(Erlend Sogge Heggen) #8

Official howto here:


(Erlend Sogge Heggen) #9