当 MAXMIND 每日配额用尽时,重建总是失败

我刚刚尝试了重新构建,但在此处失败了:

 - 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 个赞

我有一个问题。您在使用 S3 吗?我也怀疑是这样。

没有 :baymax_no: 我没有 S3。

1 个赞

我不知道这是否只会在每日限额用尽时发生。但在这里,这种情况已经持续了 2-3 个月了。其他人似乎也有同样的问题:

也许可以从本地目录提供 Maxmind 文件?我反正会下载它用于其他用途,所以它已经存在了。

也许甚至可以把 Maxmind 文件放在 Discourse 容器中的共享目录里,以始终拥有最新版本?正如我所说,我反正会下载它,并每天更新一次文件。

1 个赞

我认为问题与限制无关。换句话说,即使输入了错误的密钥或账户 ID,也会出现错误。以下是解决此问题的办法:出现错误时,让它使用旧数据库并继续重建。当然,确定此问题的根本原因非常重要。

我两天前尝试创建一个示例,结果出现了错误。这与限制无关,因为那天是我当天第一次重建。然后我创建了一个新密钥并尝试了一下,结果成功了。这里有一个情况:当你创建一个密钥时,它需要一段时间才能激活。如果你立即重新创建它,就会出现错误。

真有趣 :slight_smile:

嗯,我的密钥很旧了,自从开始使用后我就没换过。为什么你创建一个新密钥就能用呢?你说过密钥需要一段时间才能激活。那到时候应该会报错吧?

这是个好主意。或者像我建议的那样,提供本地目录中的文件。所有选项都是可选的。但重建好几周以来就像是开彩票一样,这真的让我很困扰……

1 个赞

这违反了 Maxmind 的使用条款,这就是为什么我们需要让每个人都提供 API 密钥以单独下载文件。

分配给我自己,看看达到每日限制时会出现什么问题。

2 个赞

我曾遇到过重建失败的情况,然后关闭 maxmind 设置构建了镜像。之后在容器内重新添加设置,并成功运行了 rake 任务。

也许可以不下载数据库进行重建,然后在容器启动时下载数据库?

另外,我添加了一个 PR,应该能让引导(bootstrap)在下载失败时也能成功(该 PR 已合并),但它仍然导致引导失败。

2 个赞

是的,我认为你说得对。Maxmind 不是一个关键功能,所以我们没有必要在无法下载东西时导致引导失败。

6 个赞

我认为您没有理解我想说的。让我再说一遍:

我有一个脚本,每隔几天下载一次 Maxmind 文件。当然,使用我自己的 API 密钥。这些文件在服务器上用于多种用途,例如 AWstats 网站统计信息、WordPress 插件等。

所以无论如何我都有这些文件。在重建 Discourse 容器时,为什么要(再次)下载文件?

这是一个绝妙的主意。 :slight_smile:

1 个赞

是的。如果能将这些文件放在持久存储中,尤其是能在实例之间共享,那就太好了。我在同一台机器上有几个 Discourse 站点,它们都在 traefik 后面,所以如果它们能共享同一个 mmdb,就能节省保存和下载大量单独副本的麻烦。即使是标准安装,它们也能在重建之间持久存在。也许这已经可以实现了?也许只是将 /var/www/discourse/vendor/data 挂载到某个持久的地方?

啊哈。我认为 GlobalSetting.maxmind_backup_path 就是为此而设的。所以我想,如果你因为某种原因需要 maxminddb,你可以将 DISCOURSE_MAXMIND_BACKUP_PATH 设置为容器中可用的某个路径。

另外,为什么我们需要 mmdb 来预编译资源?

2 个赞

那么,这已经奏效了吗?在 app.yml 中设置 DISCOURSE_MAXMIND_BACKUP_PATH(是从容器内部的链接还是 Docker 主机上的绝对链接?)是否会禁用在重建期间从 Maxmind 下载?

它在代码里。我从没用过它。看起来如果你在那里包含一个路径,它就能找到它。我不记得了,但我想它是一个目录的路径。

好的,我可以试试。我有几个实例,其中一个仅用于测试。

我能查看文件是本地获取的还是下载的吗?

那么,就像 Docker 主机上的 /var/discourse/maxmind 这样的路径吗?

抱歉,我不太确定。看起来它需要一个目录,你可以随意命名,所以也许你可以在你的 app.yml 中添加一个卷,如下所示:

  - volume:
      host: /data/
      guest: /data

然后设置 DISCOURSE_maxmind_backup_path=/data/mmdb(修正了环境变量的大小写)。

这是代码:

再次感谢。我创建了 /var/discourse/shared/discourse_test/data/mmdb,并在 app.yml 中进行了如下修改:

  ## 用于 IP 地址查找的 MaxMind 地理位置 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 并添加了第三个卷。

DISCOURSE_MAXMIND_BACKUP_PATH 的目录是否正确?该路径是容器内的路径吗?

我现在是否需要删除 DISCOURSE_MAXMIND_ACCOUNT_IDDISCOURSE_MAXMIND_LICENSE_KEY

抱歉,太激动了,也有些不清楚。 :wink:

好的 :smiley:

检测到 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

我认为这就是我们(或者说我)想要看到的。 :smiley:

3 个赞

我认为你可以跳过额外的卷并执行

DISCOURSE_MAXMIND_BACKUP_PATH: /shared/data

但是,如果你有其他进程在其他地方维护该数据库的最新状态,那么你可以挂载该目录,这样你的驱动器上就只有一个本地副本,并且只需要更新这一个副本。

2 个赞

我认为就这样吧。在我看来,这是一种更清晰的配置,几个月后仍然可以理解。它也可能比我个人的情况更通用,适用于更多用例。

下载 Maxmind 的三个 mmdb 文件时,我将它们复制到该目录中。我只是调整了我正在使用的脚本(顺便说一句,下载我使用的是 geoipupdate,它也可以作为 Debian(以及其他大多数 Linux 发行版)的软件包使用)。

刚刚完成了四个不同的 Discourse 容器的重建,所有这些都没有任何错误!这几个月来这里都没有发生过。太棒了!:slight_smile:

3 个赞

此问题仍然存在。我将详细解释该事件:
我从管理员那里进行了一次更新,但中途停止了。因此,我从 ssh 面板开始重新编译。砰,出现了一个错误,示例如下。

然后我创建了一个新的 maxmind 密钥并重新编译了它,但又出现了同样的错误。(有趣的是,也许密钥未激活)。

然后我禁用了 app.yml 文件中的 maxmind 设置。我重新编译了它,编译成功了。

我使用的附加组件显示在图片中,我使用的其他东西:

  • Cloudflare R2
  • 独立的 postgresql 服务器
  • cloudflare

我再也弄不清楚是什么原因导致了这个问题。

1 个赞