Move from standalone container to separate web and data containers

Я предполагаю, что загружать его не строго обязательно. Большинство пользователей запускают один облачный экземпляр, у которого может быть, а может и не быть резервной копии в S3. Загрузка резервной копии была бы единственным способом для этой группы создать резервную копию вне сайта, как вы и упоминали.

Я бы даже пошел дальше и создал бы дополнительную систему резервного копирования у совершенно другого провайдера, особенно после того, что недавно произошло с этим разработчиком с открытым исходным кодом. Независимо от достоверности этого случая, это служит отличным предупреждением: нужно делать еженедельные или ежемесячные резервные копии в совершенно другом месте хранения или у другого провайдера.

1 лайк

Спасибо @pfaffman за добавление этой функции, теперь всё действительно стало проще! (за исключением восстановления большой резервной копии, что всегда немного напряжно и долго, независимо от настройки).

Кстати, я думаю, что этот путь указан неверно: по умолчанию должно быть web-only, верно?:

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

PS Я соответствующим образом отредактировал первое сообщение темы.

1 лайк

Да. web-only, и это немного сбивает с толку, так как в любом другом контексте используется web_only. Но, возможно, когда речь идёт о директории или контейнере — это что-то другое.

Что я знаю… Я просто потратил 4 часа на борьбу с SearXNG, хотя это должно было занять 5 минут (я действительно не люблю вещи, связанные с Docker).

редактирование и оффтоп

Правда :flushed_face:? Слово «he and ck» запрещено? В школе нас учили, что это не оскорбительное слово. Значит, они ошибались, очевидно :joy:

1 лайк

Думаю, это было добавлено, когда впервые тестировали функцию отслеживания слов, и просто так и осталось.

Да, я часто путаюсь в этом. На самом деле, думаю, именно поэтому однажды, когда я пытался просто переименовать вещи, чтобы переключиться с одиночного на двойной контейнер, я ошибся с символом подчёркивания/тире, и всё не сработало.

И что ещё хуже, я почти уверен, что это моя вина. При создании варианта с двумя контейнерами в discourse-setup возникла какая-то ошибка (возможно, контейнеры не могут содержать подчёркивания?). Ruby любит подчёркивания в именах файлов, поэтому, возможно, я использовал именно их? Думаю, так и есть — и, похоже, web_only не может работать как имя контейнера Docker, поскольку они также должны быть допустимыми именами хостов.

1 лайк

Я предпочитаю дефисы в путях к каталогам, так что всё отлично. Честно говоря, нижнее подчёркивание в имени контейнера имеет смысл, поэтому оставим как есть.

Кстати, я думаю, что на meta стоит добавить заголовок или значок самоподтверждённого статуса для тех, кто использует настройку с двумя контейнерами :wink: Когда вы будете здесь год, я считаю, что миграция ваших стандартных установок должна стать обязательной. :rocket:

2 лайка

Если бы не так много существующей документации об установке в одном контейнере, я бы почти утверждал, что она должна быть по умолчанию, хотя потребовались бы некоторые инструменты, чтобы сообщать людям, что с базой данных, возможно, нужно будет что-то сделать, или что-то в этом роде.

Я часто вижу, что многие люди недовольны установками в двух контейнерах и в целом их боятся. (Недавно, например, кто-то попросил перенести установку в двух контейнерах, которую я создал при их установке, в один контейнер.) Это настолько редко становится проблемой, что в тот единственный раз, когда она возникает, это на самом деле экономит нервы, так как позволяет отложить обновление Postgres до тех пор, пока вы не будете готовы к нему. Обычно обновление PG можно отложить на довольно долгое время (за исключением случая, когда в ядро был добавлен плагин ИИ и потребовалось это расширение).

2 лайка

Мои резервные копии начали сбоить после этого:

[2025-09-09 09:34:50] Создание архива: blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] Проверка, не существует ли уже архив...
[2025-09-09 09:34:50] Создание пустого архива...
[2025-09-09 09:34:50] ИСКЛЮЧЕНИЕ: 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/blah-forum-2025-09-09-093246-v20250828181952.tar: Не удалось открыть: Отказано в доступе
tar: Ошибка неисправима: завершение работы

Проверка прав доступа из контейнера web_only:

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

Если посмотреть на другой экземпляр (стандартная установка), то владелец другой:

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

Что пошло не так здесь и что нужно изменить в этой директории для контейнера web_only — должно ли оно быть таким же, как при стандартной установке?

tl;dr: возможно, стоит попробовать

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

И ещё немного слов.

Не глядя, я бы следующим шагом попробовал пересобрать контейнер данных, надеясь, что любые внесённые изменения также затронули (или повлияли на) контейнер данных.

Плохой совет — сделать ...backups/default доступным для записи всем и проверить владельца резервной копии.

Так что, думаю, вам нужно изменить владельца директории default на discourse.www-data в контейнере web (именно он выполняет резервное копирование).

Вот пример недавнего одноконтейнерного решения:

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

Раньше процесс сборки выполнял chown для всех файлов, но это могло занимать очень много времени, поэтому, возможно, эту операцию убрали (это скорее предположение, чем результат внимательного изучения коммитов).

1 лайк

Это эквивалентно ./launcher enter web_only?

В основном да. ./launcher сначала выполнит git pull (по крайней мере, я так думал, но возможно, это не так?), и у вас с большей вероятностью будет работать автодополнение по клавише Tab для docker, чем для ./launcher.

1 лайк

Это также помещает вас в корневую директорию, тогда как лаунчер помещает вас в директорию discourse

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

Кажется, это правильное исправление, так что посмотрим, как всё получится с следующим резервным копированием, спасибо!

1 лайк

Теперь вы можете просто запустить это из командной строки или через интерфейс, чтобы проверить, сработало ли это.

Кроме того, если бы я был чуть хитрее:

docker exec -it web_only bash -c "chown  -R discourse:www-data /shared/backups"
1 лайк

Я проявил терпение и дождался запланированной задачи, и, похоже, это сработало. Большое спасибо за вашу помощь @pfaffman :folded_hands:

Мне остаётся только гадать, случится ли это с другими, и нужно ли где-то внести изменения, чтобы предотвратить такое?

В этом наше отличие.

Да. Раньше при каждой пересборке выполнялась команда chown, я почти уверен. Это может занять время и почти всегда излишне (кроме случаев, когда это не так). Это не связано с различием между одним и двумя контейнерами. Думаю, дело в переходе с одной версии Debian для базового образа на другую, и в новой версии отображения пользователей отличаются от старых.

1 лайк

Разве плагин docker_manager бесполезен в этой конфигурации? — Он постоянно требует пересобрать приложение!

Я не уверен, что означает «это», но и эта тема, и та, на которую я ссылаюсь, относятся к стандартной установке, поэтому docker_manager работает как обычно.

Docker_manager не связан с процессом переноса на другой сервер, так как вам нужно создать новый контейнер.

Он должен заставлять вас создавать новое приложение при изменении базового образа, что, как мне кажется, в последнее время происходит довольно часто. Честно говоря, я до конца не разобрался в механизмах, которые здесь задействованы.

Вот как я это обнаружил: после запуска web_only и выполнения команды replace (с уничтожением и запуском), я попытался обновить систему после единственного изменения в плагине, но получил предложение пересобрать приложение!

1 лайк

./launcher bootstrap data && ./launcher destroy data && ./launcher start data

не выполняется с ошибкой, если предварительно не остановить контейнер данных командой ./launcher stop data

Это происходит на инстансах, созданных заново с помощью ./discourse-setup --two-container и конвертированных более длительным методом.

В обоих случаях
./launcher stop web_only && ./launcher rebuild data && ./launcher rebuild web_only
и
./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only

работают как ожидается.

Не упустил ли я что-то?

data_yml error.txt (5.2 KB)
data_yml error --two-container method.txt (5.0 KB)

1 лайк

Да, в этом логе указано: “postgres уже запущен, остановите контейнер”.

Это говорит о том, что сначала нужно остановить контейнер перед инициализацией контейнера с данными.

Похоже, что инструкции больше не актуальны?

Это также означает, что при полной пересборке будет больше простоев. К счастью, такие случаи редки.

Предполагаю, что после остановки контейнера с данными у вас не возникло проблем?

1 лайк