Настанови з налаштовування¶

Установлення Weblate¶

Залежно від налаштувань та вашого досвіду, виберіть для себе відповідний спосіб встановлення:

install/docker, рекомендовано для промислових налаштувань.
Установлення у віртуальному середовищі, рекомендовано для промислових конфігурацій:
install/source, рекомендовано для розробки.
Установлення на 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 включає PostgreSQL і Redis, що робить встановлення простішим.

Вимоги для програмного забезпечення¶

Операційна система¶

Відомо, що Weblate працює у Linux, FreeBSD і macOS. Ймовірно, Weblate працює на більшості інших Unix-подібних системах.

Підтримки Weblate у Windows не передбачено. Втім, Weblate може там працювати — будемо раді вашим латкам, які реалізуватимуть підтримку.

Дивись також

Огляд архітектури 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/
Translate Toolkit: https://toolkit.translatehouse.org/
translation-finder: https://github.com/WeblateOrg/translation-finder
Python Social Auth: https://python-social-auth.readthedocs.io/
Бібліотеки REST Django: 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
`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/, see 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 може виникнути потреба у встановленні відповідних залежностей. Список залежить від способу встановлення, тому ознайомтеся із документацією до окремих пакунків. Можливо, встановлення не знадобиться, якщо ви користуєтеся попередньо зібраним Wheels під час встановлення за допомогою pip або пакунками з вашого дистрибутива.

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 криптографічно підписано з використанням підписів 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 намагається створити каталоги автоматично, але це неможливо зробити, якщо для цього немає прав доступу.

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

У контейнері Docker усі файли в томі /app/data мають належати користувачеві weblate всередині контейнера (UID 1000).

Дивись також

Обслуговування статичних файлів

Налаштування бази даних для Weblate¶

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

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

Передбачено підтримку MySQL і MariaDB, але не рекомендуємо нею користуватися для нових встановлень.

Примітка

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

Дивись також

Використання потужного рушія бази даних, Databases, Перенесення даних з інших баз даних до PostgreSQL

З’єднання із базою даних¶

За типових налаштувань кожен процес Weblate підтримує постійне з’єднання із базою даних. Постійні з’єднання покращують швидкість відгуку Weblate, але можуть вимагати більше ресурсів для сервера бази даних. Будь ласка, зверніться до CONN_MAX_AGE та Persistent connections для отримання додаткової інформації.

Weblate потрібна принаймні така кількість з’єднань:

$(4 \times \mathit{nCPUs}) + 2$ для процесів Celery
$\mathit{nCPUs} + 1$ для обробників WSGI

Це стосується типових параметрів контейнера Docker та прикладу налаштувань, який наведено у цій документації, але зміняться числа, щойно ви почнете налаштовувати кількість обробників WSGI або коригувати паралельну обробку у Celery.

Справжнє обмеження на кількість з’єднань із базою даних має бути вищим з метою врахування таких речей:

Команди керування потребують власного з’єднання.
Якщо процес примусово завершується (наприклад засобом знищення процесів OOM), наявне з’єднання може бути заблоковано до завершення часу очікування.

Дивись також

Фонові завдання з використанням 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 має поміняти під час перенесення бази даних.

Дивись також

З’єднання із базою даних

MySQL і MariaDB¶

Попередження

Хоча підтримка MySQL і MariaDB зберігається у Weblate, ми зробили основний акцент на PostgreSQL. Рекомендуємо використовувати для нових встановлень PostgreSQL і переносити наявні встановлення на PostgreSQL, див. Перенесення даних з інших баз даних до PostgreSQL.

Деякі можливості Weblate працюватимуть краще з використанням PostgreSQL. Це стосується пошуку і пам’яті перекладів — можливостей, у яких використовується повнотекстова обробка у базі даних — реалізація у PostgreSQL є найкращою.

Weblate можна також користуватися із MySQL або MariaDB. Будь ласка, ознайомтеся із розділами MySQL notes і MariaDB notes, щоб дізнатися більше про можливі проблеми із використанням Django разом із цими серверами баз даних. Через обмеження, які накладаються використанням інших баз даних, рекомендуємо використовувати для нововстановлених екземплярів PostgreSQL.

Weblate вимагає MySQL хоча б версії 8, чи MariaDB принаймні 10.4 версії.

Рекомендовано такі налаштування для Weblate:

Скористайтеся набором символів utf8mb4, щоб уможливити обробку вищих блоків Unicode (зокрема емодзі).
Налаштуйте сервер за допомогою 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 передбачено параметри підвищення швидкодії вашого сервера, які ми вважаємо необов’язковими, якщо ви не плануєте одночасну роботу у системі багатьох користувачів. Докладніший опис можна знайти у документації, яка надається розробниками відповідного програмного забезпечення.

Надзвичайно важливим для зменшення кількості проблем при встановленні є встановлення належного значення параметра innodb_file_per_table і перезапуск MySQL/MariaDB до встановлення Weblate.

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

Підказка

Якщо ви отримуєте повідомлення про помилку #2006 - MySQL server has gone away, проблему може усунути встановлення належного значення CONN_MAX_AGE.

Дивись також

З’єднання із базою даних

Налаштовування 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 у MySQL або MariaDB до початку встановлення. Для цього скористайтеся наведеними далі командами:

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

Дивись також

З’єднання із базою даних

Інші налаштування¶

Налаштовування вихідної електронної пошти¶

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), найімовірнішою причиною є використання незахищеного з’єднання і відмова сервера у розпізнаванні у незахищений спосіб. У таких випадках варто спробувати увімкнути 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.

Форма зв’язку надсилає повідомлення електронної пошти і на ці адреси, якщо не налаштовано ADMINS_CONTACT.

Дивись також

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"
Дивись також

Configuring the session engine, SESSION_ENGINE

DATABASES

Можливість з’єднання із сервером бази даних. Будь ласка, ознайомтеся із документацією до Django, щоб дізнатися більше.

Дивись також

Налаштування бази даних для Weblate, DATABASES, 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

Ви також можете скористатися списком дій у Звіт щодо швидкодії з розділу Інтерфейс керування.

Дивись також

Deployment checklist

Вимкнути режим діагностики¶

Вимикання режиму діагностики Django (DEBUG):

DEBUG = False

З увімкненим режимом діагностики Django зберігає усі виконані запити та показує користувачеві зворотні трасування помилок. Такі надмірні дані є небажаними у промисловій конфігурації.

Дивись також

Коригування налаштувань

Належне налаштовування записів адміністраторів¶

Установіть належні адреси адміністраторів за допомогою параметра ADMINS для визначення того, хто отримуватиме повідомлення електронної пошти у випадку, якщо щось на сервері піде не так. Приклад:

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

Дивись також

Коригування налаштувань

Установіть належний домен сайта¶

Скоригуйте назву сайта і домен у інтерфейсі адміністратора, інакше посилання у RSS або у повідомленнях електронної пошти щодо реєстрації не працюватимуть. Налаштувати ці параметри можна за допомогою параметра SITE_DOMAIN, який має містити назву домену сайта.

Змінено в версії 4.2: До випуску 4.2 замість цього використовувалася бібліотека sites Django. Будь ласка, див. The “sites” framework.

Дивись також

Налаштовування дозволених вузлів, Належне налаштовування 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 у :file`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, Коригування налаштувань, Databases

Увімкніть кешування¶

Якщо можна, скористайтеся 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’s cache framework

Кешування аватару¶

На додачу до кешування даних 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’s cache framework

Налаштовування надсилання електронної пошти¶

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'. Тоді вам потрібно додати '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'

Використання нетипових уповноважень за сертифікатом¶

Weblate не виконує перевірку сертифікатів SSL під час обробки запитів HTTP. Якщо ви використовуєте нетипову службу сертифікації, яка не є довіреною у типових пакетах, вам слід додати її сертифікат як довірений.

Бажаним підходом для цього є додавання на загальносистемному рівні. Щоб дізнатися більше про способи додавання, будь ласка, ознайомтеся із документацією до дистрибутива (наприклад, у Debian досягти потрібного результату можна записом сертифіката служби сертифікації до /usr/local/share/ca-certificates/ із наступним виконанням команди update-ca-certificates).

Щойно сертифікат буде додано, загальносистемні інструменти зареєструють довіру до сертифіката. Це стосується і Git.

У коді мовою 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 цю можливість вже увімкнено.

Дивись також

Common Deployment Scenarios, Обслуговування статичних файлів

Запуск сервера¶

Підказка

Якщо у вас немає досвіду з послугами, описаними далі, ви можете спробувати Установлення за допомогою 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.

Підказка

Вбудований сервер Django обслуговує статичні файли лише з увімкненим DEBUG, оскільки його призначено лише для розробників. Для промислових потреб, будь ласка, скористайтеся конфігураціями WSGI з Зразок налаштувань для NGINX і uWSGI, Зразок налаштувань для Apache, Зразок налаштувань для Apache і Gunicorn та Обслуговування статичних файлів.

Обслуговування статичних файлів¶

Django потребує збирання статичних файлів у одному каталозі. Щоб забезпечити потрібні умови, скористайтеся командою weblate collectstatic --noinput. У результаті її виконання статичні файли буде скопійовано до каталогу, який визначається параметром STATIC_ROOT (типовим є каталог static` у CACHE_DIR).

Рекомендуємо обслуговувати статичні файли безпосередньо з вашого сервера. Вам слід використовувати це для таких шляхів:

/static/: Обслуговує статичні файли для Weblate і адміністративного інтерфейсу (з визначеного змінною STATIC_ROOT).
/media/: Використовується для вивантажених користувачами мультимедійних даних (наприклад, знімків вікон).
/favicon.ico: Має бути перезаписано для перезапису правила обслуговування /static/favicon.ico.

Дивись також

Зразок налаштувань для NGINX і uWSGI, Зразок налаштувань для Apache, Зразок налаштувань для Apache і Gunicorn, Стиснення клієнтських даних, How to deploy Django, How to deploy static files

Правила щодо безпеки даних¶

За типових налаштувань 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¶

Для запуску промислового сервера скористайтеся обгорткою WSGI, яку буде встановлено з Weblate (у віртуальному середовищі відповідний файл встановлено як ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py). Не забудьте встановити шлях пошуку бібліотек у Python відповідно до вашого віртуального середовища (наприклад, за допомогою інструкції virtualenv = /home/user/weblate-env у 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

Дивись також

How to use Django with uWSGI

Зразок налаштувань для Apache¶

Рекомендовано скористатися попереднім відгалуженням MPM при використанні WSGI разом із Weblate.

У наведених нижче налаштуваннях 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.

Дивись також

Локалі і кодування системи, How to use Django with Apache and 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>

Дивись також

How to use Django with Gunicorn

Запуск Weblate у певному каталозі¶

Рекомендовано скористатися попереднім відгалуженням MPM при використанні WSGI разом із Weblate.

Зразок налаштувань 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, Додатки).
Запуск Автоматичний переклад.
Надсилання сповіщення-резюме.
Розвантаження процесу WSGI від витратних обчислювальних дій.
Надсилання змін з черги (див. «Ліниві» внески).

Типова конфігурація з використанням модуля обробки 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 буде збережено від імені різних власників, що призведе до проблем під час роботи сервера.

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

Виконання завдань Celery у WSGI з використанням «жадібного» режиму¶

Примітка

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

Для розробки варто скористатися інтенсивнішими налаштуваннями, за яких обробка усіх завдань відбувається на місці:

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

Запуск Celery як служби системи¶

Найімовірніше, вам потрібен буде запуск Celery як фонової служби. Опис відповідних налаштувань можна знайти у розділі Daemonization. Для найпоширенішої конфігурації 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¶

Weblate постачається із вбудованою конфігурацією для запланованих завдань. Втім, ви можете визначити додаткові завдання у файлі settings.py. Приклад наведено у розділі «Ліниві» внески.

Виконання завдань має забезпечувати фонова служба регулярних подій Celery. Якщо ця служба не працює належним чином, її могло бути не запущено або її базу даних могло бути пошкоджено. Якщо виникають проблеми, ознайомтеся із журналом запуску Celery, щоб визначити причину.

Спостереження за станом Celery¶

Знайти поточну довжину черг завдань Celery у Інтерфейс керування. Ви також можете скористатися celery_queues у командному рядку. У випадку значного зростання довжини черги ви також побачите повідомлення про помилку налаштувань у адміністративному інтерфейсі.

Попередження

Повідомлення про помилки Celery, типово, записуються лише до журналу Celery і є невидимими для користувача. Якщо ви хочете бачити огляд помилок подібного типу, рекомендуємо вам налаштувати Збирання звітів щодо помилок та стеження за швидкодією.

Дивись також

Спостереження за Weblate, Як перевірити, чи правильно налаштовано мій Weblate?, Configuration and defaults, Workers Guide, Daemonization, Monitoring and Management Guide, celery_queues

Налаштування однопроцесорного Celery¶

Якщо у вас дуже мало оперативної пам’яті, можливо, варто зменшити кількість процесів Weblate. За допомогою цього можна виконати всі завдання Celery в одному процесі:

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

Попередження

Це матиме помітний вплив на швидкодію Weblate.

Спостереження за Weblate¶

У Weblate передбачено адресу /healthz/ для простих перевірок працездатності, наприклад, за допомогою Kubernetes. У контейнера Docker є вбудована перевірка працездатності з використанням цієї адреси.

Для спостереження за метрикою Weblate ви можете скористатися кінцевою точкою програмного інтерфейсу 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.

Якщо коротко, вам слід скоригувати 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 зберігає дані у декількох місцях, і ці дані слід перенести належним чином. Найкращим підходом є зупинення Weblate для перенесення даних.

Перенесення бази даних¶

Залежно від модуля обробки вашої бази даних, ви можете вибрати один із декількох варіантів перенесення бази даних. Найприроднішим з цих варіантів є використання власних інструментів бази даних, оскільки, зазвичай, вони є найефективнішими (приклад mysqldump або pg_dump). Ви також можете скористатися реплікацією, якщо у базі даних передбачено її підтримку.

Дивись також

Перенесення даних між базами даних описано у розділі Перенесення даних з інших баз даних до PostgreSQL.

Перенесення сховищ системи керування версіями¶

Сховища коду систем керування версіями, які зберігаються у DATA_DIR, слід також перенести. Ви можете просто скопіювати їх або скористатися командою rsync для виконання завдання з перенесення у ефективніший спосіб.

Інші нотатки¶

Не забудьте перенести інші служби, які Weblate може використовувати, зокрема Redis, завдання Cron і нетипові модулі розпізнавання.