It’s just that it requires a bit more work and understanding of how things work. Backup restore is more foolproof.
I guess we just agree to disagree then. I’d think if someone is competent to run multiple containers, they can run a few commands, and I don’t think those commands are harder to type than any of the
bin/rails c and start typing ruby commands all over here, or require meaningfully more or different skills than required to use multiple containers at all. But I’ll migrate the content to a separate new post rather than leaving it buried in a comment here.
That’s a reasonable argument. Maybe making the procedure seem more scary would keep those who done have the skills not give it a try.
…And, if they make a mistake, there’s no substitute for a backup before a migration! I hope I made that clear in my writeup now linked above!
There’s the flaw in your argument. Adding
2container to ./discourse-setup doesn’t include any measure of competency. There are a lot of people who run two containers simply because they see topics like this and assume there’s some secret sauce or it’s the “thing to do”.
The postgres 12 topic should serve as a cautionary tale when it comes to the added complexity. Using a backup as the step between states allows a user to revert to a single container by renaming a single file, once you start moving folders that simplicity is lost.
@Stephen There’s a flaw in your argument: The multi-container description is full of warnings that you have to take responsibility for updates and understand how it works, and the long description above is so obfuscated that probably anyone who looked at it would give up anyway. Go read my How to migrate quickly to separate web and data containers and tell me that it won’t scare away the people who will have trouble following it, or that it fails to emphasize the necessity of backup and ability to fall back to a backup if anything goes wrong!
I was deeply unhappy when I hit
./launcher rebuild app shortly after migrating to a more capable server (for a security fix) and having my site down for an egregiously long time, much of which was in rebuilding the postgres parts of the container. That was when I found the 2container documentation and this documentation and really didn’t want to take another 4 hour downtime to migrate, so I kept taking long downtimes for
./launcher rebuild app to avoid the 4 hours of downtime a restore would take. As a vaguely competent person, I was very annoyed for a long time that this configuration was effectively hidden.
The postgres 12 topic is a great reference, because people end up with more downtime because they have to rebuild the entire app multiple times, when they could be rebuilding only the postgres container twice. I can’t say I’ve read the entire thread due to the 6-day auto-delete thing but it’s not at all obvious to me that incompetent multi-container deploys are the, or even a, big problem there.
(Sorry, sometimes I get a little tired of the “all users are incompetent” around here.)
It may not make sense to you, but for those of us who have been here on meta for 6/7 years offering assistance to people in #support it will always make sense to have a rollback strategy.
Bugs do make their way into tests-passed, occasionally rubygems rate-limits impact rebuilds and even GitHub has had the odd wobble. For that reason alone I don’t see any value in making a state change which makes it more difficult to simply rename a file and
./launcher start app.
Your appetite for risk may be different, in which case you can take a different route. For those who regularly help pick up the pieces the current guide works well.
I don’t feel like you actually read the process I wrote, since you write as if I didn’t emphasize the need for the ability to do the restore. Please go read it and then come back and consider editing what you wrote to be a truthful statement regarding my instructions. As it is, I feel like you are 'splaining at me without doing me the courtesy of bothering to read what I wrote.
However, I have added many more additional warnings, including one at the top, in excess of warnings in this post which has been for five years and continues to be the canonical location for instructions on this migration process.
First of all, thank you for trying to clear this “jungle” for us, adventurers , i’ll probably be in your step in a few days…
What is in the multisite.yml file ?
I recently setup a self-hosted Discourse forum on a VPS. Uploads are being stored on Wasabi. Same for backups. Everything is hosted at Linode.
I used the standalone template and found the setup to be a breath of fresh-air compared to other software. It was sublime! A pure joy. I wish every open source project paid as much attention to install and setup as Discourse did.
Here the thing tough. I have a dedicated PostgreSQL running on a separate server only accessible via an RFC-1918 address that isn’t accessible to the Internet that I’d like Discourse to use. I’m not a huge fan of database servers running on the same server as the web/ application server.
So is there any way to separate the standalone database and move that over to my dedicated database cluster?
I’m assuming all I’ll need to do is to do a pgdump of the Discourse database, move it over to my dedicated database and restore, followed by a postgres vacuum analyze all tables after the restore/ import and then just point the Discourse app to the new database across the wire?
But I can’t seem to find where the database credentials are stored. I looked in app.yml but there doesn’t appear to be any database entries and when I looked in the …/templates/ folder none of the yml files had any database credentials it doesn’t look like.
Is what I’m trying to do even possible?
You can follow this guide that goes over setting the credentials:
Excellent! That is exactly what I was looking for. Thank you so much!
Now to get nginx to see the real ip behind CloudFlare…
If there are no credentials normally for the built-in postgres database is there a way to run a pgdump and dump the database from the standalone container?
The standard Discourse backup is a pg_dump in a tarball, so you can use that.
If you want to do something custom, like piping the dump across or a different format, you always can:
ssh root@forum cd /var/discourse ./launcher enter app su postgres psql # or pg_dump
Excellent. Nope that will be perfect. Thanks again! Very much appreciated.
The command is now
worked as expected just now
Good catch! Did it print a message that made it easy to figure that out?
I’ve been meaning to clean up this topic since they change.
Yes, very helpful thanks.
Are there any plans to migrate from the old “container links” thing to proper setup with a custom network with two containers being connected to it?
“Links” are legacy and may be removed in the future according to Docker docs
That sounds like a good idea.
Unless someone beats me to it, I’ll see about subunits /creating a PR to switch to networks and /or sockets (which some prefer anyway) and creating a howto to convert an existing setup to the new configuration.