Instalowanie za pomocą Dockera#

Dzięki zadokeryzowanemu wdrożeniu Weblate możesz uruchomić swoją osobistą instancję Weblate w kilka sekund. Wszystkie zależności Weblate są już uwzględnione. PostgreSQL jest skonfigurowany jako domyślna baza danych.

Wymagania sprzętowe#

Weblate powinien działać bez problemów na każdym współczesnym sprzęcie, poniżej przedstawiono minimalną konfigurację wymaganą do uruchomienia Weblate na jednym hoście (Weblate, baza danych i serwer sieciowy):

  • 3 GB of RAM

  • 2 rdzenie procesora

  • 1 GB miejsca

Im więcej pamięci, tym lepiej - wykorzystywana jest do buforowania na wszystkich poziomach (system plików, baza danych i Weblate).

Wiele użytkowników jednocześnie zwiększa liczbę potrzebnych rdzeni procesora. W przypadku setek elementów tłumaczenia zalecane jest co najmniej 4 GB pamięci RAM.

Typowe użycie magazynu bazy danych wynosi około 300 MB na 1 milion hostowanych słów. Miejsce do magazynowania potrzebne do sklonowanych repozytoriów jest różna, ale Weblate stara się zachować ich minimalny rozmiar, wykonując płytkie klonowanie.

Informacja

Rzeczywiste wymagania dotyczące instalacji Weblate różnią się znacznie w zależności od rozmiaru zarządzanych tłumaczeń.

Instalacja#

Poniższe przykłady zakładają, że masz działające środowisko Docker z zainstalowanym docker-compose. Instrukcje można znaleźć w dokumentacji platformy Docker.

  1. Klonowanie repozytorium weblate-docker:

    git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
    cd weblate-docker
    
  2. Utwórz plik: docker-compose.override.yml z ustawieniami. Zobacz Zmienne środowiskowe platformy Docker aby zapoznać się z pełną listą zmiennych środowiskowych.

    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
    

    Informacja

    Jeżeli WEBLATE_ADMIN_PASSWORD nie jest ustawione, administrator jest tworzony z losowym hasłem wyświetlanym przy pierwszym uruchomieniu.

    Podany przykład sprawia, że Weblate nasłuchuje na porcie 80, edytuj mapowanie portów w pliku docker-compose.override.yml aby to zmienić.

  3. Uruchamianie kontenera Weblate:

    docker-compose up
    

Ciesz się wdrożeniem, Weblate jest teraz dostępne na porcie 80 kontenera `` weblate``.

Zmienione w wersji 3.7.1-6: W lipcu 2019 r. (Począwszy od tagu 3.7.1-6) kontenery nie działają jako użytkownik root. Zmieniło to odsłonięty port 80 na 8080.

Choosing Docker hub tag#

You can use following tags on Docker hub, see https://hub.docker.com/r/weblate/weblate/tags/ for full list of available ones.

Nazwa tagu

Opis

Przypadek użycia

latest

Weblate stable release, matches latest tagged release

Rolling updates in a production environment

<VERSION>-<PATCH>

Wersja stabilna Weblate

Well defined deploy in a production environment

edge

Weblate stable release with development changes in the Docker container (for example updated dependencies)

Rolling updates in a staging environment

edge-<DATE>-<SHA>

Weblate stable release with development changes in the Docker container (for example updated dependencies)

Well defined deploy in a staging environment

bleeding

Development version Weblate from Git

Rollling updates to test upcoming Weblate features

bleeding-<DATE>-<SHA>

Development version Weblate from Git

Well defined deploy to test upcoming Weblate features

Every image is tested by our CI before it gets published, so even the bleeding version should be quite safe to use.

Kontener platformy Docker z obsługą protokołu HTTPS#

Zobacz Instalacja, aby zapoznać się z ogólnymi instrukcjami dotyczącymi wdrażania, ta sekcja wspomina tylko o różnicach w porównaniu z ogólną instrukcją.

Używanie własnych certyfikatów SSL#

Nowe w wersji 3.8-3.

Jeśli masz własny certyfikat SSL, którego chcesz użyć, po prostu umieść pliki w woluminie danych Weblate (zobacz Woluminy kontenerów platformy Docker):

  • : file:ssl / fullchain.pem certyfikat zawierający wszystkie potrzebne certyfikaty CA

  • ssl/privkey.pem zawierający klucz prywatny

Oba te pliki muszą być własnością tego samego użytkownika, który uruchamia kontener docker i mieć maskę pliku ustawioną na «»600»» (czytelną i zapisywalną tylko przez użytkownika będącego właścicielem).

Dodatkowo, kontener Weblate będzie teraz akceptował połączenia SSL na porcie 4443, będziesz musiał uwzględnić przekierowanie portu dla HTTPS w docker-compose.override.yml:

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

Jeśli masz już inne strony na tym samym serwerze, prawdopodobnie porty 80 i 443 są używane przez odwrotny serwer proxy, taki jak NGINX. Aby przekazać połączenie HTTPS z NGINX do kontenera dockerowego, można użyć następującej konfiguracji:

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

    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>;
    }
}

Zastąp <SITE_URL>, <SITE> i <EXPOSED_DOCKER_PORT> rzeczywistymi wartościami z twojego środowiska.

Automatyczne certyfikaty SSL z wykorzystaniem Let’s Encrypt#

In case you want to use Let’s Encrypt automatically generated SSL certificates on public installation, you need to add a reverse HTTPS proxy an additional Docker container, https-portal will be used for that. This is made use of in the docker-compose-https.yml file. Then create a docker-compose-https.override.yml file with your settings:

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'

Whenever invoking docker-compose you need to pass both files to it, and then do:

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

Uaktualnianie kontenera platformy Docker#

Usually it is good idea to only update the Weblate container and keep the PostgreSQL container at the version you have, as upgrading PostgreSQL is quite painful and in most cases does not bring many benefits.

Zmienione w wersji 4.10-1: Since Weblate 4.10-1, the Docker container uses Django 4.0 what requires PostgreSQL 10 or newer, please upgrade it prior to upgrading Weblate. See Uaktualnienie z 4.9 do 4.10 and Uaktualnianie kontenera PostgreSQL.

You can do this by sticking with the existing docker-compose and just pull the latest images and then restart:

# 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

The Weblate database should be automatically migrated on first startup, and there should be no need for additional manual actions.

Informacja

Upgrades across major versions are not supported by Weblate. For example, if you are on 3.x series and want to upgrade to 4.x, first upgrade to the latest 4.0.x-y image (at time of writing this it is the 4.0.4-5), which will do the migration and then continue upgrading to newer versions.

You might also want to update the docker-compose repository, though it’s not needed in most case. See Uaktualnianie kontenera PostgreSQL for upgrading the PostgreSQL server.

Uaktualnianie kontenera PostgreSQL#

PostgreSQL containers do not support automatic upgrading between version, you need to perform the upgrade manually. Following steps show one of the options of upgrading.

  1. Zatrzymaj kontener Weblate:

    docker-compose stop weblate cache
    
  2. Utwórz kopię zapasową bazy danych:

    docker-compose exec database pg_dumpall --clean --username weblate > backup.sql
    
  3. Zatrzymaj kontener bazy danych:

    docker-compose stop database
    
  4. Usuń wolumin PostgreSQL:

    docker-compose rm -v database
    docker volume remove weblate-docker_postgres-data
    
  5. Adjust docker-compose.yml to use new PostgreSQL version.

  6. Uruchom kontener bazy danych:

    docker-compose up -d database
    
  7. Przywróć bazę danych z kopii zapasowej:

    cat backup.sql | docker-compose exec -T database psql --username weblate --dbname postgres
    
  8. (Optional) Update password for the Weblate user. This might be needed when migrating to PostgreSQL 14 or 15 as way of storing passwords has been changed:

    docker-compose exec -T database psql --username weblate --dbname postgres -c "ALTER USER weblate WITH PASSWORD 'weblate'"
    
  9. Uruchom wszystkie pozostałe kontenery:

    docker-compose up -d
    

Zaloguj się jako administrator#

After container setup, you can sign in as admin user with password provided in WEBLATE_ADMIN_PASSWORD, or a random password generated on first start if that was not set.

To reset admin password, restart the container with WEBLATE_ADMIN_PASSWORD set to new password.

Number of processes and memory consumption#

The number of worker processes for both uWSGI and Celery is determined automatically based on number of CPUs. This works well for most cloud virtual machines as these typically have few CPUs and good amount of memory.

In case you have a lot of CPU cores and hit out of memory issues, try reducing number of workers:

environment:
  WEBLATE_WORKERS: 2

You can also fine-tune individual worker categories:

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

Scaling horizontally#

Nowe w wersji 4.6.

You can run multiple Weblate containers to scale the service horizontally. The /app/data volume has to be shared by all containers, it is recommended to use cluster filesystem such as GlusterFS for this. The /app/cache volume should be separate for each container.

Each Weblate container has defined role using WEBLATE_SERVICE environment variable. Please follow carefully the documentation as some of the services should be running just once in the cluster and the ordering of the services matters as well.

You can find example setup in the docker-compose repo as docker-compose-split.yml.

Zmienne środowiskowe platformy Docker#

Many of Weblate’s Konfiguracja can be set in the Docker container using the environment variables described below.

If you need to define a setting not exposed through Docker environment variables, see Configuration beyond environment variables.

Ustawienia ogólne#

WEBLATE_DEBUG#

Configures Django debug mode using DEBUG.

Przykład:

environment:
  WEBLATE_DEBUG: 1
WEBLATE_LOGLEVEL#

Konfiguruje szczegółowość rejestrowania.

WEBLATE_LOGLEVEL_DATABASE#

Konfiguruje rejestrowanie szczegółowości zapytań bazy danych.

WEBLATE_SITE_TITLE#

Changes the site-title shown in the header of all pages.

WEBLATE_SITE_DOMAIN#

Konfiguruje domenę strony. Ten parametr jest wymagany.

WEBLATE_ADMIN_NAME#
WEBLATE_ADMIN_EMAIL#

Configures the site-admin’s name and e-mail. It is used for both ADMINS setting and creating admin user (see WEBLATE_ADMIN_PASSWORD for more info on that).

Przykład:

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

Sets the password for the admin user.

  • If not set and admin user does not exist, it is created with a random password shown on first container startup.

  • If not set and admin user exists, no action is performed.

  • If set the admin user is adjusted on every container startup to match WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME and WEBLATE_ADMIN_EMAIL.

Ostrzeżenie

It might be a security risk to store password in the configuration file. Consider using this variable only for initial setup (or let Weblate generate random password on initial startup) or for password recovery.

WEBLATE_ADMIN_PASSWORD_FILE#

Sets the path to a file containing the password for the admin user.

Zobacz także

WEBLATE_ADMIN_PASSWORD

WEBLATE_SERVER_EMAIL#

The email address that error messages are sent from.

WEBLATE_DEFAULT_FROM_EMAIL#

Configures the address for outgoing e-mails.

WEBLATE_CONTACT_FORM#

Configures contact form behavior, see CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS#

Configures allowed HTTP hostnames using ALLOWED_HOSTS.

Defaults to * which allows all hostnames.

Przykład:

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

Configures whether registrations are open by toggling REGISTRATION_OPEN.

Przykład:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
WEBLATE_REGISTRATION_ALLOW_BACKENDS#

Configure which authentication methods can be used to create new account via REGISTRATION_ALLOW_BACKENDS.

Przykład:

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

Nowe w wersji 4.16.

Configures REGISTRATION_REBIND.

WEBLATE_TIME_ZONE#

Configures the used time zone in Weblate, see TIME_ZONE.

Informacja

To change the time zone of the Docker container itself, use the TZ environment variable.

Przykład:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague
WEBLATE_ENABLE_HTTPS#

Makes Weblate assume it is operated behind a reverse HTTPS proxy, it makes Weblate use HTTPS in e-mail and API links or set secure flags on cookies.

Podpowiedź

Please see ENABLE_HTTPS documentation for possible caveats.

Informacja

This does not make the Weblate container accept HTTPS connections, you need to configure that as well, see Kontener platformy Docker z obsługą protokołu HTTPS for examples.

Przykład:

environment:
  WEBLATE_ENABLE_HTTPS: 1
WEBLATE_INTERLEDGER_PAYMENT_POINTERS#

Nowe w wersji 4.12.1.

Lets Weblate set the meta[name=monetization] field in the head of the document. If multiple are specified, chooses one randomly.

WEBLATE_IP_PROXY_HEADER#

Lets Weblate fetch the IP address from any given HTTP header. Use this when using a reverse proxy in front of the Weblate container.

Enables IP_BEHIND_REVERSE_PROXY and sets IP_PROXY_HEADER.

Informacja

The format must conform to Django’s expectations. Django transforms raw HTTP header names as follows:

  • konwertuje wszystkie znaki na wielkie litery

  • zastępuje wszystkie łączniki podkreśleniami

  • poprzedza HTTP_ prefiks

So X-Forwarded-For would be mapped to HTTP_X_FORWARDED_FOR.

Przykład:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
WEBLATE_SECURE_PROXY_SSL_HEADER#

A tuple representing a HTTP header/value combination that signifies a request is secure. This is needed when Weblate is running behind a reverse proxy doing SSL termination which does not pass standard HTTPS headers.

Przykład:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Zobacz także

SECURE_PROXY_SSL_HEADER

WEBLATE_REQUIRE_LOGIN#

Enables REQUIRE_LOGIN to enforce authentication on whole Weblate.

Przykład:

environment:
  WEBLATE_REQUIRE_LOGIN: 1
WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS#
WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS#
WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS#

Adds URL exceptions for authentication required for the whole Weblate installation using LOGIN_REQUIRED_URLS_EXCEPTIONS.

You can either replace whole settings, or modify default value using ADD and REMOVE variables.

WEBLATE_GOOGLE_ANALYTICS_ID#

Configures ID for Google Analytics by changing GOOGLE_ANALYTICS_ID.

WEBLATE_GITHUB_USERNAME#
WEBLATE_GITHUB_TOKEN#
WEBLATE_GITHUB_HOST#

Configures GitHub pull-requests integration by changing GITHUB_CREDENTIALS.

Zobacz także

GitHub pull requests

WEBLATE_GITLAB_USERNAME#
WEBLATE_GITLAB_TOKEN#
WEBLATE_GITLAB_HOST#

Configures GitLab merge-requests integration by changing GITLAB_CREDENTIALS.

Przykład:

WEBLATE_GITLAB_USERNAME=weblate
WEBLATE_GITLAB_HOST=gitlab.com
WEBLATE_GITLAB_TOKEN=token

Zobacz także

GitLab merge requests

WEBLATE_GITEA_USERNAME#
WEBLATE_GITEA_TOKEN#
WEBLATE_GITEA_HOST#

Configures Gitea pull-requests integration by changing GITEA_CREDENTIALS.

Zobacz także

Gitea pull requests

WEBLATE_PAGURE_USERNAME#
WEBLATE_PAGURE_TOKEN#
WEBLATE_PAGURE_HOST#

Configures Pagure merge-requests integration by changing PAGURE_CREDENTIALS.

Zobacz także

Pagure merge requests

WEBLATE_BITBUCKETSERVER_USERNAME#
WEBLATE_BITBUCKETSERVER_TOKEN#
WEBLATE_BITBUCKETSERVER_HOST#

Configures Bitbucket Server pull-requests integration by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_DEFAULT_PULL_MESSAGE#

Configures the default title and message for pull requests via API by changing DEFAULT_PULL_MESSAGE

Zobacz także

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES#

Configures the language simplification policy, see SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL#

Configures the default Kontrola dostępu for new projects, see DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT#

Configures the default value for Ograniczony dostęp for new components, see DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION#

Configures the default value for Zezwól na propagację tłumaczenia for new components, see DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL#

Konfiguruje DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME#

Konfiguruje DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM#

Konfiguruje DEFAULT_SHARED_TM.

WEBLATE_AKISMET_API_KEY#

Configures the Akismet API key, see AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY#

Configures GPG signing of commits, see WEBLATE_GPG_IDENTITY.

WEBLATE_URL_PREFIX#

Configures URL prefix where Weblate is running, see URL_PREFIX.

WEBLATE_SILENCED_SYSTEM_CHECKS#

Configures checks which you do not want to be displayed, see SILENCED_SYSTEM_CHECKS.

WEBLATE_CSP_SCRIPT_SRC#
WEBLATE_CSP_IMG_SRC#
WEBLATE_CSP_CONNECT_SRC#
WEBLATE_CSP_STYLE_SRC#
WEBLATE_CSP_FONT_SRC#

Allows to customize Content-Security-Policy HTTP header.

WEBLATE_LICENSE_FILTER#

Konfiguruje LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED#

Konfiguruje LICENSE_REQUIRED

WEBLATE_WEBSITE_REQUIRED#

Konfiguruje WEBSITE_REQUIRED

WEBLATE_HIDE_VERSION#

Konfiguruje HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES#

Konfiguruje BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH#

Konfiguruje DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS#
WEBLATE_RATELIMIT_LOCKOUT#
WEBLATE_RATELIMIT_WINDOW#

Nowe w wersji 4.6.

Konfiguruje ogranicznik szybkości.

Podpowiedź

You can set configuration for any rate limiter scopes. To do that add WEBLATE_ prefix to any of setting described in Ograniczenie szybkości.

WEBLATE_API_RATELIMIT_ANON#
WEBLATE_API_RATELIMIT_USER#

Nowe w wersji 4.11.

Configures API rate limiting. Defaults to 100/day for anonymous and 5000/hour for authenticated users.

WEBLATE_ENABLE_HOOKS#

Nowe w wersji 4.13.

Configures ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS#

Nowe w wersji 4.6.1.

Konfiguruje ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX#

Nowe w wersji 4.15.

Configures AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH#

Nowe w wersji 4.9.

Konfiguruje LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS#

Nowe w wersji 4.9.

Konfiguruje SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS#

Nowe w wersji 4.9.

Konfiguruje BORG_EXTRA_ARGS.

WEBLATE_ENABLE_SHARING#

Nowe w wersji 4.14.1.

Configures ENABLE_SHARING.

WEBLATE_EXTRA_HTML_HEAD#

Nowe w wersji 4.15.

Configures EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE#

Nowe w wersji 4.15.

Configures PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN#

Nowe w wersji 4.15.

Configures PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS#

Nowe w wersji 4.17.

Configures UNUSED_ALERT_DAYS.

WEBLATE_CORS_ALLOWED_ORIGINS#

Nowe w wersji 4.16.

Allow CORS requests from given origins.

Przykład:

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

Nowe w wersji 4.16.3.

Configures maximal body size accepted by the built-in web server.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Podpowiedź

This variable intentionally lacks WEBLATE_ prefix as it is shared with third-party container used in Automatyczne certyfikaty SSL z wykorzystaniem Let’s Encrypt.

Ustawienia automatycznych sugestii#

Zmienione w wersji 4.13: Automatic suggestion services are now configured in the user interface, see Konfigurowanie automatycznych sugestii.

The existing environment variables are imported during the migration to Weblate 4.13, but changing them will not have any further effect.

Ustawienia uwierzytelniania#

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

Ścieżka do pliku zawierającego hasło powiązania serwera LDAP.

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#

Konfiguracja uwierzytelniania LDAP.

** Przykład bezpośredniego powiązania: **

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

Example for search and bind:

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

Example for union search and bind:

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

Example with search and bind against 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)

Zobacz także

Uwierzytelnianie LDAP

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#

Włączanie Uwierzytelnianie GitHub.

Bitbucket#

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY#
WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET#
WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY#
WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET#

Włączanie Uwierzytelnianie Bitbucket.

Facebook#

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY#
WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET#

Włączanie 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#

Włączanie Google OAuth 2.

GitLab#

WEBLATE_SOCIAL_AUTH_GITLAB_KEY#
WEBLATE_SOCIAL_AUTH_GITLAB_SECRET#
WEBLATE_SOCIAL_AUTH_GITLAB_API_URL#

Włączanie GitLab OAuth 2.

Gitea#

WEBLATE_SOCIAL_AUTH_GITEA_API_URL#
WEBLATE_SOCIAL_AUTH_GITEA_KEY#
WEBLATE_SOCIAL_AUTH_GITEA_SECRET#

Enables Gitea authentication.

Azure Active Directory#

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY#
WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET#

Enables Azure Active Directory authentication, see Microsoft Azure Active Directory.

Azure Active Directory with Tenant support#

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY#
WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET#
WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID#

Enables Azure Active Directory authentication with Tenant support, see 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#

Enables Keycloak authentication, see documentation.

Dostawcy linuksa#

You can enable authentication using Linux vendors authentication services by setting following variables to any value.

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#

Włącza uwierzytelnianie Slack, zobacz Slack.

OpenID Connect#

Nowe w wersji 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#

Configures generic OpenID Connect integration.

Zobacz także

OIDC (OpenID Connect)

SAML#

Self-signed SAML keys are automatically generated on first container startup. In case you want to use own keys, place the certificate and private key in /app/data/ssl/saml.crt and /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 Identity Provider settings, see Uwierzytelnianie SAML.

Inne ustawienia uwierzytelniania#

WEBLATE_NO_EMAIL_AUTH#

Wyłącza uwierzytelnianie poczty e-mail, gdy jest ustawiona na dowolną wartość. Zobacz disable-e-mail-auth.

Konfiguracja bazy danych PostgreSQL#

The database is created by docker-compose.yml, so these settings affect both Weblate and PostgreSQL containers.

POSTGRES_PASSWORD#

Hasło PostgreSQL.

POSTGRES_PASSWORD_FILE#

Path to the file containing the PostgreSQL password. Use as an alternative to POSTGRES_PASSWORD.

POSTGRES_USER#

Nazwa użytkownika PostgreSQL.

POSTGRES_DATABASE#

Nazwa bazy danych PostgreSQL.

POSTGRES_HOST#

PostgreSQL server hostname or IP address. Defaults to database.

POSTGRES_PORT#

PostgreSQL server port. Defaults to none (uses the default value).

POSTGRES_SSL_MODE#

Configure how PostgreSQL handles SSL in connection to the server, for possible choices see SSL Mode Descriptions

POSTGRES_ALTER_ROLE#

Configures name of role to alter during migrations, see Konfigurowanie Weblate do korzystania z PostgreSQL.

POSTGRES_CONN_MAX_AGE#

Nowe w wersji 4.8.1.

The lifetime of a database connection, as an integer of seconds. Use 0 to close database connections at the end of each request (this is the default behavior).

Enabling connection persistence will typically, cause more open connection to the database. Please adjust your database configuration prior enabling.

Przykładowa konfiguracja:

environment:
    POSTGRES_CONN_MAX_AGE: 3600
POSTGRES_DISABLE_SERVER_SIDE_CURSORS#

Nowe w wersji 4.9.1.

Disable server side cursors in the database. This is necessary in some pgbouncer setups.

Przykładowa konfiguracja:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Ustawienia kopii zapasowej bazy danych#

WEBLATE_DATABASE_BACKUP#

Configures the daily database dump using DATABASE_BACKUP. Defaults to plain.

Konfiguracja serwera buforowania#

Using Redis is strongly recommended by Weblate and you have to provide a Redis instance when running Weblate in Docker.

Zobacz także

Włączanie buforowania

REDIS_HOST#

The Redis server hostname or IP address. Defaults to cache.

REDIS_PORT#

The Redis server port. Defaults to 6379.

REDIS_DB#

The Redis database number, defaults to 1.

REDIS_PASSWORD#

The Redis server password, not used by default.

REDIS_PASSWORD_FILE#

Ścieżka do pliku zawierającego hasło serwera Redis.

Zobacz także

REDIS_PASSWORD

REDIS_TLS#

Enables using SSL for Redis connection.

REDIS_VERIFY_SSL#

Can be used to disable SSL certificate verification for Redis connection.

Konfiguracja serwera poczty e-mail#

To make outgoing e-mail work, you need to provide a mail server.

Przykładowa konfiguracja protokołu TLS:

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

Przykładowa konfiguracja 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#

Mail server hostname or IP address.

WEBLATE_EMAIL_PORT#

Mail server port, defaults to 25.

Zobacz także

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER#

Uwierzytelnienie za pomocą e-maila.

Zobacz także

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD#

Hasło uwierzytelniania poczty e-mail.

Zobacz także

EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_HOST_PASSWORD_FILE#

Ścieżka do pliku zawierającego hasło uwierzytelniające e-mail.

WEBLATE_EMAIL_USE_SSL#

Whether to use an implicit TLS (secure) connection when talking to the SMTP server. In most e-mail documentation, this type of TLS connection is referred to as SSL. It is generally used on port 465. If you are experiencing problems, see the explicit TLS setting WEBLATE_EMAIL_USE_TLS.

Zmienione w wersji 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

WEBLATE_EMAIL_USE_TLS#

Whether to use a TLS (secure) connection when talking to the SMTP server. This is used for explicit TLS connections, generally on port 587 or 25. If you are experiencing connections that hang, see the implicit TLS setting WEBLATE_EMAIL_USE_SSL.

Zmienione w wersji 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

WEBLATE_EMAIL_BACKEND#

Configures Django back-end to use for sending e-mails.

WEBLATE_AUTO_UPDATE#

Konfiguruje, czy i jak Weblate powinno aktualizować repozytoria.

Zobacz także

AUTO_UPDATE

Informacja

This is a Boolean setting (use "true" or "false").

Integracja strony#

WEBLATE_GET_HELP_URL#

Konfiguruje GET_HELP_URL.

WEBLATE_STATUS_URL#

Konfiguruje STATUS_URL.

Konfiguruje LEGAL_URL.

WEBLATE_PRIVACY_URL#

Konfiguruje PRIVACY_URL.

Raportowanie błędów#

It is recommended to collect errors from the installation systematically, see Zbieranie raportów o błędach.

To enable support for Rollbar, set the following:

ROLLBAR_KEY#

Your Rollbar post server access token.

ROLLBAR_ENVIRONMENT#

Your Rollbar environment, defaults to production.

To enable support for Sentry, set following:

SENTRY_DSN#

Twój DSN Sentry.

SENTRY_ENVIRONMENT#

Twoje środowisko Sentry (opcjonalnie).

Lokalizacja CDN#

WEBLATE_LOCALIZE_CDN_URL#
WEBLATE_LOCALIZE_CDN_PATH#

Nowe w wersji 4.2.1.

Konfiguracja dla Lokalizacja JavaScript CDN.

The WEBLATE_LOCALIZE_CDN_PATH is path within the container. It should be stored on the persistent volume and not in the transient storage.

One of possibilities is storing that inside the Weblate data dir:

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

Informacja

You are responsible for setting up serving of the files generated by Weblate, it only does stores the files in configured location.

Changing enabled apps, checks, add-ons or autofixes#

Nowe w wersji 3.8-5.

The built-in configuration of enabled checks, add-ons or autofixes can be adjusted by the following variables:

WEBLATE_ADD_APPS#
WEBLATE_REMOVE_APPS#
WEBLATE_ADD_CHECK#
WEBLATE_REMOVE_CHECK#
WEBLATE_ADD_AUTOFIX#
WEBLATE_REMOVE_AUTOFIX#
WEBLATE_ADD_ADDONS#
WEBLATE_REMOVE_ADDONS#

Przykład:

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

Ustawienia kontenera#

WEBLATE_WORKERS#

Nowe w wersji 4.6.1.

Base number of worker processes running in the container. When not set it is determined automatically on container startup based on number of CPU cores available.

It is used to determine CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, and WEB_WORKERS. You can use these settings to fine-tune.

CELERY_MAIN_OPTIONS#
CELERY_NOTIFY_OPTIONS#
CELERY_MEMORY_OPTIONS#
CELERY_TRANSLATE_OPTIONS#
CELERY_BACKUP_OPTIONS#
CELERY_BEAT_OPTIONS#

These variables allow you to adjust Celery worker options. It can be useful to adjust concurrency (--concurrency 16) or use different pool implementation (--pool=gevent).

By default, the number of concurrent workers is based on WEBLATE_WORKERS.

Przykład:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16
WEB_WORKERS#

Configure how many uWSGI workers should be executed.

It defaults to WEBLATE_WORKERS.

Przykład:

environment:
  WEB_WORKERS: 32
WEBLATE_SERVICE#

Defines which services should be executed inside the container. Use this for Scaling horizontally.

Zdefiniowane są następujące usługi:

celery-beat

Celery task scheduler, only one instance should be running. This container is also responsible for the database structure migrations and it should be started prior others.

celery-backup

Celery worker for backups, only one instance should be running.

celery-celery

Generic Celery worker.

celery-memory

Pamięć tłumaczeniowa workera Celery.

celery-notify

Powiadomienia workera Celery.

celery-translate

Tłumaczenie automatyczne workera Celery.

web

Serwer internetowy.

Woluminy kontenerów platformy Docker#

There are two volumes (data and cache) exported by the Weblate container. The other service containers (PostgreSQL or Redis) have their data volumes as well, but those are not covered by this document.

The data volume is used to store Weblate persistent data such as cloned repositories or to customize Weblate installation.

The placement of the Docker volume on host system depends on your Docker configuration, but usually it is stored in /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ (the path consist of name of your docker-compose directory, container, and volume names). In the container it is mounted as /app/data.

The cache volume is mounted as /app/cache and is used to store static files and CACHE_DIR. Its content is recreated on container startup and the volume can be mounted using ephemeral filesystem such as tmpfs.

When creating the volumes manually, the directories should be owned by UID 1000 as that is user used inside the container.

Configuration beyond environment variables#

Docker environment variables are intended to expose most configuration settings of relevance for Weblate installations.

If you find a setting that is not exposed as an environment variable, and you believe that it should be, feel free to ask for it to be exposed in a future version of Weblate.

If you need to modify a setting that is not exposed as a Docker environment variable, you can still do so, either from the data volume or extending the Docker image.

Zobacz także

Dostosowywanie Weblate

Overriding settings from the data volume#

You can create a file at /app/data/settings-override.py, i.e. at the root of the data volume, to extend or override settings defined through environment variables.

Overriding settings by extending the Docker image#

To override settings at the Docker image level instead of from the data volume:

  1. Create a custom Python package.

  2. Add a module to your package that imports all settings from weblate.settings_docker.

    For example, within the example package structure defined at Tworzenie modułu Pythona, you could create a file at weblate_customization/weblate_customization/settings.py with the following initial code:

    from weblate.settings_docker import *
    
  3. Create a custom Dockerfile that inherits from the official Weblate Docker image, and then installs your package and points the DJANGO_SETTINGS_MODULE environment variable to your 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. Instead of using the official Weblate Docker image, build a custom image from this Dockerfile file.

    There is no clean way to do this with docker-compose.override.yml. You could add build: . to the weblate node in that file, but then your custom image will be tagged as weblate/weblate in your system, which could be problematic.

    So, instead of using the docker-compose.yml straight from the official repository, unmodified, and extending it through docker-compose.override.yml, you may want to make a copy of the official docker-compose.yml file, and edit your copy to replace image: weblate/weblate with build: ..

    See the Compose file build reference for details on building images from source when using docker-compose.

  5. Extend your custom settings module to define or redefine settings.

    You can define settings before or after the import statement above to determine which settings take precedence. Settings defined before the import statement can be overridden by environment variables and setting overrides defined in the data volume. Setting defined after the import statement cannot be overridden.

    You can also go further. For example, you can reproduce some of the things that weblate.docker_settings does, such as exposing settings as environment variables, or allow overriding settings from Python files in the data volume.

Replacing logo and other static files#

Nowe w wersji 3.8-5.

The static files coming with Weblate can be overridden by placing into /app/data/python/customize/static (see Woluminy kontenerów platformy Docker). For example creating /app/data/python/customize/static/favicon.ico will replace the favicon.

Podpowiedź

The files are copied to the corresponding location upon container startup, so a restart of Weblate is needed after changing the content of the volume.

This approach can be also used to override Weblate templates. For example Informacje prawne documents can be placed into /app/data/python/customize/templates/legal/documents.

Alternatively you can also include own module (see Dostosowywanie Weblate) and add it as separate volume to the Docker container, for example:

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

Konfigurowanie serwera PostgreSQL#

The PostgtreSQL container uses default PostgreSQL configuration and it won’t effectively utilize your CPU cores or memory. It is recommended to customize the configuration to improve the performance.

The configuration can be adjusted as described in Database Configuration at https://hub.docker.com/_/postgres. The configuration matching your environment can be generated using https://pgtune.leopard.in.ua/.

Container internals#

The container is using supervisor to start individual services. In case of Scaling horizontally, it only starts single service in a container.

To check the services status use:

docker-compose exec --user weblate weblate supervisorctl status

There are individual services for each Celery queue (see Zadania w tle korzystające z Celery for details). You can stop processing some tasks by stopping the appropriate worker:

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