Установка с помощью Docker’а

With dockerized Weblate deployment you can get your personal Weblate instance up and running in seconds. All of Weblate’s dependencies are already included. PostgreSQL is set up as the default database and Redis as a caching backend.

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

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

Установка

Подсказка

В следующих примерах предполагается, что у вас есть работающая среда Docker с установленным плагином docker-compose-plugin. Инструкции см. в документации Docker.

При этом создаётся сервер развёртывания Weblate через HTTP, поэтому вам следует разместить его за завершающим прокси-сервером HTTPS. Вы также можете выполнить развёртывание с помощью HTTPS-прокси, см. Автоматический выпуск SSL-сертификатов с помощью сервиса Let’s Encrypt. Для более крупных настроек см. Масштабирование по горизонтали.

  1. Склонируйте репозиторий weblate-docker:

    git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
    cd weblate-docker
    
  2. Создайте файл docker-compose.override.yml со своими настройками. Полный список переменных окружения приведен в разделе Переменные окружения Docker.

    version: '3'
    services:
      weblate:
        ports:
          - 80:8080
        environment:
          WEBLATE_EMAIL_HOST: smtp.example.com
          WEBLATE_EMAIL_HOST_USER: user
          WEBLATE_EMAIL_HOST_PASSWORD: pass
          WEBLATE_SERVER_EMAIL: weblate@example.com
          WEBLATE_DEFAULT_FROM_EMAIL: weblate@example.com
          WEBLATE_SITE_DOMAIN: weblate.example.com
          WEBLATE_ADMIN_PASSWORD: password for the admin user
          WEBLATE_ADMIN_EMAIL: weblate.admin@example.com
    

    Примечание

    Если переменная WEBLATE_ADMIN_PASSWORD не установлена, то пользователь-администратор создаётся со случайным паролем, отображаемым при первом запуске.

    Приведённый пример настраивает Weblate на прослушку порта 80, чтобы его изменить, отредактируйте отображение портов в файле docker-compose.override.yml.

  3. Запустите контейнеры Weblate:

    docker compose up
    

Наслаждайтесь своим развернутым Weblate’ом, он доступен на порту 80 контейнера weblate.

Выбор реестра образов Docker

Контейнеры Weblate публикуются в следующих реестрах:

Примечание

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

Выбор метки изображения Docker

Пожалуйста, выберите метку, которая соответствует вашей среде и ожиданиям:

Имя метки

Описание

Пример использования

latest

Стабильный выпуск Weblate, соответствует последнему выпуску с метками

Выполнение обновлений в рабочей среде

<MAJOR>

Стабильный выпуск Weblate

Последовательные обновления основной версии в производственной среде

<MAJOR>.<MINOR>

Стабильный выпуск Weblate

Последовательные обновления второстепенной версии в производственной среде

<ВЕРСИЯ>.<ИСПРАВЛЕНИЕ>

Стабильный выпуск Weblate

Хорошо поставленное развёртывание в рабочей среде

edge

Стабильный выпуск Weblate с изменениями в разработке в Docker-контейнере (например, обновленные зависимости)

Запуск обновлений в среде постановки

edge-<DATE>-<SHA>

Стабильный выпуск Weblate с изменениями в разработке в Docker-контейнере (например, обновленные зависимости)

Чётко определённое развертывание в среде постановки

bleeding

Версия разработчика Weblate из Git

Запуск обновлений для тестирования предстоящих функций Weblate

bleeding-<DATE>-<SHA>

Версия разработчика Weblate из Git

Хорошо определённое развёртывание для тестирования предстоящих функций Weblate

Каждое изображение тестируется нашей непрерывной интеграцией перед публикацией, поэтому даже bleeding (кровоточащая) версия должна быть вполне безопасной для использования.

Полный список опубликованных меток можно найти на странице GitHub Packages

Контейнер Docker с поддержкой HTTPS

Общие инструкции по развертыванию, пожалуйста, смотрите в разделе Установка, в этом разделе упоминаются только отличия от той инструкции.

Использование собственных SSL-сертификатов

Если вы хотите использовать свой собственный SSL-сертификат, просто поместите его файлы в том данных Weblate (смотрите раздел Тома контейнеров Docker’а):

  • ssl/fullchain.pem, содержащий сертификат и все необходимые сертификаты центров сертификации

  • ssl/privkey.pem, содержащий закрытый ключ

Обеими этими файлами должен владеть тот же самый пользователь, который запускает контейнер docker ’а, а маска этих файлов должна быть равна 600 (читать и писать в них может только владелец).

Кроме того, контейнер Weblate теперь будет принимать SSL-соединения на порт 4443 и вам нужно будет включить перенаправление портов для HTTPS в переопределении Docker Compose:

version: '3'
services:
  weblate:
    ports:
      - 80:8080
      - 443:4443

Если на этом же сервере у вас уже размещены другие сайты, скорее всего, порты 80 и 443 используются обратным прокси, например, NGINX. Для передачи HTTPS соединения из NGINX’а в контейнер docker ’а вы можете использовать следующую конфигурацию:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name <SITE_URL>;
    ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;

    location / {
            proxy_set_header HOST $host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
    }
}

Замените заполнители <SITE_URL>, <SITE> и EXPOSED_DOCKER_PORT на фактические значения из вашего окружения.

Автоматический выпуск SSL-сертификатов с помощью сервиса Let’s Encrypt

Если вы хотите использовать Let’s Encrypt для автоматической генерации SSL-сертификатов для общедоступной установки, вам нужно будет добавить дополнительный контейнер Docker с обратным HTTPS прокси — https-portal. Он используется в файле docker-compose-https.yml. Затем создайте файл docker-compose-https.override.yml со своими настройками:

version: '3'
services:
  weblate:
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for admin user
  https-portal:
    environment:
      DOMAINS: 'weblate.example.com -> http://weblate:8080'

При каждом вызове docker compose вам необходимо передать ему оба файла, а затем выполнить:

docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml up

Обновление контейнера Docker’а

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

Изменено в версии 4.17-1: Начиная с Weblate 4.17-1, контейнер Docker использует Django 4.2, для которого требуется PostgreSQL 12 или новее, обновите его перед обновлением Weblate. См. Обновление контейнера PostgreSQL.

Вы можете сделать это, оставаясь с существующим docker-compose и просто извлекая последние образы с последующим перезапуском контейнера:

# Fetch latest versions of the images
docker compose pull
# Stop and destroy the containers
docker compose down
# Spawn new containers in the background
docker compose up -d
# Follow the logs during upgrade
docker compose logs -f

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

Примечание

Обновления через основные версии Weblate не поддерживают. Если вы используете версию 3.x и хотите обновиться до 4.x, сначала выполните обновление до последнего образа 4.0.x-y (на момент написания это 4.0.4-5), которое выполнит миграцию, а затем продолжите обновление до более новых версий.

Также вы можете захотеть обновить репозиторий docker-compose, хотя в большинстве случаев в этом нет необходимости. См. Обновление контейнера PostgreSQL для обновления сервера PostgreSQL.

Обновление контейнера PostgreSQL

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

  1. Остановка контейнера Weblate:

    docker compose stop weblate cache
    
  2. Резервное копирование базы данных:

    docker compose exec database pg_dumpall --clean --if-exists --username weblate > backup.sql
    
  3. Остановка контейнера базы данных:

    docker compose stop database
    
  4. Удаление тома PostgreSQL:

    docker compose rm -v database
    docker volume remove weblate-docker_postgres-data
    

    Подсказка

    Имя тома содержит имя проекта Docker Compose, которое по умолчанию является именем каталога, как weblate-docker в данной документации.

  5. Подправьте файл docker-compose.yml, чтобы использовать новую версию PostgreSQL.

  6. Запустить контейнер базы данных:

    docker compose up -d database
    
  7. Восстановите данные из резервной копии:

    cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate
    

    Подсказка

    Убедитесь, что имя базы данных соответствует POSTGRES_DB.

  8. (Необязательно) Обновите пароль для пользователя Weblate. Это может понадобиться при переходе на PostgreSQL 14 или 15, поскольку был изменён способ хранения паролей:

    docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
    

    Подсказка

    Убедитесь, что имя базы данных соответствует POSTGRES_DB.

  9. Запустить все оставшиеся контейнеры:

    docker compose up -d
    

Вход от имени администратора

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

Для сброса пароля пользователя admin перезапустите контейнер с переменной WEBLATE_ADMIN_PASSWORD, установленной в новое значение пароля.

Количество процессов и потребление памяти

Количество рабочих процессов для uWSGI и Celery определяется автоматически на основе количества ЦП. Это хорошо подходит для большинства облачных виртуальных машин, так как они обычно имеют мало процессоров и хороший объём памяти.

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

environment:
  WEBLATE_WORKERS: 2

Вы также можете точно настроить отдельные категории процессов:

environment:
  WEB_WORKERS: 4
  CELERY_MAIN_OPTIONS: --concurrency 2
  CELERY_NOTIFY_OPTIONS: --concurrency 1
  CELERY_TRANSLATE_OPTIONS: --concurrency 1

Масштабирование по горизонтали

Added in version 4.6.

Вы можете запустить несколько Weblate-контейнеров для горизонтального масштабирования сервиса. Том /app/data должен быть общим для всех контейнеров, для этого рекомендуется использовать кластерную файловую систему, например GlusterFS. Том /app/cache должен быть отдельным для каждого контейнера.

Каждый контейнер Weblate имеет определенную роль с помощью переменной окружения WEBLATE_SERVICE. Пожалуйста, внимательно изучите документацию, так как некоторые сервисы должны быть запущены только один раз в кластере, и порядок следования сервисов также имеет значение.

Пример установки вы можете найти в репозитории docker-compose в виде docker-compose-split.yml.

Переменные окружения Docker

Многие параметры конфигурации Weblate в контейнере Docker могут быть установлены через переменные окружения, описанные ниже.

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

Прохождение кодов

Added in version 5.0.

Контейнер Weblate поддерживает передачу данных в виде ключей. Чтобы использовать это, добавьте суффикс _FILE к переменной среды и передайте файл ключей через Docker.

Связанный docker-compose.yml может выглядеть так:

services:
   weblate:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password
   database:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password


secrets:
   db_password:
     file: db_password.txt

Общие параметры

WEBLATE_DEBUG

Настраивает отладочный режим Django, используя ее переменную DEBUG.

Пример:

environment:
  WEBLATE_DEBUG: 1
WEBLATE_LOGLEVEL

Настраивает детализацию журнала. Установите для этого параметра значение DEBUG, чтобы получить более подробные журналы.

По умолчанию используется INFO, когда WEBLATE_DEBUG отключён, DEBUG используется, когда включён режим отладки.

Для более тихой регистрации используйте ERROR или WARNING.

WEBLATE_LOGLEVEL_DATABASE

Настраивает подробность ведения журнала запросов к базе данных.

WEBLATE_SITE_TITLE

Изменяет название сайта, показываемое в заголовке всех страниц.

WEBLATE_SITE_DOMAIN

Настраивает домен сайта. Этот параметр является обязательным.

WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Настраивает имя и электронную почту администратора сайта. Используется как для параметра ADMINS, так и для создания пользователя admin (подробнее смотрите в описании переменной окружения WEBLATE_ADMIN_PASSWORD).

Пример:

environment:
  WEBLATE_ADMIN_NAME: Weblate admin
  WEBLATE_ADMIN_EMAIL: noreply@example.com
WEBLATE_ADMIN_PASSWORD

Устанавливает пароль для пользователя admin.

  • Если не установлен и пользователя admin не существует, он создается со случайным паролем, который показывается при первом запуске контейнера.

  • Если не установлен и пользователя admin не существует, никакие действия не выполняются.

  • Если установлен, при каждом запуске контейнера пользователю admin устанавливаются соответствующие WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME и WEBLATE_ADMIN_EMAIL.

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

Хранение пароля в файле настроек может представлять из себя угрозу безопасности. Используйте эту переменную только для начальной установки (или пусть Weblate сгенерирует при начальной загрузке случайный пароль) или для восстановления пароля.

WEBLATE_SERVER_EMAIL

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

WEBLATE_DEFAULT_FROM_EMAIL

Настраивает адрес для исходящих сообщений электронной почты.

WEBLATE_ADMINS_CONTACT

Configures ADMINS_CONTACT.

WEBLATE_CONTACT_FORM

Настраивает поведение контактной формы, смотреть параметр CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS

Настраивает разрешённые имена HTTP-хостов с помощью параметра ALLOWED_HOSTS.

По умолчанию установлен в *, что позволяет использовать все имена хостов.

Пример:

environment:
  WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com
WEBLATE_REGISTRATION_OPEN

Настраивает статус открытия регистрации, переключая параметр REGISTRATION_OPEN.

Пример:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
WEBLATE_REGISTRATION_ALLOW_BACKENDS

Настраивает через параметр REGISTRATION_ALLOW_BACKENDS методы авторизации, которые можно использовать для создания новой учётной записи.

Пример:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
  WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2
WEBLATE_REGISTRATION_REBIND

Added in version 4.16.

Настраивает REGISTRATION_REBIND.

WEBLATE_TIME_ZONE

Настраивает используемый в Weblate часовой пояс, смотрите описание параметра TIME_ZONE.

Примечание

Для изменения часового пояса самого контейнера Docker используйте переменную окружения TZ.

Пример:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague
WEBLATE_ENABLE_HTTPS

Заставляет Weblate думать, что он работает за обратным HTTPS-прокси, что принуждает Weblate использовать HTTPS в ссылках писем электронной почты и API или устанавливать у кук флаги безопасности.

Подсказка

Смотрите возможные топкие места в документацию к параметру ENABLE_HTTPS.

Примечание

Этот параметр не включает разрешение на прием контейнером Weblate’а соединений по HTTPS, его нужно настроить отдельно, для примеров смотрите раздел Контейнер Docker с поддержкой HTTPS.

Пример:

environment:
  WEBLATE_ENABLE_HTTPS: 1
WEBLATE_INTERLEDGER_PAYMENT_POINTERS

Added in version 4.12.1.

Позволяет Weblate установить поле meta[name=monetization] в заголовке документа. Если указано несколько, выбирается один случайным образом.

WEBLATE_IP_PROXY_HEADER

Позволяет Weblate’у получать IP-адрес из любого заданного HTTP-заголовка. Используйте его при использовании обратного прокси перед контейнером Weblate.

Включает параметр IP_BEHIND_REVERSE_PROXY и устанавливает параметр IP_PROXY_HEADER.

Примечание

Формат должен соответствовать ожиданиям Django. Django трансформирует необработанные имена HTTP-заголовков следующим образом:

  • переводит все символы в верхний регистр

  • все дефисы заменяет на подчеркивания

  • добавляет префикс `` HTTP_``

Таким образом, заголовок X-Forwarded-For` отображается на ``HTTP_X_FORWARDED_FOR.

Пример:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
WEBLATE_IP_PROXY_OFFSET

Added in version 5.0.1.

Настраивает IP_PROXY_OFFSET.

WEBLATE_USE_X_FORWARDED_PORT

Added in version 5.0.1.

Логическое значение, указывающее, следует ли использовать заголовок X-Forwarded-Port вместо переменной SERVER_PORT META. Следует включать только в том случае, если используется прокси-сервер, который устанавливает этот заголовок.

См.также

USE_X_FORWARDED_PORT

Примечание

Это логическая настройка (используйте "true" или "false").

WEBLATE_SECURE_PROXY_SSL_HEADER

Кортеж, представляющий собой комбинацию HTTP-заголовков/значений, указывающую, что запрос является безопасным. Он необходим, когда Weblate работает за обратным прокси, выполняющим SSL-терминацию, которая не передает стандартные HTTPS-заголовки.

Пример:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

См.также

SECURE_PROXY_SSL_HEADER

WEBLATE_REQUIRE_LOGIN

Включает параметр REQUIRE_LOGIN, в результате чего авторизация будет требоваться для всего Weblate.

Пример:

environment:
  WEBLATE_REQUIRE_LOGIN: 1
WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS
WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS
WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS

Добавляет исключения из URL-адресов (для которых требование авторизации установлено глобально для всего Weblate) с помощью параметра LOGIN_REQUIRED_URLS_EXCEPTIONS.

Вы можете либо заменить все настройки целиком, либо изменить значение по умолчанию с помощью переменных ADD и REMOVE.

Чтобы обеспечить авторизацию для контактной формы, выполните следующие действия:

environment:
  WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$
WEBLATE_GOOGLE_ANALYTICS_ID

Настраивает идентификатор для Google Analytics, изменяя параметр GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE

Настройте заголовок и сообщение по умолчанию для запросов на извлечение через API, изменяя DEFAULT_PULL_MESSAGE

См.также

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES

Настраивает политику упрощения языка, смотрите описание параметра SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL

Настраивает значение по умолчанию для управления доступом в новых проектах, смотрите описание параметра DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT

Настраивает значение по умолчанию для ограниченного доступа в новых компонентах, смотрите описание параметра DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION

Настраивает значение по умолчанию для разрешения распространения переводов в новых компонентах, смотрите описание параметра DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL

Настраивает параметр DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME

Настраивает параметр DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM

Настраивает параметр DEFAULT_SHARED_TM.

WEBLATE_AKISMET_API_KEY

Настраивает API-ключ Akismet, смотрите описание параметра AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY

Настраивает GPG для подписи коммитов, смотрите описание параметра WEBLATE_GPG_IDENTITY.

WEBLATE_URL_PREFIX

Настраивает префикс URL-адреса, на котором запущен Weblate, смотрите описание параметра URL_PREFIX.

WEBLATE_SILENCED_SYSTEM_CHECKS

Настраивает проверки, которые вы не хотите видеть, смотрите описание параметра SILENCED_SYSTEM_CHECKS.

WEBLATE_CSP_SCRIPT_SRC
WEBLATE_CSP_IMG_SRC
WEBLATE_CSP_CONNECT_SRC
WEBLATE_CSP_STYLE_SRC
WEBLATE_CSP_FONT_SRC

Позволяет настраивать HTTP-заголовок политики безопасности содержимого Content-Security-Policy.

WEBLATE_LICENSE_FILTER

Настраивает параметр LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED

Настройка LICENSE_FILTER

WEBLATE_WEBSITE_REQUIRED

Настройка DEFAULT_AUTO_WATCH

WEBLATE_HIDE_VERSION

Настраивает параметр HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES

Настраивает параметр BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH

Настраивает параметр DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS
WEBLATE_RATELIMIT_LOCKOUT
WEBLATE_RATELIMIT_WINDOW

Added in version 4.6.

Настраивает ограничитель скорости.

Подсказка

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

WEBLATE_API_RATELIMIT_ANON
WEBLATE_API_RATELIMIT_USER

Added in version 4.11.

Настраивает ограничение частоты запросов API. По умолчанию 100/day для анонимных пользователей и 5000/hour для авторизованных пользователей.

WEBLATE_ENABLE_HOOKS

Added in version 4.13.

Настраивает параметр ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS

Added in version 4.6.1.

Настраивает параметр ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX

Added in version 4.15.

Настраивает параметр AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH

Added in version 4.9.

Настраивает параметр LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS

Added in version 4.9.

Настраивает параметр SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS

Added in version 4.9.

Настраивает BORG_EXTRA_ARGS как список аргументов, разделённых запятыми.

Пример:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/
WEBLATE_ENABLE_SHARING

Added in version 4.14.1.

Настраивает параметр setting:ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK

Added in version 5.5.

Configures SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD

Added in version 4.15.

Настраивает EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE

Added in version 4.15.

Настраивает PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN

Added in version 4.15.

Настраивает PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS

Added in version 4.17.

Настраивает UNUSED_ALERT_DAYS.

WEBLATE_CORS_ALLOWED_ORIGINS

Added in version 4.16.

Разрешить запросы CORS из заданных источников.

Пример:

environment:
  WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org
CLIENT_MAX_BODY_SIZE

Added in version 4.16.3.

Настраивает максимальный размер тела, принимаемый встроенным веб сервером.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Подсказка

В этой переменной намеренно отсутствует префикс WEBLATE_, поскольку он используется совместно со сторонним контейнером, используемым в docker-https-portal.

Учётные данные сайтов хостинга кода

В контейнере Docker учётные данные хостинга кода могут быть настроены как в отдельных переменных, так и с помощью словаря Python для их одновременного задания. Приведённые ниже примеры относятся к Запрос на извлечение в GitHub, но применимы ко всем Интеграция с системой контроля версий с соответствующим изменением имён переменных.

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

WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com

Будут использоваться в качестве:

GITHUB_CREDENTIALS = {
    "api.github.com": {
        "username": "api-user",
        "token": "api-token",
    }
}

В качестве альтернативы словарь Python может быть предоставлен в виде строки:

WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'

Или путь к файлу, содержащему словарь Python:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'
WEBLATE_GITHUB_USERNAME
WEBLATE_GITHUB_TOKEN
WEBLATE_GITHUB_HOST
WEBLATE_GITHUB_CREDENTIALS

Настраивает Запрос на извлечение в GitHub, изменяя GITHUB_CREDENTIALS.

WEBLATE_GITLAB_USERNAME
WEBLATE_GITLAB_TOKEN
WEBLATE_GITLAB_HOST
WEBLATE_GITLAB_CREDENTIALS

Настраивает Запросы на слияние в GitLab, изменяя GITLAB_CREDENTIALS.

WEBLATE_GITEA_USERNAME
WEBLATE_GITEA_TOKEN
WEBLATE_GITEA_HOST
WEBLATE_GITEA_CREDENTIALS

Конфигурирует Запрос на извлечение в Gitea, изменяя GITEA_CREDENTIALS.

WEBLATE_PAGURE_USERNAME
WEBLATE_PAGURE_TOKEN
WEBLATE_PAGURE_HOST
WEBLATE_PAGURE_CREDENTIALS

Конфигурирует Запросы на слияние в Pagure путём изменения PAGURE_CREDENTIALS.

WEBLATE_BITBUCKETSERVER_USERNAME
WEBLATE_BITBUCKETSERVER_TOKEN
WEBLATE_BITBUCKETSERVER_HOST
WEBLATE_BITBUCKETSERVER_CREDENTIALS

Настраивает Запрос на принятие изменений в сервер Bitbucket, изменяя BITBUCKETSERVER_CREDENTIALS.

WEBLATE_AZURE_DEVOPS_USERNAME
WEBLATE_AZURE_DEVOPS_ORGANIZATION
WEBLATE_AZURE_DEVOPS_TOKEN
WEBLATE_AZURE_DEVOPS_HOST
WEBLATE_AZURE_DEVOPS_CREDENTIALS

Настраивает Запросы на извлечение Azure DevOps, изменяя AZURE_DEVOPS_CREDENTIALS.

Настройки автоматических предложений

Изменено в версии 4.13: Службы автоматических предложений сейчас настраиваются в пользовательском интерфейсе, см. Автоматические советы.

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

Параметры авторизации

LDAP

WEBLATE_AUTH_LDAP_SERVER_URI
WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE
WEBLATE_AUTH_LDAP_USER_ATTR_MAP
WEBLATE_AUTH_LDAP_BIND_DN
WEBLATE_AUTH_LDAP_BIND_PASSWORD
WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS
WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER
WEBLATE_AUTH_LDAP_USER_SEARCH_UNION
WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER

Настройка авторизации через LDAP.

Пример прямой привязки:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE: uid=%(user)s,ou=People,dc=example,dc=net
  # map weblate 'full_name' to ldap 'name' and weblate 'email' attribute to 'mail' ldap attribute.
  # another example that can be used with OpenLDAP: 'full_name:cn,email:mail'
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail

Пример поиска и привязки:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com

Пример объединения поиска и привязки:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH_UNION: ou=users,dc=example,dc=com|ou=otherusers,dc=example,dc=com

Пример поиска и привязки в Active Directory:

environment:
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS: 0
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER: (sAMAccountName=%(user)s)

GitHub

WEBLATE_SOCIAL_AUTH_GITHUB_KEY
WEBLATE_SOCIAL_AUTH_GITHUB_SECRET
WEBLATE_SOCIAL_AUTH_GITHUB_ORG_KEY
WEBLATE_SOCIAL_AUTH_GITHUB_ORG_SECRET
WEBLATE_SOCIAL_AUTH_GITHUB_ORG_NAME
WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_KEY
WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_SECRET
WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_ID

Включает авторизацию через GitHub.

GitHub Enterprise Edition

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY
WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET
WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL
WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL
WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE

Включает Авторизация GitHub EE.

Bitbucket

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET
WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY
WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET

Включает авторизацию через Bitbucket.

Facebook

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY
WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET

Включает Facebook OAuth 2.

Google

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET
WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS
WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS

Включает Google OAuth 2.

GitLab

WEBLATE_SOCIAL_AUTH_GITLAB_KEY
WEBLATE_SOCIAL_AUTH_GITLAB_SECRET
WEBLATE_SOCIAL_AUTH_GITLAB_API_URL

Включает GitLab OAuth 2.

Gitea

WEBLATE_SOCIAL_AUTH_GITEA_API_URL
WEBLATE_SOCIAL_AUTH_GITEA_KEY
WEBLATE_SOCIAL_AUTH_GITEA_SECRET

Включает авторизацию Gitea.

Azure Active Directory

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET

Включает авторизацию через Azure Active Directory, смотрите раздел Microsoft Azure Active Directory.

Azure Active Directory с поддержкой Tenant

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET
WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID

Включает авторизацию через Azure Active Directory с поддержкой Tenant, смотрите раздел Microsoft Azure Active Directory.

Keycloak

WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY
WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET
WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY
WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM
WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL
WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL
WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE
WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE

Включает авторизацию через Keycloak, смотрите документацию.

Поставщики Linux

Вы можете включить авторизацию с помощью сервисов авторизации поставщиков Linux, установив следующие переменные в любое значение.

WEBLATE_SOCIAL_AUTH_FEDORA
WEBLATE_SOCIAL_AUTH_OPENSUSE
WEBLATE_SOCIAL_AUTH_OPENINFRA
WEBLATE_SOCIAL_AUTH_UBUNTU

Slack

WEBLATE_SOCIAL_AUTH_SLACK_KEY
SOCIAL_AUTH_SLACK_SECRET

Включает авторизацию через Slack, смотрите раздел Slack.

OpenID Connect

Added in version 4.13-1.

WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT
WEBLATE_SOCIAL_AUTH_OIDC_KEY
WEBLATE_SOCIAL_AUTH_OIDC_SECRET
WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY

Настраивает общую интеграцию OpenID Connect.

См.также

OIDC (OpenID Connect)

SAML

Самоподписанные ключи SAML генерируются автоматически при первом запуске контейнера. Если вы хотите использовать собственные ключи, поместите сертификат и закрытый ключ в файлы /app/data/ssl/saml.crt и /app/data/ssl/saml.key.

WEBLATE_SAML_IDP_ENTITY_ID
WEBLATE_SAML_IDP_URL
WEBLATE_SAML_IDP_X509CERT
WEBLATE_SAML_IDP_IMAGE
WEBLATE_SAML_IDP_TITLE

Настройки провайдера идентификационных данных SAML, смотрите раздел Авторизация через SAML.

WEBLATE_SAML_ID_ATTR_NAME
WEBLATE_SAML_ID_ATTR_USERNAME
WEBLATE_SAML_ID_ATTR_EMAIL
WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID

Added in version 4.18.

Сопоставление атрибутов SAML.

Другие параметры авторизации

WEBLATE_NO_EMAIL_AUTH

При установке в любое значение отключает авторизацию через электронную почту. См. Отключение авторизации по паролю.

WEBLATE_MIN_PASSWORD_SCORE

Minimal password score as evaluated by the zxcvbn password strength estimator. Defaults to 3, set to 0 to disable strenght checking.

Настройки базы данных PostgreSQL

База данных создается в файле docker-compose.yml, поэтому эти настройки влияют как на контейнер Weblate, так и на контейнер PostgreSQL.

POSTGRES_PASSWORD

Пароль PostgreSQL.

POSTGRES_USER

Имя пользователя PostgreSQL.

POSTGRES_DB

Имя базы данных PostgreSQL.

POSTGRES_HOST

Имя хоста или IP-адрес сервера PostgreSQL. По умолчанию равен database.

POSTGRES_PORT

Порт сервера PostgreSQL. По умолчанию не установлен (используется значение по умолчанию).

POSTGRES_SSL_MODE

Настраивает обработку SSL сервером PostgreSQL при соединении с сервером, возможные варианты настройки смотрите документе Описания режимов SSL

POSTGRES_ALTER_ROLE

Устанавливает имя роли, которую Weblate будет настраивать во время миграции, смотреть раздел Настройка Weblate для использования PostgreSQL.

POSTGRES_CONN_MAX_AGE

Added in version 4.8.1.

Время соединения с базой данных, выраженное целым числом секунд. Используйте 0, чтобы закрывать соединения с базой данных в конце каждого запроса (это поведение по умолчанию).

Изменено в версии 5.1: По умолчанию используется неограниченное количество постоянных соединений с базой данных.

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

Пример настроек:

environment:
    POSTGRES_CONN_MAX_AGE: 3600
POSTGRES_DISABLE_SERVER_SIDE_CURSORS

Added in version 4.9.1.

Отключите курсоры на стороне сервера в базе данных. Это необходимо в некоторых настройках pgbouncer.

Пример настроек:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1
WEBLATE_DATABASES

Added in version 5.1.

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

Сервер MySQL или MariaDB

Ни MySQL, ни MariaDB не могут быть настроены через переменные окружения. Информацию об их использовании см. в разделе Weblate MySQL и MariaDB. Используйте WEBLATE_DATABASES для настройки подключения к базе данных вручную.

Параметры резервного копирования базы данных

WEBLATE_DATABASE_BACKUP

Настраивает ежедневный дамп базы данных с помощью параметра DATABASE_BACKUP. По умолчанию установлен в plain.

Настройка сервера кэширования

Weblate настоятельно рекомендует использовать Redis и при запуске Weblate’а в Docker’е вы должны предоставить экземпляр Redis’а.

REDIS_HOST

Имя хоста или IP-адрес сервера Redis. По умолчанию установлен в cache.

REDIS_PORT

Порт сервера Redis. По умолчанию установлен в 6379.

REDIS_DB

Номер базы данных Redis, по умолчанию установлен в 1.

REDIS_PASSWORD

Пароль сервера Redis, по умолчанию не используется.

REDIS_TLS

Включает использование SSL для соединения с Redis.

REDIS_VERIFY_SSL

Может использоваться для отключения проверки SSL-сертификата для соединениий с Redis.

Настройка почтового сервера

Чтобы работала отправка писем электронной почты, необходимо предоставить почтовый сервер.

Пример конфигурации TLS:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass

Пример конфигурации SSL:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_PORT: 465
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass
    WEBLATE_EMAIL_USE_TLS: 0
    WEBLATE_EMAIL_USE_SSL: 1
WEBLATE_EMAIL_HOST

Имя хоста или IP-адрес почтового сервера.

WEBLATE_EMAIL_PORT

Порт почтового сервера, по умолчанию установлен в 25.

См.также

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER

Пользователь для авторизации по электронной почте.

См.также

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD

Пароль для авторизации по электронной почте.

WEBLATE_EMAIL_USE_SSL

Использовать ли неявное TLS (безопасное) соединение при общении с сервером SMTP. В большей части документации по электронной почте этот тип TLS-соединения называется SSL. Он обычно используется на 465-м порту. Если у вас возникли проблемы, попробуйте включить явный TLS параметром WEBLATE_EMAIL_USE_TLS.

Изменено в версии 4.11: Поддержка SSL/TLS включается автоматически на основе WEBLATE_EMAIL_PORT.

WEBLATE_EMAIL_USE_TLS

Использовать ли TLS (безопасное) соединение при общении с сервером SMTP. Он используется для явных TLS-соединений, обычно на портах 587 или 25. Если ваши соединения зависают, попробуйте включить неявный TLS параметром WEBLATE_EMAIL_USE_SSL.

Изменено в версии 4.11: Поддержка SSL/TLS включается автоматически на основе WEBLATE_EMAIL_PORT.

WEBLATE_EMAIL_BACKEND

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

WEBLATE_AUTO_UPDATE

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

См.также

AUTO_UPDATE

Примечание

Это логическое значение параметра (используйте "true" или "false").

Интеграция с сайтом

WEBLATE_GET_HELP_URL

Настраивает параметр GET_HELP_URL.

WEBLATE_STATUS_URL

Настраивает параметр STATUS_URL.

Настраивает параметр LEGAL_URL.

WEBLATE_PRIVACY_URL

Настраивает параметр PRIVACY_URL.

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

Рекомендуется систематически собирать ошибки от установки, смотрите раздел Сбор отчётов об ошибках и мониторинг производительности.

Для включения поддержки Rollbar установите следующие переменные:

ROLLBAR_KEY

Ваш токен доступа к серверу Rollbar.

ROLLBAR_ENVIRONMENT

Ваше окружение Rollbar, по умолчанию установлена в production.

Для включения поддержки Sentry установите следующие переменные:

SENTRY_DSN

Ваш Sentry DSN, см. SENTRY_DSN.

SENTRY_ENVIRONMENT

Ваша среда Sentry (необязательно) по умолчанию: WEBLATE_SITE_DOMAIN.

SENTRY_TRACES_SAMPLE_RATE

Настройте частоту выборки для мониторинга производительности. Установите значение 1 для отслеживания всех событий, значение 0 (по умолчанию) отключает отслеживание.

Пример:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5
SENTRY_PROFILES_SAMPLE_RATE

Настройте частоту выборки для мониторинга профилирования. Установите значение 1 для отслеживания всех событий, значение 0 (по умолчанию) отключает отслеживание.

Пример:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5
SENTRY_SEND_PII

Настраивает SENTRY_SEND_PII.

CDN локализации

WEBLATE_LOCALIZE_CDN_URL
WEBLATE_LOCALIZE_CDN_PATH

Added in version 4.2.1.

Настройки для CDN локализации JavaScript.

Переменная WEBLATE_LOCALIZE_CDN_PATH указывает путь внутри контейнера. Он должен указывать на постоянный том, а не на временное хранилище.

Одной из возможных настроек является направление пути внутрь каталога данных Weblate:

environment:
  WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/
  WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn

Примечание

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

Изменение включённых приложений, проверок, надстроек или автоматических исправлений

Встроенную конфигурация включённых проверок, надстроек или автоматических исправлений можно изменить с помощью следующих переменных:

WEBLATE_ADD_APPS
WEBLATE_REMOVE_APPS
WEBLATE_ADD_CHECK
WEBLATE_REMOVE_CHECK
WEBLATE_ADD_AUTOFIX
WEBLATE_REMOVE_AUTOFIX
WEBLATE_ADD_ADDONS
WEBLATE_REMOVE_ADDONS

Пример:

environment:
  WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
  WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon

Параметры контейнера

WEBLATE_WORKERS

Added in version 4.6.1.

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

Используется для определения CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, и WEB_WORKERS. Вы можете использовать эти настройки для точной регулировки.

CELERY_MAIN_OPTIONS
CELERY_NOTIFY_OPTIONS
CELERY_MEMORY_OPTIONS
CELERY_TRANSLATE_OPTIONS
CELERY_BACKUP_OPTIONS
CELERY_BEAT_OPTIONS

Эти переменные позволяют настроить параметры рабочего Celery. Может быть полезно подправить степень параллелизма (--concurrency 16) или включить использование другой реализации пула (--pool=gevent).

По умолчанию количество одновременно обработчиков основано на WEBLATE_WORKERS.

Пример:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16
WEB_WORKERS

Настраивает количество выполняемых рабочих процессов uWSGI.

По умолчанию это означает WEBLATE_WORKERS.

Пример:

environment:
  WEB_WORKERS: 32
WEBLATE_SERVICE

Определяет, какие службы должны выполняться внутри контейнера. Используйте это для Масштабирование по горизонтали.

Определены следующие услуги:

celery-beat

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

celery-backup

Обработчик Celery для резервного копирования, должен быть запущен только один.

celery-celery

Общий обработчик Celery.

celery-memory

Память переводов обработчиков Celery.

celery-notify

Обработчики уведомлений Celery.

celery-translate

Тип фильтра автоматического перевода обработчика Celery.

web

Веб-сервер.

Тома контейнеров Docker’а

Контейнер Weblate экспортирует только два тома (данные и кэш). Контейнеры других сервисов (PostgreSQL или Redis) имеют свои собственные тома данных, которые в настоящем документе не рассматриваются.

Том данных используется для хранения таких постоянных данных Weblate, как склонированные репозитории, или для настройки установки Weblate.

Непосредственное размещение этого тома в хост-системе зависит от настроек самого Docker’а, но обычно он хранится в каталоге /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ (путь состоит из имени вашего каталога docker-compose, имён контейнеров и томов). В контейнере он монтируется под именем /app/data.

Том кэша монтируется как /app/cache и используется для хранения статических файлов и CACHE_DIR. Его содержимое воссоздаётся при запуске контейнера, и том можно смонтировать с использованием эфемерной файловой системы, такой как tmpfs.

При создании томов вручную, каталоги должны принадлежать UID 1000, так как именно этот пользователь используется внутри контейнера.

Корневая файловая система только для чтения

Added in version 4.18.

При запуске контейнера с корневой файловой системой, доступной только для чтения, требуются два дополнительных тома tmpfs — /tmp и /run.

Конфигурация за пределами переменных среды

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

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

Если вам нужно изменить параметр, который не представлен как переменная среды Docker, вы всё равно можете это сделать либо из тома данных, либо расширив образ Docker.

См.также

Настройка Weblate

Переопределение настроек из тома данных

Вы можете создать файл /app/data/settings-override.py, то есть в корне тома данных, чтобы расширить или переопределить настройки, определённые через переменные среды.

Переопределение настроек путём расширения образа Docker

Чтобы переопределить настройки на уровне образа Docker, а не на уровне тома данных:

  1. Создайте собственный пакет Python.

  2. Добавьте в свой пакет модуль, который импортирует все настройки из weblate.settings_docker.

    Например, в структуре пакета, определенной в Создание модуля Python, вы можете создать файл weblate_customization/weblate_customization/settings.py со следующим исходным кодом:

    from weblate.settings_docker import *
    
  3. Создайте собственный Dockerfile, который унаследован от официального образа Docker Weblate, а затем установите ваш пакет и укажите переменную среды DJANGO_SETTINGS_MODULE в ваш модуль настроек:

    FROM weblate/weblate
    
    USER root
    
    COPY weblate_customization /usr/src/weblate_customization
    RUN pip install --no-cache-dir /usr/src/weblate_customization
    ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings
    
    USER 1000
    
  4. Вместо использования официального образа Docker Weblate создайте собственный образ из этого файла Dockerfile.

    Не существует чистого способа сделать это с помощью docker-compose.override.yml. Вы можете добавить build: . в узел weblate в этом файле, но тогда ваше собственное изображение будет помечено в вашей системе как weblate/weblate, что может быть проблематичным.

    Итак, вместо использования docker-compose.yml прямо из официального репозитория, без изменений и расширения его через docker-compose .override.yml, вы можете сделать копию официального файла docker-compose.yml и отредактировать свою копию, заменив image: weblate/weblate на build: ..

    См. «Справочник по сборке файла Compose» для получения подробной информации о создании образов из исходного кода при использовании docker-compose.

  5. Расширьте свой модуль пользовательских настроек, чтобы определить или переопределить настройки.

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

    Вы также можете пойти дальше. Например, вы можете воспроизвести некоторые действия, которые weblate.docker_settings делает <https://github.com/WeblateOrg/weblate/blob/main/weblate/settings_docker.py>`__, например, раскрывает настройки в качестве переменных среды или разрешить переопределение настроек из файлов Python в томе данных.

Замена логотипа и других статических файлов

Статические файлы, поставляемые с Weblate, можно переопределить, поместив их в каталог /app/data/python/customize/static (смотрите раздел Тома контейнеров Docker’а). Например, создав файл /app/data/python/customize/static/favicon.ico, вы замените им иконку сайта.

Подсказка

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

Этот подход также можно использовать для переопределения шаблонов Weblate. Например, документы Правовые вопросы могут быть помещены в /app/data/python/customize/templates/legal/documents.

В качестве альтернативы вы также можете включить свой собственный модуль (смотрите раздел Настройка Weblate) и добавить его в контейнер Docker’а отдельным томом, например:

weblate:
  volumes:
    - weblate-data:/app/data
    - ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
  environment:
    WEBLATE_ADD_APPS: weblate_customization

Настройка сервера PostgreSQL

Контейнер PostgreSQL использует конфигурацию PostgreSQL по умолчанию, которая неэффективно использует ядра процессора или память. Рекомендуется настроить конфигурацию для повышения производительности.

Конфигурацию можно изменить, как описано в разделе Конфигурация базы данных по адресу https://hub.docker.com/_/postgres. Конфигурацию, соответствующую вашей среде, можно сгенерировать с помощью https://pgtune.leopard.in.ua/.

Внутренние свойства контейнера

Контейнер использует supervisor для запуска отдельных сервисов. В случае Масштабирование по горизонтали он запускает только один сервис в контейнере.

Для проверки состояния услуг используйте:

docker compose exec --user weblate weblate supervisorctl status

Для каждой очереди Celery существуют отдельные службы (подробности см. в разделе Фоновые задачи с использованием Celery). Вы можете остановить обработку некоторых задач, остановив соответствующего исполнителя:

docker compose exec --user weblate weblate supervisorctl stop celery-translate