Что нужно знать перед обновлением с v3.4.0 до v2026.7.2

Поддержка Самостоятельное хостинг
1

Я отвечаю за установку Discourse на базе Docker, работающую на Ubuntu, которую я унаследовал в рамках проекта с открытым исходным кодом. В течение нескольких лет я обновлял её с помощью git pull && ./launcher rebuild app, а затем через административный интерфейс по адресу /admin/update. Однако после болезненного опыта с критическим обновлением из-за docker_manager в январе 2024 года (см. комментарии к коммиту здесь и отменённый коммит здесь) я перестал обновлять систему так небрежно.

С тех пор прошло 2,5 года, и мне нужно снова войти в ритм регулярных обновлений, но я всё ещё немного насторожен из-за последнего сломанного обновления. Мне бы хотелось понять, что мне нужно знать перед попыткой обновления с версии v3.4.0 до v2026.7.2. Наш сайт не использует никаких дополнительных плагинов, и единственная особая конфигурация, о которой я знаю, — это использование URL Discourse Connect для настройки SSO с нашим основным сайтом сообщества.

Это так просто, как?

cd /var/discourse
git pull
./launcher rebuild app

А затем обновление через административный интерфейс? Есть ли какие-либо промежуточные шаги, о которых мне нужно знать при переходе с версии v3.4.0 на v2026.7.2?

Спасибо,

Кори

2

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

С одной серьёзной проблемой, с которой вы столкнётесь, является крупное обновление Postgres (до версии 18). Если вы развернёте новый сервер, вам не придётся проходить через этот процесс обновления.

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

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