Пересборка всегда завершается неудачей, когда исчерпан дневной лимит MAXMIND

Я только что попытался выполнить пересборку, и она завершилась неудачей на этом этапе:

 - dist/javascripts/media-optimization-worker.js: 5.01 kB (1.74 kB сжато)
 - dist/javascripts/pikaday/1.8.2/pikaday.js: 42.54 kB (9.67 kB сжато)
 - dist/javascripts/squoosh/mozjpeg_enc.js: 39.03 kB (10.81 kB сжато)
 - dist/javascripts/squoosh/squoosh_resize.js: 4.53 kB (1.28 kB сжато)
Готово за 355.08 с.

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'
Очистка временных файлов
Упаковка ресурсов
I, [2024-07-08T07:59:57.247206 #1532]  INFO -- : Запись /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
I, [2024-07-08T07:59:57.264957 #1532]  INFO -- : Запись /var/www/discourse/public/assets/service-worker-9764e1cd771b38dbe65a0d1e42d89cb2cb5f72b266ab7316e55d3371cb0ac870.js
I, [2024-07-08T07:59:57.271269 #1532]  INFO -- : Запись /var/www/discourse/public/assets/locales/i18n-3b40e842fd72b9bcc74ea83e094c823cd9ca535e4ecc5e78722e6f99d3656137.js
I, [2024-07-08T07:59:57.277082 #1532]  INFO -- : Запись /var/www/discourse/public/assets/scripts/discourse-test-listen-boot-9b14a0fc65c689577e6a428dcfd680205516fe211700a71c7adb5cbcf4df2cc5.js
I, [2024-07-08T07:59:59.103776 #1532]  INFO -- : Запись /var/www/discourse/public/assets/locales/ar-dfed7a58f30378bc60d7a2cc8d6347524f68b272ae012f0232604f730e442f91.js
I, [2024-07-08T08:00:00.112555 #1532]  INFO -- : Запись /var/www/discourse/public/assets/locales/be-e12ac4c99df2289f422efd371dd3da766754aecb1189ea763fe003376aca9028.js
rake aborted!
Zlib::BufError: ошибка буфера (Zlib::BufError)
1 лайк

У меня есть вопрос. Вы используете S3? Я тоже так подозреваю.

Нет :baymax_no: Нет S3 для меня.

1 лайк

Не знаю, происходит ли это только после исчерпания дневного лимита. Но у меня это случается постоянно уже 2–3 месяца. Похоже, у других людей та же проблема:

Возможно, было бы неплохо предоставлять файлы MaxMind из локальной директории? Я всё равно скачиваю их для других целей, так что они уже есть.

А ещё лучше, возможно, было бы размещать файлы MaxMind в общей директории внутри контейнера Discourse, чтобы всегда иметь актуальную версию? Как я уже сказал, я скачиваю их и обновляю файлы раз в день.

1 лайк

Я думаю, что проблема не связана с лимитом. Иными словами, ошибка возникает также при вводе неверного ключа или идентификатора аккаунта. Вот как мы можем решить эту проблему: в случае ошибки использовать старую базу данных и продолжить её восстановление. Конечно, очень важно определить основную причину этой проблемы.

Два дня назад я попытался создать пример, и он выдал ошибку. Это не имело ничего общего с лимитом, так как это было моё первое восстановление в тот день. Затем я создал новый ключ, попробовал снова, и всё сработало. Здесь есть такая ситуация: при создании ключа требуется некоторое время для его активации. Если создать его снова немедленно, возникнет ошибка.

интересно :slight_smile:

Что ж, мои ключи старые, я никогда их не менял после начала использования. Почему это работает, когда вы создаете новый ключ? Вы сказали, что требуется время, пока он не станет активным. Значит, тогда должно возникать сообщение об ошибке?

Это хорошая идея. Или предоставление файлов из локальной директории, как я предлагал. Всё опционально. Но меня действительно раздражает, что перестроение уже много недель напоминает лотерею…

1 лайк

Это противоречит условиям использования Maxmind, поэтому нам необходимо, чтобы каждый пользователь предоставлял свои API-ключи для индивидуальной загрузки файлов.

Назначаю себя для изучения проблемы, возникающей при достижении дневного лимита.

2 лайка

У меня не удавалось выполнить пересборку, поэтому я собрал образ с отключёнными настройками MaxMind. Затем внутри контейнера я добавил эти настройки обратно и успешно выполнил задачу rake.

Возможно, можно выполнить пересборку без загрузки базы данных, а затем загружать её при запуске контейнера?

Также я добавил PR, который должен позволять загрузке (bootstrap) завершаться успешно (он уже принят в основную ветку), даже если загрузка не удалась, но это всё ещё приводит к сбою загрузки.

2 лайка

Да, я думаю, что вы правы. MaxMind не является критически важной функцией, поэтому нам не стоит допускать сбоя процесса загрузки, если мы не можем загрузить данные.

6 лайков

Кажется, вы не совсем поняли, что я хотел сказать. Попробую ещё раз:

У меня есть скрипт, который каждые несколько дней загружает файлы Maxmind. Разумеется, с использованием моих собственных API-ключей. Эти файлы используются на сервере для различных задач, например, для веб-статистики AWstats, плагинов WordPress и так далее.

Таким образом, файлы уже есть на машине. Зачем загружать их (снова), когда я пересобираю контейнер Discourse?

Это блестящая идея. :slight_smile:

1 лайк

Да. Было бы здорово иметь возможность хранить их в постоянном хранилище, особенно если это можно организовать с общим доступом между экземплярами. У меня на одной машине за traefik работает несколько сайтов Discourse, поэтому, если бы они все могли использовать один и тот же файл mmdb, это избавило бы от необходимости хранить и скачивать множество отдельных копий. Даже при стандартной установке они могли бы сохраняться между сборками. Возможно, это уже реализовано? Может быть, просто смонтировать /var/www/discourse/vendor/data в какое-то постоянное место?

Ага. Думаю, для этого и существует GlobalSetting.maxmind_backup_path. То есть, если у вас по какой-то причине есть maxminddb, вы можете установить переменную окружения DISCOURSE_MAXMIND_BACKUP_PATH в путь, доступный внутри контейнера.

Кстати, зачем вообще нужен mmdb для предварительной компиляции ассетов?

2 лайка

Значит, это уже работает? Если задать DISCOURSE_MAXMIND_BACKUP_PATH в app.yml (как внутреннюю ссылку изнутри контейнера или абсолютный путь на хосте Docker?), это отключит загрузку с Maxmind во время пересборки?

Это в коде. Я никогда его не использовал. Похоже, если указать там путь, он его найдет. Я не помню точно, но думаю, что это путь к каталогу.

Хорошо, я могу попробовать. У меня есть несколько экземпляров, и один из них предназначен только для тестирования.

Могу ли я проверить, были ли файлы взяты локально или загружены?

То есть что-то вроде /var/discourse/maxmind на хосте Docker?

Извините, я не совсем уверен. Похоже, что требуется каталог, и вы можете назвать его как угодно. Возможно, вам стоит добавить том в ваш app.yml следующим образом:

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

а также установить DISCOURSE_maxmind_backup_path=/data/mmdb (исправив регистр для переменной окружения).

Вот код:

Ещё раз спасибо. Я создал /var/discourse/shared/discourse_test/data/mmdb и вот что я добавил в app.yml:

  ## Ключ учётной записи 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_ID и DISCOURSE_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 лайка

Я думаю, оставлю всё как есть. На мой взгляд, это более понятная конфигурация, которую можно будет понять и через несколько месяцев. Кроме того, она может быть более универсальной и подходить для большего числа сценариев использования, чем только мой.

При загрузке я копирую три файла mmdb от MaxMind в эту директорию. Я просто адаптировал используемый мной скрипт (кстати, для загрузки я использую geoipupdate, который также доступен как пакет для Debian и, скорее всего, для других дистрибутивов Linux).

Только что успешно пересобрал четыре разных контейнера Discourse, и все без ошибок! У меня такого не случалось уже несколько месяцев. Отлично! :slight_smile:

3 лайка

Эта проблема всё ещё сохраняется. Я подробно объясню инцидент:
Я выполнил обновление из админ-панели, но оно прервалось на полпути. Тогда я запустил повторную компиляцию через панель SSH. Произошла ошибка, пример ошибки приведён ниже.

Затем я создал новый ключ MaxMind и снова запустил компиляцию, но ошибка возникла вновь — та же самая. (Интересно, возможно, ключ не был активирован).

После этого я отключил настройку MaxMind в файле app.yml. Я снова запустил компиляцию, и она прошла успешно.

Используемые мной дополнения показаны на изображении, остальные используемые компоненты:

  • Cloudflare R2
  • отдельный сервер PostgreSQL
  • Cloudflare

Я больше не могу понять, что вызывает проблему.

1 лайк