root@www:/var/discourse# ./launcher start data
x86_64 アーキテクチャが検出されました。
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -h www-data -e DOCKER_HOST_IP=172.17.0.1 --name data -t -v /var/discourse/shared/data:/shared -v /var/discourse/shared/data/log/var-log:/var/log --mac-address 02:e6:17:cc:a2:dc local_discourse/data /sbin/boot
イメージ 'local_discourse/data:latest' をローカルで見つけられませんでした
docker: daemon からの応答エラー: local_discourse/data へのアクセスをプルできません。リポジトリが存在しないか、'docker login' が必要になる場合があります: 要求されたリソースへのアクセスが拒否されました。
詳細については 'docker run --help' を実行してください
root@www:/var/discourse#
何か提案はありますか？そのエラーメッセージを検索しても、このスレッドしか見つかりません。
これは、./launcher cleanup を実行してデータコンテナを削除した可能性があることを示唆しています（コンテナが失われる他の方法が私には見えませんが、間違っている可能性もあります）。もしそうであれば、そして実際、いずれの場合も、私が推奨するのは、新しいドロップレットを起動し、yml ファイルをコピーして、最新のバックアップを復元することです。
魚を釣る方法を教えるのではなく、魚そのものが欲しい場合は、私に連絡するか、Marketplace で質問してください。
「いいね！」 1
サイトを復旧させたのは、データコンテナがなくなった後、data.ymlを編集してテンプレートをpostgres13テンプレートに変更し、その後データコンテナを再構築したことです。そうすることでデータコンテナを起動できるようになり、web_onlyコンテナを削除して起動しました（作成時に見つけたデータコンテナとは異なるデータコンテナには接続できません）。その後、サイトは復旧しました。
データベースのアップグレードを再試行すれば機能したと確信していますが、念のため、新しいデータベースバックアップを作成し、新しいドロップレットに移動し、データベースを復元したところ、彼は再び稼働しています。
「いいね！」 1
問題がどのように発生したか、例えば他の人がそれに該当しない可能性が高いことを安心させるために、いくつか説明していただけますか？
「いいね！」 1
Tk;dr: いいえ。
元の問題が何であったかを伝えることはできません。コンテナが削除された後、pg13テンプレートに切り替えることが問題の解決策でした。それはpg15トピックが実行するように指示していることの一部です。ディスク容量の問題があったのでしょうか？
ああ、なるほど…かなり古いシステムをpg13でアップグレードしたのですね。かなり珍しい状況です。
アップグレードは、PostgreSQLのアップグレードに14GBの空きディスク容量が必要でしたが、ドロップレットにはそれだけの容量がなかったため失敗しました。
ディスク容量を拡張した後も機能しなかった理由は、上記で@Jagsterが提案したように、2コンテナインストールには不適切な./launcher cleanupを実行したためかもしれません。
Discourseのアーキテクチャをよく知らない者にとっては、問題が少ないように思われるため、いつかは単一コンテナインストールに切り替えたいと思っています。また、セルフホスティングは避けたいのですが、サイトには多くの写真があり、ディスク容量がなくなったときにDiscourseホスティングが月額$100から$200に跳ね上がりました。サイトのGoogle Adからの収入は月額約$30〜$40しかありません。
私は2年前にしかDigital Oceanに移行していません。
それでも、1週間前に容量がなくなった時に実行しました。
@pfaffman がその問題だったのではないかと示唆していましたが、私には全く分かりません。
いいえ。それはシングルコンテナセットアップでも同様の問題を引き起こしたでしょう。
問題は、ディスク容量を確保しようとしたときに、停止していたデータコンテナを破壊してしまったことです。重要な間違いは、データコンテナとウェブコンテナが停止している間にクリーンアップを実行したことだと思います。
2コンテナセットアップは、Postgresのアップグレードを遅らせることを容易にしたため、いくつかの問題からあなたを救いました。しかし、この場合、アップグレードでaiプラグインが追加され、データコンテナでPostgresのアップグレードを行う必要があったため、あなたは行き詰まってしまいました。
アップグレードを試みる前にランチャーのクリーンアップを実行していれば、あるいはクリーンアップを実行せずにサイズ変更していれば、うまくいったかもしれません。
したがって、いくつかの問題がありました。
- ディスクを使い果たしたDockerイメージが多すぎる（ディスクが小さすぎる可能性）
- PostgreSQLのアップデートが必要
- Aiプラグインがコアに追加され、データベースのアップグレードが強制された
- PostgreSQLのアップグレードが何らかの理由で失敗し、データコンテナを起動する必要があることを知らなかった（メッセージに記載されていると思います）
- データコンテナをシャットダウンした状態でランチャーのクリーンアップを実行し、クリーンシャットダウンを実行するために必要なコンテナを削除してしまった
「いいね！」 1
ディスク容量を確保するために行ったことは、ドロップレットのサイズ変更だけです。
それ以外に行ったことはすべて、コマンド出力、ここでの投稿、またはリンクされたトピックの提案に基づいて、失敗したアップグレードを完了しようとしたことです。
「いいね！」 1
@pfaffman 私のサイトは明らかなスパムで攻撃されています。アップグレードでスパム対策ツールが失われた可能性はありますか？
可能性は低いです。Akismetが設定されていたかどうかはわかりませんが、もはやあまり効果的ではありません。現在推奨されているのは次のとおりです。Discourse AI - Spam detection AIプラグインは現在コアの一部であり、インストールされています。
お手伝いが必要な場合は、私にメールしてください。
編集：ここで説明されている変更こちらがスパムの増加を説明している可能性はありますが、可能性は低いです。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.