Upgrade failed spectacularilyからの議論を続けます。
Discourseのアップデートを実行する前に、VPSにアップグレードが必要かどうかを確認する最善の方法は何ですか？ありがとうございます。
「いいね！」 3
私の記憶が確かであれば、OSのバージョンが古い場合やDockerが古い場合にアップグレードできると思います。
「いいね！」 1
Ubuntu LTS（通常はDiscourseに推奨されるディストリビューション）を実行している場合。私の理解では、無料版の各エディションには5年間のサポートサイクルがあります。
したがって、リストから私の理解では、18.04または20.04を実行している場合は、OSのアップグレードを検討する必要があります。18.04が確定しており、20.04のサポートが4月に終了するため、これも検討すべきです。
もう1つのコンポーネントは、Dockerバージョンの互換性を確認することです。この部分は正直なところわかりません。ただし、推測ですが、Ubuntu 22.04 LTSはDiscourseが必要とする最新のDockerをサポートする可能性がありますが、より詳しい知識を持つ人に意見を求める必要があります。しかし、ここMetaで検索してもこの情報が見つかるかもしれません。
「いいね！」 1
Discourse 3.4 は Docker 24.0.7 min を探しています。
Google 検索によると、Ubuntu 22.04 LTS はこれをサポートしているようです。
もちろん、最新の Ubuntu 24 LTS でもサポートされています。Ubuntu 20.04 LTS でもサポートされているようですが、この LTS のサポートは 2025 年 4 月に終了するため、アップグレードを検討すべきだと思います。ただし、OS をアップグレードする前に時間が必要な場合は、理論的には問題ないはずです。
お使いの OS のバージョンをご存知ですか？ Ubuntu LTS を実行していると仮定しています。
私の Docker バージョン (20.10.21) はそれよりも古いですが、Discourse のバージョンは 3.4.0.beta4-dev です。Discourse は現在 3.4.0.beta4 へのアップグレードを求めています。「重要なアップデートが利用可能です。アップデートしてください！」
2つの質問があります。
-
リリースノートのどこかに要件が記載されていますか？ 私は常にアナウンス投稿をざっと読んでいましたが、Docker や Ubuntu の要件が記載されているのに気づきませんでした。
-
Discourse を再度アップグレードする前に、Ubuntu 24.04 とそれに付属する Docker バージョンにアップデートすべきだと思います。それで合っていますか？
よろしくお願いします。
「できない」ということですか？ そうだと思います。
要件が満たされていない場合、フォーラムを台無しにすることなく、アップグレードスクリプトは正常に終了するということですか？
discourse_docker/launcher at main · discourse/discourse_docker · GitHub で確認したところ：
docker_min_version='20.10.0'
docker_rec_version='24.0.7'
ですので、今のところ大丈夫かもしれません。24.0.7 について間違っていたことを願っていますが、もしかしたら私自身が間違った場所を見ているのかもしれません。確認して教えていただけますでしょうか？ 感謝いたします。ありがとうございます。
「いいね！」 1
Discourse 3.4のDocker要件は、コマンドラインアップグレードに失敗したトピックから取得しました。引用されたトピックのJayが、提供されたログに基づいてDockerのアップグレードが必要だと述べたか、別のトピックで述べたと思います。ログには、Dockerが私が言及した最小バージョンである必要があると記載されています。
おそらく記載されているのでしょうが、正直に言うと、それらを完全に読み通すのが得意ではありません。ここで検索してみて、確認してみます。
Ubuntu LTSがバージョン18.04の場合は、間違いなくそうすべきです。Ubuntu 20.04 LTSの場合は、言及されている通りです。コマンドライン経由で手動でアップグレードできると思います。私の記憶が正しければ、Dockerのアップグレードに関するトピックがあります。私がリンクしたDockerのドキュメントには、アップグレード方法の説明が含まれているはずです。しかし、最初に従うべき推奨手順があるかもしれないので、トピックがあるかどうかを確認することをお勧めします。
私もDiscourseに関してはまだ多くのことを学んでいることを忘れないでください。JayやRobert(Merrifield)のような人々は、これらのトピックに関して、より多くの経験と理解を持っている数少ない人々です。
しかし、最も重要なステップは、バックアップを作成することです。私の意見では、サーバーのスナップショットとDiscourseのバックアップを作成することをお勧めします。計画されたダウンタイムを告知したサーバーバックアップは、アップグレード前にスナップショットをロードできるため、良いでしょう。Discourseのバックアップも同様にうまく機能すると思います。
「いいね！」 1
わかりません。共有されたログを含む投稿を参考にしていただけです。
しかし、こちらに Documentation からのガイドがあります。これが役立つかもしれません。
フローチャートを作成して回答するとしたら、最初の質問は次のようになります。
以下のすべてが当てはまりますか？ 当てはまる場合は、ご自身の経験に従って進めてください。当てはまらない場合は、少なくとも 1 か月経過している限り、最新の LTS を使用するようにしてください。
- 経験豊富なシステム管理者である
- 安全な場所に最新のバックアップがあり、それを復元できると確信している
- コマンドラインでのアップグレード方法を知っている
- meta で問題を報告する際に、ログの関連部分を見つけて引用する方法を知っている
/etc/lsb-release を読んで現在の OS バージョンを確認してください。
root# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS"
最近更新されたもので、LTS であり、2 年以上経過していない必要があります。最初の 2 桁は年数です。ただし、1 か月未満の LTS は信頼しないでください。
「いいね！」 3
新しい仮想マシンを起動し、Discourseサイトをrsyncで別のVPSに移行する で説明されているように移行することをお勧めします。ダウンタイムを気にせず、システムが壊れる可能性があっても構わないのであれば、複数の dist-upgrade を試すことができます。もしそうするのであれば、復元できるようにスナップショットを作成する必要があります（これもダウンタイムが発生します）。
「いいね！」 1
18.04 から 20.04 への移行は、同じサーバー上で実施したと思います。おそらく、How to upgrade your Ubuntu release - Ubuntu Server documentation のような手順に従ったのだと思います。100%確実ではありません。この点について、どう思われますか？
インプレースアップグレードではなく移行するもう一つの利点は、より良い価値のオファーを得られる可能性があることです。私の場合は、x86からARMに切り替えたことで、同じホスティングサービスで、同じ価格でより多くのストレージを備えた構成になりました。また、別のホスティングサービスに変更する可能性もあり、別のケースでもそうしましたが、やはりより良い取引になりました。
「いいね！」 2
Hetznerでは、ARMサーバーはx86サーバーよりも、同じスペック（vCPU、RAM、ストレージ）でわずかに安価です。
特に、体感ではより高速です（Discourseの再構築速度とページ読み込み）。
残念ながら、Discourseのベンチマークはありませんが、最近ビルド時間の比較を行いました。
| プロバイダー | 価格 | ディスク | CPU | RAM | ビルド時間 | データセンター |
|---|---|---|---|---|---|---|
| Hetzner CX22 (x86) | €3.95 | 40GB | 2 | 4 | 9m56s | DE, FI, SG, US (2) |
| Hetzner CAX11 (arm64) | €3.95 | 40GB | 2 | 4 | 5m45s | DE, FI |
公式のARM互換の#mail-receiverイメージがないことに注意してください。
参照：
「いいね！」 4
5分で再構築？すごいですね。私だと2〜3時間かかります。
DigitalOceanの最も低いプランである2GBメモリのドロップレットを使用しており、完了までに約10分かかると考えています。
「いいね！」 1
それは「Google検索」ではなく、Geminiです。特定のバージョン番号や互換性のあるバージョンについて言及するAIの出力には注意が必要です。LLMはこのような詳細を扱うのが得意ではないためです。しかし、もし確実な情報源を見つけられるなら、それに越したことはありません。
こちらが私が得た情報です。異なります。
「いいね！」 2
ありがとうございます、良い指摘です。私が投稿したDockerドキュメントへのリンクも、Geminiの出力が正しかったことを確認しました。しかし、アドバイスありがとうございます。今後はAIの出力には間違いなく注意します。
「いいね！」 2
rsync のトピックは、質問や提案されたバリエーションが多すぎて理解できないと思っていました。そこで代わりにこれを行い、すべてうまくいっているようです！
「いいね！」 1