Настанови з налаштовування¶
Установлення Weblate¶
Залежно від налаштувань та вашого досвіду, виберіть для себе відповідний спосіб встановлення:
install/docker, рекомендовано для промислових налаштувань.
Установлення у віртуальному середовищі, рекомендовано для промислових конфігурацій:
install/source, рекомендовано для розробки.
Огляд архітектури¶
- Вебсервер
Обробка вхідних HTTP-запитів, Обслуговування статичних файлів.
- Робітники Celery
Фонові завдання з використанням Celery виконались тут.
Залежно від вашого робочого навантаження, ви можете налаштувати кількість працівників.
Використовуйте спеціальний вузол для масштабування Weblate по горизонталі.
- WSGI сервер
Сервер WSGI, що обслуговує вебсторінки для користувачів.
Використовуйте спеціальний вузол для масштабування Weblate по горизонталі.
- База даних
Сервер бази даних PostgreSQL для зберігання всього контенту, див. Налаштування бази даних для Weblate.
Використовуйте виділений вузол бази даних для сайтів з сотнями мільйонів розміщених слів.
- Redis
Сервер Redis для кешування і черги завдань, див. Фонові завдання з використанням Celery.
Використовуйте спеціальний вузол для масштабування Weblate по горизонталі.
- Файлова система
Файлова система для зберігання репозиторіїв VCS та завантажених користувацьких даних. Це спільне для всіх процесів.
Використовуйте мережеве сховище при горизонтальному масштабуванні Weblate.
- Сервер електронної пошти
SMTP-сервер для вихідної електронної пошти, див. Налаштовування вихідної електронної пошти. Він може бути наданий ззовні.
Підказка
Установлення за допомогою Docker включає PostgreSQL і Redis, що робить встановлення простішим.
Вимоги для програмного забезпечення¶
Операційна система¶
Відомо, що Weblate працює у Linux, FreeBSD і macOS. Ймовірно, Weblate працює на більшості інших Unix-подібних системах.
Підтримки Weblate у Windows не передбачено. Втім, Weblate може там працювати — будемо раді вашим латкам, які реалізуватимуть підтримку.
Дивись також
Огляд архітектури описує загальну архітектуру Weblate та необхідні сервіси.
Залежності Python¶
Weblate написано на Python і підтримує Python 3.10 або новішу версію. Ви можете встановити залежності за допомогою pip або з пакунків вашого дистрибутива, повний список доступний у requirements.txt
.
Основні залежності:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Бібліотеки REST Django
pip extra |
Пакунок Python |
Функція Weblate |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
MySQL або MariaDB, див. Налаштування бази даних для Weblate |
|
|
||
|
PostgreSQL, див. Налаштування бази даних для Weblate |
|
|
||
|
При встановленні за допомогою pip ви можете безпосередньо вказати бажані можливості:
pip install "Weblate[Postgres,Amazon,SAML]"
Ви також можете встановити Weblate з усіма додатковими можливостями:
pip install "Weblate[all]"
Або встановити Weblate без будь-яких необов’язкових можливостей:
pip install Weblate
Інші вимоги до системи¶
У системі має бути встановлено вказані нижче залежності:
Git
- Pango, Cairo та пов’язані файли заголовків, а також дані інтроспекції GObject
https://cairographics.org/, https://pango.gnome.org/, see Pango і Cairo
git-review
(необов’язкова, призначено для підтримки Gerrit)git-svn
(необов’язкова, призначено для підтримки Subversion)tesseract
(потрібно лише якщо бінарні колеса tesserocr недоступні для вашої системи)licensee
(необов’язкова, для виявлення умов ліцензування при створенні складників)
Залежності для збирання¶
Для збирання Залежності Python може виникнути потреба у встановленні відповідних залежностей. Список залежить від способу встановлення, тому ознайомтеся із документацією до окремих пакунків. Можливо, встановлення не знадобиться, якщо ви користуєтеся попередньо зібраним Wheels
під час встановлення за допомогою pip
або пакунками з вашого дистрибутива.
Pango і Cairo¶
Weblate використовує Pango і Cairo для обробки растрових віджетів (див. Просування перекладу) і перевірки обробки перекладених рядків в інтерфейсі (див. Керування шрифтами). Для належного встановлення прив’язок Python для цих складників вам слід встановити спочатку загальносистемні бібліотеки — вам потрібні і Cairo, і Pango, які, очевидно, залежать від GLib. Усі ці пакунки слід встановити разом із пакунками для розробки та даними інтроспекції GObject.
Вимоги щодо обладнання¶
Weblate повинен без проблем працювати на будь-якому сучасному обладнанні, нижче наведено мінімальну конфігурацію, необхідну для запуску Weblate на одному хості (Weblate, база даних і веб-сервер):
3 ГБ оперативної пам’яті
2 ядра процесора
1 ГБ вільного місця на диску
Примітка
Реальні вимоги до встановленого вами Weblate значно залежать від розміру перекладів, які ним керуються.
Використання пам’яті¶
Чим більше пам’яті, тим краще - вона використовується для кешування на всіх рівнях (файлова система, база даних і Weblate). Для сотень компонентів перекладу рекомендується щонайменше 4 ГБ оперативної пам’яті.
Підказка
Для систем з меншим обсягом пам’яті, ніж рекомендовано, рекомендується використовувати Налаштування однопроцесорного Celery.
Використання CPU¶
Багато одночасних користувачів збільшують кількість необхідних ядер процесора.
Використання сховища¶
Типове використання сховища бази даних становить близько 300 МБ на 1 мільйон розміщених слів.
Обсяг пам’яті, необхідний для клонованих репозиторіїв варіюється, але Weblate намагається тримати його мінімальним, роблячи неглибокі клони.
Вузли¶
Для малих сайтів та сайтів середнього розміру (мільйони розміщених слів), усі складники Weblate (див. Огляд архітектури) можна запустити на одному вузлі.
Якщо кількість розміщених рядків зросте до сотень мільйонів, рекомендуємо розмістити базу даних на окремому вузлі (див. Налаштування бази даних для Weblate).
Перевірка підписів випуску¶
Випуск Weblate криптографічно підписано з використанням підписів Sigstore. Підписи долучено до випуску на GitHub.
Перевірку можна виконати за допомогою пакунка sigstore. У наведеному нижче прикладі виконано перевірку підпису випуску 5.4:
sigstore verify github \
--cert-identity https://github.com/WeblateOrg/weblate/.github/workflows/setup.yml@refs/tags/weblate-5.4 \
--bundle Weblate-5.4-py3-none-any.whl.sigstore \
Weblate-5.4-py3-none-any.whl
Права доступу у файловій системі¶
Процес Weblate повинен мати можливість читати дані з каталогу, де зберігає дані, і записувати дані до нього — DATA_DIR
. Усі файли у цьому каталозі мають належати користувачеві, від імені якого запущено усі процеси Weblate (типово, WSGI і Celery, див. Запуск сервера і Фонові завдання з використанням Celery) і бути придатними до запису від імені цього користувача.
За типових налаштувань, ці файли розташовуються у тій самій ієрархії каталогів, що і початкові коди Weblate. Втім, ви можете надати перевагу пересуванню цих файлів до вдалішого місця, наприклад /var/lib/weblate
.
Weblate намагається створити каталоги автоматично, але це неможливо зробити, якщо для цього немає прав доступу.
Вам також слід бути обережним із запуском Команди керування, оскільки програму слід запускати від імені того самого користувача, що і користувач, від імені якого запущено Weblate, інакше права доступу до деяких файлів можуть виявитися не тими, які потрібні для працездатності системи.
У контейнері Docker усі файли в томі /app/data
мають належати користувачеві weblate
всередині контейнера (UID 1000).
Дивись також
Налаштування бази даних для Weblate¶
Рекомендуємо користуватися Weblate у поєднанні із сервером баз даних PostgreSQL.
Передбачено підтримку PostgreSQL 12 та новіших версій. Рекомендуємо PostgreSQL 15 або новіший.
Передбачено підтримку MySQL і MariaDB, але не рекомендуємо нею користуватися для нових встановлень.
Примітка
У поточній версії не передбачено підтримки інших баз даних, але можлива реалізація інших підтримуваних Django баз даних.
Дивись також
Використання потужного рушія бази даних, Databases, Перенесення даних з інших баз даних до PostgreSQL
З’єднання із базою даних¶
За типових налаштувань кожен процес Weblate підтримує постійне з’єднання із базою даних. Постійні з’єднання покращують швидкість відгуку Weblate, але можуть вимагати більше ресурсів для сервера бази даних. Будь ласка, зверніться до CONN_MAX_AGE
та Persistent connections для отримання додаткової інформації.
Weblate потрібна принаймні така кількість з’єднань:
\((4 \times \mathit{nCPUs}) + 2\) для процесів Celery
\(\mathit{nCPUs} + 1\) для обробників WSGI
Це стосується типових параметрів контейнера Docker та прикладу налаштувань, який наведено у цій документації, але зміняться числа, щойно ви почнете налаштовувати кількість обробників WSGI або коригувати паралельну обробку у Celery.
Справжнє обмеження на кількість з’єднань із базою даних має бути вищим з метою врахування таких речей:
Команди керування потребують власного з’єднання.
Якщо процес примусово завершується (наприклад засобом знищення процесів OOM), наявне з’єднання може бути заблоковано до завершення часу очікування.
PostgreSQL¶
PostgreSQL, зазвичай є найкращим вибором для заснованих на Django сайтів. Це еталонна база даних, яка використовується для реалізації шару бази даних Django.
Примітка
Weblate використовує розширення обробки триграм, яке можна встановити у деяких випадках. Пошукайте postgresql-contrib
або пакунок із подібною назвою.
Дивись також
Створення бази даних у PostgreSQL¶
Зазвичай, варто зробити так, щоб Weblate працював із окремою базою даних і окремим обліковим записом користувача:
# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"
# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate
# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate
Підказка
Якщо ви не хочете робити користувача Weblate надкористувачем у PostgreSQL, ви можете пропустити це. У такому випадку вам доведеться виконати деякі з кроків з перенесення вручну від імені надкористувача PostgreSQL у схемі, яку використовуватиме Weblate:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Налаштовування Weblate на використання PostgreSQL¶
Фрагмент settings.py
для PostgreSQL:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.postgresql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# 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 залежить від можливості отримання клієнтської 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).
HTTP-проксі¶
Weblate виконує команди системи керування версіями, а ці команди приймають налаштування проксі-сервера із середовища. Рекомендованим підходом є визначення параметрів проксі-сервера у settings.py
:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Дивись також
Коригування налаштувань¶
Дивись також
Скопіюйте weblate/settings_example.py
до weblate/settings.py
і скоригуйте його відповідно до ваших потреб. Ймовірно, вам потрібно скоригувати такі параметри:
ADMINS
Список адміністраторів сайта, які отримуватимуть сповіщення при помилках, зокрема сповіщення щодо невдалого об’єднання або помилок Django.
Форма зв’язку надсилає повідомлення електронної пошти і на ці адреси, якщо не налаштовано
ADMINS_CONTACT
.Дивись також
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"Дивись також
DATABASES
Можливість з’єднання із сервером бази даних. Будь ласка, ознайомтеся із документацією до Django, щоб дізнатися більше.
Дивись також
DEBUG
Вимкніть цю можливість для будь-яких промислових серверів. Якщо діагностичний режим увімкнено, Django показуватиме користувачам дані зворотного трасування при помилці. Якщо ви вимкнете її, помилки буде надіслано електронною поштою до
ADMINS
(див. вище).Режим діагностики також уповільнює роботу Weblate, оскільки у такому режимі Django на внутрішньому рівні зберігає набагато більше даних.
Дивись також
DEFAULT_FROM_EMAIL
Адреса електронної пошти відправника для вихідної електронної пошти, наприклад, повідомлень електронної пошти щодо реєстрації.
Дивись також
SECRET_KEY
Ключ, який використовується Django для підписування даних у куках. Див. Секретний ключ Django, щоб дізнатися більше.
Дивись також
SERVER_EMAIL
Адреса електронної пошти, яку буде використано для надсилання повідомлень електронної пошти адміністратору, наприклад, для сповіщень щодо помилок під час об’єднання змін.
Дивись також
Заповнення бази даних¶
Коли ваші налаштування буде готово, ви можете запустити migrate
для створення структури бази даних. Після цього ви зможете створювати проєкти перекладу за допомогою інтерфейсу адміністратора.
Щойно потрібні дії буде виконано, вам слід також ознайомитися зі Звітом щодо швидкодії в інтерфейсі адміністратора, там ви зможете знайти підказки щодо потенційних недоліків у налаштуваннях на вашому сайті.
Дивись також
Промислові налаштування¶
Для налаштовування промислового сервера вам слід виконати коригування, які описано у наступних розділах. Для найкритичніших параметрів буде показано попередження, вказівкою на яке є знак оклику на верхній панелі, який буде показано, якщо ви увійдете на сервер як супер користувач:
Також рекомендуємо вам звернути увагу на підсумки перевірок, які буде започатковано Django (хоча вам і не треба виправляти усі причини показаних попереджень):
weblate check --deploy
Ви також можете скористатися списком дій у Звіт щодо швидкодії з розділу Інтерфейс керування.
Дивись також
Вимкнути режим діагностики¶
Вимикання режиму діагностики Django (DEBUG
):
DEBUG = False
З увімкненим режимом діагностики Django зберігає усі виконані запити та показує користувачеві зворотні трасування помилок. Такі надмірні дані є небажаними у промисловій конфігурації.
Дивись також
Належне налаштовування записів адміністраторів¶
Установіть належні адреси адміністраторів за допомогою параметра ADMINS
для визначення того, хто отримуватиме повідомлення електронної пошти у випадку, якщо щось на сервері піде не так. Приклад:
ADMINS = (("Your Name", "your_email@example.com"),)
Дивись також
Установіть належний домен сайта¶
Скоригуйте назву сайта і домен у інтерфейсі адміністратора, інакше посилання у RSS або у повідомленнях електронної пошти щодо реєстрації не працюватимуть. Налаштувати ці параметри можна за допомогою параметра SITE_DOMAIN
, який має містити назву домену сайта.
Змінено в версії 4.2: До випуску 4.2 замість цього використовувалася бібліотека sites Django. Будь ласка, див. The “sites” framework.
Належне налаштовування HTTPS¶
Наполегливо рекомендуємо вам запускати з Weblate з використанням шифрованого протоколу HTTPS. Після його вмикання вам слід встановити ENABLE_HTTPS
у параметрах сервера:
ENABLE_HTTPS = True
Підказка
Вам також, ймовірно, варто налаштувати HSTS. Див. SSL/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.
Увімкніть кешування¶
Якщо можна, скористайтеся 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, 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
.
У результаті буде вимкнено надсилання усіх повідомлень електронної пошти, зокрема повідомлень щодо реєстрації та повідомлень щодо скидання паролів.
Налаштовування дозволених вузлів¶
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.
Дивись також
Запуск завдань щодо супроводу¶
Для забезпечення оптимальної швидкодії варто запускати деякі завдання з супроводу працездатності сервера у фоновому режимі. У нових версіях це автоматично виконується за допомогою Фонові завдання з використанням Celery і стосується таких завдань:
Перевірки коректності налаштувань (щогодинно).
Надсилання змін з черги (щогодини), див. «Ліниві» внески і
commit_pending
.Оновлення нагадувань щодо складників (щоденно).
Оновлення віддалених гілок (щодня), див.
AUTO_UPDATE
.Резервного копіювання пам’яті перекладів до JSON (щодня), див.
dump_memory
.Завдань із супроводу обробки всього тексту й бази даних (щоденних і щотижневих завдань), див.
cleanuptrans
.
Локалі і кодування системи¶
Для локалі системи слід вибрати якусь із локалей UTF-8. У більшості дистрибутивів Linux такий вибір є типовим. Якщо у вашій системі вибрано якусь іншу локаль, будь ласка, змініть локаль на один з варіантів UTF-8.
Зробити це можна, наприклад, редагуванням /etc/default/locale
зі встановленням LANG="C.UTF-8"
.
У деяких випадках окремі служби мають окремі налаштування для локалей. Це залежить від дистрибутива та вебсерверів, тому для вирішення цього завдання ознайомтеся із документацією до пакунків вашого сервера.
У Apache на Ubuntu використовують /etc/apache2/envvars
:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
У Apache на CentOS використовують /etc/sysconfig/httpd
(або /opt/rh/httpd24/root/etc/sysconfig/httpd
):
LANG='en_US.UTF-8'
Стиснення клієнтських даних¶
Weblate постачається із набором файлів JavaScript і CSS. З міркувань забезпечення оптимальної швидкодії варто стиснути їх до надсилання клієнту. У типовій конфігурації результат досягається пакуванням «на льоту» із певною зайвою витратою ресурсів. На серверах із значним навантаженням рекомендуємо увімкнути режим попереднього стискання. Зробити це слід у налаштуваннях, а стискання слід започатковувати після кожного оновлення Weblate.
Перемикання у налаштуваннях є простим — увімкніть django.conf.settings.COMPRESS_OFFLINE
і налаштуйте django.conf.settings.COMPRESS_OFFLINE_CONTEXT
(останній вже включено у приклад налаштувань):
COMPRESS_OFFLINE = True
При кожному розгортанні вам слід стискати файли відповідно до поточної версії:
weblate compress
Підказка
У офіційному образі для Docker цю можливість вже увімкнено.
Дивись також
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
.
Правила щодо безпеки даних¶
За типових налаштувань 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
CSP_FORM_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
Дивись також
Зразок налаштувань для 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.
Зразок налаштувань для 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>
Дивись також
Запуск 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
Крім того, вам слід запустити обробник 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 і є невидимими для користувача. Якщо ви хочете бачити огляд помилок подібного типу, рекомендуємо вам налаштувати Збирання звітів щодо помилок та стеження за швидкодією.
Налаштування однопроцесорного Celery¶
Якщо у вас дуже мало оперативної пам’яті, можливо, варто зменшити кількість процесів Weblate. За допомогою цього можна виконати всі завдання Celery в одному процесі:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
An installation using Docker can be configured to use a single-process Celery setup by setting CELERY_SINGLE_PROCESS
.
Попередження
Це матиме помітний вплив на швидкодію Weblate.
Спостереження за Weblate¶
У Weblate передбачено адресу /healthz/
для простих перевірок працездатності, наприклад, за допомогою Kubernetes. У контейнера Docker є вбудована перевірка працездатності з використанням цієї адреси.
Для спостереження за метрикою Weblate ви можете скористатися кінцевою точкою програмного інтерфейсу GET /api/metrics/
.
Збирання звітів щодо помилок та стеження за швидкодією¶
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
.
Дивись також
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 і нетипові модулі розпізнавання.