Инструкции по настройке¶

Установка Weblate¶

В зависимости от ваших настроек и опыта выберите подходящий для вас способ установки:

Установка с помощью Docker’а, рекомендуется для установки на рабочих серверах.
Установка в виртуальное окружение, рекомендуется для рабочей среды:
Установка из исходников, рекомендуется для разработки.
Установка на OpenShift
Установка на Kubernetes

Обзор архитектуры¶

Веб-сервер

Handling incoming HTTP requests, Обслуживание статических файлов.

Celery workers

Фоновые задачи с использованием Celery are executed here.

Depending on your workload, you might want to customize the number of workers.

Use dedicated node when scaling Weblate horizontally.

WSGI server

A WSGI server serving web pages to users.

Use dedicated node when scaling Weblate horizontally.

База данных

Сервер базы данных PostgreSQL для хранения всего содержимого, см. Настройка базы данных для Weblate.

Use dedicated database node for sites with hundreds of millions of hosted words.

Redis

Сервер Redis для кэша и очереди задач, смотрите раздел Фоновые задачи с использованием Celery.

Use dedicated node when scaling Weblate horizontally.

File system

File system storage for storing VCS repositories and uploaded user data. This is shared by all the processes.

Use networked storage when scaling Weblate horizontally.

E-mail server

SMTP server for outgoing e-mail, see Настройка исходящей почты. It can be provided externally.

Подсказка

Установка с помощью Docker’а includes PostgreSQL and Redis, making the installation easier.

Требования к программному обеспечению¶

Операционная система¶

Weblate работает на Linux, FreeBSD и macOS. Скорее всего будет работать и на других Unix-подобных системах.

Работа Weblate под Windows не поддерживается. Тем не менее, работать под ней он всё ещё может и патчи под неё с радостью принимаются.

См.также

Обзор архитектуры describes overall Weblate architecture and required services.

Зависимости Python¶

Weblate is written in Python and supports Python 3.10 or newer. You can install dependencies using pip or from your distribution packages, full list is available in requirements.txt.

Основные зависимости:

Django: https://www.djangoproject.com/
Celery: https://docs.celeryq.dev/
Инструментарий для перевода: https://toolkit.translatehouse.org/
поисковик переводов: https://github.com/WeblateOrg/translation-finder
Python Social Auth: https://python-social-auth.readthedocs.io/
Среда Django REST: https://www.django-rest-framework.org/

Необязательные зависимости¶
pip extra	Пакет Python	Функция Weblate
`alibaba`	aliyun-python-sdk-alimt	Alibaba
`amazon`	boto3	Amazon Translate
`antispam`	python-akismet	Защита от спама
`gerrit`	git-review	Gerrit
`google`	google-cloud-translate	Google Cloud Translation Advanced
`ldap`	django-auth-ldap	Авторизация через LDAP
`mercurial`	mercurial	Mercurial
`mysql`	mysqlclient	MySQL или MariaDB, см. Настройка базы данных для Weblate
`openai`	openai	OpenAI
`postgres`	psycopg	PostgreSQL, см. Настройка базы данных для Weblate
`saml`	python3-saml	Авторизация через SAML
`zxcvbn`	django-zxcvbn-password	Авторизация по паролю

При установке с помощью pip вы можете напрямую указать желаемые функции при установке:

pip install "Weblate[Postgres,Amazon,SAML]"

Или вы можете установить Weblate со всеми дополнительными функциями:

pip install "Weblate[all]"

Или вы можете установить Weblate без каких-либо дополнительных функций:

pip install Weblate

Другие системные требования¶

В системе должны быть установлены следующие зависимости:

Git: https://git-scm.com/
Pango, Cairo и связанные заголовочные файлы, а также данные интроспекции GObject: https://cairographics.org/, https://pango.gnome.org/, смотрите раздел Pango и Cairo
git-review (необязательная зависимость для поддержки Gerrit): https://pypi.org/project/git-review/
git-svn (необязательная зависимость для поддержки Subversion): https://git-scm.com/docs/git-svn
tesseract (необходимо только в том случае, если бинарные колёса tesserocr недоступны для вашей системы): https://github.com/tesseract-ocr/tesseract
licensee (необязательная зависимость для определения лицензии при создании компонента): https://github.com/licensee/licensee

Зависимости времени компиляции¶

Для сборки некоторых зависимостей Python может потребоваться установка также и их зависимостей. Это зависит от того, как именно вы их устанавливаете, так что за справкой по установке обратитесь к документации соответствующих пакетов. Вручную устанавливать зависимости зависимостей вам не понадобятся, если вы, например, устанавливаете их через pip и используете предварительно-собранные «колёса» (Wheels) или устанавливаете их через пакетный менеджер вашего дистрибутива.

Pango и Cairo¶

Weblate использует Pango и Cairo для отрисовки растровых виджетов (смотрите раздел Продвижение перевода) и проверки отрисовки текста (смотрите раздел Управление шрифтами). Для правильной установки привязок Python сначала нужно установить системные библиотеки — вам нужны и Cairo, и Pango, которым, в свою очередь, нужна GLib. Все они должны быть установлены с файлами для разработки и данными интроспекции GObject.

См.также

Установка на Debian и Ubuntu, Установка на SUSE и openSUSE, Установка на RedHat, Fedora и CentOS, Установка на macOS

Требования к оборудованию¶

Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):

3 ГБ ОЗУ
2-х ядерный процессор
1 ГБ дискового пространства

Примечание

Фактические требования к вашей установке Weblate сильно зависят от размера управляемых ею переводов.

Memory usage¶

The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.

Подсказка

Для систем с меньшим, чем рекомендуется, объёмом памяти рекомендуется использовать Однопроцессная установка для производства Celery.

CPU usage¶

Many concurrent users increase the amount of needed CPU cores.

Storage usage¶

The typical database storage usage is around 300 MB per 1 million hosted words.

Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.

Nodes¶

For small and medium-sized sites (millions of hosted words), all Weblate components (see Обзор архитектуры) can be run on a single node.

When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Настройка базы данных для Weblate).

Проверка подписей выпусков¶

Weblate release are cryptographically signed using Sigstore signatures. The signatures are attached to the GitHub release.

The verification can be performed using sigstore package. The following example verifies signature of the 5.4 release:

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 попытается автоматически создать эти каталоги, но у него ничего не получится, если у него не будет соответствующих прав доступа.

Также вам следует быть особенно внимательными, когда запускаете команды управления, поскольку они должны выполняться под тем же пользователем, под которым запущен сам Weblate. В противном случае права доступа на некоторые файлы могут быть выставлены неверно.

В контейнере Docker все файлы в томе /app/data должны принадлежать пользователю weblate внутри самого контейнера (UID 1000).

См.также

Обслуживание статических файлов

Настройка базы данных для Weblate¶

Рекомендуется запускать Weblate с сервером баз данных PostgreSQL.

PostgreSQL 12 and higher is supported. PostgreSQL 15 or newer is recommended.

MySQL и MariaDB is supported, but not recommended for new installs.

Примечание

No other database servers are currently supported, but support for other Django supported databases should be possible to implement.

См.также

Использование мощного движка базы данных, Базы данных, Переход с других баз данных на PostgreSQL

Database connections¶

В конфигурации по умолчанию каждый процесс Weblate поддерживает постоянное соединение с базой данных. Постоянные соединения улучшают отзывчивость Weblate, но могут потребовать больше ресурсов для сервера базы данных. Для получения дополнительной информации обратитесь к CONN_MAX_AGE и Persistent connections.

Weblate needs at least the following number of connections:

$(4 \times \mathit{nCPUs}) + 2$ for Celery processes
$\mathit{nCPUs} + 1$ for WSGI workers

This applies to Docker container defaults and example configurations provided in this documentation, but the numbers will change once you customize the amount of WSGI workers or adjust parallelism of Celery.

The actual limit for the number of database connections needs to be higher to account following situations:

Команды управления need their connection as well.
If case process is killed (for example by OOM killer), it might block the existing connection until timeout.

См.также

Фоновые задачи с использованием Celery, Примеры файлов настроек NGINX и uWSGI, WEBLATE_WORKERS

PostgreSQL¶

PostgreSQL, как правило, является лучшим выбором для сайтов, написанных на Django. Это эталонная база данных, используемая для реализации слоя баз данных Django.

Примечание

Weblate использует расширение для триграмм, которое в некоторых случаях должно быть установлено отдельно. Ищите пакет postgresql-contrib или аналогичный.

См.также

PostgreSQL notes

Создание базы данных в 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",
        # Name of role to alter to set parameters in PostgreSQL,
        # use in case role name is different than user used for authentication.
        # "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 совместно с PostgreSQL, хотя это может происходить и при других обстоятельствах. Установите параметр ALTER_ROLE, чтобы задать ту роль, которую Weblate должен изменить во время миграции базы данных.

См.также

Database connections

MySQL и MariaDB¶

Предупреждение

В то время как поддержка MySQL и MariaDB по-прежнему поддерживается в Weblate, наше основное внимание уделяется PostgreSQL. Рекомендуется использовать PostgreSQL для новых установок, а для переноса существующих установок в PostgreSQL см. Переход с других баз данных на PostgreSQL.

Некоторые функции Weblate лучше работают с PostgreSQL. Среди них: поиск и память переводов, обе из которых используют функции полнотекстового поиска базы данных, а их реализация в PostgreSQL превосходит все остальные.

Weblate также можно использовать с MySQL или MariaDB, ознакомитесь с предостережениями по их использованию вместе с Django в разделах Замечания по MySQL и Замечания по MariaDB его документации. Из-за ограничений рекомендуется использовать :ref:`postgresql`при новой установке.

Для Weblate требуется MySQL не ниже 8 или MariaDB не ниже 10.4.

Для Weblate рекомендуется следующая конфигурация:

Используйте кодовую таблицу utf8mb4 для представления символов с более высоких плоскостей Юникода (например, эмодзи).
Настройте сервер на использование innodb_large_prefix для разрешения более длинных индексов для текстовых полей.
Установите уровень изоляции в READ COMMITTED.
Режим SQL должен быть установлен в STRICT_TRANS_TABLES.

MySQL 8.x, MariaDB 10.5.x или новее имеют разумную конфигурацию по умолчанию, поэтому не требуется настройка сервера, а всё необходимое можно настроить на стороне клиента.

Ниже приведён пример типового файла настроек /etc/my.cnf.d/server.cnf для сервера с 8ГБ ОЗУ. Таких настроек должно хватить для большинства установок. У MySQL и MariaDB есть и другие параметры, которые могут повысить производительность сервера, но обычно прибегать к ним нет смысла, если только вы не планируете, что достаточно большое количество пользователей будут работать с вашему сервером одновременно. В таком случае смотрите подробности по конфигурации сервера для таких задач в документации своей СУБД.

Дабы при установке Weblate не возникло проблем, абсолютно критично, чтобы параметр innodb_file_per_table был включён; а также после его изменения нужно не забыть перезапустить MySQL/MariaDB.

[mysqld]
character-set-server = utf8mb4
character-set-client = utf8mb4
collation-server = utf8mb4_unicode_ci

datadir=/var/lib/mysql

log-error=/var/log/mariadb/mariadb.log

innodb_large_prefix=1
innodb_file_format=Barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=2G
sql_mode=STRICT_TRANS_TABLES

Подсказка

Если вы получаете ошибку #1071 - Specified key was too long; max key length is 767 bytes (указанный ключ слишком длинный; максимальная длина ключа - 767 байт), то убедитесь, что в конфигурации вашего сервера включены параметры innodb, описанные выше.

Подсказка

В случае, если вы получаете ошибку #2006 - MySQL server has gone away (сервер MySQL более недоступен), то может помочь настройка параметра CONN_MAX_AGE.

См.также

Database connections

Настройка Weblate для работы совместно с MySQL/MariaDB¶

Фрагмент файла настроек settings.py для MySQL и MariaDB:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.mysql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "127.0.0.1",
        # Set to empty string for default
        "PORT": "3306",
        # In case you wish to use additional
        # connection options
        "OPTIONS": {},
    }
}

Также прежде чем начать установку вам нужно будет создать пользователя базы данных с именем weblate. Это можно сделать с помощью следующей команды:

GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

См.также

Database connections

Другие настройки¶

Настройка исходящей почты¶

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, Настройка исходящего адреса электронной почты внутри контейнера Docker

Работа за обратным прокси¶

Некоторые функции Weblate полагаются на возможность получения IP-адреса клиента. Среди этих функций Ограничение частоты запросов, Защита от спама или Журнал аудита.

В стандартной конфигурации Weblate достает IP-адрес из переменной REMOTE_ADDR, которая устанавливается обработчиком WSGI.

Если же вы используете обратный прокси, то это поле, скорее всего, будет содержать его адрес. Вам нужно настроить Weblate на доверие дополнительным HTTP-заголовкам и доставать IP-адрес из них. Эту настройку нельзя включить по умолчанию, поскольку она разрешит подмену IP-адреса для установок, не использующих обратный прокси. Для самых обычных установок будет достаточно включения параметра IP_BEHIND_REVERSE_PROXY, но вам также может понадобиться подправить параметры IP_PROXY_HEADER и IP_PROXY_OFFSET.

Ещё один момент, на который следует обратить внимание, это заголовок Host. Он должен соответствовать тому, что настроено в SITE_DOMAIN. Дополнительная настройка может потребоваться в вашем обратном прокси (например, используйте ProxyPreserveHost On для Apache или proxy_set_header Host $host; для nginx).

См.также

Защита от спама, Ограничение частоты запросов, Журнал аудита, IP_BEHIND_REVERSE_PROXY, IP_PROXY_HEADER, IP_PROXY_OFFSET, 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"

См.также

Proxy Environment Variables

Изменение конфигурации под свои нужды¶

См.также

Пример файла настроек

Скопируйте weblate/settings_example.py в weblate/settings.py и подправьте его в соответствии со своими настройками. Скорее всего, вы захотите настроить следующие параметры:

ADMINS

Список администраторов сайтов для получения уведомлений, когда что-то идет не так, например, для получения уведомлений о неудачных слияниях, или об ошибках Django.

Contact form sends e-mail on these as well unless ADMINS_CONTACT is configured.

См.также

ADMINS, ADMINS_CONTACT, Правильная настройка администраторов

ALLOWED_HOSTS

Вы должны установить эту настройку в список хостов, которые должен обслуживать ваш сайт. Например:
ALLOWED_HOSTS = ["demo.weblate.org"]
Или же вы можете указать символ шаблона:
ALLOWED_HOSTS = ["*"]
См.также

ALLOWED_HOSTS, WEBLATE_ALLOWED_HOSTS, Настройка разрешенных хостов

SESSION_ENGINE

Настраивает то, как будут храниться ваши сессии. В случае, если вы оставили механизм хранения по умолчанию — в базе данных — вы должны настроить расписание для команды weblate clearsessions, удаляющей из базы данных данные об устаревших сессиях.

Если вы используете в качестве кэша Redis (смотрите раздел Включение кэширования), рекомендуется использовать его также и для сессий:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
См.также

Настройка движка сессий, SESSION_ENGINE

DATABASES

Подключение к серверу базы данных, подробнее об этой настройке читайте в документации Django.

См.также

Настройка базы данных для Weblate, DATABASES, Базы данных

DEBUG

Отключите эту настройку для любого рабочего сервера. При включенном режиме отладки Django в случае возникновения ошибки будет показывать трассировки стека пользователям, при его же отключении ошибки будут отправляться на адреса электронной почты из массива ADMINS (смотрите выше).

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

См.также

DEBUG, Отключение отладочного режима

DEFAULT_FROM_EMAIL

Адрес электронной почты отправителя для исходящих сообщений электронной почты, например, для писем регистрации.

См.также

DEFAULT_FROM_EMAIL

SECRET_KEY

Ключ, используемый Django для подписывания некоторой информации, сохраняемой в куках, подробнее смотрите в разделе Секретный ключ Django.

См.также

SECRET_KEY

SERVER_EMAIL

Адрес электронной почты, используемый в качестве адреса отправителя для отправки сообщений администратору, например, уведомлений о неудачных слияниях.

См.также

SERVER_EMAIL

Наполнение базы данных¶

После того, как ваша конфигурация будет готова, вы можете запустить migrate, чтобы создать структуру базы данных. Теперь вы сможете создавать проекты перевода, используя интерфейс администратора.

После того, как вы закончите, вам также стоит проверить Отчёт о производительности в интерфейсе администратора. Информация оттуда может дать вам подсказки по исправлению потенциально не оптимальной конфигурации вашего сайта.

См.также

Конфигурация, Список привилегий

Рабочая среда¶

Для установки в рабочую среду необходимо провести корректировки, описанные в следующих разделах. Наиболее критичные настройки вызовут предупреждение, которое обозначается восклицательным знаком в верхней панели, если вы вошли в систему под суперпользователем:

Также рекомендуется изучить все проверки, произведённые Django (хотя, возможно, исправлять их все нет необходимости):

weblate check --deploy

You can also review the very same checklist at Отчёт о производительности in the Интерфейс управления.

См.также

Контрольный список развертывания

Отключение отладочного режима¶

Отключите отладочный режим Django (DEBUG), установив:

DEBUG = False

При включенном отладочном режиме Django сохраняет все выполненные запросы и при возникновении ошибок показывает пользователям обратную трассировку стека, что в рабочей среде не желательно.

См.также

Изменение конфигурации под свои нужды

Правильная настройка администраторов¶

Укажите в настройке ADMINS правильные адреса администраторов, чтобы определить, кто будет получать электронную почту в случае, если на сервере что-то пойдёт не так, например:

ADMINS = (("Your Name", "your_email@example.com"),)

См.также

Изменение конфигурации под свои нужды

Установка правильного домена сайта¶

Поправьте имя сайта и домен в интерфейсе администратора, иначе ссылки в RSS или регистрационные письма не будут работать. Эта настройка осуществляется с помощью параметра SITE_DOMAIN, который должен содержать доменное имя сайта.

Изменено в версии 4.2: До выхода версии 4.2 вместо него использовалась среда «сайтов» Django, см. раздел среды «сайтов».

См.также

Настройка разрешенных хостов, Правильная настройка HTTPS SITE_DOMAIN, WEBLATE_SITE_DOMAIN, ENABLE_HTTPS

Правильная настройка HTTPS¶

Настоятельно рекомендуется запускать Weblate с использованием шифрующего протокола HTTPS. После его включения в настройках необходимо установить параметр ENABLE_HTTPS:

ENABLE_HTTPS = True

Подсказка

Возможно, вы также захотите настроить HSTS, для получения более подробной информации смотрите документ SSL/HTTPS.

См.также

ENABLE_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.

См.также

Настройка базы данных для Weblate, Переход с других баз данных на PostgreSQL, Изменение конфигурации под свои нужды, Базы данных

Включение кэширования¶

Если возможно, используйте 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",
        },
    }
}

Подсказка

Если вы измените настройки кеширования Redis, то вам также понадобится изменить их и в Celery, смотреть раздел Фоновые задачи с использованием Celery.

См.также

Кеширование аватаров, среда кэширования Django

Кеширование аватаров¶

Помимо кэширования силами 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,
        },
    },
}

См.также

ENABLE_AVATARS, AVATAR_URL_PREFIX, Аватары, Включение кэширования, среда кэширования Django

Настройка отправки электронной почты¶

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.

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

См.также

Изменение конфигурации под свои нужды, Настройка исходящей почты, EMAIL_BACKEND, DEFAULT_FROM_EMAIL, SERVER_EMAIL

Настройка разрешенных хостов¶

Django требует, чтобы в параметре ALLOWED_HOSTS содержался список доменных имен, которые разрешено обслуживать вашему сайту, если его оставить пустым, любые запросы будут заблокированы.

В случае, если он не настроен на соответствие вашему HTTP-серверу, вы будете получать ошибки вида Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS. (Неверный заголовок HTTP_HOST: '1.1.1.1'. Возможно, вам нужно добавить '1.1.1.1' в ALLOWED_HOSTS.)

Подсказка

Внутри контейнера Docker он доступен через переменную окружения WEBLATE_ALLOWED_HOSTS.

См.также

ALLOWED_HOSTS, WEBLATE_ALLOWED_HOSTS, Установка правильного домена сайта

Секретный ключ Django¶

Параметр SECRET_KEY используется Django для подписания файлов кук и вы обязательно должны сгенерировать свое собственное значение, а не использовать приведенное в примере настройки.

Создать новый ключ вы можете с помощью скрипта weblate/examples/generate-secret-key, поставляемого вместе с Weblate.

См.также

SECRET_KEY

Выполнение задач технического обслуживания¶

Для оптимальной производительности рекомендуется запускать некоторые задачи обслуживания в фоновом режиме. Это автоматически делается Фоновые задачи с использованием 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'

Использование пользовательского центра сертификации¶

Во время HTTP-запросов Weblate проверяет SSL-сертификаты. Если вы используете пользовательский центр сертификации, который цепочке сертификатов по умолчанию не является доверенным, вам придется добавить его сертификат в качестве доверенного.

Предпочтительный подход — сделать это на системном уровне, подробнее смотрите документацию по дистрибутиву (например, в debian это можно сделать, разместив сертификат центра сертификации в каталоге /usr/local/share/ca-certificates/ и запустив команду update-ca-certificates).

Как только это будет сделано, системные инструменты станут доверять сертификату, среди этих инструментов будет и Git.

Для кода Python вам будет необходимо настроить запросы на использование системной цепочки сертификатов вместо использования цепочки, поставляемой с Python. Этого можно добиться, поместив в settings.py следующий фрагмент кода (путь указан для Debian):

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

Сжатие клиентских ресурсов¶

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 выполняется как uWSGI или fcgi (смотрите ниже примеры для различных веб-серверов).

В целях тестирования можно использовать встроенный в Django веб-сервер:

weblate runserver

Предупреждение

НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР В РАБОЧЕЙ СРЕДЕ. Он не проходил аудиты безопасности или тесты производительности. Также смотрите документацию Django по команде runserver.

Подсказка

The Django built-in server serves static files only with DEBUG enabled as it is intended for development only. For production use, please see WSGI setups in Примеры файлов настроек NGINX и uWSGI, Пример файла настроек Apache, Пример файла настроек Apache и Gunicorn, and Обслуживание статических файлов.

Обслуживание статических файлов¶

Django необходимо собрать статические файлы в одном каталоге. Для этого выполните weblate Collectstatic --noinput. Это скопирует статические файлы в каталог, указанный настройкой STATIC_ROOT (по умолчанию это static каталог внутри CACHE_DIR).

Статические файлы рекомендуется раздавать непосредственно с вашего веб-сервера, это следует делать для следующих путей:

/static/: Предоставляет статические файлы для Weblate и интерфейса администратора (определяется STATIC_ROOT).
/media/: Используется для загрузки пользовательских мультимедийных данных (например, снимков экрана).
/favicon.ico: Должен быть переписан, чтобы переписать правило для раздачи /static/favicon.ico.

См.также

Примеры файлов настроек NGINX и uWSGI, Пример файла настроек Apache, Пример файла настроек Apache и Gunicorn, Сжатие клиентских ресурсов, Развёртывание Django, Развёртывание статических файлов

Политика безопасности содержимого¶

В конфигурации Weblate по умолчанию уже включено использование промежуточного ПО weblate.middleware.SecurityMiddleware, которое устанавливает связанные с безопасностью заголовки HTTP, такие как Content-Security-Policy или X-XSS-Protection. По умолчанию они настроены для работы с Weblate и его конфигурацией, но для этого может потребоваться настройка вашего окружения.

См.также

CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC

Примеры файлов настроек NGINX и uWSGI¶

To run production webserver, use the WSGI wrapper installed with Weblate (in virtual env case it is installed as ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py). Don’t forget to set the Python search path to your virtualenv as well (for example using virtualenv = /home/user/weblate-env in uWSGI).

Со следующими файлами настроек Weblate будет запускаться как uWSGI-приложение под веб-сервером NGINX.

Файл настроек NGINX (этот же пример есть в weblate/examples/weblate.nginx.conf):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate virtualenv 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 /media/ {
        # DATA_DIR/media/
        alias /home/weblate/data/media/;
        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;
    }
}

Файл настроек uWSGI (этот же пример есть в weblate/examples/weblate.uwsgi.ini):

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate virtualenv 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

# In case you're using virtualenv uncomment this:
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

См.также

Как совместно использовать Django c uWSGI

Пример файла настроек Apache¶

Когда Weblate используется с WSGI, то рекомендуется использовать модуль мультипроцессовой обработки (MPM) prefork.

Со следующим файлом настроек Weblate будет запускаться как WSGI-приложение, вам нужно включить модуль mod_wsgi (этот же пример есть в weblate/examples/apache.conf):

#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv 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>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    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.

См.также

Системные локали и кодировки, Как совместно использовать Django c Apache и mod_wsgi

Пример файла настроек Apache и Gunicorn¶

Со следующим файлом настроек Weblate будет запускаться в Gunicorn и Apache 2.4 (этот же пример есть в weblate/examples/apache.gunicorn.conf):

#
# 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 virtualenv 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>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        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 /media/ !

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

См.также

Как совместно использовать Django c Gunicorn

Запуск Weblate по определённому пути в URL¶

Когда Weblate используется с WSGI, то рекомендуется использовать модуль мультипроцессовой обработки (MPM) prefork.

Пример файла настроек Apache для предоставления доступу к Weblate по пути /weblate. Снова используя модуль mod_wsgi (этот же пример есть в weblate/examples/apache-path.conf):

# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later

#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv 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>

    # DATA_DIR/media/
    Alias /weblate/media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    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, Надстройки).
Выполнение Автоматический перевод.
Отправка уведомлений о сводках.
Offloading expensive operations from the WSGI process.
Коммитинг отложенных изменений (смотрите раздел Отложенные коммиты).

Типовая конфигурация, основанная на Redis, выглядит как-то так:

CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL

См.также

Настройка Redis в качестве брокера в Celery

Также вы должны запустить рабочего Celery для обработки задач и запуска запланированных задач, это можно сделать непосредственно в командной строке (что в основном полезно при отладке или разработке):

./weblate/examples/celery start
./weblate/examples/celery stop

Примечание

Процесс Celery должен выполняться под тем же пользователем, под которым работает процесс WSGI, иначе файлы в каталоге DATA_DIR будут сохраняться с разными владельцами, что приведёт к проблемам во время выполнения.

Смотреть также раздел Права доступа к файлам и Запуск сервера.

Executing Celery tasks in the WSGI using eager mode¶

Примечание

Это сильно повлияет на производительность веб-интерфейса и приведёт к поломке функций, зависящих от регулярного срабатывания (например, коммитинг ожидающих изменений, уведомления о сводке или резервное копирование).

При разработке Weblate или модулей для него вы можете использовать «нетерпеливую» конфигурацию, тогда все задачи будут выполнятся непосредственно при их вызове:

CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True

Запуск Celery в качестве системного сервиса¶

Скорее всего вы захотите запустить Celery в качестве демона, и как выполнить ваше желание описывается в разделе Демонизация документации Celery. Для наиболее распространённой установки Linux с использованием systemd вы можете воспользоваться примерами перечисленных ниже файлов, поставляемых в каталоге examples.

Модуль 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,
# increase concurrency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
    --queues:notify=notify --prefetch-multiplier:notify=10 \
    --queues:memory=memory --prefetch-multiplier:memory=10 \
    --queues:translate=translate --prefetch-multiplier:translate=4 \
    --concurrency:backup=1 --queues:backup=backup  --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:

# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later

/var/log/celery/*.log {
        weekly
        missingok
        rotate 12
        compress
        notifempty
}

Периодические задачи при помощи Celery beat¶

Weblate поставляется со встроенной конфигурацией планировщика задач. Вы, однако, можете определить в settings.py дополнительные задачи, для примера смотрите раздел Отложенные коммиты.

Предполагается, что задачи будут выполняться демоном Celery beat. В случае, если он не работает должным образом, он может быть не запущен или его база данных была повреждена. В этом случае проверьте журналы запуска Celery, чтобы выяснить первопричину проблемы.

Мониторинг состояния Celery¶

Вы можете узнать текущую длину очередей задач Celery в Интерфейс управления или использовать celery_queues в командной строке. Если очередь станет слишком длинной, вы также получите сообщение об ошибке конфигурации в интерфейсе администратора.

Предупреждение

Ошибки Celery по умолчанию записываются только в журнал Celery и пользователю не видны. В случае, если вы хотите видеть сводку по таким ошибкам, рекомендуется настроить сбор отчетов об ошибках.

См.также

Мониторинг Weblate, Как мне проверить, правильно ли настроен мой Weblate?, Configuration and defaults, Workers Guide, Daemonization, : doc:celery:userguide/monitoring, celery_queues

Однопроцессная установка для производства Celery¶

В случае, если у вас очень ограниченный объём памяти, возможно, стоит уменьшить количество процессов Weblate. Все задачи Celery могут выполняться в одном процессе с помощью:

celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo

Предупреждение

Это заметно скажется на производительности Weblate.

Мониторинг Weblate¶

Weblate предоставляет URL-адрес /healthz/, который можно использоваться для простой проверки его работоспособности, например, при использовании Kubernetes. Docker container имеет встроенную проверку работоспособности с помощью этого URL-адреса.

Для мониторинга метрик Weblate вы можете использовать конечную точку API GET /api/metrics/.

См.также

Как мне проверить, правильно ли настроен мой Weblate?, Мониторинг состояния Celery, Плагин Weblate для Munin

Сбор отчётов об ошибках и мониторинг производительности¶

Weblate, как и любое другое программное обеспечение, может дать сбой. Для сбора полезной информации о сбоях мы рекомендуем использовать услуги сторонних сервисов. Особенно они полезны в случае сбоя в задачах Celery, которые в противном случае просто записали бы ошибку в журнал, и вы не получили о ней никакого уведомления. Weblate поддерживает следующие сервисы:

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.

См.также

Мониторинг производительности Sentry, профилирование Sentry

Rollbar¶

Weblate имеет встроенную поддержку Rollbar. Для его использования достаточно следовать инструкциям из документа`Уведомления Rollbar для Python <https://docs.rollbar.com/docs/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",
    "client_token": "POST_CLIENT_ITEM_ACCESS_TOKEN",
    "environment": "development" if DEBUG else "production",
    "branch": "main",
    "root": "/absolute/path/to/code/root",
}

Все остальное интегрируется автоматически, теперь у вас будут собираться ошибки как со стороны сервера, так и со стороны клиента.

Примечание

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

Перенос Weblate на другой сервер¶

Перенос Weblate на другой сервер должен быть достаточно простой операцией, однако он хранит данные в нескольких местах, переносить которые следует с некоторой осторожностью. Лучше всего для переноса на время остановить Weblate.

Перенос базы данных¶

В зависимости от бэкэнда вашей базы данных у вас может быть несколько вариантов миграции базы данных. Самый простой подход — использовать собственные инструменты базы данных, поскольку они обычно наиболее эффективны (например, mysqldump или pg_dump). В качестве альтернативы вы можете использовать репликацию, если ваша база данных поддерживает её.

См.также

Миграция между базами данных описана в разделе Переход с других баз данных на PostgreSQL.

Перенос репозиториев системы контроля версий¶

Также необходимо перенести репозитории системы контроля версий, хранящиеся в каталоге DATA_DIR. Вы можете просто скопировать их, либо воспользоваться командой rsync для более эффективного выполнения переноса.

Прочие заметки¶

Не забудьте переместить и другие сервисы, которые Weblate мог использовать, например, Redis, задачи Cron или модули пользовательской авторизации.