Я только что попытался выполнить пересборку, и она завершилась неудачей на этом этапе:
- 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)
Не знаю, происходит ли это только после исчерпания дневного лимита. Но у меня это случается постоянно уже 2–3 месяца. Похоже, у других людей та же проблема:
Возможно, было бы неплохо предоставлять файлы MaxMind из локальной директории? Я всё равно скачиваю их для других целей, так что они уже есть.
А ещё лучше, возможно, было бы размещать файлы MaxMind в общей директории внутри контейнера Discourse, чтобы всегда иметь актуальную версию? Как я уже сказал, я скачиваю их и обновляю файлы раз в день.
Я думаю, что проблема не связана с лимитом. Иными словами, ошибка возникает также при вводе неверного ключа или идентификатора аккаунта. Вот как мы можем решить эту проблему: в случае ошибки использовать старую базу данных и продолжить её восстановление. Конечно, очень важно определить основную причину этой проблемы.
Два дня назад я попытался создать пример, и он выдал ошибку. Это не имело ничего общего с лимитом, так как это было моё первое восстановление в тот день. Затем я создал новый ключ, попробовал снова, и всё сработало. Здесь есть такая ситуация: при создании ключа требуется некоторое время для его активации. Если создать его снова немедленно, возникнет ошибка.
Что ж, мои ключи старые, я никогда их не менял после начала использования. Почему это работает, когда вы создаете новый ключ? Вы сказали, что требуется время, пока он не станет активным. Значит, тогда должно возникать сообщение об ошибке?
Это хорошая идея. Или предоставление файлов из локальной директории, как я предлагал. Всё опционально. Но меня действительно раздражает, что перестроение уже много недель напоминает лотерею…
Это противоречит условиям использования Maxmind, поэтому нам необходимо, чтобы каждый пользователь предоставлял свои API-ключи для индивидуальной загрузки файлов.
Назначаю себя для изучения проблемы, возникающей при достижении дневного лимита.
У меня не удавалось выполнить пересборку, поэтому я собрал образ с отключёнными настройками MaxMind. Затем внутри контейнера я добавил эти настройки обратно и успешно выполнил задачу rake.
Возможно, можно выполнить пересборку без загрузки базы данных, а затем загружать её при запуске контейнера?
Также я добавил PR, который должен позволять загрузке (bootstrap) завершаться успешно (он уже принят в основную ветку), даже если загрузка не удалась, но это всё ещё приводит к сбою загрузки.
Да, я думаю, что вы правы. MaxMind не является критически важной функцией, поэтому нам не стоит допускать сбоя процесса загрузки, если мы не можем загрузить данные.
Кажется, вы не совсем поняли, что я хотел сказать. Попробую ещё раз:
У меня есть скрипт, который каждые несколько дней загружает файлы Maxmind. Разумеется, с использованием моих собственных API-ключей. Эти файлы используются на сервере для различных задач, например, для веб-статистики AWstats, плагинов WordPress и так далее.
Таким образом, файлы уже есть на машине. Зачем загружать их (снова), когда я пересобираю контейнер Discourse?
Да. Было бы здорово иметь возможность хранить их в постоянном хранилище, особенно если это можно организовать с общим доступом между экземплярами. У меня на одной машине за traefik работает несколько сайтов Discourse, поэтому, если бы они все могли использовать один и тот же файл mmdb, это избавило бы от необходимости хранить и скачивать множество отдельных копий. Даже при стандартной установке они могли бы сохраняться между сборками. Возможно, это уже реализовано? Может быть, просто смонтировать /var/www/discourse/vendor/data в какое-то постоянное место?
Ага. Думаю, для этого и существует GlobalSetting.maxmind_backup_path. То есть, если у вас по какой-то причине есть maxminddb, вы можете установить переменную окружения DISCOURSE_MAXMIND_BACKUP_PATH в путь, доступный внутри контейнера.
Кстати, зачем вообще нужен mmdb для предварительной компиляции ассетов?
Значит, это уже работает? Если задать DISCOURSE_MAXMIND_BACKUP_PATH в app.yml (как внутреннюю ссылку изнутри контейнера или абсолютный путь на хосте Docker?), это отключит загрузку с Maxmind во время пересборки?
Извините, я не совсем уверен. Похоже, что требуется каталог, и вы можете назвать его как угодно. Возможно, вам стоит добавить том в ваш app.yml следующим образом:
- volume:
host: /data/
guest: /data
а также установить DISCOURSE_maxmind_backup_path=/data/mmdb (исправив регистр для переменной окружения).
Обнаружена резервная копия 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
Думаю, это именно то, что мы (или, лучше сказать, «мы») хотели увидеть.
Я думаю, вы могли бы пропустить дополнительный том и просто указать
DISCOURSE_MAXMIND_BACKUP_PATH: /shared/data
Однако, если у вас есть другой процесс, который обновляет эту базу данных в другом месте, вы можете смонтировать эту директорию. В этом случае у вас будет только одна локальная копия на вашем диске, и обновлять нужно будет лишь её.
Я думаю, оставлю всё как есть. На мой взгляд, это более понятная конфигурация, которую можно будет понять и через несколько месяцев. Кроме того, она может быть более универсальной и подходить для большего числа сценариев использования, чем только мой.
При загрузке я копирую три файла mmdb от MaxMind в эту директорию. Я просто адаптировал используемый мной скрипт (кстати, для загрузки я использую geoipupdate, который также доступен как пакет для Debian и, скорее всего, для других дистрибутивов Linux).
Только что успешно пересобрал четыре разных контейнера Discourse, и все без ошибок! У меня такого не случалось уже несколько месяцев. Отлично!
Эта проблема всё ещё сохраняется. Я подробно объясню инцидент:
Я выполнил обновление из админ-панели, но оно прервалось на полпути. Тогда я запустил повторную компиляцию через панель SSH. Произошла ошибка, пример ошибки приведён ниже.
Затем я создал новый ключ MaxMind и снова запустил компиляцию, но ошибка возникла вновь — та же самая. (Интересно, возможно, ключ не был активирован).
После этого я отключил настройку MaxMind в файле app.yml. Я снова запустил компиляцию, и она прошла успешно.
Используемые мной дополнения показаны на изображении, остальные используемые компоненты: