Multi-Container Install - Redis

(keelan) #1

I’ve set up a multiple container install, using an external postgres DB (actually a paid), and a couple Discourse servers. I’m using Gluster to synchronize the uploads directories of the two app servers. Right now, I’m running a Redis instance per app server, and things seem to work except that each of the two app servers maintain independent sessions; meaning that if I use non-sticky load balancing, things will get sketchy.

Do matters pertaining to sessions live in the Redis DB? Would it make sense to pull the Redis instances out of the web servers, and make a separate Redis server? How are y’all handling high availability in those scenarios?

(Sam Saffron) #2

One redis for one discourse setup is CRITICAL. Stuff will get very weird very fast if you fragment redis.

Redis does not contain any non-recoverable data, so on disaster you can just spin up a new redis instance.

(keelan) #3

Ah, excellent. That makes a lot of sense and simplifies things for me. Tried it out and the level of coherence has increased to 100%.

(keelan) #4

Alright, on to the next problem. It looks like /var/www/discourse/public/assets will need to be… umm… glusterified… in order for non-sticky load balancing to work, is there anything in this directory that isn’t ‘disposable’? I could just blow it away and test the theory, but that’s losing it’s fun-factor at this point.

(Sam Saffron) #5

Assets does not need to be glusterfied. just the “uploads” and “backups” directory.

When doing multi host stuff it is critical all hosts use the exact same image so all precompiled assets will be carbon copies.

(keelan) #6

Ah, I see. I’ve been separately bootstrapping two Discourses (Discoursen? Discoursi?), so they end up with different precompiled assets. Thanks!