10年セルフホストのDiscourse管理者からの質問：再構築の一部としてランチャーのクリーンアップを行わないのはなぜですか？

インストール
1

皆さん、こんにちは。私の名前はリーです。2013年からDiscourseをセルフホストしたりしなかったりしています。開始するためにrbenvをいじくり回さなければならなかったことを覚えています。物事を実行するためにPhusion Passengerでnginxをコンパイルしなければならなかったことを覚えています。10年前に@samと、「Dockerに切り替えるのは、開発者の「俺のホームディレクトリとドットファイル地獄で動くんだ」という弱さへの降伏だ」と議論したことを覚えています（そして、完全に間違っていました！）。「バイク小屋化」という言葉を初めて聞いたことを覚えています。あの男の言葉を引用すると、私はすべてを覚えている。

数年間離れていましたが、通常1日あたり約1万PV、ハリケーン時には1日あたり約200万PV、月間ユニーク訪問者100万人になる可能性のあるヒューストン地域の気象サイトのネイティブWordPressコメントの代替として、Discourseをセルフホストする機会がありました。長年WordPressのネイティブコメントに苦労してきましたが、先週水曜日からセルフホストDiscourseで稼働しています。(しかもGraviton3で！本当に、ただ動くだけで素晴らしいです。)

私が言いたいのは、これは2025年であり、セルフホスターとして、私はまだDockerイメージスペースを手動で管理しています。本番稼働から1週間も経たないうちに、コードスニペットで語られる/dev/rootについての物語を紹介します。

[11:49:56] 0 ✓ (1.8ms)
root@discourse:/var/discourse # df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         30G   21G  9.6G  69% /
tmpfs            7.7G     0  7.7G   0% /dev/shm
tmpfs            3.1G  1.1M  3.1G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16  891M  109M  720M  14% /boot
/dev/nvme1n1p15   98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1      32G  346M   30G   2% /var/discourse
tmpfs            1.6G   12K  1.6G   1% /run/user/1001
overlay           30G   21G  9.6G  69% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:49:59] 0 ✓ (4.8ms)
root@discourse:/var/discourse # ./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: discourse/base@sha256:3696bdf18652b5455bd33795ec3b8e0f201c17a04f0e0126fc0317ed821373cd
....

[a whoooooooooooooooole lot of lines redacted]

....
Total reclaimed space: 12.43GB

[11:50:34] 0 ✓ (27.8s)
root@discourse:/var/discourse # df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         30G  6.9G   24G  23% /
tmpfs            7.7G     0  7.7G   0% /dev/shm
tmpfs            3.1G  1.1M  3.1G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16  891M  109M  720M  14% /boot
/dev/nvme1n1p15   98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1      32G  346M   30G   2% /var/discourse
tmpfs            1.6G   12K  1.6G   1% /run/user/1001
overlay           30G  6.9G   24G  23% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:55:28] 0 ✓ (3.3ms)
root@discourse:/var/discourse #

みんな、愛してるよ。Discourseも愛してる。製品に惚れ込んでいて、ほぼ永遠に使い続けるつもりだ。

でも、ちょっと、 なぜなんだ 。なぜ2025年なのに、私自身が まだ launcher cleanup をいじくり回しているんだ？なぜイメージ管理がlauncherの固有の機能ではないんだ？

繰り返すが、みんな愛してるよ。SCWのためにDiscourseを選んだのは、みんなが築き上げたものを信じているし、使うのが大好きだからだ。でも、私の貧弱なAMIのブートボリュームの半分が、無駄なゴミで占められているんだ。これは、少なくとも技術的な側面を理解しているなら、自動的に管理できるはずだ。

文句を言っているわけではない。数年ぶりに管理者の椅子に戻ってきて、ただ近況を報告しているだけだ。AIスパム検出とAIトリアージは大好きだ。特に、気候変動に関する政治的に議論を呼ぶ投稿（賛成派も反対派も）が定期的に見られる気象フォーラムではね。すべてに感謝します <3

「いいね！」 7
2

おかえりなさい、リー！

私も今週、セルフホストサイトで同じことが起こりました。バックアップが失敗していて、しばらくの間、外出中でラップトップにアクセスできなかったため、そのままにしていました。戻ってすぐにクリーンアップを実行したところ、多くのディスク容量が回復し、バックアップが再び実行できるようになりました。

「いいね！」 4
3

こんにちは、またお会いできて嬉しいです！

その理由の一部は、「十分」だったということです。私たちはホスティングでそれを使用していません。コンテナとイメージを頻繁にローテーションするため、セルフホスティングサイトとはペースが大きく異なります。

ここでのもう1つの説明は、ランチャーとDockerの間で、データ削除スケジュールについて完全な責任を取りたいシステムがないということです。ユーザーデータの削除スケジュールは、ユーザーが完全に制御できるようにする必要があります。

セルフホストサイトで、クリーンアップが新しいDiscourseベースもクリーンアップしてしまうという問題が発生したことがあり、ひどいニワトリと卵の問題につながりました。自動実行されるためにそれに気づかれなかった場合、特定するのが少し困難だったかもしれません。

ここでの簡単な提案は、自己責任で docker system prune または launcher clean をcronジョブにすることかもしれません。うまくいくでしょうか？

「いいね！」 6
4

なぜなら、それが唯一動作しているコンテナを削除してしまうことがあるからです。

すべての動作しているコンテナがまだ実行されている間に、再構築を実行する前に毎回実行することができます。

「いいね！」 1
5

良い考えです。時には単純な答えが最善であることもあります。ありがとうございます。そのように実行してみます！

6

cron経由で./launcer cleanupを実行する際に、どのように「はい」と答えることができますか？コンテナはそれほど大きな問題ではありませんが、孤立したイメージは問題です。

「いいね！」 1
7

cronで実行する必要はありません。launcherでイメージをビルドするときにのみ新しいイメージを作成します。イメージをビルドする前または後に実行するだけで済みます。

launcherのプロンプトを回避したい場合は、上記で提案されているdockerコマンドを使用できます。以下はその一例です（ただし、何をするかについてはマニュアルを読んで、それが望むものであることを確認してください）。

/usr/bin/docker image prune -a -f
「いいね！」 1
8

それをチェックする必要があります。ありがとうございます。

それ以外は何も知りませんが、今日、また、空き容量が5GB未満になったため、再構築に失敗しました。確かに、cleanupはうまくいきましたが、それは少し迷惑なだけでした。それでも、このような状況は見たくありません。

そして、ここで私がDockerの仕組みをどれだけ理解していないかがわかります:joy:もし私が正しく理解していれば、コンテナによって使用されていなかったために破棄されたそれらのイメージは、私がずっと考えていたような画像という意味でのイメージではなかったのです:face_with_peeking_eye::rofl:

「いいね！」 2
9

直接的な答えは、echo y | launcher cleanup を実行して「y」を早期に送信できるということです。

間接的な答えは、実際のランチャー クリーンアップ（後で同等になるもの）は次の 2 つのコマンドです。

docker container prune --force --filter until=24h
docker image prune --all --force --filter until=24h

そして、あなたが言及していると思われるプロンプトは、古い postgres データ ディレクトリを削除するためのものです。

rm -rf /var/discourse/shared/standalone/postgres_data_old*

ランチャーへの依存関係を削除して、これらのコマンドを直接使用できます。

「いいね！」 2
10

実際、私は ./launcher cleanup を実行した際に得た質問について言及しています。まず、停止しているすべてのコンテナが削除されます。次に、少なくとも1つのコンテナによって使用されていないすべてのイメージを削除するかどうか尋ねられます。そして、その部分が私にとってスペースを解放するもので、前回は40GB近く解放されました。

そのため、なぜそんなに多くの孤立したイメージ（jpg、pngなど）があったのか理解できなかったので、かなり混乱していました。しかし、私たちはここでまったく異なるイメージについて話しているのですよね。

はい、私は週に少なくとも2回再構築しています。あるいは、最近ある動作がおかしいプラグインを探していたときは、少なくとも十数回再構築しました。

毎回新しいイメージが作成されるかどうかは、わかりません。

11

再構築ごとに新しいイメージが作成されるため、クリーンアップしないと蓄積されてしまいます。

ランチャーは現在、ディスク容量が少ない場合にのみ、他のコマンドを実行する際にクリーンアップを促します。

「いいね！」 1
12

スクリプトで実行している場合は、応答を待ってスクリプトがハングしてしまう可能性があります（そのため、yes をパイプで渡すのだと思います）。ディスクの空き容量が10GB未満の場合は、クリーンアップを実行します。

「いいね！」 1
13

これは、私にとってうまくいくかもしれない、潜在的な回避策かもしれません。他の人に役立つかもしれないので、ここに提起します。

/etc/docker/daemon.json に data-root 設定を追加することを検討しています。これにより、Docker がイメージ（この場合は Discourse のイメージ。他にボックスでホストされているものはないため）を、ブートボリュームを破裂させない、それほどクリティカルではない場所に配置するようになるかどうかを確認します。

メタで過去のスレッドを検索すると、いくつか の 結果 がありますが、あまり役に立ちません。本番の Discourse インスタンスが炎上してくすぶるゴミの山に崩壊する前に、これが実行可能かどうか尋ねたいと思いました :slight_smile:

14

私は別のアプローチを取り、/var/lib/docker を別のファイルシステムとしてマウントしました。

私の場合は、サイト固有の理由により、/var/discourse/shared、/var/discourse/shared/data、/var/discourse/shared/app/uploads/default/original、および /var/lib/docker のそれぞれに別のファイルシステムを選択しました。しかし、/var/discourse のみを別のファイルシステムにしたい場合は、/var/discourse/share/docker ディレクトリを作成し、それを /var/lib/docker にバインドマウントできる可能性があります（もちろん、システムが静止している状態で行い、必要に応じてファイルを移動する必要があります）。

「いいね！」 4
15

それは Docker の内部をいじるよりもさらに良いアイデアですね。ありがとうございます!!

「いいね！」 1
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.