Move from standalone container to separate web and data containers

Gemeenschaps wiki Systeembeheerders
, , ,
110

I assume it’s not strictly necessary to download it. Most people are running a single cloud instance, who may or may not have a backup S3 bucket. Downloading the backup would be the only way for this group to make an off-site backup, like you mentioned.

I would even go as far as to make an additional backup system on a completely different provider as well, especially after what recently happened to this open source dev. Regardless of its validity, it’s a great warning to have a weekly or monthly backup to an entirely separate storage location/provider.

1 like
111

Thanks @pfaffman for adding this, really painless now! (except for restoring a large backup which is always a little bit of a tense and long wait whatever the setup).

btw I think this path is incorrect: should be web-only (by default) I think?:

volumes:
  - volume:
      host: /var/discourse/shared/web-only
      guest: /shared
  - volume:
      host: /var/discourse/shared/web-only/log/var-log
      guest: /var/log

PS I’ve edited the OP accordingly

1 like
112

Yeah. web-only and that is a bit confusing when in every other context it is web_only. But perhaps when something is a directory or a container-what-ever is different thing.

What the I know… I just wasted 4 hours fighting with SearXNG and that should be 5 mins jobs (I really dislike docker things)

edit and off topic

Really :flushed_face: he and ck is a banned word? It was teached to us in school as a non-offended word. So, they were wrong, obvious :joy:

1 like
113

I think that might have been added when watched words were first being tested and just never got removed.

Yeah. I get confused about that often. In fact, I think that’s probably why once when I tried to just rename things to switch from single to double-container I got the underscore/dash thing wrong and it failed.

And worse, I am pretty sure it’s my fault. I got some error when I created the two-container option in discourse-setup (maybe containers couldn’t have underscores?) Ruby likes underscores in filenames, so maybe that’s why I used an underscore there? I think that’s it–and I think web_only can’t work as a docker container name since they also need to be valid hostnames.

1 like
114

I prefer hyphens in directory paths, so all good as it is, and underscore in the container name honestly, makes sense, so leave it as it is.

btw, I think there should be a title or a self-certified badge on meta for those rocking the two container setup :wink: Once you’ve been here for a year, I think it should be mandatory for your standard installs to be migrated. :rocket:

2 likes
115

If not for so much existing documentation about the single-container setup, I’d almost argue that it should be the default, though there’d need to be some tooling to let people know that the database might need attention, or something.

I often see lots of people unhappy about and otherwise scared of two-container installs. (Recently someone wanted the two-container install I’d create when I did their install moved to a single container, for example.) It’s so very rare that it’s a problem, and the one time that it causes problems, it actually saves some hassle since it makes it easy to put off a Postgres Upgrade until you’re ready to do it. You can usually put off a PG upgrade for a good while (except when the AI plugin got added to core and required that extension).

2 likes
116

mijn back-ups begonnen te falen na dit:

[2025-09-09 09:34:50] Creating archive: blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] Making sure archive does not already exist...
[2025-09-09 09:34:50] Creating empty archive...
[2025-09-09 09:34:50] EXCEPTION: tar --create --file /var/www/discourse/public/backups/default/blah-forum-2025-09-09-093246-v20250828181952.tar --files-from /dev/null
tar: /var/www/discourse/public/backups/default/mvertigo-org-vestibular-disorders-support-forum-2025-09-09-093246-v20250828181952.tar: Cannot open: Permission denied
tar: Error is not recoverable: exiting now

als ik naar de permissies kijk vanuit de web_only container:

/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep  6 12:37 default

als ik naar een ander exemplaar kijk, is de eigenaar anders:

/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep  9 03:46 default

wat is hier misgegaan en wat moet ik veranderen aan die map voor de web_only container - moet het hetzelfde zijn als voor een standaard installatie?

117

tl;dr maybe try

docker exec -it web_only bash
chown  -R discourse:www-data /shared/backups

And more words.

Without looking, I’d next try rebuilding the data container, hoping that whatever change was made also got made to (or affects) the data container.

The bad-advice answer is to make ...backups/default world writable and seeing the ownership of the backup.

So I think what you want to do is chown default to discourse.www-data in the web container (that’s the one doing the backups).

Here’s a recent single-container:

root@forum.mbse-capella.org(app):~$ docker exec -it app  bash
root@new-app:/# grep www /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
root@new-app:/# grep discourse /etc/passwd
discourse:x:1000:1000::/home/discourse:/bin/bash

At some points in the past the build process would chown all the files, but it can take a really long time, so I think that may have been removed at some point (this is more than a feeling than anything based on paying attention to commits).

1 like
118

this is equivalent to ./launcher enter web_only?

119

Mostly. ./launcher will do a git pull (at least I thought so, but maybe not?) first and you’re more likely to have tab-completion working for docker than ./launcher.

1 like
120

Het plaatst je ook in de root, terwijl de launcher je in de discourse-directory plaatst

1 like
121 
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep  6 12:37 default

that seems to make the right tweak, so lets see how we get on with next backup, thanks!

1 like
122

Je kunt er nu een uitvoeren vanaf de opdrachtregel of de UX om te zien of het werkte.

Ook, als ik slimmer was geweest:

docker exec -it web_only bash -c "chown -R discourse:www-data /shared/backups"
1 like
123

Ik was geduldig en wachtte op de geplande taak (maar het documenteren daarvan is erg nuttig!) en dat lijkt te hebben gewerkt, dus veel dank voor uw hulp @pfaffman

124

That’s how we’re different.

Yeah. There used to be a chown that ran every rebuild, I’m pretty sure. It can take a while, and is almost always superfluous (except when it’s not). It doesn’t have anything to do with one- vs two-containers. I think it has to do with moving from one version of Debian for the base image to another version and the new version has differnt user mappings than the old one did.

1 like
125

Is docker_manager plugin not useful in this setup? - it’s always telling me to rebuild app!

126

I’m not sure what “this” is but both this topic and the one that I refer to are for a Standard install, so docker_manager works as normal.

Docker_manager isn’t related to the process of moving to another server, as you’ve got to build a new container.

It should force you to build a new app when there’s a change to the base image, which I think has been happening a fair amount lately. TBH, I’ve not quite figured out the mechanisms at play there.

127

so how I found this was after a bootstrap of web_only and replace (destroy, start) I went to update after a single plugin change, only to be prompted to rebuild app!

1 like