上記のエラーが発生しました。何らかの操作を実行しようとした際のことです。なぜこのようなことが起きているのか、全く見当がつきません。
単に
./docker rebuild app
を実行して、結果を確認してみましたか？以前は最初に git pull が必要でしたが、今は不要だと思います。
そうでない場合、app.conf ファイルを見直す必要があるかもしれません。最近編集しましたか？
「いいね！」 1
いいえ、最近編集していません。昨日サイトがクラッシュしたため、クリーンアップを実行し、その後以下を実行しました。
rm /var/discourse/shared/standalone/backups/default/*
その後、./launcher rebuild app で再構築しました。
それ以降サイトは再び動作し始めましたが、現在は再び停止してしまいます。
「いいね！」 1
申し訳ありません、意味は以下の通りです。
./launcher rebuild app
つまり、あなたは正しい手順を踏んでいます。
「いいね！」 1
Discourse Doctorをご覧になりましたか？
「いいね！」 1
わかりました、ストレージの問題ですね。では、今すぐ空き容量をどう確保すればよいのでしょうか？初心者で申し訳ありません。
discourse-doctorを実行したところ、ストレージがいっぱいである旨を伝える複数の行が表示されました。
「いいね！」 1
サーバーに他に何かありますか？なければ、Discourseのバックアップなので削除して問題ないでしょう。
「いいね！」 1
バックアップ削除の手順を詳しく教えていただけますか？これまで一度も理解できていませんでした。長期間ストレージの問題に悩まされているので、これで完全に確認したいのです。
いいえ、サーバーには他に何もありません。
「いいね！」 1
まず最初に試すべきことは、次のコマンドを実行することです。
./launcher cleanup
それでも解決しない場合は、次を試してください。
./discourse-doctor
まだ問題が解決しない場合は、以下のディレクトリから古いバックアップを削除することも検討できます。
/var/discourse/shared/standalone/backups/default
これらの手順の結果について、ぜひお知らせください！
「いいね！」 4
@seshu_ram さん、こんにちは
コンテナを再構築する際、プロセスが孤児イメージを残すことがよくあります。コンテナを頻繁に再構築している場合、これらのイメージは多くの容量を占有する可能性があります。
実際、これらの孤児イメージは私が削除するまで、当社のサーバーでほぼ 100 GB 以上を占有していました。簡単に確認できます。
以下のコマンドの出力を投稿してください。
docker images
出力は、 fenced markdown を使用してテキスト（コピー＆ペースト）で投稿してください。ターミナルのスクリーンショット画像は、モバイル端末では読みづらい場合があります。
ありがとうございます。
注:
なお、launcher cleanup もこれらの孤児イメージを削除します（過去 24 時間に基づくと考えています）。
if tty > /dev/null; then
read -p "Would you like to attempt to recover space by cleaning docker images and containers in the system? (y/N)" -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]
then
$docker_path container prune --force --filter until=1h > /dev/null
$docker_path image prune --all --force --filter until=1h > /dev/null
echo "If the cleanup was successful, you may try again now"
fi
fi
「いいね！」 3
local_discourse/app latest 674fd54f165f 4 分前 2.5GB
<none> <none> f3a4104c3f75 22 時間前 2.5GB
discourse/base 2.0.20201221-2020 c0704d4ce2b4 11 日前 2.11GB```
「いいね！」 1
これで動作しました。私のウェブサイトが現在ライブ状態です。本当にありがとうございます。お時間をいただき、心から感謝申し上げます。大変助かりました。
「いいね！」 4
@seshu_ram さん、こんにちは
参考までに：この孤立したイメージを削除して、ディスク容量を少し取り戻すことができます。
f3a4104c3f75
docker image rm f3a4104c3f75
私の記憶では、ランチャーのクリーンアップ処理は、24 時間未満のイメージを削除しません。
あるいは、ご都合の良いタイミングで数時間後に再度クリーンアップを実行することも可能です。
「いいね！」 5
最近のDiscourseのコマンドラインアップデートでディスク容量をかなり消費していることに気づきました。
root@endoffice-b:/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:
deleted: sha256:284403a252ba061b3ab97f4bfe293ac5e8f05f39ada429d718f58e56191251c2
deleted: sha256:6b6899d54d4dd1f21568956b652975f7c0b9e439978b8cc53036efc46baaf971
untagged: discourse/base:2.0.20211118-0105
untagged: discourse/base@sha256:74b41fffd4f05433eb7c9b72954b1f5f8b15cd0e802bb724c96b7d699c3f6fa1
deleted: sha256:b6cc7cf8974a6ef7bb64c36f4592af261cda0d5565bd91da603568ce26968048
deleted: sha256:c1455b2fdbca024c36c4e75746051b77c3637020cfa1e36a41440292a8c39424
deleted: sha256:77b323d4ec74aad770337f99a60e862a64ccc53f4775b5f4945df0e606f78b90
untagged: discourse/base:2.0.20220128-1817
untagged: discourse/base@sha256:dcb4eb8e41a2e84f776f80587f308d167a54ad7ff4ba616199891828bbd4ddae
Total reclaimed space: 3.54GB
これは両方のインスタンスで発生しました。もう一方は3.538GBでした 
私は通常、Discourseのアップデートごとに./launcher cleanupを実行するようにしていますが、月に一度アップデートしているので、最後のアップデートだけで約4GBのディスク容量を消費したことになります。@falco @sam これは懸念すべきことでしょうか？
「いいね！」 4
避けられないことだと思います。過去数ヶ月でベースイメージを2回ぶつかりました。私たちができることはあまりありません。サーバーのクリーンアップでベースイメージが2つ削られたようです。
「いいね！」 3
@anon43908006、こちらにガイドがあります。
ドメイン名を変更する際の多くの考慮事項が記載されていますので、ご確認ください。
「いいね！」 1
全体的なアップグレードサイズの増加についてできることが少ないのか、それとも最近のベースイメージの更新の急増（将来それほど影響しないもの）についてできることが少ないのか、どちらを明確にしていただけますか？
驚いています。ユーザーが非常に少ない小さな Discourse がたくさんあるのですが、最近この問題に遭遇しました。アップロードなどもしていません。クラウドインストールが次のサイズ（2GB RAM/1vCPU/50GB SSD）へのドライブスペースの推奨に近づいているのではないかと疑問に思っています。
「いいね！」 5
チャットで@falcoにこの件について尋ねたところ、最近は依存関係の更新によりベースイメージの変更が多く、過去約6か月間は通常よりも多くのディスク容量がアップグレードに使用されているとのことでした。
「いいね！」 5
ドメイン名の変更で問題が発生したとのこと、申し訳ありません、@anon43908006様。
こちらは#supportですので、お客様の具体的な状況を説明する新しいトピックを作成されることをお勧めします。このトピックは一般的な傾向についての議論であり、お客様の状況にはより詳細な議論が必要な場合があります。
ご希望であれば、私（@maiki）に言及していただければ、お客様のサイトで何が起こっているのか喜んで議論させていただきます。
「いいね！」 6
Discourse のバックアップを試みると、同じ No space left on device エラーが発生します。
[2022-11-15 08:23:38] EXCEPTION: /var/www/discourse/lib/discourse.rb:131:in `exec': Failed to gzip archive.
gzip: /var/www/discourse/public/backups/default/forum-leasehackr-2022-11-15-080439-v20221110175456.tar.gz: No space left on device
私のバックアップと画像アップロードは DigitalOcean の Spaces で設定されており、ここ数年は問題なく動作していましたが、最近になって問題が発生するようになりました。以下は、これまでに試したことです。
- DO Space のすべての非表示マルチパートアップロードをクリアしました。DO Space には 100GiB 以上のストレージが利用可能であるはずです。
- 以下のコマンドを使用して、再構築とクリーンアップを試みました。
cd /var/discourse
apt-get update
apt-get upgrade
apt-get autoclean
apt-get autoremove
./launcher rebuild app
./launcher cleanup
バックアップがまだ失敗し続ける理由を知っている人はいますか？よろしくお願いします！