Я предполагаю, что загружать его не строго обязательно. Большинство пользователей запускают один облачный экземпляр, у которого может быть, а может и не быть резервной копии в S3. Загрузка резервной копии была бы единственным способом для этой группы создать резервную копию вне сайта, как вы и упоминали.
Я бы даже пошел дальше и создал бы дополнительную систему резервного копирования у совершенно другого провайдера, особенно после того, что недавно произошло с этим разработчиком с открытым исходным кодом. Независимо от достоверности этого случая, это служит отличным предупреждением: нужно делать еженедельные или ежемесячные резервные копии в совершенно другом месте хранения или у другого провайдера.
Спасибо @pfaffman за добавление этой функции, теперь всё действительно стало проще! (за исключением восстановления большой резервной копии, что всегда немного напряжно и долго, независимо от настройки).
Кстати, я думаю, что этот путь указан неверно: по умолчанию должно быть web-only, верно?:
Да. web-only, и это немного сбивает с толку, так как в любом другом контексте используется web_only. Но, возможно, когда речь идёт о директории или контейнере — это что-то другое.
Что я знаю… Я просто потратил 4 часа на борьбу с SearXNG, хотя это должно было занять 5 минут (я действительно не люблю вещи, связанные с Docker).
редактирование и оффтоп
Правда ? Слово «he and ck» запрещено? В школе нас учили, что это не оскорбительное слово. Значит, они ошибались, очевидно
Думаю, это было добавлено, когда впервые тестировали функцию отслеживания слов, и просто так и осталось.
Да, я часто путаюсь в этом. На самом деле, думаю, именно поэтому однажды, когда я пытался просто переименовать вещи, чтобы переключиться с одиночного на двойной контейнер, я ошибся с символом подчёркивания/тире, и всё не сработало.
И что ещё хуже, я почти уверен, что это моя вина. При создании варианта с двумя контейнерами в discourse-setup возникла какая-то ошибка (возможно, контейнеры не могут содержать подчёркивания?). Ruby любит подчёркивания в именах файлов, поэтому, возможно, я использовал именно их? Думаю, так и есть — и, похоже, web_only не может работать как имя контейнера Docker, поскольку они также должны быть допустимыми именами хостов.
Я предпочитаю дефисы в путях к каталогам, так что всё отлично. Честно говоря, нижнее подчёркивание в имени контейнера имеет смысл, поэтому оставим как есть.
Кстати, я думаю, что на meta стоит добавить заголовок или значок самоподтверждённого статуса для тех, кто использует настройку с двумя контейнерами Когда вы будете здесь год, я считаю, что миграция ваших стандартных установок должна стать обязательной.
Если бы не так много существующей документации об установке в одном контейнере, я бы почти утверждал, что она должна быть по умолчанию, хотя потребовались бы некоторые инструменты, чтобы сообщать людям, что с базой данных, возможно, нужно будет что-то сделать, или что-то в этом роде.
Я часто вижу, что многие люди недовольны установками в двух контейнерах и в целом их боятся. (Недавно, например, кто-то попросил перенести установку в двух контейнерах, которую я создал при их установке, в один контейнер.) Это настолько редко становится проблемой, что в тот единственный раз, когда она возникает, это на самом деле экономит нервы, так как позволяет отложить обновление Postgres до тех пор, пока вы не будете готовы к нему. Обычно обновление PG можно отложить на довольно долгое время (за исключением случая, когда в ядро был добавлен плагин ИИ и потребовалось это расширение).
[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 — должно ли оно быть таким же, как при стандартной установке?
Не глядя, я бы следующим шагом попробовал пересобрать контейнер данных, надеясь, что любые внесённые изменения также затронули (или повлияли на) контейнер данных.
Плохой совет — сделать ...backups/default доступным для записи всем и проверить владельца резервной копии.
Так что, думаю, вам нужно изменить владельца директории default на discourse.www-data в контейнере web (именно он выполняет резервное копирование).
Раньше процесс сборки выполнял chown для всех файлов, но это могло занимать очень много времени, поэтому, возможно, эту операцию убрали (это скорее предположение, чем результат внимательного изучения коммитов).
В основном да. ./launcher сначала выполнит git pull (по крайней мере, я так думал, но возможно, это не так?), и у вас с большей вероятностью будет работать автодополнение по клавише Tab для docker, чем для ./launcher.
Да. Раньше при каждой пересборке выполнялась команда chown, я почти уверен. Это может занять время и почти всегда излишне (кроме случаев, когда это не так). Это не связано с различием между одним и двумя контейнерами. Думаю, дело в переходе с одной версии Debian для базового образа на другую, и в новой версии отображения пользователей отличаются от старых.
Я не уверен, что означает «это», но и эта тема, и та, на которую я ссылаюсь, относятся к стандартной установке, поэтому docker_manager работает как обычно.
Docker_manager не связан с процессом переноса на другой сервер, так как вам нужно создать новый контейнер.
Он должен заставлять вас создавать новое приложение при изменении базового образа, что, как мне кажется, в последнее время происходит довольно часто. Честно говоря, я до конца не разобрался в механизмах, которые здесь задействованы.
Вот как я это обнаружил: после запуска web_only и выполнения команды replace (с уничтожением и запуском), я попытался обновить систему после единственного изменения в плагине, но получил предложение пересобрать приложение!