Есть ли преимущества у установки через Docker?

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

Я знаю, что документация и множество тем здесь утверждают, что Docker — это единственный (хороший) путь вперёд, но я хотел понять причины. У меня есть виртуальная машина Debian от Amazon Lightsail за $3,50 в месяц, и я запустил Discourse за 20 минут. Я использовал rbenv для установки Ruby 3.2.2, а остальное было несложно. Мне показалось, что Discourse не следует конвенциям Rails: например, почему существует ./config/discourse.conf и GlobalSetting, а не значения в config/environments/production.rb? Неужели именно так создаются образы Docker (также обратите внимание, что в sidekiq.yml нет значений для окружения production)?

Есть ли преимущества в запуске этого в Docker? Возможно, я что-то упускаю…

2

Если вы не используете стандартную установку, мы не сможем оказать вам здесь никакой поддержки. При отклонении от этого пути может возникнуть слишком много проблем.

3

Ах, понял, да, разные ОС и прочее. Уже кто-то спросил, как я это сделал — я опубликую здесь на всякий случай.

Вам понадобится Ruby 3.2.x (через rbenv, чтобы не зависеть от ОС), Node v16.19.x/npm 8.19.x и PostgreSQL (версия, скорее всего, любая выше 11).

  1. Я создал файл .ruby-version, в котором указал версию Ruby, которую я установил (3.2.2).
  2. Выполнил bundle, и все gem-пакеты собрались без проблем.
  3. В самой PostgreSQL нужно было настроить базу данных:
CREATE DATABASE discourse;
CREATE USER discourse WITH password 'fA....';
GRANT ALL PRIVILEGES ON DATABASE discourse TO discourse;
\c discourse
GRANT ALL ON SCHEMA public TO discourse;

Я был удивлен, что database.yml не принимает переменные для окружения production (это кажется очень анти-Rails-конвенцией). Все настройки БД находились в config/discourse.conf, вместе со значениями SMTP. Я их заполнил.

Затем выполнил миграции базы данных:

bundle exec rails db:migrate

Всё сработало отлично, миграции прошли успешно.

  1. В файле config/sidekiq.yml, после секции development, я добавил:
production:
  :concurrency: 2
  :queues:
    - [critical, 2]
    - [default, 1]
    - [low]
    - [ultra_low]
  1. Затем отредактировал lib/tasks/assets.rake, примерно на строке 151, добавив:
harmony: true,

чтобы это выглядело так:

  uglified, map =
    Uglifier.new(
      comments: :none,
      harmony: true,
      source_map: {
        filename: File.basename(from),
        output_filename: File.basename(to),
      },
    ).comp

И установил следующие npm-пакеты:

npm install terser
npm install -g uglify-js@"<3"

Затем собрал ассеты:

RAILS_ENV=production bundle exec rake assets:precompile

И вуаля! Теперь это должно работать:

 bundle exec sidekiq -e production -C config/sidekiq.yml
 bundle exec puma --config config/puma.rb -e production

Это запускает sidekiq и веб-сервер puma.

(намного дешевле и больше контроля, например, у меня уже запущен Ruby 3.2.2). Большую часть времени я потратил на обход странностей (например, поиск значений production, так как они находились не там, где должны быть). Но в остальном всё было довольно быстро!

4

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

Чем дольше сайт остаётся недоступным, тем больше потерь в репутации и оттока участников может испытать ваш сайт.

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