Creating single docker instance with exchangeable data volumes


(Jeffrey C Witt) #1

So I don’t know if this is a weird (or unusual) idea or not.

But I’ve been using Discourse for a discussion board in my classes this semester. These classes change every semester, and I’d generally like to create a fresh discussion for each new class.

Ideally, what I’d like to do is keep an existing web container running and just exchange a data volume with a new one (let’s a say a kind of bare bones postgres template for the start of a new course).

This might also be useful if I wanted, quickly reload an old discussion board from a previous year — perhaps I want to demonstrate to someone an exciting class discussion board from three years ago. In such I case I would like to be able to make a quick change to data.yml file and then rebuild see the discussion board exactly as it was at the end of that older semester. Then, of course, I’d like to be able to quickly switch back. (Obviously, this would mean that the current discussion board would be done for a while – but that’s fine in my case, because we take breaks between each semester :slight_smile: )

So here’s my concrete suggestion:

Would this be as simple as creating a new volume in the data.yml file for each new class I want to create.

So for example, let’s say I want to make a new discussion board for the Spring2014 and I name the data volume Spring2014 in the data.yml taken from the sample folder.

volumes:
  - volume:
        host: /var/discourse/shared/Spring2014 #I've changed this from `data` to `Spring2014'
        guest: /shared
  - volume:
        host: /var/discourse/shared/Spring2014/log/var-log #same change here `data` to `Spring2014'
        guest: /var/log

Then could I just run:

cd /var/discourse
./launcher bootstrap data
./launcher start data

I would expect this to create a data volume in /var/discourse/shared called `Spring2014’

At this point, would I even need to make any changes to web container?

Then, each semester, I could just modify the data.yml in this way to create the next class ‘Fall2014’ etc. And if I wanted to revert back to old instance, could I just supply the name of older class already existing in the /var/discourse/shared folder?


One final wrinkle, assuming the above is even close to correct: this semester I ran a multisite config, with a separate data and web container. But despite having, two databases for two sites, only one data volume was created, let’s call this /var/discourse/shared/Fall2014' (even thought right now it is really 'var/discourse/shared/data). Is it correct to think about a multisite configuration as really having only one data volume, even though there are two separate databases?

If so, in terms of the idea sketched above, it would be important for me to identify that this volume was created by a multisite config, because, if I ever wanted to re-launch it, I would need to use a different data.yml and web.yml file especially configured for multisite use. Maybe it should be called var/discourse/shared/Fall2014-multi so that I know I should run a separate data.yml and web.yml file configured for multisite. Even here though I would need to be careful, because while in a single config the first and only database name defaults to discourse, in a multi-site set up, I’ve created a second database name that needs to match up with the database in the Fall2014-multi' data volume. (This is also true for theweb` only container in which the second database also needs to be named.)

Perhaps in this case its best to create a different image file for each semester, (i.e. Fall2014-multi.yml) rather than trying to modify a single data-multi.yml and ‘web-multi.yml’ to be re-used each semester.

Thoughts.


(James Milligan) #2

Why not use categories?
2013-14
– Class 1
– Class 2
2014-15
– Class 3
– Class 2


(Jeffrey C Witt) #3

That’s a possibility – then data from previous classes is all part of one big discussion board. Usually, I like to create an closed internal discussion for each class. It’s something to think about though.


(Jeff Atwood) #4

You could also use the Admin, Backups web interface to export all the data, then drop in a new blank backup at the beginning of each semester.