Migrating an old Discourse install to Docker


(Sam Saffron) #1

Deploying Discourse on Docker is currently our recommended setup. It avoids many pitfalls installations have, such as misconfigured nginx, sub-optimal Ruby defaults and so on.

The Docker based setup ensures we are all on the same page when diagnosing installation issues and completely eradicates a class of support calls.

Today, all sites hosted by Discourse are on Docker.

This is a basic guide on how to move your current Discourse setup to a Docker based setup.

Getting started

First, get a blank site with working email installed. Follow the guide at GitHub - discourse/discourse_docker: A Docker image for Discourse and install a new, empty Discourse instance.

Tips:

  • Bind the web to a different port than port 80, if you are on the same box. Eg:

      expose:
        - "81:80"
    
  • Be sure to enter your email in the developer email section, so you get admin:

      env:
        # your email here
        DISCOURSE_DEVELOPER_EMAILS: 'my_email@email.com'
    
  • Make sure email is setup and working by visiting /admin/email and sending a test email.

  • Make sure you have can enter your container ./launcher enter my_container must work.

If any of the above is skipped your migration will fail.

At the end of this process you will have a working website. Carry on.

Exporting and importing the old site

  • Ensure you are running the absolute latest version of Discourse. We had bugs in the export code in the past, make sure you are on latest before attempting an export.

  • On your current instance

    • go to /admin/backups and click on the button.
    • once the backup is done, you will be able to it.
  • On your newly installed docker instance

    • enable the allow_restore site setting
    • refresh your browser for the change to be taken into account
    • go to /admin/backups and your backup.
    • once your upload is done, click on the button
  • Change port binding so its on 80

  • Rebuild container ./launcher rebuild app

Yay. You are done.


Should we switch to Docker?
Install Discourse in Under 30 Minutes
Discourse Installs for Non-Profit and Education
Upgrading from Discourse 0.9.9.5
Migrating assets from old installation into docker
Upgrading from a release way in the past
Directory of public discourse sites, or, where are my new users coming from?
My discourse is going crazy. I need to hire someone who can help!
Transitioning to Docker
Problems sending email through sendgrid
Time is not correct after new installation and data restoration
(Kane York) #2

For some reason, I was about to start a topic for this exact same purpose. And then you made this public. How did you read my mind? :stuck_out_tongue:

Here’s an imgur album with screenshots of the Export/Import process, in case anybody’s a more visual learner: Imgur: The magic of the Internet

Also, once you have done a successful restore (which is what you do in this guide), the button in the Backups tab will be enabled. You’ll have to re-enable allow_restore to use it.


(German Viscuso) #3

/admin/backups is available starting in which version?
I want to to migrate to an empty Docker based instance from a 0.9.7.8 instance.
If this possible?
One more question, is CentOS out of the question for running Discourse under Dockers?
Thx


(Jeff Atwood) #4

The first step, per the above instructions, is to update to the latest version of Discourse.


(German Viscuso) #5

Done! The upgrade wasn’t so bad after all (pretty straight forward).
Now running on bleeding edge!
@codinghorror How did it go the meeting in Madrid, still in town?
Best


(German Viscuso) #6

I have a problem with the schema dumping from your backup script. pg_dump works for user discourse from the command line but not from your script:

[2014-02-28 05:18:57] sh: pg_dump: command not found
[2014-02-28 05:18:57] EXCEPTION: pg_dump failed

Is it a cron job?
Best


(Sam Saffron) #7

Interesting, @zogstrip will have a look


(Archon) #11

I have uploaded my backup but it still says ‘No backup available.’

EDIT: An older backup worked.


(Graeme Stuart) #12

Should I not enable read-only mode before running the initial backup to avoid users posting during the upgrade?


(Kane York) #13

Backups automatically enable read-only mode when they begin.


(Graeme Stuart) #14

OK, but what if my users post after the backup is completed? Only the backup will be moved to the new install.

Are you saying that read-only mode is left on after a backup is completed and would need to be manually turned off to allow users to post? Or would read-only mode be disabled automatically when the backup is complete?


(Kane York) #15

Yeah, this is what happens. You can click the button to reenable read-only, though, and there probably won’t be a post submitted in the meantime :wink:


(Graeme Stuart) #16

Without labouring the point too much, if I want to move my data to a new install, I would want to enable read-only mode first, then takes a backup and move the data to a new install. At no point would I want users to have access to writing data to the original copy of the data.

So, with this in mind, if read-only mode is enabled prior to taking a backup, will it be automatically disabled once the backup is completed? If so, this is a bug IMO.


(Régis Hanol) #17

Backup/restore operations used to always enable read-only mode when they start and disable it when they finish.

Agreed and fixed :wink:

https://github.com/discourse/discourse/commit/d23585e444edb18210b22d1d5d33f6520187563a


(Kane York) #18

Tip: Be sure to disable the old services before rebooting…

update-rc.d -f nginx disable
update-rc.d -f postgresql disable
update-rc.d -f redis-server disable

(Once we get systemd in 15.04, that’ll be systemctl nginx.service disable I think ;))


(dirkcuys) #19

I’m responsible for discourse over at http://thepeople.p2pu.org. We are running version 0.9.7.8 in a pre-pre-docker environment.

I tried setting up a new discourse instance with docker, grab the database from the old installation, load it into the docker db and then rebuild the docker image to rerun the migrations on the old database. Unfortunately that crashed and burned. So much wasted caffeine.

Now, I may have done something wrong in that process. In fact, I’m hoping I did something wrong. Are there other important places where data also lives? Redis? Should I manually run the migrations? Would the migrations work from any old version of the database or am I just being optimistic?

I guess this would be my last resort. And it would probably be more like: recreate the old environment, update to latest, fix what breaks, export.

Any suggestions, or do I need to print myself a teashirt saying: “they told me it was pre-alpha, but it looked cool and worked…”, suck it up and do the dreaded update of the old environment?


(Kane York) #20

Yes! You need to an incomplete upgrade, and run the migrations before taking the backup. (Incomplete, as in, don’t bother precompiling assets because you’re not going to start the web server.) Use script/discourse backup to take the backup, then download it using SCP.

I actually just did this for @cyanbane - Discourse Meta


(ben_a_adams) #21

I have allow restore set in settings:


However the restore button won’t allow me to click it:

Anything else I need to set?


(Sam Saffron) #22

reload the page :slight_smile:

sorry, we got to fix this some time @zogstrip


(ben_a_adams) #23

Works, thank you :slight_smile:

Aside: Odd that something that we are used to trying on web pages we forget to try on web apps.