Dockerのインストールに利点はありますか？

インストール
1

ドキュメントや多くのスレッドでDockerが唯一（良い）方法であると推奨されていることは承知していますが、その理由を知りたいと思いました。月額3.50ドルのAmazon Lightsail Debianボックスを入手し、20分でDiscourseを稼働させました。rbenvを使用してRuby 3.2.2をインストールし、残りは簡単でした。Discourseは、なぜ./config/discourse.confやGlobalSettingがあり、これらの値を指定するconfig/environments/production.rbではなく、GlobalSettingが使われているのかといったRailsの規約に従っていないように思えました。これはDockerイメージが最終的に作成するものなのでしょうか（また、sidekiq.ymlに本番環境の値がないことも）。

Dockerで実行することに利点はありますか？何か見落としていることがあるのでしょうか…

2

本当に簡単なバージョンは、標準のインストールを使用していない場合、ここでは支援を提供できないということです。そのパスから逸脱すると、問題が発生する可能性が多すぎます。

「いいね！」 4
3

なるほど、OSの違いなどがあるのですね。すでに「どうやったのか」と聞かれているので、ここに投稿しておきます。

Ruby 3.2.x（rbenv経由でOSに依存しないように）、Node v16.19.x/npm 8.19.x、PostgreSQL（11以上のバージョンならおそらくどれでも）が必要です。

  1. Rubyのバージョンを指定する.ruby-versionファイルを作成し、インストールしました（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の慣習のように思えます）ことに驚きました。すべてのDB設定は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 Webサーバーが起動します。

（はるかに安価で、より多くの制御が可能になります。たとえば、すでにRuby 3.2.2を使用しています）。ほとんどの時間は、quirks（たとえば、production値が本来あるべき場所にないことなど）を回避するのに費やされました。しかし、それ以外は非常に迅速でした！

「いいね！」 2
4

それはかなり印象的です。しかし、問題は、サイトが壊れるような問題が発生した場合です。修正を手伝える可能性のあるコミュニティの非常に限られたメンバーに立ち往生する可能性があります。したがって、最大の潜在的なリスク/欠点は、完全な再インストールが必要になる可能性のある、長期間または壊滅的なダウンタイムです。

サイトがダウンしている時間が長ければ長いほど、サイトの評判とメンバーの損失は大きくなる可能性があります。

実験中で、安定した本番サイトに依存していない場合は、時間以外に失うものはあまりありません。

「いいね！」 1