Инструкции по настройке¶
Установка Weblate¶
В зависимости от ваших настроек и опыта выберите подходящий для вас способ установки:
Установка с помощью Docker’а, рекомендуется для установки на рабочих серверах.
Установка в виртуальное окружение, рекомендуется для рабочей среды:
Установка из исходников, рекомендуется для разработки.
Обзор архитектуры¶
- Веб-сервер
Обработка входящих HTTP-запросов, Обслуживание статических файлов.
- Обработчики Celery
Фоновые задачи с использованием Celery оформлены здесь.
В зависимости от нагрузки, возможно, вы захотите изменить количество обработчиков.
Используйте выделенный узел для масштабирования Weblate по горизонтали.
- WSGI сервер
Сервер WSGI, обслуживающий веб-страницы для пользователей.
Используйте выделенный узел для масштабирования Weblate по горизонтали.
- База данных
Сервер базы данных PostgreSQL для хранения всего содержимого, см. Настройка базы данных для Weblate.
Используйте выделенный узел базы данных для сайтов с сотнями миллионов слов.
- Хранилище данных
Хранилище ключей/значений, такое как Valkey или Redis, для кэша и очереди задач, см. Фоновые задачи с использованием Celery.
Используйте выделенный узел для масштабирования Weblate по горизонтали.
- Файловая система
Файловая система хранения репозиториев VCS и загруженных пользовательских данных. Она является общей для всех процессов.
Используйте сетевое хранилище для масштабирования Weblate по горизонтали.
- Сервер электронной почты
SMTP-сервер для исходящей почты, смотрите раздел Настройка исходящей почты. Он может быть предоставлен извне.
Подсказка
Установка с помощью Docker’а включает PostgreSQL и Valkey, что упрощает установку.
Требования к программному обеспечению¶
Операционная система¶
Weblate работает на Linux, FreeBSD и macOS. Скорее всего будет работать и на других Unix-подобных системах.
Работа Weblate под Windows не поддерживается. Тем не менее, работать под ней он всё ещё может и патчи под неё с радостью принимаются.
См. также
Обзор архитектуры описывает общую архитектуру Weblate и необходимые сервисы.
Зависимости Python¶
Weblate написан на Python и поддерживает Python 3.12 или новее. Вы можете установить зависимости с помощью pip или из пакетов вашего дистрибутива, полный список доступен в requirements.txt.
Основные зависимости:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Среда Django REST
Необязательный спецификатор зависимости |
Пакеты Python |
Функция Weblate |
|---|---|---|
|
||
|
||
|
||
|
Расширенный облачный перевод Google с поддержкой словаря |
|
|
||
|
||
|
PostgreSQL, см. Настройка базы данных для Weblate |
|
|
||
|
||
|
Интеграция SAML 2 IDP в Weblate |
|
|
Необходимо для Обновление файла POT (Sphinx) |
|
|
Интеграция Hosted Weblate |
|
|
Сервер wsgi для Weblate |
|
|
При установке с помощью pip вы можете напрямую указать желаемые функции при установке:
uv pip install "weblate[Postgres,Amazon,SAML]"
Или вы можете установить Weblate со всеми дополнительными функциями:
uv pip install "weblate[all]"
Или вы можете установить Weblate без каких-либо дополнительных функций:
uv pip install weblate
Решение проблем с pip install¶
ERROR: Dependency 'gobject-introspection-2.0' is required but not found.Установленный пакет
PyGobjectне может найти соответствующую библиотеку GObject Introspection —gobject-introspection-2.0.Более старые версии больше не поддерживаются Weblate.
ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)Это вызвано несовместимостью бинарных пакетов, распространяемых через PyPI, с дистрибутивом. Для решения этой проблемы необходимо пересобрать пакет в вашей системе:
uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?Это известная проблема пакета xmlsec, подробнее смотрите https://github.com/xmlsec/python-xmlsec/issues/314.
lxml & xmlsec libxml2 library version mismatchПакеты
lxmlиxmlsecдолжны быть собраны с одинаковойlibxml2. Чтобы избежать этой проблемы, вам следует собрать их локально:uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec
Другие системные требования¶
В системе должны быть установлены следующие зависимости:
Git- Pango, Cairo и связанные заголовочные файлы, а также данные интроспекции GObject
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, смотрите раздел Pango и Cairo
git-review(необязательная зависимость для поддержки Gerrit)git-svn(необязательная зависимость для поддержки Subversion)tesseract(необходимо только в том случае, если бинарные колёса tesserocr недоступны для вашей системы)
Зависимости времени компиляции¶
Для сборки некоторых Зависимости Python вам может потребоваться установить их зависимости. Это зависит от того, как вы их устанавливаете, поэтому, пожалуйста, обратитесь к документации отдельных пакетов. Они не понадобятся, если вы используете предварительно собранные Wheels при установке через pip или если вы используете пакеты дистрибутива.
Pango и Cairo¶
Weblate использует Pango и Cairo для отрисовки растровых виджетов (смотрите раздел Построение сообщества переводчиков) и проверки отрисовки текста (смотрите раздел Управление шрифтами). Для правильной установки привязок Python сначала нужно установить системные библиотеки — вам нужны и Cairo, и Pango, которым, в свою очередь, нужна GLib. Все они должны быть установлены с файлами для разработки и данными интроспекции GObject.
Требования к оборудованию¶
Weblate должен без проблем работать на любом современном оборудовании, ниже приведена минимальная конфигурация, необходимая для запуска Weblate на одном сервере (сам Weblate, база данных и веб-сервер):
3 ГБ ОЗУ
2-х ядерный процессор
1 ГБ дискового пространства
Примечание
Фактические требования к вашей установке Weblate сильно зависят от размера управляемых ею переводов.
Использование памяти¶
Чем больше памяти, тем лучше — она используется для кэширования на всех уровнях (на уровне файловой системы, уровне базы данных и уровне Weblate). Для сотен компонентов перевода рекомендуется не менее 4 ГБ оперативной памяти.
Подсказка
Для систем с меньшим, чем рекомендуется, объёмом памяти рекомендуется использовать Однопроцессная установка для производства Celery.
Использование CPU¶
Множество одновременно работающих пользователей увеличивают количество необходимых ядер процессора.
Использование хранилища¶
Типовое использование дискового пространства базой данной находится в районе 300MB на 1 миллион хранимых слов.
Пространство необходимое для клонирования репозиториев разнится, хотя Weblate и пытается поддерживать их размер минимальным, делая поверхностные (shallow) копии.
Узлы¶
Для небольших и средних сайтов (миллионы размещённых слов) все компоненты Weblate (см. Обзор архитектуры) могут работать на одном узле.
Когда вы вырастете до сотен миллионов размещённых слов, рекомендуется выделить отдельный узел для базы данных (см. Настройка базы данных для Weblate).
Проверка подписей выпусков¶
Выпуски Weblate криптографически подписываются с помощью подписей Sigstore. Подписи прикреплены к выпуску на GitHub.
Проверку можно выполнить с помощью пакета sigstore. Следующий пример проверяет подпись выпуска 5.4:
sigstore verify github \
--cert-identity https://github.com/WeblateOrg/weblate/.github/workflows/setup.yml@refs/tags/weblate-5.4 \
--bundle Weblate-5.4-py3-none-any.whl.sigstore \
Weblate-5.4-py3-none-any.whl
Права доступа к файлам¶
Процесс Weblate должен мочь читать и писать в каталог, в котором он хранит свои данные — DATA_DIR. Все файлы в этом каталоге должны принадлежать и иметь разрешение на запись для пользователей, от имени которых работают все процессы Weblate (в частности WSGI и Celery, смотреть раздел Запуск сервера и Фоновые задачи с использованием Celery).
В конфигурации по умолчанию они расположены в том же дереве, что и исходный код Weblate, однако вы можете предпочесть переместить их в более подходящее место, например, в /var/lib/weblate.
Weblate попытается автоматически создать эти каталоги, но у него ничего не получится, если у него не будет соответствующих прав доступа.
Настроенный CACHE_DIR также должен быть доступен для записи процессу Weblate и должен разрешать выполнение сгенерированных вспомогательных файлов. Не монтируйте CACHE_DIR с опцией noexec.
Вы также должны быть осторожны при запуске Команды управления, так как они должны выполняться от того же пользователя, от которого работает сам Weblate, иначе права на некоторые файлы могут быть неверными.
В контейнере Docker все файлы в томе /app/data должны принадлежать пользователю weblate внутри самого контейнера (UID 1000).
См. также
Настройка базы данных для Weblate¶
Рекомендуется запускать Weblate с сервером баз данных PostgreSQL.
Поддерживается PostgreSQL 13 и выше. Рекомендуется PostgreSQL 15 и новее.
См. также
Подключения к базе данных¶
В конфигурации по умолчанию каждый процесс Weblate поддерживает постоянное соединение с базой данных. Постоянные соединения улучшают отзывчивость Weblate, но могут потребовать больше ресурсов для сервера базы данных. Для получения дополнительной информации обратитесь к CONN_MAX_AGE и Persistent connections.
Weblate требует как минимум следующее количество соединений:
\((4 \times \mathit{nCPUs}) + 2\) для процессов Celery
\(\mathit{nCPUs} + 1\) для рабочих процессов WSGI
Это относится к параметрам контейнера Docker по умолчанию и примерам конфигураций, приведённым в этой документации, но числа изменятся, как только вы настроите количество рабочих процессов WSGI или измените параллелизм Celery.
Фактический лимит количества подключений к базе данных должен быть выше, чтобы учесть следующие ситуации:
Команды управления также требуют своего соединения.
Если процесс будет завершён (например, OOM killer-ом), он может заблокировать существующее подключение до истечения тайм-аута.
PostgreSQL¶
PostgreSQL, как правило, является лучшим выбором для сайтов, написанных на Django. Это эталонная база данных, используемая для реализации слоя баз данных Django.
Примечание
Weblate использует расширение для триграмм, которое в некоторых случаях должно быть установлено отдельно. Ищите пакет postgresql-contrib или аналогичный.
См. также
Создание базы данных в PostgreSQL¶
Обычно рекомендуется запускать Weblate в отдельной базе данных и под отдельной учётной записью:
# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"
# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate
# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate
Подсказка
Если вы не хотите делать пользователя Weblate суперпользователем в PostgreSQL, вы можете пропустить этот шаг. В этом случае вам придётся выполнить некоторые шаги по миграции вручную, так как суперпользователь PostgreSQL запускает в схеме Weblate следующую команду:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Настройка Weblate для использования PostgreSQL¶
Фрагмент настроек settings.py для PostgreSQL:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.postgresql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# Configures name of the PostgreSQL role to alter during the database migration
# "ALTER_ROLE": "weblate",
# Database password
"PASSWORD": "password",
# Set to empty string for localhost
"HOST": "database.example.com",
# Set to empty string for default
"PORT": "",
# Persistent connections
"CONN_MAX_AGE": None,
"CONN_HEALTH_CHECKS": True,
}
}
Миграция базы данных выполняет ALTER ROLE для роли базы данных, используемой Weblate. В большинстве случаев имя роли совпадает с именем пользователя. В более сложных настройках имя роли отличается от имени пользователя, и вы получите ошибку о несуществующей роли во время миграции базы данных (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Известно, что это происходит с Azure Database for PostgreSQL, но не ограничивается этой средой. Пожалуйста, установите ALTER_ROLE, чтобы изменить имя роли, которую Weblate должен изменить во время миграции базы данных.
См. также
Другие настройки¶
Настройка исходящей почты¶
Weblate отправляет электронные письма по разным поводам — для активации учетной записи и по различным уведомлениям, настроенным пользователями. Для этого ему необходим доступ к SMTP-серверу.
Настройка почтового сервера производится с помощью следующих параметров: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER и EMAIL_PORT. Их имена говорят сами за себя, а более подробную информацию вы можете найти в документации Django.
Подсказка
Если вы получаете ошибку о том , что авторизация не поддерживается (например, SMTP AUTH extension not supported by server, «расширение SMTP AUTH не поддерживается сервером»), то скорей всего это вызвано тем, что используется небезопасное соединение и из-за этого сервер отказывается производить авторизацию. В таком случае попробуйте включить EMAIL_USE_TLS.
Работа за обратным прокси¶
Некоторые функции Weblate полагаются на правильную передачу HTTP-заголовков в Weblate. При использовании обратного прокси убедитесь, что необходимая информация передаётся корректно.
Для отладки этой конфигурации вы можете посмотреть Окружение HTTP в Отчёт о производительности.
- IP-адрес клиента
Это необходимо для Ограничение частоты запросов или Журнал аудита.
Weblate извлекает IP-адрес из
REMOTE_ADDR, который устанавливается обработчиком WSGI. Он может быть пустым (при использовании сокета для WSGI) или содержать адрес обратного прокси, поэтому Weblate требуется дополнительный HTTP-заголовок с IP-адресом клиента.Включения
IP_BEHIND_REVERSE_PROXYдолжно быть достаточно для большинства обычных конфигураций, но вам также может потребоваться настроитьIP_PROXY_HEADERиIP_PROXY_OFFSET(используйтеWEBLATE_IP_PROXY_HEADERиWEBLATE_IP_PROXY_OFFSETв контейнере Docker).Подсказка
Эту конфигурацию нельзя включить по умолчанию, так как она позволила бы подделывать IP-адреса в установках, где нет правильно настроенного обратного прокси.
- Имя хоста сервера
Заголовок Host должен соответствовать тому, что настроено как
SITE_DOMAIN. Может потребоваться дополнительная настройка в вашем обратном прокси (например, используйтеProxyPreserveHost Onдля Apache илиproxy_set_header Host $host;для nginx).Подсказка
Ошибки сбоя проверки CSRF часто вызваны несоответствием между заголовком Host и настроенным
SITE_DOMAIN.- Протокол клиента
Непередача правильного протокола может привести к тому, что Weblate попадёт в цикл перенаправлений, пытаясь перевести клиента на HTTPS. Убедитесь, что он правильно передаётся обратным прокси как X-Forwarded-Proto.
Затем этот заголовок необходимо настроить в
SECURE_PROXY_SSL_HEADER(settings.py) илиWEBLATE_SECURE_PROXY_SSL_HEADER(среда Docker).Важно
Значение заголовка в конфигурации чувствительно к регистру, поэтому
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,httpsиWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPSне взаимозаменяемы.Подсказка
Если вы получаете ошибку «Слишком много перенаправлений» от браузера, это, скорее всего, вызвано несоответствием между фактическим протоколом (HTTPS) и тем, что наблюдает Weblate.
Изменено в версии 5.13: Заголовки прокси протокола автоматически обрабатываются gunicorn в конфигурации по умолчанию, но другие WSGI-серверы имеют более безопасную конфигурацию и требуют явной установки этого параметра.
Начиная с Weblate 5.13, контейнер Docker использует granian, и теперь он требует явной конфигурации
WEBLATE_SECURE_PROXY_SSL_HEADER.
См. также
HTTP-прокси¶
Weblate запускает команды системы контроля версий, а те берут настройки прокси из переменных окружения. Для их настройки рекомендуемый подход — определить необходимые параметры прокси в файле settings.py:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
См. также
Изменение конфигурации под свои нужды¶
См. также
Скопируйте weblate/settings_example.py в weblate/settings.py и подправьте его в соответствии со своими настройками. Скорее всего, вы захотите настроить следующие параметры:
ADMINS
Список администраторов сайтов для получения уведомлений, когда что-то идет не так, например, для получения уведомлений о неудачных слияниях, или об ошибках Django.
Контактная форма также отправляет электронную почту о них, если не настроено
ADMINS_CONTACT.
ALLOWED_HOSTS
Вы должны установить эту настройку в список хостов, которые должен обслуживать ваш сайт. Например:
ALLOWED_HOSTS = ["demo.weblate.org"]Или же вы можете указать символ шаблона:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Настраивает то, как будут храниться ваши сессии. В случае, если вы оставили механизм хранения по умолчанию — в базе данных — вы должны настроить расписание для команды weblate clearsessions, удаляющей из базы данных данные об устаревших сессиях.
Если вы используете Valkey или Redis в качестве кэша (см. Настройка кэша), рекомендуется использовать его также и для сеансов:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"См. также
DATABASES
Подключение к серверу базы данных, подробнее об этой настройке читайте в документации Django.
DEBUG
Отключите эту настройку для любого рабочего сервера. При включенном режиме отладки Django в случае возникновения ошибки будет показывать трассировки стека пользователям, при его же отключении ошибки будут отправляться на адреса электронной почты из массива
ADMINS(смотрите выше).Кроме того, отладочный режим замедляет работу Weblate, поскольку в этом случае Django сохраняет внутри себя гораздо больше информации.
См. также
DEFAULT_FROM_EMAIL
Адрес электронной почты отправителя для исходящих сообщений электронной почты, например, для писем регистрации.
См. также
SECRET_KEY
Ключ, используемый Django для подписывания некоторой информации, сохраняемой в куках, подробнее смотрите в разделе Секретный ключ Django.
См. также
SERVER_EMAIL
Адрес электронной почты, используемый в качестве адреса отправителя для отправки сообщений администратору, например, уведомлений о неудачных слияниях.
См. также
Наполнение базы данных¶
После того, как ваша конфигурация будет готова, вы можете запустить migrate, чтобы создать структуру базы данных. Теперь вы сможете создавать проекты перевода, используя интерфейс администратора.
После того, как вы закончите, вам также стоит проверить Отчёт о производительности в интерфейсе администратора. Информация оттуда может дать вам подсказки по исправлению потенциально не оптимальной конфигурации вашего сайта.
См. также
Рабочая среда¶
Для установки в рабочую среду необходимо провести корректировки, описанные в следующих разделах. Наиболее критичные настройки вызовут предупреждение, которое обозначается восклицательным знаком в верхней панели, если вы вошли в систему под суперпользователем:
Также рекомендуется изучить все проверки, произведённые Django (хотя, возможно, исправлять их все нет необходимости):
weblate check --deploy
Вы также можете просмотреть этот же список в Отчёт о производительности в Интерфейс управления.
См. также
Отключение отладочного режима¶
Отключите отладочный режим Django (DEBUG), установив:
DEBUG = False
При включенном отладочном режиме Django сохраняет все выполненные запросы и при возникновении ошибок показывает пользователям обратную трассировку стека, что в рабочей среде не желательно.
См. также
Правильная настройка администраторов¶
Укажите в настройке ADMINS правильные адреса администраторов, чтобы определить, кто будет получать электронную почту в случае, если на сервере что-то пойдёт не так, например:
ADMINS = ("Your Name <your_email@example.com>",)
См. также
Установка правильного домена сайта¶
Поправьте имя сайта и домен в интерфейсе администратора, иначе ссылки в RSS или регистрационные письма не будут работать. Эта настройка осуществляется с помощью параметра SITE_DOMAIN, который должен содержать доменное имя сайта.
Изменено в версии 4.2: До выпуска 4.2 вместо этого использовалась платформа сайтов Django, пожалуйста, см. The “sites” framework.
Правильная настройка HTTPS¶
Настоятельно рекомендуется запускать Weblate с использованием шифрующего протокола HTTPS. После его включения в настройках необходимо установить параметр ENABLE_HTTPS:
ENABLE_HTTPS = True
Подсказка
Возможно, вы также захотите настроить HSTS, для получения более подробной информации смотрите документ SSL/HTTPS.
Установка правильного значения SECURE_HSTS_SECONDS¶
Если ваш сайт обслуживается по SSL, вам необходимо рассмотреть возможность установки значения параметра SECURE_HSTS_SECONDS в файле settings.py, включающего HTTP Strict Transport Security. По умолчанию его значение установлено в 0, как показано ниже.
SECURE_HSTS_SECONDS = 0
Если для него установлено ненулевое целое значение, то django.middleware.security.SecurityMiddleware устанавливает заголовок HTTP Strict Transport Security у всех ответов, которые его ещё не имеют.
Предупреждение
Неправильная настройка этого параметра может привести к необратимому (на некоторое время) выходу из строя вашего сайта. Поэтому сперва ознакомьтесь с документацией по HTTP Strict Transport Security.
Использование мощного движка базы данных¶
Пожалуйста, используйте для рабочего окружения PostgreSQL, для получения более подробной информации смотрите раздел Настройка базы данных для Weblate.
Используйте соседнее место для размещения сервера базы данных, иначе производительность или надёжность сети может испортить работу с Weblate.
Проверьте производительность сервера базы данных или настройте его конфигурацию, например, используя PGTune.
Настройка кэша¶
Если возможно, используйте Valkey или Redis в Django, настроив переменную конфигурации CACHES, например:
CACHES = {
"default": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://127.0.0.1:6379/0",
# If redis is running on same host as Weblate, you might
# want to use unix sockets instead:
# 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
"PARSER_CLASS": "redis.connection.HiredisParser",
},
}
}
Подсказка
Если вы измените настройки кэша, вам может потребоваться также настроить их для Celery, см. Фоновые задачи с использованием Celery.
См. также
Кеширование аватаров¶
Помимо кэширования силами Django, Weblate выполняет кэширование аватаров. Для этой цели рекомендуется воспользоваться отдельным файловым кэшем:
CACHES = {
"default": {
# Default caching backend setup, see above
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "unix:///var/run/redis/redis.sock?db=0",
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
"PARSER_CLASS": "redis.connection.HiredisParser",
},
},
"avatar": {
"BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
"LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
"TIMEOUT": 604800,
"OPTIONS": {
"MAX_ENTRIES": 1000,
},
},
}
Настройка отправки электронной почты¶
Weblate’у по разным случаям необходимо отправлять электронные письма и эти письма должны иметь правильный адрес отправителя, поэтому настройте параметры SERVER_EMAIL и DEFAULT_FROM_EMAIL так, чтобы они соответствовали вашему окружению, например:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Примечание
Для отключения отправки писем Weblate’ом установите переменную EMAIL_BACKEND в значение django.core.mail.backends.dummy.EmailBackend.
При этом доставка сообщений электронной почты будет отключена целиком, включая сообщения для регистрации или сброса пароля.
Настройка разрешенных хостов¶
Django требует, чтобы в параметре ALLOWED_HOSTS содержался список доменных имен, которые разрешено обслуживать вашему сайту, если его оставить пустым, любые запросы будут заблокированы.
В случае, если он не настроен на соответствие вашему HTTP-серверу, вы будете получать ошибки вида Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
Подсказка
Внутри контейнера Docker он доступен через переменную окружения WEBLATE_ALLOWED_HOSTS.
Секретный ключ Django¶
Параметр SECRET_KEY используется Django для подписания файлов кук и вы обязательно должны сгенерировать свое собственное значение, а не использовать приведенное в примере настройки.
Создать новый ключ вы можете с помощью скрипта weblate-generate-secret-key, поставляемого вместе с Weblate.
См. также
Выполнение задач технического обслуживания¶
Для оптимальной производительности рекомендуется запускать некоторые задачи обслуживания в фоновом режиме. Это автоматически делается Фоновые задачи с использованием Celery и охватывает следующие задачи:
Проверку работоспособности состояния конфигурации (ежечасно).
Фиксация ожидающих изменений (ежечасно) см. Отложенные коммиты и
commit_pending.Обновление предупреждений компонента (ежедневно).
Обновление удалённых веток (по ночам), смотрите параметр
AUTO_UPDATE.Резервное копирование памяти переводов в JSON (ежедневно), см.
dump_memory.Полнотекстовые задачи и задачи по обслуживанию базы данных (ежедневные и еженедельные), см.
cleanuptrans.
Системные локали и кодировки¶
Системные локали должны быть настроены на поддерживающие UTF-8. В большинстве дистрибутивов Linux это умолчательная их настройка. В случае, если в вашей системе это не так, измените пожалуйста локали на вариант с поддержкой UTF-8.
Например, путём редактирования файла /etc/default/locale и прописывания в нём команды LANG="C.UTF-8".
В некоторых случаях отдельные сервисы имеют отдельные настройки для локалей. Это зависит от дистрибутива и веб-сервера, поэтому проверьте документацию к пакетам вашего веб-сервера.
Apache на Ubuntu использует /etc/apache2/envvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache на CentOS использует /etc/sysconfig/httpd (или /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Сжатие клиентских ресурсов¶
Weblate поставляется с кучей файлов JavaScript и CSS. Из соображений производительности хорошей практикой будет сжимать их перед отправкой клиенту. В конфигурации по умолчанию это делается на лету ценой небольших накладных расходов. В больших же установках рекомендуется включить режим предварительного сжатия. Это можно сделать в настройках, а повторное сжатие файлов должно запускаться при каждом обновлении Weblate.
Такое переключение режима выполняется простым включением параметра django.conf.settings.COMPRESS_OFFLINE и заданием соответствующих настроек в параметре django.conf.settings.COMPRESS_OFFLINE_CONTEXT (последний уже включён в пример файла настроек):
COMPRESS_OFFLINE = True
При каждом развёртывании вам необходимо сжимать файлы, чтобы они соответствовали текущей версии:
weblate compress
Подсказка
В официальном образе Docker эта функция уже включена.
Запуск сервера¶
Подсказка
Если у вас нет опыта работы с услугами, описанными ниже, вы можете попробовать Установка с помощью Docker’а.
Чтобы запустить Weblate, вам понадобится несколько сервисов, рекомендуемая конфигурация состоит из:
Сервера базы данных (смотрите раздел Настройка базы данных для Weblate)
Сервера кэша (смотрите раздел Настройка кэша)
Веб-сервера на клиентской части для раздачи статических файлов и SSL-терминации (смотрите раздел Обслуживание статических файлов)
Сервера WSGI для генерации динамического содержимого (смотрите раздел Примеры файлов настроек NGINX и uWSGI)
Celery для выполнения фоновых задач (смотрите раздел Фоновые задачи с использованием Celery)
Примечание
Между некоторыми сервисами существуют зависимости, например, кэш и база данных должны быть запущены до запуска процессов Celery или uwsgi.
В большинстве случаев вы будете запускать все сервисы на одном (виртуальном) сервере, но в случае, если ваша установка испытывает тяжелые нагрузки, вы можете их разделить. Единственным ограничением является то, что серверы Celery и Wsgi должны иметь доступ к каталогу DATA_DIR.
Примечание
Процесс WSGI должен выполняться под тем же пользователем, под которым работает Celery, иначе файлы в каталоге DATA_DIR будут сохраняться с разными владельцами, что приведёт к проблемам во время выполнения.
Смотреть также раздел Права доступа к файлам и Фоновые задачи с использованием Celery.
Запуск веб-сервера¶
Запуск Weblate ничем не отличается от запуска любой другой программы на базе Django. Как правило, Django выполняется как WSGI или fcgi (смотрите ниже примеры для различных веб-серверов).
Примечание
The sample configuration files shown below are maintained in the Weblate
source tree under weblate/examples/. They are included in source
distributions and in this documentation, but Python wheels only install
runtime files. When installing Weblate from PyPI, get the matching source
distribution or source checkout before copying these examples.
В целях тестирования можно использовать встроенный в Django веб-сервер:
weblate runserver
Предупреждение
НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР В РАБОЧЕЙ СРЕДЕ. Он не проходил аудиты безопасности или тесты производительности. Также смотрите документацию Django по команде runserver.
Подсказка
Встроенный сервер Django обслуживает статические файлы только с включённым параметром DEBUG, поскольку он предназначен только для разработки. Для использования в рабочей среде смотрите установки WSGI:
Обслуживание статических файлов¶
Изменено в версии 5.15.2: /media/ больше не используется для обслуживания снимков экрана.
Django необходимо собрать статические файлы в одном каталоге. Для этого выполните weblate collectstatic --noinput. Это скопирует статические файлы в каталог, указанный настройкой STATIC_ROOT (по умолчанию это static каталог внутри CACHE_DIR).
Статические файлы рекомендуется раздавать непосредственно с вашего веб-сервера, это следует делать для следующих путей:
/static/Предоставляет статические файлы для Weblate и интерфейса администратора (определяется
STATIC_ROOT)./favicon.icoДолжен быть переписан, чтобы переписать правило для раздачи
/static/favicon.ico.
Политика безопасности содержимого¶
В конфигурации Weblate по умолчанию уже включено использование промежуточного ПО weblate.middleware.SecurityMiddleware, которое устанавливает связанные с безопасностью заголовки HTTP, такие как Content-Security-Policy или X-XSS-Protection. По умолчанию они настроены для работы с Weblate и его конфигурацией, но для этого может потребоваться настройка вашего окружения.
Пример конфигурации для NGINX и Granian¶
Следующая конфигурация запускает Weblate с использованием Granian под веб-сервером NGINX:
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:8888;
proxy_read_timeout 3600;
}
}
Пример файла настроек NGINX и Gunicorn¶
The following configuration runs Weblate using Gunicorn under the NGINX webserver
(weblate/examples/weblate.nginx.gunicorn.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://unix:/run/gunicorn.sock;
proxy_read_timeout 3600;
}
}
Примеры файлов настроек NGINX и uWSGI¶
Для запуска рабочего веб-сервера используйте обёртку WSGI, установленную с Weblate (при использовании виртуального окружения Python она устанавливается как ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). Не забудьте также указать путь поиска Python в вашем виртуальном окружении (например, используя virtualenv = /home/user/weblate-env в uWSGI).
Со следующими файлами настроек Weblate будет запускаться как uWSGI-приложение под веб-сервером NGINX.
Configuration for NGINX (weblate/examples/weblate.nginx.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
include uwsgi_params;
# Needed for long running operations in admin interface
uwsgi_read_timeout 3600;
# Adjust based to uwsgi configuration:
uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
# uwsgi_pass 127.0.0.1:8080;
}
}
Configuration for uWSGI (weblate/examples/weblate.uwsgi.ini in the source tree):
#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins = python3
master = true
protocol = uwsgi
socket = 127.0.0.1:8080
wsgi-file = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py
# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path = /path/to/weblate
# Path to the Python environment
virtualenv = /home/weblate/weblate-env
# Needed for OAuth/OpenID
buffer-size = 8192
# Reload when consuming too much of memory
reload-on-rss = 250
# Increase number of workers for heavily loaded sites
workers = 8
# Enable threads for Sentry error submission
enable-threads = true
# Child processes do not need file descriptors
close-on-exec = true
# Avoid default 0000 umask
umask = 0022
# Run as weblate user
uid = weblate
gid = weblate
# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true
# Enable uWSGI stats server
# stats = :1717
# stats-http = true
# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true
См. также
Пример файла настроек Apache¶
Когда Weblate используется с WSGI, то рекомендуется использовать модуль мультипроцессовой обработки (MPM) prefork.
The following configuration runs Weblate as WSGI, you need to have enabled
mod_wsgi (weblate/examples/apache.conf in the source tree):
#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Примечание
Weblate требует Python 3, поэтому, пожалуйста, убедитесь, что вы используете вариант modwsgi, собранный с Python 3. Обычно он доступен в виде отдельного пакета, например libapache2-mod-wsgi-py3.
Используйте соответствующую версию Python для установки Weblate.
Пример файла настроек Apache и Gunicorn¶
The following configuration runs Weblate in Gunicorn and Apache 2.4
(weblate/examples/apache.gunicorn.conf in the source tree):
#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/https_cert.cert
SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
SSLProxyEngine On
ProxyPass /favicon.ico !
ProxyPass /static/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Пример конфигурации для запуска Granian¶
Weblate имеет необязательную зависимость wsgi (см. Зависимости Python), которая установит всё необходимое для запуска Granian. При установке Weblate вы можете указать её как:
uv pip install Weblate[all,wsgi]
После установки Granian вы можете запустить его. Обычно это делается на системном уровне. Следующие примеры показывают запуск через systemd:
[Unit]
Description=granian daemon
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
--no-ws \
--workers-max-rss 350 \
--interface wsgi \
--workers 2 \
--backpressure 16 \
--runtime-threads 8 \
--runtime-mode mt \
--port 8888 \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
~
Пример конфигурации для запуска Gunicorn¶
Gunicorn необходимо установить отдельно:
uv pip install gunicorn
После установки Gunicorn вы можете запустить его. Обычно это делается на системном уровне. Следующие примеры показывают запуск через systemd:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
--preload \
--timeout 3600 \
--graceful-timeout 3600 \
--worker-class=gthread \
--workers=2 \
--threads=16 \
--bind unix:/run/gunicorn.sock \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
См. также
Запуск Weblate по определённому пути в URL¶
Когда Weblate используется с WSGI, то рекомендуется использовать модуль мультипроцессовой обработки (MPM) prefork.
A sample Apache configuration to serve Weblate under /weblate. Again using
mod_wsgi (weblate/examples/apache-path.conf in the source tree):
#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /weblate/static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Кроме того, вам нужно будет подправить weblate/settings.py:
URL_PREFIX = "/weblate"
Фоновые задачи с использованием Celery¶
Weblate использует Celery для выполнения обычных и фоновых задач. Вы должны запустить службу Celery, которая будет их выполнять. Например, он отвечает за выполнение следующих операций (этот список не является полным):
Получение веб-обработчиков от внешних служб (смотрите раздел Обработчики уведомлений).
Выполнение регулярных задач обслуживания, таких как резервное копирование, очистка, ежедневные надстройки или обновления (смотрите раздел Резервное копирование и перенос Weblate,
BACKGROUND_TASKS, Дополнения).Выполнение Автоматический перевод.
Отправка уведомлений о сводках.
Выделение дорогостоящих операций из процесса WSGI.
Коммитинг отложенных изменений (смотрите раздел Отложенные коммиты).
Типичная настройка с использованием Valkey или Redis в качестве бэкенда выглядит так:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
См. также
You should also start the Celery worker to process the tasks and start scheduled tasks. For debugging or development, this can be done directly on the command-line:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup
Примечание
Процесс Celery должен выполняться под тем же пользователем, под которым работает процесс WSGI, иначе файлы в каталоге DATA_DIR будут сохраняться с разными владельцами, что приведёт к проблемам во время выполнения.
Смотреть также раздел Права доступа к файлам и Запуск сервера.
Выполнение задач Celery в WSGI с использованием режима eager mode¶
Примечание
Это сильно повлияет на производительность веб-интерфейса и приведёт к поломке функций, зависящих от регулярного срабатывания (например, коммитинг ожидающих изменений, уведомления о сводке или резервное копирование).
При разработке Weblate или модулей для него вы можете использовать «нетерпеливую» конфигурацию, тогда все задачи будут выполнятся непосредственно при их вызове:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Запуск Celery в качестве системного сервиса¶
Most likely you will want to run Celery as a daemon and that is covered by
Daemonization. For the most common Linux setup using
systemd, adapt the example files listed below. These examples are maintained in
the Weblate source tree under weblate/examples/; Python wheels do not
install these deployment samples.
Модуль systemd, размещаемый по пути /etc/systemd/system/celery-weblate.service:
[Unit]
Description=Celery Service (Weblate)
After=network.target
[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
-A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
--logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
--pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
-A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
--logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
[Install]
WantedBy=multi-user.target
Файл настроек переменных окружения должен быть размещён в /etc/default/celery-weblate:
# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"
# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"
# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"
# Extra command-line arguments to the worker. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
--queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
--queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
--queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
--queues:backup=backup --concurrency:backup=1 --prefetch-multiplier:backup=2"
# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
# and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"
Для ротации журналов Celery файл настроек logrotate должен быть размещён в /etc/logrotate.d/celery:
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Периодические задачи при помощи Celery beat¶
Weblate поставляется со встроенной конфигурацией планировщика задач. Расписание задач хранится в базе данных, а задачи выполняются демоном Celery beat.
Подсказка
Вы можете определить дополнительные задачи в settings.py, например, см. Отложенные коммиты.
Мониторинг состояния Celery¶
Вы можете узнать текущую длину очередей задач Celery в Интерфейс управления или использовать celery_queues в командной строке. Если очередь станет слишком длинной, вы также получите сообщение об ошибке конфигурации в интерфейсе администратора.
Предупреждение
Ошибки Celery по умолчанию записываются только в журнал Celery и не видны пользователю. Если вы хотите иметь обзор таких сбоев, рекомендуется настроить Сбор отчётов об ошибках и мониторинг производительности.
Однопроцессная установка для производства Celery¶
В случае, если у вас очень ограниченный объём памяти, возможно, стоит уменьшить количество процессов Weblate. Все задачи Celery могут выполняться в одном процессе с помощью:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Установку с использованием Docker можно настроить на использование одно-процессной конфигурации Celery, установив CELERY_SINGLE_PROCESS.
Предупреждение
Это заметно скажется на производительности Weblate.
Мониторинг Weblate¶
Weblate предоставляет URL-адрес /healthz/, который можно использоваться для простой проверки его работоспособности, например, при использовании Kubernetes. Docker container имеет встроенную проверку работоспособности с помощью этого URL-адреса.
Для мониторинга метрик Weblate вы можете использовать конечную точку API GET /api/metrics/.
Сбор отчётов об ошибках и мониторинг производительности¶
Weblate, как и любое другое программное обеспечение, может дать сбой. Для сбора полезной информации о сбоях мы рекомендуем использовать услуги сторонних сервисов. Особенно они полезны в случае сбоя в задачах Celery, которые в противном случае просто записали бы ошибку в журнал, и вы не получили о ней никакого уведомления. Weblate поддерживает следующие сервисы:
Эл. почта¶
Конфигурация Weblate по умолчанию настраивает Django на отправку электронных писем при ошибках сервера через django.utils.log.AdminEmailHandler. Это наиболее простая настройка, но по соображениям конфиденциальности вам следует рассмотреть другие варианты, так как письма об ошибках могут содержать конфиденциальные данные. Подробнее об этом можно прочитать в Security implications.
Чтобы отключить это поведение, удалите mail_admins из LOGGING в настройках Weblate, или отключите WEBLATE_ADMIN_NOTIFY_ERROR в среде Docker.
Sentry¶
В Weblate встроена поддержка Sentry. Для его использования достаточно установить параметр SENTRY_DSN в settings.py:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Sentry также может использоваться для мониторинга производительности Weblate путем сбора трасс и профилей для определенного процента операций. Это можно настроить с помощью SENTRY_TRACES_SAMPLE_RATE и SENTRY_PROFILES_SAMPLE_RATE.
Rollbar¶
Weblate имеет встроенную поддержку Rollbar. Для его использования достаточно следовать инструкциям из документа Уведомления Rollbar для Python.
Вкратце, вам необходимо дописать в settings.py:
# Add rollbar as last middleware:
MIDDLEWARE = [
# … other middleware classes …
"rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]
# Configure client access
ROLLBAR = {
"access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
"environment": "development" if DEBUG else "production",
"branch": "main",
"root": "/absolute/path/to/code/root",
}
Все остальное интегрируется автоматически, теперь у вас будут собираться ошибки как со стороны сервера, так и со стороны клиента.
Примечание
Журнал ошибок также включает исключения, которые были правильно обработаны, но могут указывать на проблему, например, на неудачный разбор загруженного файла.
Управление журналами Graylog¶
Добавлено в версии 5.9.
Weblate можно настроить для ведения журнала с использованием протокола GELF TCP. Это было разработано для интеграции с Graylog, но может использоваться с любой совместимой платформой ведения журналов.
Шаблон конфигурации включён в Пример файла настроек, для Docker это можно настроить с помощью WEBLATE_LOG_GELF_HOST.
Перенос Weblate на другой сервер¶
Перенос Weblate на другой сервер должен быть достаточно простой операцией, однако он хранит данные в нескольких местах, переносить которые следует с некоторой осторожностью. Лучше всего для переноса на время остановить Weblate.
Перенос базы данных¶
Самый простой подход — использовать собственные инструменты базы данных, так как они обычно наиболее эффективны (например, pg_dump). Как вариант, вы можете использовать репликацию, если ваша база данных поддерживает её.
См. также
Миграция между базами данных описана в разделе Переход с других баз данных на PostgreSQL.
Перенос репозиториев системы контроля версий¶
Также необходимо перенести репозитории системы контроля версий, хранящиеся в каталоге DATA_DIR. Вы можете просто скопировать их, либо воспользоваться командой rsync для более эффективного выполнения переноса.
Прочие заметки¶
Не забудьте переместить другие службы, которые могли использоваться Weblate, такие как Valkey, Redis, задачи Cron или пользовательские бэкенды аутентификации.