再ビルドを試しましたが、この時点で失敗しました。
- dist/javascripts/media-optimization-worker.js: 5.01 kB (1.74 kB gzipped)
- dist/javascripts/pikaday/1.8.2/pikaday.js: 42.54 kB (9.67 kB gzipped)
- dist/javascripts/squoosh/mozjpeg_enc.js: 39.03 kB (10.81 kB gzipped)
- dist/javascripts/squoosh/squoosh_resize.js: 4.53 kB (1.28 kB gzipped)
Done in 355.08s.
I, [2024-07-08T07:59:42.015855 #1] INFO -- : cd /var/www/discourse & su discourse -c 'SKIP_EMBER_CLI_COMPILE=1 bundle exec rake themes:update assets:precompile'
Purging temp files
Bundling assets
I, [2024-07-08T07:59:57.247206 #1532] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
I, [2024-07-08T07:59:57.264957 #1532] INFO -- : Writing /var/www/discourse/public/assets/service-worker-9764e1cd771b38dbe65a0d1e42d89cb2cb5f72b266ab7316e55d3371cb0ac870.js
I, [2024-07-08T07:59:57.271269 #1532] INFO -- : Writing /var/www/discourse/public/assets/locales/i18n-3b40e842fd72b9bcc74ea83e094c823cd9ca535e4ecc5e78722e6f99d3656137.js
I, [2024-07-08T07:59:57.277082 #1532] INFO -- : Writing /var/www/discourse/public/assets/scripts/discourse-test-listen-boot-9b14a0fc65c689577e6a428dcfd680205516fe211700a71c7adb5cbcf4df2cc5.js
I, [2024-07-08T07:59:59.103776 #1532] INFO -- : Writing /var/www/discourse/public/assets/locales/ar-dfed7a58f30378bc60d7a2cc8d6347524f68b272ae012f0232604f730e442f91.js
I, [2024-07-08T08:00:00.112555 #1532] INFO -- : Writing /var/www/discourse/public/assets/locales/be-e12ac4c99df2289f422efd371dd3da766754aecb1189ea763fe003376aca9028.js
rake aborted!
Zlib::BufError: buffer error (Zlib::BufError)
「いいね!」 1
kuaza
(kuaza)
24
質問があります。S3を使用していますか?私もそう疑っています。
Roi
26
毎日制限に達したときにのみ発生するかどうかはわかりませんが、ここでは2〜3か月間常に発生しています。他の人も同様の問題を抱えているようです。
Maxmindファイルをローカルディレクトリから提供するのは良い考えかもしれません。他の用途でもダウンロードしているので、すでにあります。
そして、Discourseコンテナ内の共有ディレクトリにMaxmindファイルを提供して、常に最新バージョンを入手できるようにするのはさらに良いかもしれません。前述したように、とにかくダウンロードして、1日1回ファイルを更新しています。
「いいね!」 1
kuaza
(kuaza)
27
問題は制限に関連していないと思います。言い換えると、間違ったキーまたはアカウントIDを入力した場合でもエラーが発生します。ここで問題を解決する方法は次のとおりです。エラーが発生した場合は、古いデータベースを使用し、再構築を続行させます。もちろん、この問題の根本原因を特定することが非常に重要です。
2日前に例を作成しようとしましたが、エラーが発生しました。その日はその日の最初の再構築だったので、制限とは関係ありませんでした。次に、新しいキーを作成して試したところ、機能しました。ここに状況があります。キーを作成すると、アクティブになるまでしばらく時間がかかります。すぐに再作成すると、エラーが発生します。
面白い 
Roi
28
まあ、私のキーは古く、使い始めてから一度も変更していません。新しいキーを作成すると機能するのはなぜですか?アクティブになるまで時間がかかると言いましたよね。それならエラーが出るはずですよね?
それは良いアイデアですね。あるいは、私が提案したように、ローカルディレクトリからファイルを提供するという方法もあります。すべてオプションです。しかし、何週間もリビルドが運任せになっているのは本当に腹立たしいです…
「いいね!」 1
tgxworld
(Alan Tan)
29
これはMaxmindの利用規約に違反するため、全員に個別にファイルをダウンロードするためのAPIキーを提供してもらう必要があります。
日次制限に達した場合の問題を確認するために、自分自身を割り当てます。
「いいね!」 2
pfaffman
(Jay Pfaffman)
31
リビルドに失敗し、maxmind設定をオフにしてイメージをビルドしました。その後、コンテナ内で設定を元に戻し、正常にrakeタスクを実行しました。
データベースをダウンロードせずにリビルドし、コンテナ起動時にデータベースをダウンロードするようにすることは可能でしょうか?
また、ダウンロードが失敗した場合でもブートストラップが成功するはずのPRを追加しましたが(マージ済み)、ブートストラップは引き続き失敗しています。
「いいね!」 2
tgxworld
(Alan Tan)
32
はい、その通りだと思います。Maxmindは重要な機能ではないため、ダウンロードできない場合にブートストラップを失敗させる必要はありません。
「いいね!」 6
Roi
33
私の言おうとしたことを理解していただけなかったようです。もう一度説明させてください。
数日おきにMaxmindファイルをダウンロードするスクリプトがあります。もちろん、私自身のAPIキーを使用します。これらのファイルは、AWstatsのウェブ統計やWordPressプラグインなど、サーバー上のさまざまな目的で使用されます。
そのため、どうせマシン上にファイルがあるので、Discourseコンテナを再構築するときにファイルを(再度)ダウンロードする必要があるのでしょうか?
それは素晴らしいアイデアです。
「いいね!」 1
pfaffman
(Jay Pfaffman)
34
ええ。それらを永続ストレージに置くことができると素晴らしいでしょう。特にインスタンス間で共有できるなら。私はTraefikの背後にある同じマシン上にいくつかのDiscourseサイトを持っているので、それらすべてが同じmmdbを共有できれば、たくさんの別々のコピーを保持したりダウンロードしたりする手間が省けます。標準的なインストールであっても、ビルド間で永続化できます。それはすでに可能かもしれませんか?単に /var/www/discourse/vendor/data を永続的な場所にマウントするだけですか?
ああ。それは GlobalSetting.maxmind_backup_path のためのものだと思います。ですから、何らかの理由でmaxminddbを持っている場合、DISCOURSE_MAXMIND_BACKUP_PATH をコンテナで利用可能なものに設定できると思います。
また、mmdbはアセットをプリコンパイルするために必要ですか?
「いいね!」 2
Roi
35
では、これはすでに機能していますか? app.yml で DISCOURSE_MAXMIND_BACKUP_PATH を設定する(コンテナ内からの内部リンク、または Docker ホスト上の絶対リンク?)ことで、再構築中の Maxmind からのダウンロードを無効にできますか?
pfaffman
(Jay Pfaffman)
36
コードの中にあります。使ったことはありません。そこにパスを含めると、それが見つかるようです。覚えていませんが、ディレクトリへのパスだと思います。
Roi
37
はい、試すことができます。テスト専用のインスタンスがいくつかあります。
ファイルがローカルで取得されたか、ダウンロードされたかを確認できますか?
Dockerホスト上の /var/discourse/maxmind のようなものですか?
pfaffman
(Jay Pfaffman)
38
申し訳ありません。よくわかりません。ディレクトリを求めているようで、好きなように設定できます。そのため、app.yml に次のようなボリュームを追加するかもしれません。
- volume:
host: /data/
guest: /data
そして DISCOURSE_maxmind_backup_path=/data/mmdb (環境変数の大文字小文字を修正) です。
こちらがコードです。
Roi
39
再度ありがとうございます。/var/discourse/shared/discourse_test/data/mmdb を作成し、app.yml に以下の変更を加えました。
## IPアドレス検索用の MaxMind geolocation IP アドレスキー
## 詳細については https://meta.discourse.org/t/-/137387/23 を参照してください
DISCOURSE_MAXMIND_ACCOUNT_ID: 123456
DISCOURSE_MAXMIND_LICENSE_KEY: abcdefg
DISCOURSE_MAXMIND_BACKUP_PATH: /data/mmdb
## Docker コンテナはステートレスです。すべてのデータは /shared に保存されます。
volumes:
- volume:
host: /var/discourse/shared/discourse_test
guest: /shared
- volume:
host: /var/discourse/shared/discourse_test/log/var-log
guest: /var/log
- volume:
host: /var/discourse/shared/discourse_test/data
guest: /data
DISCOURSE_MAXMIND_BACKUP_PATH を追加し、3つ目のボリュームを追加しました。
DISCOURSE_MAXMIND_BACKUP_PATH のディレクトリは正しいですか?パスはコンテナ内のパスですか?
DISCOURSE_MAXMIND_ACCOUNT_ID と DISCOURSE_MAXMIND_LICENSE_KEY を削除する必要はありますか?
すみません、興奮しすぎて少し不明瞭になってしまいました。 
Roi
40
はい、わかりました 
MaxMindDBのバックアップを検出しました(ダウンロード日時: 2024-07-17 23:15:02 +0000) /data/mmdb
MaxMindDBを/data/mmdbから/var/www/discourse/vendor/dataにコピーしています
MaxMindDBは最後に2024-07-17 23:15:02 +0000にダウンロードされたため、ダウンロードをスキップします
これが(というか「私たちが」)見たかったものだと思います。 
「いいね!」 3
pfaffman
(Jay Pfaffman)
41
追加のボリュームをスキップして、以下のようにできたと思います。
DISCOURSE_MAXMIND_BACKUP_PATH: /shared/data
しかし、他にそのデータベースを最新の状態に保つプロセスがある場合は、そのディレクトリをマウントして、ドライブ上にローカルコピーを1つだけ持つようにすれば、そのコピーだけを更新すればよくなります。
「いいね!」 2
Roi
42
そのままにしておくつもりです。私の考えでは、それはより明確な構成であり、数か月後でも理解できるはずです。また、私のものだけでなく、より汎用的で多くのユースケースに対応できる可能性があります。
MaxMindからダウンロードした3つのmmdbファイルをそのディレクトリにコピーしています。使用しているスクリプトを調整しただけです(ちなみに、ダウンロードにはgeoipupdateを使用しています。これはDebian(およびおそらく他のLinuxディストリビューション)のパッケージとしても利用可能です)。
4つの異なるDiscourseコンテナの再構築が完了しました。すべてエラーなしです!これは数か月間起こりませんでした。素晴らしいです!
「いいね!」 3
kuaza
(kuaza)
43
この問題はまだ解決していません。インシデントの詳細を説明します。
管理画面からアップデートを実行しましたが、途中で停止しました。そこで、SSHパネルから再コンパイルを開始しました。エラーが発生しました。以下にエラーの例を示します。
その後、新しいMaxMindキーを作成して再コンパイルしましたが、同じエラーが再度発生しました。(興味深いことに、キーが有効化されていなかったのかもしれません。)
その後、app.ymlファイルでMaxMindの設定を無効にし、再コンパイルしたところ、コンパイルは成功しました。
使用したアドオンは画像に示されています。その他に使用したもの:
- Cloudflare R2
- 独立したPostgreSQLサーバー
- Cloudflare
何が問題の原因となっているのか、もう分かりません。
「いいね!」 1