Бета-версии после тестирования в конечном итоге выпускаются как стабильные релизы. В зависимости от масштаба изменений в ядре могут потребоваться специальные шаги, выполняемые через командную строку.
VPS (виртуальный частный сервер) — это то, на чём работает ваша установка Discourse, за что вы платите. Если вы не используете домашний ПК, что, как правило, считается неподдерживаемой установкой.
Раньше я использовал Upcloud как провайдера VPS. Сейчас я использую Cobtabo.
Все бета-версии после достаточного тестирования становятся тем, что люди называют стабильными релизами.
В ссылке, которую предоставил Мойн, вы найдёте:
Обычно тарифные планы для хостинга Discourse используют ветку Tests-Passed, чтобы обеспечить максимальную безопасность и хорошую стабильность.
Не воспринимайте это неправильно, но тот факт, что вы не знакомы с такими терминами, как VPS, говорит о том, что вы очень новичок в этом. Вы установили Discourse самостоятельно или, возможно, унаследовали существующий форум Discourse? Все мы когда-то были новичками в настройке и поддержке Discourse.
Это не мнение. Это факт, если вы выбираете использовать такое ПО. Оно наравне с большинством программного обеспечения с открытым исходным кодом и даже закрытым ПО, которое вы используете. Я написал VPS. Android написал V и P с заглавной буквы.
Однако, справедливости ради, я полагаю, вам придётся разбираться во всём самостоятельно, если вы не очень хотите учиться с помощью других.
Удачи! 
Я заметил, что @anon55243134 удалил почти все свои сообщения. Действительно, здесь есть важные уроки для команды и для поддержания скриптов обновлений и коммуникации вокруг процесса обновления.
@anon55243134 — это человек, который уже несколько лет управляет собственным хостингом Discourse, и теперь у него повреждена и неработоспособна установка — просто потому что он следовал подсказкам для обновления.
Если бы это случилось со мной, я был бы очень разозлен и расстроен из-за возможной потери содержимого форума. Выбрав самостоятельный хостинг, я мог бы не быть готовым или не иметь возможности заплатить большие деньги за исправление, если это вообще возможно.
Я считаю, что предупреждений и проверок недостаточно:
Ещё более тревожно то, что в одном из удалённых сообщений я вижу довольно серьёзные сбои, которые не были перехвачены, и скрипт продолжил выполнение:
cat: /shared/postgres_data/PG_VERSION: No such file or directory
...
E: Unable to locate package postgresql--pgvector
cp: cannot stat '/etc/postgresql//main/*': No such file or directory
sh: 1: /usr/lib/postgresql/bin/postgres: not found
...
Finding the real data directory for the source cluster
could not get data directory using "/usr/lib/postgresql/bin/postgres" -D "/shared/postgres_data" -C data_directory: No such file or directory
Failure, exiting
Я не проверял скрипты, но отсутствие файлов должно служить сигналом надвигающихся проблем, и в такой момент нужно остановиться.
Извините, что поднимаю старую проблему! В моём случае я обновил Ubuntu и Postgres, а затем снова выполнил команду sudo ./launcher rebuild app в директории /var/discourse. Всё, похоже, успешно пересобралось, и сайт снова работает.
Спасибо всем, кто помог мне в этом. Я ценю вашу помощь и не представляю, где бы я был без этого сообщества.
Спасибо!
Здесь определённо есть возможности для улучшения Discourse. У меня уже 7–8 лет работает стабильная инстанция, и за это время неоднократно возникала необходимость выполнять обновление через командную строку сервера. Это даже указано в документации с рекомендуемой периодичностью.
Однако доступ к документации не так удобен, как мог бы быть. Плагин «Document Categories» — это определённо шаг вперёд, но, на мой взгляд, всё ещё можно сделать лучше.
Мои рекомендации по улучшению: разместить прямые ссылки в веб-интерфейсе администратора. Возможно, добавить ссылку с (?) рядом с кнопкой обновления, которая открывала бы всплывающее окно с краткой информацией и ссылкой на тему в Meta с более подробными сведениями.
В панели обновлений было бы удобно добавить аналогичную дополнительную информацию. Например, для разделов «Core» и «Docker» можно было бы сделать кнопку неактивной (серой) с сообщением о том, что обновление необходимо выполнять через командную строку сервера, и добавить ссылку на соответствующие примечания к выпуску, где в первом разделе указаны требования: версия Docker X, Ubuntu LTS версии X (или эквивалентные официально поддерживаемые дистрибутивы Linux). Ссылка на тему в Meta, на мой взгляд, также должна содержать готовые к копированию команды для командной строки сервера.
Что касается скриптов — не уверен, насколько это легко реализуемо. Но можно было бы добавить в начальный скрипт проверку базовых требований. Если какая-либо необходимая зависимость отсутствует, скрипт должен завершаться с сообщением об ошибке и, возможно, ссылкой на информацию о том, как её установить.
Сообщение об ошибке при неудачном обновлении должно быть более интуитивно понятным. Хотя в нём сказано прокрутить вверх, чтобы найти предыдущие ошибки, я замечал, что некоторые ошибки встречаются часто и не влияют на процесс пересборки. Было бы гораздо лучше экспортировать ключевые ошибки, вызвавшие сбой пересборки, в отдельный лог-файл. Однако реализация этих предложений потребует значительных усилий и времени.
В категории Documentation > Self-Hosting действительно необходим более подробный гайд по началу работы с введением в то, что нужно знать перед самостоятельным хостингом. Например, базовые знания об операционной системе, такой как Ubuntu LTS, информация о её обслуживании и обновлении дистрибутива, лучшие практики резервного копирования и пошаговые инструкции. Эти материалы можно было бы оформить в виде тем с тегами в категории «Staff» со ссылками на Meta.
Насколько я помню, Bloomberg создал отличную тему о том, что произошло в этой дискуссии. С моей стороны приношу извинения пользователю @anon55243134. Однако и им самим необходимо взять на себя ответственность. Если вы обращаетесь за поддержкой, нужно быть готовым слушать то, что говорят, и предоставлять запрашиваемую информацию, чтобы все желающие могли помочь вам найти возможные решения.
У всех нас могут быть свои идеи о том, как можно улучшить дизайн и другие аспекты. Но пока эти изменения не внедрены, нам нужно принять текущее состояние системы.
Я понимаю, насколько мучительно переживать простои из-за сбоев. Недавно у меня возникла проблема с клиентом, которого я администрирую на волонтёрских началах. Более месяца я просил их увеличить ресурсы сервера, так как приложение не удавалось пересобрать из-за нехватки места, а представленные здесь инструкции по освобождению места не помогли. Они проигнорировали мои предупреждения, и в итоге, как я и предсказывал, сервер серьёзно вышел из строя. В результате им пришлось нанять одного из участников форума для устранения проблемы, что потребовало развёртывания нового сервера с достаточным объёмом дискового пространства. Сайт был недоступен более двух недель из-за их халатности. Позже они перестали обслуживать почтовый сервер; хотя сам сайт работал, отсутствие уведомлений по электронной почте нанесло значительный ущерб. Я мог бы привести ещё много примеров, но это уже не проблема самого Discourse, а вопрос самостоятельного хостинга.
Давным-давно у меня была проблема с пересборкой, вызванная файлом шаблона. Лог-файл дал мне достаточно информации, чтобы предположить, что нужно закомментировать этот файл шаблона. Это помогло решить проблему. Когда эта ситуация была обсуждена здесь, я поделился своим решением, что помогло команде выявить корень проблемы.
Нам всем нужно стремиться к улучшению. Уделяйте время чтению и слушанию тех, кто обладает опытом и навыками для решения проблем. Именно так я сам приобрёл знания о том, что могу делать. В тех областях, где у меня нет достаточного опыта (особенно учитывая сложность Discourse), я стараюсь как можно лучше провести исследование, прошу о помощи и прислушиваюсь к советам всех здесь присутствующих, кто обладает более глубоким пониманием этого замечательного программного обеспечения.
@anon55243134, если вы готовы дать шанс, возможно, мы все сможем помочь вам вернуть сайт в строй. Нам просто нужно в процессе избегать отклонений в сторону «как мы считаем, должно быть» и временно принять «как есть». После восстановления мы сможем обсудить извлечённые уроки и начать конструктивное обсуждение рекомендаций по потенциальному улучшению системы. Если команда будет готова (а обычно она готова), мы должны понимать, что это займёт значительное время из-за других текущих проектов. С нашей стороны мы можем прорабатывать идеи, а те, кто обладает реальными знаниями, при наличии времени могут заняться созданием необходимой информации: инструкций, лучших практик и т.д..
Вместе мы достигаем большего. Если действовать поодиночке, мы добьёмся очень little или вообще ничего.