Это правильно? Сколько времени займет установка dev-версии?

Я пытаюсь установить версию Discourse для разработки на виртуальном сервере (droplet) с Ubuntu 20.04 в DigitalOcean исключительно для миграции форума FluxBB в Discourse: экспортировать данные, а затем импортировать их в продакшн-версию Discourse.

У меня не возникло проблем с установкой продакшн-версии Docker в качестве теста (без миграции с FluxBB).

Однако при попытке установить версию Discourse для разработки по этой инструкции:

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

bundle exec rake autospec

После примерно 30 минут ожидания завершения я получаю тайм-аут удалённого сеанса.

Также я получаю множество ошибок, к сожалению, у меня нет их под рукой, но все они имеют вид, когда какая-то функция постоянно возвращает «nil».

Поскольку я не знаю, что делает эта команда и необходима ли она (в инструкции просто сказано «попробуйте запустить тесты», без объяснения, что это такое и зачем это нужно), я решил перейти к следующей команде:

bundle exec rails server --binding=0.0.0.0

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

Итак, мой вопрос: это ожидаемое поведение или я что-то делаю не так? Примерно сколько времени должны занимать эти команды?

И возможно ли просто мигрировать форум FluxBB, используя продакшн/Docker-версию Discourse, без необходимости использовать версию для разработки? В данный момент у меня ещё нет продакшн-сайта, поэтому я не беспокоюсь о его поломке; я могу уничтожить его и воссоздать в любой момент.

Это означает, что сервер запущен. И, конечно же, он будет продолжать работать, пока вы не нажмете Control C или не закроете терминал.

Информация выводится в терминал бесконечно, если вы не остановите сервер.

В течение нескольких секунд после запуска веб-страница станет доступна в вашем браузере.

Вы подключаетесь к правильному порту в браузере? Обычно это порт 3000.

Существует несколько руководств по запуску импорта на производственных серверах. Вы можете использовать одно из них в качестве руководства для запуска нужного скрипта.

Похоже, что вы установили среду разработки, и скрипт следует запускать именно там.

В браузере ничего не отображается. Если запустить команду ‘top’ из терминала, я вижу запущенный процесс Ruby.

Если вывод терминала продолжается бесконечно после выполнения

bundle exec rails server --binding=0.0.0.0

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

Существует несколько руководств по запуску импорта на продакшн-серверах.

Где их можно найти? Единственное, что я вижу для FluxBB, явно указывает на необходимость выполнения импорта на установке для разработки:

Считается само собой разумеющимся, что если вы запускаете веб-сервер, то он не должен останавливаться, если администратор этого не захочет. Веб-серверы обычно предназначены для обслуживания страниц день за днём, изо дня в день… но, конечно, кто-то мог бы добавить это уточнение. Любой может предложить улучшения для руководства через pull request.

Но является ли здравым смыслом то, что эта команда запускает веб-сервер? Она просто говорит «rails server», что не обязательно означает веб-сервер. Когда вы запускаете веб-сервер Apache, вас сразу же возвращают к командной строке, и он не выводит бесконечный поток сообщений в Терминал…

Rails — это фреймворк для веб-приложений. Я считаю, что сравнивать его напрямую с Apache несправедливо.

Мне, кстати, нравится, что можно видеть, как он активно работает. Если он останавливается, значит, что-то обычно не так! Вывод может быть полезен в некоторых ситуациях, особенно при разработке. Вы можете изменить количество отображаемой информации с помощью конфигурации окружения.

Кстати, согласно документации, Rails можно запустить как демон с помощью флага -d. Не стесняйтесь разобраться, почему это не работает в стандартной установке — возможно, это связано с каким-то ограничением. Лучше всего обратиться к команде разработчиков по этому вопросу.

Привет @epsteindidnt

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

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

Помимо удивительного лога сервера Rails, который предоставляет детальные сведения о происходящем, есть ещё один «лучший друг разработчика» — консоль Rails!

Когда я пишу код для Rails, я обычно черновик делаю в VSC, а затем копирую и вставляю фрагменты в консоль Rails, чтобы убедиться, что всё работает как ожидалось.

При отладке я добавляю в код операторы Ruby типа print (p, puts) и наблюдаю за тем, что происходит в «бесконечном потоке золотой информации лога сервера Rails» на экране. Почти все мои ошибки исправляются именно так! Как я уже сказал, я недавно купил новый изогнутый игровой монитор, чтобы видеть информацию лога сервера Rails, которая вас сейчас раздражает :slight_smile:

Судя по вашим сообщениям, мне кажется, что вы немного похожи на меня в начале этого года: вы мигрируете на приложение Rails без предварительного опыта разработки на Rails. В начале я тоже немного раздражался из-за Rails (возможно, даже больше), а теперь, спустя 9 месяцев, я ежедневно работаю исключительно на Rails для клиентов (мой лимит — половина рабочего времени, так как я на полупенсии) и полностью прекратил предыдущую разработку на PHP. Честно говоря, у меня появилась новая страсть к Rails (и Ruby), и очень сильная. Лучше поздно, чем никогда, как говорится!

Что касается Apache2, то Apache не предоставляет таких детальных сведений о том, что происходит за кулисами приложения, как это делает Rails. Я использую Apache2 в качестве обратного прокси-сервера перед всеми своими приложениями на Rails, и, честно говоря, я не помню, когда в последний раз смотрел в лог-файл Apache, потому что всю отладку я провожу с помощью лога сервера Rails, который вас сейчас раздражает :slight_smile:

В заключение, я искренне надеюсь, что другая точка зрения от человека, который ранее «переносил форум на Rails», хоть немного поможет вам. Для меня решение уйти от веб-приложений LAMP и перейти на веб-приложения Rails стало одним из лучших «технических событий» в моей жизни в 2020 году.

С праздниками!

Последнее время меня тоже немного это пугало. Вот что я понял сегодня:

Вывод в терминале при запуске rails s показывает множество запросов при старте, но он также включает вывод от фоновых задач Sidekiq в Discourse (по крайней мере, в настройках разработки через Docker). Поэтому, если вы выполняете очень большой импорт, у вас образуется огромная очередь задач Sidekiq для постобработки, которая может выполняться очень долго. Я думаю, это не критичные задачи, например, загрузка кэшей, которые, похоже, не мешают вам просматривать сайт до их завершения.

Это меня сбивало с толку, потому что я сделал большой импорт, затем откатился, сбросил базу данных и запустил крошечный тестовый импорт, но система всё ещё бесконечно работала, выполняя запросы, связанные с уже несуществующей большой базой данных! Решение состояло в том, чтобы очистить очереди Sidekiq через консоль Rails.

Уже слишком поздно, чтобы помочь вам, но решил поделиться этим.