Я ценю это, но пересборка приложения занимает около 3 часов!
И это на мощном VPS.
Разве не было бы здорово иметь возможность удалять плагины так же, как мы можем добавлять и удалять темы?
Возможно, стоит рассмотреть это как функцию в будущем?
Спасибо!!
Извините?! Это должно занимать ~20 минут?!
не здесь
Первоначальная установка заняла 2 часа.
Теперь команды ./launcher rebuild app как будто нет:
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating eeefdde..30be122
Fast-forward
image/base/install-imagemagick | 5 ++++-
launcher | 2 +-
templates/web.letsencrypt.ssl.template.yml | 2 +-
templates/web.template.yml | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
Launcher updated, restarting...
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
Unable to find image 'discourse/base:2.0.20220818-0047' locally
2.0.20220818-0047: Pulling from discourse/base
1efc276f4ff9: Pulling fs layer
1b880e64942b: Pulling fs layer
794f6dc9a2ff: Pulling fs layer
1efc276f4ff9: Verifying Checksum
1efc276f4ff9: Download complete
1efc276f4ff9: Pull complete
794f6dc9a2ff: Verifying Checksum
794f6dc9a2ff: Download complete
1b880e64942b: Verifying Checksum
1b880e64942b: Download complete
1b880e64942b: Pull complete
794f6dc9a2ff: Pull complete
Digest: sha256:7734701087766821ffb2ddcef423754798bd345c2ac0d550131c6e6905c268e8
Status: Downloaded newer image for discourse/base:2.0.20220818-0047
После последней строки процесс просто продолжает мигать (работа идёт).
Это уже длится около 30 минут.
В прошлый раз это заняло целых 160 минут.
Общий объём памяти сервера: 4.657 ГиБ, версия ядра: 5.15.0-43-generic, операционная система: Ubuntu 22.04 LTS, SSD-диск 50 ГБ, 2.5 ядра, 5 потоков, процессоры Intel® Xeon®
…
Не знаю, что здесь может быть не так, кроме того, что это занимает очень много времени 
3 часа — это действительно очень странно. Вам необходимо расследовать эту проблему и решить её в первую очередь.
В логах сборки есть «визуальные паузы» — это нормально, но такая задержка — нет.
Мне кажется, что во время сборки система начинает использовать swap, но я не специалист по архитектуре. Запускаете ли вы что-то ещё на этой машине?
Загрузки требуют распаковки архивов, что требует значительных вычислительных ресурсов, но у всех используются одинаковые образы.
Для справки: я только что пересобрал сайт, и это заняло 13 минут 46 секунд на машине с 2 ГБ ОЗУ и 2 виртуальными ядрами на https://scaleway.com
Нет, это VPS, выделенный исключительно для этого экземпляра Discourse. Я использую множество других VPS у того же провайдера, и все они работают безупречно (хотя это не экземпляры Discourse, а другие приложения, например, кастомные PHP-скрипты или CMS на базе WordPress/Concrete5 и т.д.).
Я не знаю о каком-либо использовании swap-памяти и не вижу скачков использования ресурсов, которые могли бы это оправдать.
Сейчас статус — building.... — процесс кажется немного быстрее, чем в прошлый раз, однако он всё ещё явно превышает 20 минут.
Я спрошу у провайдера серверов, не видят ли они чего-то необычного на своей стороне, однако помню, что они лично сообщали мне, что их собственный экземпляр Discourse тоже собирался около двух часов. (Примечание: эти VPS размещены на машинах Hetzner, арендованных через посредника; сомневаюсь, что я смогу получить что-то лучшее.)
В любом случае, моё предложение остаётся в силе: было бы здорово иметь возможность добавлять и удалять плагины так же, как мы это делаем с темами. Возможно, это стоит рассмотреть?
Я действительно ничего не знаю, но насколько мне известно, это невозможно, потому что Discourse состоит из множества скомпилированных JavaScript-файлов. Когда возникает необходимость добавить или удалить что-то, что меняет работу ядра, требуется пересборка.
Ситуация очень похожа, например, на работу с Varnish.
Хм…
Кстати, я связался с командой серверов, и да, мы достигли 100% использования памяти.
5 ГБ ??? 5 ГБ оперативной памяти — это довольно много для чего бы то ни было.
Требования к Discourse гласят, что нужно всего 1 ГБ!
И сейчас процесс застрял на следующем:
104:M 04 Oct 2022 07:19:27.251 # Redis is now ready to exit, bye bye...
sha256:662695076506add39a630c2169b8b618f0121386951e93c6ffd2a6473107ae55
f4a95a1e69d5375e6ea30dfb22576209d249e5bc67b04a6fa09df289b1441888
Removing old container
+ /usr/bin/docker rm app
app
Поэтому я даже не могу обновить сервер, так как процесс будет прерван.
Честно говоря, я не думаю, что это проблема сервера. Если требуется 1 ГБ, то 5 ГБ должно быть более чем достаточно.
Что-то здесь не так, и очень серьёзно.
Я понимаю, что у других, должно быть, опыт лучше (взгляните на @merefield, который говорил об обновлении на 2 ГБ…), но у нас это не работает так, как должно.
В любом случае, это, наверное, уже не по теме этой ветки.
Я только что снова пересобрал другой сайт на 4 ГБ и 3 vCPU, и это заняло опять же меньше 15 минут (то есть лишняя память и процессорная мощность в моём случае не сильно помогли, но всё равно это далеко не часы!).
Единственное, что я заметил, так это то, что мой VPS использует vfs вместо рекомендуемых aufs или overlay.
Однако, согласно этой ссылке Can't run ./launcher rebuild app - Docker storage driver is unsupported - #45 by david, это не должно быть критично, поэтому мы запускаем лаунчер с флагом --skip-prereqs, иначе мы вообще не сможем запустить Discourse.
Меня всё же интересует, есть ли что-то ещё в требовании к драйверу хранилища.
Это немного… слишком оптимистично. Для тестирования этого может хватить, но даже в этом случае будет впритык. 2 ГБ гораздо ближе к реальности.
4 ГБ достаточно для более крупных экземпляров. Однако количество и мощность ядер также играют важную роль.
И всё же… если у вас 5 ГБ, а процесс пересборки занимает так много времени, значит, что-то не так.
У меня DigitalOcean/4 ГБ/2 виртуальных ядра Intel, и пересборка занимает около 25 минут.
Какая у вас точно система? И покажите app.yml — есть ли там что-то кастомное?
Привет! Единственная кастомизация — это то, о чём я упоминал ранее (vfs вместо aufs/overlay). Остальное — ванильное.
Сервер:
Общий объем памяти сервера: 4.657 ГиБ, версия ядра: 5.15.0-43-generic, операционная система: Ubuntu 22.04 LTS, SSD-накопитель 50 ГБ, 2.5 ядра, 5 потоков процессоров Intel® Xeon®
Файл yaml оригинальный, за исключением следующих плагинов-дополнений:
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
Из этих данных неясно, почему восстановление займет столько времени.
Попробуйте запустить такой же VPS с Ubuntu где-нибудь еще. Это поможет понять, проблема ли это в хостинг-провайдере. Это обойдется вам в несколько долларов и займет пару часов работы.
Для предварительной компиляции JavaScript требуется много памяти. Попробуйте добавить swap.
Наложение
Думаю, этот тест существует не просто так. Возможно, это ваша проблема.
Почему для 5 ГБ ОЗУ с чистым Discourse требуется больше swap, если системы с меньшим объёмом памяти полностью довольны тем, что получают автоматически?
Потому что это проще, чем делать то, что вам действительно нужно.
Добавление swap-раздела может помочь, но это не самая большая проблема.
Полагаю, мне следовало попробовать это до развёртывания контейнера Discourse: How to change the Docker storage driver – Webdock
Оказывается, сменить драйвер хранилища возможно — вопреки тому, что мне говорил хостинг-провайдер при развёртывании контейнера (тогда советовали либо отредактировать файл загрузчика, либо проигнорировать проверку).
Дурацкий момент, теперь, полагаю, уже слишком поздно.
В любом случае спасибо. Если это причина проблем, то, видимо, ошибка пользователя. Mea culpa 
Я бы так не думал.
Кроме того, двухконтейнерная конфигурация сокращает время простоя, поскольку вы можете пересобрать новый веб-контейнер из CSV, пока старый продолжает работать.
Каков размер вашего сайта? Я бы всё равно добавил swap-файл для решения проблемы с памятью.
Пустой экземпляр с 1 ГБ ОЗУ и 1 ГБ swap-файла работает нормально для небольшого тестового сообщества, но как только оно начнёт расти, этого будет недостаточно. Swap-файл действительно имеет значение.
Если пересборка на «мощном» VPS, расположенном в дата-центре с высокоскоростным каналом в интернет, занимает 3 часа, а пересборка моей установки на https://discourse-on-a-pi.falco.dev, которая работает на плате размером с кредитную карту на моём столе и подключена к интернету через стандартный домашний тариф в стране третьего мира, занимает всего 14 минут (+4 минуты при наличии нового образа контейнера), то с продуктом, который вам продают, что-то не так…
Как обстоят дела с использованием памяти на сервере? Если вы находитесь на пределе или близко к нему до начала перестройки, у вас будет активное использование файла подкачки, что, безусловно, значительно замедлит все процессы.
Если это так, я бы предложил вам временно отключить всё остальное, что может работать на сервере, если это возможно.