ありがとうございます。しかし、_アプリの再構築_には約3時間かかります！
しかも、これは大規模なVPS上でです。
テーマを追加・削除するのと同じように、プラグインを削除できるようになると良いと思いませんか？
将来的な機能として検討すべきことでしょうか？
よろしくお願いします！
「いいね！」 1
すみません？！ 約20分で終わるはずですが？！
「いいね！」 1
ここにはありません。
最初のインストールには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.657GiB、カーネルバージョン: 5.15.0-43-generic、オペレーティングシステム: Ubuntu 22.04 LTS、50GB SSDドライブ、2.5コア、5スレッド Intel® Xeon® CPU
…
何が問題なのかよくわかりませんが、非常に時間がかかること以外は考えられません:confused:
3時間というのは、確かに非常に長すぎます。この問題を調査し、最優先で解決する必要があります。
ビルドログには「視覚的な一時停止」がありますが、これは正常な動作です。しかし、この遅延は正常ではありません。
私の推測では、ビルド中にスワップメモリの使用を開始している可能性がありますが、私はSAではありません。そのマシンで他に何か実行していますか？
ダウンロードには解凍が必要で、これは計算コストが高いですが、それは誰にとっても同じ画像です。
参考までに、私は今、https://scaleway.com の 2GB 2vCPU マシンでサイトを再構築しましたが、13分46秒かかりました。
「いいね！」 4
いいえ、これはこの Discourse インスタンス専用の VPS です。また、同じ会社で他の多くの VPS を実行しており、すべて非常にスムーズに動作しています（ただし、これらは Discourse インスタンスではなく、カスタム PHP や WP/CP CMS インスタンスなどの他のアプリです）。
スワップの使用状況は把握しておらず、それを正当化できるようなリソース使用量の急増も見られません。
現在 building.... と表示されており、前回よりは少し速いようですが、それでも明らかに 20 分以上かかっています。
サーバープロバイダーに、彼らの側で何か異常がないか確認するように依頼しますが、彼ら自身が管理する Discourse インスタンスでもビルドに約 2 時間かかったと個人的に言われたことを思い出します。（追伸：これらの VPS は Hetzner マシン上にあり、サードパーティ経由でレンタルしています。これ以上良いものは期待できないと思います。）
いずれにしても、テーマを追加・削除できるのと同じように、プラグインを追加・削除できると素晴らしいという私の提案は変わりません。何か検討していただけることはありますか？
私は何も知りませんが、知る限りでは、Discourse はコンパイルされた JavaScript が多いため、それは不可能ではありません。コアの動作や機能の変更が必要な場合、再構築が必要です。
Varnish と同じような状況です。
「いいね！」 1
承知いたしました…
ところで、サーバー担当者に確認したところ、メモリ使用率が100%に達していたとのことです。
5GB？？？ 5GBのRAMを消費するのは、どんな用途であっても多すぎます。
Discourseの要件では1GBのRAMが必要とされています！
そして、現在は以下の状態で停止しています。
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
そのため、プロセスが中断されるため、サーバーをアップグレードすることさえできません。
本当に、これはサーバーの問題ではないと思います。1GBが必要なのであれば、5GBで十分すぎるはずです。
何かが根本的に間違っています。
他の人はもっと良い経験をしているはずだと理解しています（2GBでアップグレードするように言った@merefieldさんを見ていますが）、しかし、私たちにとっては期待通りに機能していません。
とにかく、これはこのスレッドでは話題がずれていると思います。
「いいね！」 1
サイトを再構築しました。4GB、3vCPUで、15分未満でした（つまり、追加のメモリ/CPUは私のケースではそれほど役立ちませんでしたが、それでも数時間よりはるかに短いです！）。
気づいた唯一の点は、私のVPSが推奨されているaufsやoverlayの代わりにvfsを使用していることです。
しかし、Can't run ./launcher rebuild app - Docker storage driver is unsupported - #45 by david によると、それは重要ではないはずであり、そのため、そうでなければDiscourseを実行することさえできないため、--skip-prereqsでランチャーを実行します。
ストレージドライバーの要件について、他に何かあるのか疑問に思っています。
「いいね！」 1
それは少し…楽観的すぎますね。テスト目的であれば十分かもしれませんが、それでも少しきついかもしれません。現実的には2GBの方が近いです。
ただし、大規模なインスタンスには4GBで十分です。しかし、コアの数とパワーも重要な役割を果たします。
それでも…5GBあって再構築にそんなに時間がかかるなら、何か問題があるはずです。
私はDigitalOcean/4GB/2 Intel vCPUを使用しており、再構築には約25分かかります。
あなたのシステムは正確には何ですか？それに加えてapp.yml — 何かカスタム設定はありますか？
こんにちは、唯一のカスタマイズは前述したこと（aufs/overlayの代わりにvfs）です。
残りはバニラです。
サーバー：
サーバー総メモリ：4.657GiB、カーネルバージョン：5.15.0-43-generic、オペレーティングシステム：Ubuntu 22.04 LTS、50GB SSDドライブ、2.5コア、5スレッド Intel® Xeon® CPU
yamlは、これらの追加プラグインを除いてオリジナルです。
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
そのデータから、なぜ再構築にそれほど時間がかかるのか分かりません。
代わりに、どこか別の場所に同じサイズのUbuntu VPSを立ち上げてみてはどうでしょうか。ホスティング会社に問題があるかどうかを確認するためです。数ドルと1〜2時間で済みます。
JavaScript のプリコンパイルには多くのメモリが必要です。スワップの追加を試してください。
オーバーレイ
そのテストには理由があるのだと思います。これが問題の原因である可能性があります。
「いいね！」 1
バニラ Discourse で 5 GB の RAM が、自動的に割り当てられたもので完全に問題ないはずのより小さいものよりも多くのスワップを必要とするのはなぜですか？
なぜなら、本当にやるべきことよりも簡単だからです。
スワップを追加すると役立つかもしれませんが、それが最大の課題ではありません。
「いいね！」 3
おそらく、ディスコースコンテナをデプロイする前にこれを試すべきでした: How to change the Docker storage driver – Webdock
ホストがコンテナをデプロイしたときに指示したこと（ローダーファイルを編集するか、チェックを無視すること）とは対照的に、ストレージドライバーを変更することは可能であるようです。
しまった、今となっては手遅れだと思います。
とにかく、もしこれが問題の原因であれば、それはユーザーの過失ということになるでしょう。私のミスです 
そうは思いません。
また、2つのコンテナの設定により、古いコンテナが稼働し続けている間に新しいWebコンテナをCSVで再構築するため、ダウンタイムが短縮されます。
「いいね！」 1
サイトの規模はどれくらいですか？メモリの問題を解決するために、スワップを追加することをお勧めします。
1GBのスワップを備えた1GBの空のインスタンスは、小規模なテストコミュニティでは問題なく動作しますが、規模が大きくなると十分ではなくなります。スワップは間違いなく違いを生みます。
インターネットへの太いパイプを持つデータセンターにある「巨大な」VPSで再構築するのに3時間かかり、私のデスクにあるクレジットカードサイズのボードで実行されている https://discourse-on-a-pi.falco.dev の私のインストールを、第三世界の標準的な家庭用プラン経由でインターネットに接続して再構築するのにわずか14分（新しいコンテナイメージがある場合はさらに4分）しかかからない場合、彼らがあなたに販売している製品には何か問題があります…
「いいね！」 15
サーバーのメモリ使用率はどうなっていますか？ 再構築を開始する前に容量の上限に近い、または上限に達している場合、多くのスワップが発生し、すべてに非常に時間がかかる原因となります。
もしそうであれば、可能であればサーバーで実行されている他のものを一時的に無効にすることをお勧めします。
「いいね！」 3