こちらが機能する可能性が高いです。例えば docker start b5f2a8a39709 でそのイメージを開始できます。
(古いイメージの一部を削除することも検討した方が良いでしょう。ディスク容量のかなりの部分を回収できる可能性があります!)
こちらが機能する可能性が高いです。例えば docker start b5f2a8a39709 でそのイメージを開始できます。
(古いイメージの一部を削除することも検討した方が良いでしょう。ディスク容量のかなりの部分を回収できる可能性があります!)
エラーが発生しました: エラー応答: デーモンから: コンテナが見つかりません: b5f2a8a39709
ありがとうございます。また、バックアップ手順ではシステムからすべてのファイルをコピーしています。どこを見ればよいか、どこにコピーすればよいか分かれば、そこにもっと新しいイメージがあるはずです。
作業を中断させて申し訳ありませんが、別のサーバーに移行することになりました。これは、専用サーバーであったため、それ自体が課題でした。昨年6月に1年間の契約を更新したばかりでした。
おそらく、Discourseチームは、サポートされなくなったサーバーで実行しているユーザーに警告を発するのが良いでしょう。私たちが発見した方法は非常に不快でした。(同じ問題を抱えた3人のユーザー、サーバーの話をしていますが、ラップトップのように速く更新されるわけではありません。)
これが意図的な変更ではなかったことを明確にしたいと思います。
また、このような古いハードウェアに直接アクセスすることはできず、何が問題なのかを正確に判断するために、コミュニティの支援に頼る必要があります。
これがgem自体のコンパイルの問題であると確信できれば、対応することができます。
@here
app.yml ファイルに以下のトップレベルキーを追加します。
base_image: discourse/base:2.0.20220621-0049-slim
これにより問題は回避されるはずですが、再構築の速度は少し遅くなります。
それはもっともですが、そのようなサーバーは依然として世界中のプロバイダーによって低価格のサーバーとして提供されています。
多くの小規模なオープンソースプロジェクトにとって、そのようなサーバーは価格面で理想的であり、多くの場合、32GBのRAMを搭載したIntel XeonやAMD Ryzenを購入する余裕はありません。
ハードウェアがなくソフトウェアをテストできないことは完全に理解できますが、このスレッドでのやり取りから、私たちがそれを確立した後、まったく反応がありませんでした。
「すみません、調査します」といった簡単な一言で十分だったのに、私たちを放置しました。
この変更でテスト中です。
ビルドは同じように失敗するようです。
これは、containers/app.yml に以下を追加する変更によるものです。
base_image: discourse/base:2.0.20220621-0049-slim
一番上の方に。
つまり、問題はプリコンパイルされたバージョンのgemを出荷することではなく、アップストリームのgemがそれらの古いCPUでコンパイルできないということになります。
oj gemに対してissue #789を起票しました。
承知いたしました。最近のDockerイメージを復元したいのですが、rsyncバックアップから取得します。それらを見つけて、1つを復元/起動する手順を教えていただけますか?よろしくお願いします!
./launcher start app を試しましたか?
それでもうまくいかない場合は、最後に正常に機能したコミットから再構築するために詳述した別の方法を試してください。
はい。それでウェブサーバーは起動しますが、実際にはどのスレッドにもアクセスできず、ただ回転するだけです。
これは役に立ちません。
問題は、更新されたgemが命令をCPUでサポートされているかどうかを確認せずに使用してしまうことです。
これは、以前の動作するgemバージョンをインストールするため、Discourseインスタンスを復旧させるのに役立ちます(Bryanのインスタンスを復旧させるために行ったことで証明されています)が、はい、それ以降のアップデート(admin/upgrade経由)は同じ問題を引き起こします。
新しいビルドを試しても、以前のインスタンスを実行しようとしても、うまくいっていません。週末が近づいているので、状況がgem側で修正されることを期待して、来週までこのままにしておくかもしれません…
これはどの手順でしたか?このスレッドのさまざまなアイデアをたどろうとして、正直少し混乱しています。ありがとうございます!
この投稿の後半:
試してみます。ありがとうございます。
別の回避策として、app.yml に以下を追加できます。
hooks:
after_code:
- exec:
cmd:
- sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
これもあって、アップデートはまだ安全ではないと仮定してよいですか? 現在、古いコミットでビルドしています。