Discourse не обновляется в интерфейсе администратора — что бы ни делал

При обновлении через UI-обновлятор в админ-панели он всегда завершается ошибкой. Это происходит с момента установки Discourse более года назад. Я могу легко подключиться к серверу по SSH и обновить его вручную, но раздражает, что функция работает некорректно.

Так как Discourse работает в Docker, а я не очень хорошо разбираюсь в нём, хотел бы узнать, сталкивался ли кто-то с подобными проблемами и как их исправить.

Коротко: UI-обновлятор всегда падает, а обновление через командную строку проходит с первого раза. Хотелось бы исправить это, чтобы не приходилось так часто подключаться к серверу по SSH.

Спасибо!

Привет, то же самое, так уже несколько месяцев.

Если вы подключаетесь к своему серверу по SSH, что выводит команда free -h?

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

image

У меня не более 3 одновременных пользователей, а мне нужно больше. Думаю, вам стоит обновить ваш VPS.


Где находится большинство ваших пользователей?

Раньше я мог выполнять обновление с 2 ГБ ОЗУ и 2 ГБ подкачки, но это было, кажется, до появления Ember, который очень требователен. Если у вас есть место на диске, чтобы увеличить подкачку до 4 ГБ, это может помочь. Или временно и осторожно перенесите систему на экземпляр с большим объемом ОЗУ, выполните обновление, а затем вернитесь обратно.

Что бы вы ни делали, сначала создайте резервную копию и скачайте её.

Обратите внимание, что большинство провайдеров позволяют переносить систему на тот же диск или на диск большего размера. Перенос на диск меньшего размера невозможен. Поэтому вам нужно найти тарифный план, который предлагает больше ОЗУ, но тот же объем дискового пространства.

В итоге я сменил провайдера, чтобы получить более мощный сервер по более низкой цене (4 ГБ ОЗУ и 40 ГБ дискового пространства).

Я изучу вариант с файлом подкачки и посмотрю, поможет ли это. У меня 2 ГБ оперативной памяти и 80 ГБ дискового пространства.

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

Спасибо за помощь.

Раньше у меня было 2 ГБ ОЗУ и 40 ГБ дискового пространства, я полагался на .\discourse-setup для настройки swap-файла, обновления через веб-интерфейс были медленными.

Возможно, стоит обратить внимание на этот хостинг Ionos в США

Да, я на уровне ниже, через год это будет 8 долларов в месяц. К сожалению.

Я знаю, что Contabo предоставляет VPS по хорошим ценам.


Вы же сказали «менее 5»…

Вау, отличная цена. Я посмотрю. Спасибо!

На рынке США и Contabo, и IONOS разрешают входящий порт 25, что критично для конфигураций mail-receiver — поэтому функциональных ограничений здесь нет.

Главное отличие заключается в надёжности и репутации поддержки:

  • Contabo (Trustpilot 4,2/5, ~6700 отзывов) предлагает агрессивные цены и высокие характеристики, но пользователи из США часто сообщают о высокой задержке, медленной реакции поддержки и нестабильности производительности, особенно под нагрузкой. У Contabo есть дата-центры в США, но они не всегда работают так отзывчиво, как ожидалось.

  • IONOS (Trustpilot 4,5/5, ~31 000 отзывов) работает в США лучше, чем многие предполагают. Компания имеет более сильную репутацию в области поддержки и более надёжную инфраструктуру, при этом количество отзывов с одной звездой меньше (~10% против 16% у Contabo). Пользователи последовательно сообщают о лучшей доступности, живой поддержке и управлении аккаунтом по сравнению с Contabo.

Вывод (США):
Если вы находитесь в США и вам нужны стабильность, быстрая поддержка и минимальные риски для производственных нагрузок, IONOS — более безопасный выбор. Contabo всё ещё может быть целесообразен для сред разработки/тестирования или развертываний, чувствительных к стоимости, но следует ожидать компромиссов в задержке и качестве поддержки.

У меня тоже это началось: всё работало отлично более 4 лет, а теперь вылетает. Хотя иногда оно заявляет о сбое, но после обновления страницы оказывается, что всё актуально и обновлять больше нечего. Но почти всегда в конце выводится:

ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Команда была завершена сигналом SIGKILL (принудительное завершение): ember build -prod /var/www/discourse/script/assemble_ember_build.rb:103:in `system': Команда завершилась с кодом 1: pnpm (RuntimeError) from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>' Docker Manager: FAILED TO UPGRADE

В большинстве случаев было бы очень полезно увидеть предыдущие 50–200 строк вывода. Жаль, что скрипты не предлагают этого.

Вот что меня беспокоило: связано ли это с проблемой в самом коде, а не с оборудованием моего сервера.

Полагаю, следующим шагом будет написание собственного плагина со скриптом для ручного обновления.

Рад, что у других такая же проблема — значит, я не один (знаю, это неприятно). Возможно, кто-то из активно разрабатывающих для Discourse сможет разобраться. Также хотелось бы получить более подробную информацию об отладке, а не просто сообщение «не удалось».

Эд, я проверю, смогу ли я это для тебя достать. И сразу же опубликую.

Я не разработчик и не эксперт в вопросах серверов и всего остального. Я выбрал Digital Ocean просто потому, что он упоминался в официальных инструкциях по установке, а также потому, что я видел это название снова и снова на протяжении многих лет.

В данный момент я использую второй по стоимости тарифный план — 6 долларов в месяц за сервер, который, кажется, значительно «медленнее» тех, что предлагаются Contabo или IONOS. Поскольку минимум для хорошей производительности Discourse составляет как минимум 2 ГБ оперативной памяти, мне пришлось бы перейти на план за 12 долларов. За 4,95 доллара в месяц в Contabo я получил бы 8 ГБ… это небольшая разница :wink: как в цене, так и в объёме оперативной памяти, не говоря уже о дисковом пространстве и прочем.

Так что, спрашивая вас и любых других опытных пользователей, имеет ли смысл мигрировать мой Discourse, например, на Contabo вместо того, чтобы оставаться на Digital Ocean? Даже учитывая, что я всё ещё создаю всё сообщество и так далее, до сих пор DO работал нормально, за исключением проблемы с обновлением Discourse через веб-интерфейс, даже с файлом подкачки объёмом 4 ГБ (потому что моё дисковое пространство составляет всего 25 ГБ), но я не хочу мигрировать всё, чтобы потом начать сталкиваться с другими проблемами.

Я нашёл эту страницу, но не уверен, насколько надёжны эти тесты и достаточно ли их, чтобы заставить меня переключиться?

Любая обратная связь будет очень ценной!
Спасибо! :raising_hands:

Это полностью обесценивает то, что Digital Ocean предлагает за 6 долларов в месяц с всего 1 ГБ оперативной памяти…

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

********************************************************
*** Пожалуйста, подождите, следующие шаги могут занять время ***
********************************************************
Cycling Unicorn для освобождения памяти
Перезапуск unicorn pid: 1580
Ожидание перезагрузки Unicorn.
Ожидание перезагрузки Unicorn..
Ожидание перезагрузки Unicorn...
Ожидание перезагрузки Unicorn....
Ожидание перезагрузки Unicorn.....
Ожидание перезагрузки Unicorn......
Ожидание перезагрузки Unicorn.......
Ожидание перезагрузки Unicorn........
Ожидание перезагрузки Unicorn.........
Ожидание перезагрузки Unicorn..........
Ожидание перезагрузки Unicorn...........
Ожидание перезагрузки Unicorn............
Ожидание перезагрузки Unicorn.............
Ожидание перезагрузки Unicorn..............
Остановка 1 воркера Unicorn для освобождения памяти
Остановка очереди заданий для возврата памяти, мастер pid 1585
$ cd /var/www/discourse && git fetch --tags --prune-tags --prune --force
$ cd /var/www/discourse && git reset --hard HEAD@{upstream}
HEAD теперь на 20ff23ed0 DEV: удаление избыточных переводов для отключенной кнопки создания новой темы (#33929)
$ bundle install --retry 3 --jobs 4
Готово! 160 зависимостей Gemfile, установлено 207 gem-ов.
Gem-ы в группах 'test' и 'development' не устанавливались.
Собранные gem-ы установлены в `./vendor/bundle`
3 установленных gem-а, от которых вы напрямую зависите, ищут финансирование.
  Запустите `bundle fund` для получения деталей
$ if [ -f yarn.lock ]; then yarn install; else CI=1 pnpm install; fi
Область: все 16 проектов рабочего пространства
Файл блокировки актуален, этап разрешения пропущен
Уже актуально

Готово за 2.9 с с использованием pnpm v9.15.9
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-custom-wizard уже на последней совместимой версии
docker_manager уже на последней совместимой версии
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Мигратор мультисайта работает с использованием 1 потока

Миграция default
Заполнение default
*** Сборка ресурсов. Это займет время *** 
$ bundle exec rake themes:update assets:precompile
Обновление тем с конкурентностью: 10
[db:default] 'Air Theme' - проверка...
[db:default] 'Air Theme' - актуально
[db:default] 'Modern Category + Group Boxes' - проверка...
[db:default] 'Modern Category + Group Boxes' - актуально
[db:default] 'Clickable Topic' - проверка...
[db:default] 'Clickable Topic' - актуально
[db:default] 'Search Banner' - проверка...
Ограничение heap_size_limit для Node.js меньше 2048 МБ. Установка --max-old-space-size=2048 и CHEAP_SOURCE_MAPS=1
Существующая сборка не может быть переиспользована.
- Существующая: {"ember_env"=>"production", "core_tree_hash"=>"cd74e4ac33647244c041061633d6ca67f9166e5c"}
- Текущая: {"ember_env"=>"production", "core_tree_hash"=>"7ac67590cc51e22690a2711b593892cd1d266781"}
Запуск полной сборки ядра...
Сборка
Окружение: production
Настройка 'staticAddonTrees' по умолчанию будет true в следующей версии Embroider и её нельзя будет отключить. Чтобы подготовиться к этому, установите 'staticAddonTrees: true' в конфигурации Embroider.
Настройка 'staticAddonTestSupportTrees' по умолчанию будет true в следующей версии Embroider и её нельзя будет отключить. Чтобы подготовиться к этому, установите 'staticAddonTestSupportTrees: true' в конфигурации Embroider.
сборка...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] Примечание: генератор кода оптимизировал стилизацию /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js, так как она превышает максимум 500 КБ.
[BABEL] Примечание: генератор кода оптимизировал стилизацию /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js, так как она превышает максимум 500 КБ.
...[Babel: @glimmer/component > applyPatches]
...[Babel: @ember/test-waiters > applyPatches]
...[Babel: ember-this-fallback > applyPatches]
...[Babel: ember-cache-primitive-polyfill > applyPatches]
...[Babel: select-kit > applyPatches]
...[@embroider/compat/app]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
undefined
 ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL  Команда была прервана сигналом SIGKILL (принудительное завершение): ember build -prod
/var/www/discourse/script/assemble_ember_build.rb:103:in `system': Команда завершилась с ошибкой (exit 1): pnpm (RuntimeError)
	from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>'
Docker Manager: НЕ УДАЛОСЬ ОБНОВИТЬ
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:211:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:112:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `block in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2/lib/active_support/execution_wrapper.rb:91:in `wrap'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:70:in `conditional_executor'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:178:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor.rb:538:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:73:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:65:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:143:in `with_argv'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:63:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands.rb:18:in `<main>'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.18.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
Запуск 1 воркера Unicorn, который был остановлен изначально

Вот результат. Воспроизведено сегодня.