Installation über Docker¶

Mit der Bereitstellung von Weblate über Docker können Sie Ihre persönliche Weblate-Instanz in Sekundenschnelle zum Laufen bringen. Alle Abhängigkeiten von Weblate sind bereits enthalten. PostgreSQL ist als Standarddatenbank und Redis als Caching-Backend eingerichtet.

Hardwareanforderungen¶

Weblate sollte auf jeder zeitgemäßen Hardware problemlos laufen. Nachfolgend finden Sie die minimale Konfiguration, die erforderlich ist, um Weblate auf einem einzelnen Host zu betreiben (Weblate, Datenbank und Webserver):

3 GB Arbeitsspeicher
2 CPU-Kerne
1 GB Speicherplatz

Je mehr Speicher, desto besser – er wird für das Caching auf allen Ebenen (Dateisystem, Datenbank und Weblate) verwendet.

Viele gleichzeitige Benutzer erhöhen die Anzahl der benötigten CPU-Kerne. Für Hunderte von Übersetzungskomponenten werden mindestens 4 GB RAM empfohlen.

Der typische Speicherbedarf der Datenbank liegt bei etwa 300 MB pro 1 Million gehosteter Wörter. Der Speicherplatzbedarf für geklonte Repositorys variiert, aber Weblate versucht, die Größe der Repositorys durch flache Klone gering zu halten.

Bemerkung

Die tatsächlichen Anforderungen an Ihre Weblate-Installation hängen stark von der Größe der darin verwalteten Übersetzungen ab.

Hinweis

Für Systeme mit weniger Speicher als empfohlen, wird Celery-Einzelprozess einrichten empfohlen.

Installation¶

Hinweis

Die folgenden Beispiele gehen davon aus, dass Sie eine funktionierende Docker-Umgebung haben, in der docker-compose-plugin installiert ist. Anweisungen hierzu finden Sie in der Docker-Dokumentation.

Dadurch wird ein Weblate-Bereitstellungsserver über HTTP erstellt, daher sollten Sie ihn hinter einem abschließenden HTTPS-Proxy platzieren. Sie können auch einen HTTPS-Proxy einsetzen, siehe Automatische SSL-Zertifikate mit Let’s Encrypt. Für größere Installationen siehe Horizontale Skalierung.

Das Weblate-Docker-Repository klonen:

git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
cd weblate-docker

Eine docker-compose.override.yml mit den eigenen Einstellungen erstellen. Siehe Docker-Umgebungsvariablen für eine vollständige Liste der Umgebungsvariablen.

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

Bemerkung

Wenn WEBLATE_ADMIN_PASSWORD nicht gesetzt ist, wird der Benutzer admin mit einem zufälligen Passwort erstellt, das beim ersten Start angezeigt wird.

Das mitgelieferte Beispiel lässt Weblate auf Port 80 lauschen. Bearbeiten Sie die Portzuordnung in der Datei docker-compose.override.yml, um sie zu ändern.

Weblate-Container starten:
```
docker compose up
```

Viel Spaß beim Einsatz von Weblate, es ist über Port 80 des Containers weblate erreichbar.

Siehe auch

Aufrufen von Verwaltungsbefehlen

Auswahl der Docker-Image-Registry¶

Weblate-Container werden in den folgenden Registrys veröffentlicht:

Docker Hub, siehe https://hub.docker.com/r/weblate/weblate
GitHub Packages Registry, siehe https://github.com/WeblateOrg/docker/pkgs/container/weblate

Bemerkung

Alle Beispiele beziehen derzeit Images von Docker Hub, bitte passen Sie die Konfiguration entsprechend an, um eine andere Registry zu verwenden.

Auswahl des Docker-Image-Tags¶

Bitte wählen Sie einen Tag, der Ihrer Einsatzumgebung und Ihren Erwartungen entspricht:

Tag-Name	Beschreibung	Anwendungsfall
`latest`	Stabile Version von Weblate, entspricht der neuesten getaggten Version	Fortlaufende Updates in einer Produktionsumgebung
`<MAJOR>`	Stabile Weblate-Version	Fortlaufende Updates innerhalb einer Hauptversion in einer Produktionsumgebung
`<MAJOR>.<MINOR>`	Stabile Weblate-Version	Fortlaufende Updates innerhalb einer Unterversion in einer Produktionsumgebung
`<VERSION>.<PATCH>`	Stabile Weblate-Version	Gut definierter Einsatz in einer Produktionsumgebung
`edge`	Stabile Weblate-Version mit Entwicklungsänderungen im Docker-Container (z. B. aktualisierte Abhängigkeiten)	Fortlaufende Updates in einer Staging-Umgebung
`edge-<DATE>-<SHA>`	Stabile Weblate-Version mit Entwicklungsänderungen im Docker-Container (z. B. aktualisierte Abhängigkeiten)	Gut definierter Einsatz in einer Staging-Umgebung
`bleeding`	Weblate-Entwicklungsversion von Git	Fortlaufende Updates zum Testen kommender Weblate-Funktionen
`bleeding-<DATE>-<SHA>`	Weblate-Entwicklungsversion von Git	Gut definierter Einsatz zum Testen kommender Weblate-Funktionen

Jedes Image wird vor der Veröffentlichung von unserer CI getestet, sodass selbst die bleeding-Version sicher verwendbar ist.

Eine vollständige Liste der veröffentlichten Tags finden Sie unter GitHub Packages

Docker-Container mit HTTPS-Unterstützung¶

Bitte lesen Sie Installation für allgemeine Bereitstellungsanweisungen, dieser Abschnitt erwähnt nur Unterschiede im Vergleich dazu.

Verwendung eigener SSL-Zertifikate¶

Wenn Sie ein eigenes SSL-Zertifikat haben, das Sie verwenden möchten, legen Sie die Dateien einfach in das Weblate-Daten-Volume (siehe Docker-Container-Volumes):

ssl/fullchain.pem, die das Zertifikat einschließlich aller erforderlichen CA-Zertifikate enthält
ssl/privkey.pem mit dem privaten Schlüssel

Beide Dateien müssen demselben Benutzer gehören wie demjenigen, der den Docker-Container startet und die Dateimaske muss auf 600 gesetzt sein (nur lesbar und schreibbar für den besitzenden Benutzer).

Außerdem akzeptiert der Weblate-Container jetzt SSL-Verbindungen auf Port 4443. Sie müssen die Portweiterleitung für HTTPS in die Docker-Compose-Überschreibung aufnehmen:

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

Wenn Sie bereits andere Sites auf demselben Server hosten, werden die Ports 80 und 443 wahrscheinlich von einem Reverse-Proxy wie NGINX verwendet. Um die HTTPS-Verbindung von NGINX an den Docker-Container zu übergeben, können Sie die folgende Konfiguration verwenden:

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

Ersetzen Sie <SITE_URL>, <SITE> und <EXPOSED_DOCKER_PORT> durch tatsächliche Werte aus Ihrer Einsatzumgebung.

Automatische SSL-Zertifikate mit Let’s Encrypt¶

Für den Fall, dass Sie automatisch generierte Let’s Encrypt SSL-Zertifikate auf der öffentlichen Installation verwenden möchten, müssen Sie einen Reverse-HTTPS-Proxy in einem zusätzlichen Docker-Container hinzufügen, https-portal wird dafür verwendet. Dieser wird in der Datei docker-compose-https.yml verwendet. Anschließend erstellen Sie eine Datei docker-compose-https.override.yml mit Ihren Einstellungen:

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'

Bei jedem Aufruf von docker compose müssen Sie beide Dateien übergeben und dann Folgendes tun:

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

Aktualisieren des Docker-Containers¶

Normalerweise ist es eine gute Idee, nur den Weblate-Container zu aktualisieren und den PostgreSQL-Container auf der vorhandenen Version zu belassen, da ein Upgrade von PostgreSQL ziemlich mühsam ist und in den meisten Fällen nicht viel bringt.

Geändert in Version 4.17-1: Seit Weblate 4.17-1 verwendet der Docker-Container Django 4.2, was PostgreSQL 12 oder neuer erfordert. Bitte aktualisieren Sie es vor dem Upgrade von Weblate. Siehe Aktualisieren des PostgreSQL-Containers.

Sie können dies tun, indem Sie das bestehende Docker-Compose beibehalten und einfach die neuesten Images ziehen und dann neu starten:

# 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

Die Weblate-Datenbank sollte beim ersten Start automatisch migriert werden, und es sollten keine weiteren manuellen Maßnahmen erforderlich sein.

Bemerkung

Upgrades über Hauptversionen hinweg werden von Weblate nicht unterstützt. Wenn Sie zum Beispiel mit der 3.x-Serie arbeiten und auf 4.x aktualisieren möchten, aktualisieren Sie zunächst auf das neueste 4.0.x-y-Image (zum Zeitpunkt der Erstellung dieses Artikels ist es das 4.0.4-5), das die Migration durchführt, und fahren Sie dann mit dem Upgrade auf neuere Versionen fort.

Sie können auch das docker-compose Repository aktualisieren, obwohl dies in den meisten Fällen nicht notwendig ist. Siehe Aktualisieren des PostgreSQL-Containers für die Aktualisierung des PostgreSQL-Servers.

Aktualisieren des PostgreSQL-Containers¶

PostgreSQL-Container unterstützen kein automatisches Upgrade zwischen Versionen, Sie müssen das Upgrade manuell durchführen. Die folgenden Schritte zeigen eine der Möglichkeiten des Upgrades.

Siehe auch

https://github.com/docker-library/postgres/issues/37

Weblate-Container stoppen:
```
docker compose stop weblate cache
```

Datenbank sichern:

docker compose exec database pg_dumpall --clean --if-exists --username weblate > backup.sql

Datenbank-Container sperren:
```
docker compose stop database
```
PostgreSQL-Volumen entfernen:
```
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
Hinweis

Der Volume-Name enthält den Namen des Docker-Compose-Projekts, der standardmäßig der Verzeichnisname ist, das in dieser Dokumentation weblate-docker heißt.
docker-compose.yml anpassen, um die neue PostgreSQL-Version zu verwenden.
Datenbank-Container öffnen:
```
docker compose up -d database
```
Datenbank aus Sicherung wiederherstellen:
```
cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate
```
Hinweis

Bitte prüfen Sie, ob der Datenbankname mit POSTGRES_DB übereinstimmt.
(Optional) Das Passwort für den Weblate-Benutzer aktualisieren. Dies kann bei der Migration auf PostgreSQL 14 oder 15 erforderlich sein, da die Art der Speicherung von Passwörtern geändert wurde:
```
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
Hinweis

Bitte prüfen Sie, ob der Datenbankname mit POSTGRES_DB übereinstimmt.
Alle verbleibenden Container öffnen:
```
docker compose up -d
```

Administratoranmeldung¶

Nach der Container-Einrichtung können Sie sich als Benutzer admin mit dem in WEBLATE_ADMIN_PASSWORD bereitgestellten Passwort oder, falls es nicht festgelegt wurde, mit einem beim ersten Öffnen generierten Zufallspasswort anmelden.

Um das Passwort für admin zurückzusetzen, öffnen Sie den Container mit dem in WEBLATE_ADMIN_PASSWORD neu festgelegten Passwort nochmals.

Siehe auch

WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

Anzahl der Prozesse und Speicherverbrauch¶

Die Anzahl der Worker-Prozesse wird sowohl für uWSGI als auch Celery automatisch auf Grundlage der Anzahl der CPUs bestimmt. Dies funktioniert für die meisten virtuellen Maschinen in der Cloud gut, da sie typischerweise wenig CPUs und große Speicherkapazitäten besitzen.

Für den Fall, dass Sie sehr viele CPU-Kerne haben und auf Speicherprobleme stoßen, versuchen Sie die Zahl der Worker zu reduzieren:

environment:
  WEBLATE_WORKERS: 2

Sie können auch einzelne Worker-Kategorien feinabstimmen:

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

Siehe auch

WEBLATE_WORKERS CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, UWSGI_WORKERS

Horizontale Skalierung¶

Added in version 4.6.

Sie können mehrere Weblate-Container ausführen, um den Dienst horizontal zu skalieren. Das Volume /app/data muss von allen Containern gemeinsam genutzt werden, es wird empfohlen, dafür ein Cluster-Dateisystem wie z. B. GlusterFS zu verwenden. Das Volume /app/cache sollte für jeden Container separat sein.

Jeder Weblate-Container hat eine definierte Rolle mit der Umgebungsvariablen WEBLATE_SERVICE. Bitte folgen Sie sorgfältig der Dokumentation, da einige der Dienste nur einmal im Cluster laufen sollen und auch die Reihenfolge der Dienste wichtig ist.

Eine Beispieleinrichtung finden Sie im docker-compose-Repo als docker-compose-split.yml.

Docker-Umgebungsvariablen¶

Vieles von der Weblate-Konfiguration kann mit den unten beschriebenen Umgebungsvariablen im Docker-Container eingestellt werden.

Wenn Sie eine Einstellung definieren müssen, die nicht über Docker-Umgebungsvariablen zugänglich ist, siehe Konfiguration über Umgebungsvariablen hinaus.

Geheimnisse weitergeben¶

Added in version 5.0.

Der Weblate-Container unterstützt die Weitergabe von Geheimnissen als Dateien. Um dies zu nutzen, hängen Sie das Suffix _FILE an die Umgebungsvariable an und übergeben Sie die geheime Datei über Docker.

Die zugehörige docker-compose.yml könnte so aussehen:

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

Siehe auch

Wie man Geheimnisse in Docker Compose verwendet

Allgemeine Einstellungen¶

WEBLATE_DEBUG¶

Konfiguriert den Debugmodus von Django mit DEBUG.

Beispiel:

environment:
  WEBLATE_DEBUG: 1

Siehe auch

Debugmodus deaktivieren

WEBLATE_LOGLEVEL¶

Legt die Ausführlichkeit der Protokollierung fest. Auf DEBUG setzen, um ausführlichere Protokolle zu erhalten.

Der Standardwert ist INFO wenn WEBLATE_DEBUG ausgeschaltet ist, DEBUG wird verwendet, wenn der Debugmodus eingeschaltet ist.

Für eine ruhigere Protokollierung ERROR oder WARNING verwenden.

WEBLATE_LOGLEVEL_DATABASE¶: Konfiguriert die Protokollierung der Ausführlichkeit der Datenbankabfragen.

WEBLATE_SITE_TITLE¶: Ändert den Seitentitel, der in der Kopfzeile aller Seiten angezeigt wird.

WEBLATE_SITE_DOMAIN¶: Konfiguriert die Seitendomain. Dieser Parameter ist erforderlich.

Siehe auch

Seitendomain richtig einstellen, SITE_DOMAIN

WEBLATE_ADMIN_NAME¶

WEBLATE_ADMIN_EMAIL¶

Legt den Namen und die E-Mail des Website-Administrators fest. Es wird sowohl für die ADMINS-Einstellung als auch für die Erstellung des admin-Benutzers verwendet (siehe WEBLATE_ADMIN_PASSWORD für weitere Informationen dazu).

Beispiel:

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

Siehe auch

Administratoranmeldung, Administratoren richtig konfigurieren, ADMINS

WEBLATE_ADMIN_PASSWORD¶

Setzt das Passwort für den Benutzer admin.

Wenn nicht gesetzt und der Benutzer admin nicht existiert, wird er mit einem zufälligen Passwort erstellt, das beim ersten Start des Containers angezeigt wird.
Wenn nicht gesetzt und der Benutzer admin existiert, wird keine Aktion durchgeführt.
Wenn gesetzt, wird der admin-Benutzer bei jedem Start des Containers angepasst, um WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME und WEBLATE_ADMIN_EMAIL zu entsprechen.

Warnung

Es könnte ein Sicherheitsrisiko darstellen, das Passwort in der Konfigurationsdatei zu speichern. Erwägen Sie, diese Variable nur für die Ersteinrichtung zu verwenden (oder lassen Sie Weblate beim ersten Start ein zufälliges Passwort generieren) oder für die Wiederherstellung des Passworts.

Siehe auch

Administratoranmeldung, Geheimnisse weitergeben, WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

WEBLATE_SERVER_EMAIL¶: Die E-Mail-Adresse, von der aus Fehlermeldungen gesendet werden.

Siehe auch

SERVER_EMAIL, E-Mail-Versand konfigurieren

WEBLATE_DEFAULT_FROM_EMAIL¶: Legt die Adresse für ausgehende E-Mails fest.

Siehe auch

DEFAULT_FROM_EMAIL, E-Mail-Versand konfigurieren

WEBLATE_ADMINS_CONTACT¶: Konfiguriert ADMINS_CONTACT.

WEBLATE_CONTACT_FORM¶: Konfiguriert das Verhalten des Kontaktformulars, siehe CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS¶

Konfiguriert erlaubte HTTP-Hostnamen mit ALLOWED_HOSTS.

Der Standardwert ist *, der alle Hostnamen zulässt.

Beispiel:

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

Siehe auch

ALLOWED_HOSTS, Einrichtung zulässiger Hosts, Seitendomain richtig einstellen

WEBLATE_REGISTRATION_OPEN¶

Legt fest, ob Registrierungen offen sind, durch Umschaltung von REGISTRATION_OPEN.

Beispiel:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS¶

Konfiguriert, welche Authentifizierungsmethoden zum Erstellen eines neuen Kontos verwendet werden können, über REGISTRATION_ALLOW_BACKENDS.

Beispiel:

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

WEBLATE_REGISTRATION_REBIND¶: Added in version 4.16.

Konfiguriert REGISTRATION_REBIND.

WEBLATE_TIME_ZONE¶

Konfiguriert die verwendete Zeitzone in Weblate, siehe TIME_ZONE.

Bemerkung

Um die Zeitzone des Docker-Containers selbst zu ändern, die Umgebungsvariable TZ verwenden.

Beispiel:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague

WEBLATE_ENABLE_HTTPS¶

Lässt Weblate davon ausgehen, dass es hinter einem Reverse-HTTPS-Proxy betrieben wird, und bringt Weblate dazu, HTTPS in E-Mails und API-Links zu verwenden oder sichere Markierungen für Cookies zu setzen.

Hinweis

Bitte lesen Sie die ENABLE_HTTPS-Dokumentation für mögliche Vorsichtsmaßnahmen.

Bemerkung

Dies führt nicht dazu, dass der Weblate-Container HTTPS-Verbindungen akzeptiert. Sie müssen dies ebenfalls konfigurieren, siehe Docker-Container mit HTTPS-Unterstützung für Beispiele.

Beispiel:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Siehe auch

ENABLE_HTTPS Seitendomain richtig einstellen, WEBLATE_SECURE_PROXY_SSL_HEADER

WEBLATE_INTERLEDGER_PAYMENT_POINTERS¶: Added in version 4.12.1.

Lässt Weblate das Feld meta[name=monetization] im Kopf des Dokuments setzen. Wenn mehrere angegeben sind, wird eines zufällig ausgewählt.

Siehe auch

INTERLEDGER_PAYMENT_POINTERS

WEBLATE_IP_PROXY_HEADER¶

Ermöglicht es Weblate, die IP-Adresse aus einem beliebigen HTTP-Header zu holen. Verwenden Sie dies, wenn Sie einen Reverse-Proxy vor dem Weblate-Container einsetzen.

Aktiviert IP_BEHIND_REVERSE_PROXY und setzt IP_PROXY_HEADER.

Bemerkung

Das Format muss mit den Erwartungen von Django übereinstimmen. Django wandelt rohe HTTP-Header-Namen wie folgt um:

wandelt alle Zeichen in Großbuchstaben um
ersetzt alle Bindestriche durch Unterstriche
stellt den``HTTP_`` Präfix voran

So würde X-Forwarded-For auf HTTP_X_FORWARDED_FOR abgebildet werden.

Beispiel:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

WEBLATE_IP_PROXY_OFFSET¶: Added in version 5.0.1.

Konfiguriert IP_PROXY_OFFSET.

WEBLATE_USE_X_FORWARDED_PORT¶: Added in version 5.0.1.

Ein boolescher Wert, der angibt, ob der X-Forwarded-Port-Header anstelle der SERVER_PORT META-Variable verwendet werden soll. Dies sollte nur aktiviert werden, wenn ein Proxy verwendet wird, der diesen Header setzt.

Siehe auch

USE_X_FORWARDED_PORT

Bemerkung

Dies ist eine boolesche Einstellung ("true" oder "false" verwenden).

WEBLATE_SECURE_PROXY_SSL_HEADER¶

Ein Tupel, das eine HTTP-Header/Wert-Kombination darstellt, die bedeutet, dass eine Anfrage sicher ist. Dies wird benötigt, wenn Weblate hinter einem Reverse-Proxy läuft, der die SSL-Terminierung durchführt und keine Standard-HTTPS-Header weitergibt.

Beispiel:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Siehe auch

SECURE_PROXY_SSL_HEADER

WEBLATE_REQUIRE_LOGIN¶

Aktiviert REQUIRE_LOGIN, um die Authentifizierung auf dem gesamten Weblate zu erzwingen.

Beispiel:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

Fügt URL-Ausnahmen für die Authentifizierung hinzu, die für die gesamte Weblate-Installation durch LOGIN_REQUIRED_URLS_EXCEPTIONS erforderlich sind.

Sie können entweder ganze Einstellungen ersetzen oder den Standardwert mittels der Variablen ADD und REMOVE ändern.

Um die Authentifizierung für das Kontaktformular zu erzwingen, tun Sie dies:

environment:
  WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$

WEBLATE_GOOGLE_ANALYTICS_ID¶: Konfiguriert die ID für Google Analytics durch Ändern von GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE¶: Konfiguriert den Standardtitel und die Nachricht für Pull Requests über die API durch Ändern von DEFAULT_PULL_MESSAGE

Siehe auch

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES¶: Konfiguriert die Richtlinie zur Sprachvereinfachung, siehe SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL¶: Konfiguriert die standardmäßige Zugriffssteuerung für neue Projekte, siehe DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT¶: Legt den Standardwert für Eingeschränkter Zugriff für neue Komponenten fest, siehe DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION¶: Legt den Standardwert für Weitergabe von Übersetzungen erlauben für neue Komponenten fest, siehe DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL¶: Konfiguriert DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME¶: Konfiguriert DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM¶: Konfiguriert DEFAULT_SHARED_TM.

WEBLATE_AKISMET_API_KEY¶: Konfiguriert den Akismet-API-Schlüssel, siehe AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY¶: Konfiguriert die GPG-Signierung von Commits, siehe WEBLATE_GPG_IDENTITY.

Siehe auch

Git-Commits mit GnuPG signieren

WEBLATE_URL_PREFIX¶: Konfiguriert den URL-Präfix, unter dem Weblate läuft, siehe URL_PREFIX.

WEBLATE_SILENCED_SYSTEM_CHECKS¶: Konfiguriert Prüfungen, die nicht angezeigt werden sollen, siehe SILENCED_SYSTEM_CHECKS.

WEBLATE_CSP_SCRIPT_SRC¶

WEBLATE_CSP_IMG_SRC¶

WEBLATE_CSP_CONNECT_SRC¶

WEBLATE_CSP_STYLE_SRC¶

WEBLATE_CSP_FONT_SRC¶: Ermöglicht die Anpassung des HTTP-Headers Content-Security-Policy.

Siehe auch

Richtlinie zur Inhaltssicherheit, CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC

WEBLATE_LICENSE_FILTER¶: Konfiguriert LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED¶: Konfiguriert LICENSE_REQUIRED

WEBLATE_WEBSITE_REQUIRED¶: Konfiguriert WEBSITE_REQUIRED

WEBLATE_HIDE_VERSION¶: Konfiguriert HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES¶: Konfiguriert BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH¶: Konfiguriert DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS¶

WEBLATE_RATELIMIT_LOCKOUT¶

WEBLATE_RATELIMIT_WINDOW¶: Added in version 4.6.

Konfiguriert den Ratenbegrenzer.

Hinweis

Sie können die Konfiguration für beliebige Ratenbegrenzer-Bereiche festlegen. Fügen Sie dazu das Präfix WEBLATE_ zu einer der in Ratenbegrenzung beschriebenen Einstellungen hinzu.

Siehe auch

Ratenbegrenzung, RATELIMIT_ATTEMPTS, RATELIMIT_WINDOW, RATELIMIT_LOCKOUT

WEBLATE_API_RATELIMIT_ANON¶

WEBLATE_API_RATELIMIT_USER¶: Added in version 4.11.

Konfiguriert die API-Ratenbegrenzung. Der Standardwert ist 100/day für anonyme und 5000/hour für authentifizierte Benutzer.

Siehe auch

API-Ratenbegrenzung

WEBLATE_ENABLE_HOOKS¶: Added in version 4.13.

Konfiguriert ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS¶: Added in version 4.6.1.

Konfiguriert ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX¶: Added in version 4.15.

Konfiguriert AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶: Added in version 4.9.

Konfiguriert LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS¶: Added in version 4.9.

Konfiguriert SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS¶

Added in version 4.9.

Konfiguriert BORG_EXTRA_ARGS als komma-getrennte Liste von Argumenten.

Beispiel:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/

WEBLATE_ENABLE_SHARING¶: Added in version 4.14.1.

Konfiguriert ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK¶: Added in version 5.5.

Configures SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD¶: Added in version 4.15.

Konfiguriert EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶: Added in version 4.15.

Konfiguriert PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶: Added in version 4.15.

Konfiguriert PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS¶: Added in version 4.17.

Konfiguriert UNUSED_ALERT_DAYS.

WEBLATE_CORS_ALLOWED_ORIGINS¶

Added in version 4.16.

Lässt CORS-Anfragen von bestimmten Quellen zu.

Beispiel:

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

CLIENT_MAX_BODY_SIZE¶

Added in version 4.16.3.

Konfiguriert die maximale Body Size, die der integrierte Webserver akzeptiert.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Hinweis

Dieser Variable fehlt absichtlich das Präfix WEBLATE_, da sie mit dem in Automatische SSL-Zertifikate mit Let’s Encrypt verwendeten Container eines Drittanbieters geteilt wird.

Anmeldedaten für Code-Hosting-Sites¶

Im Docker-Container können die Zugangsdaten für das Code-Hosting entweder in separaten Variablen konfiguriert werden oder mit einem Python-Wörterbuch auf einmal festgelegt werden. Die folgenden Beispiele sind für GitHub-Pull-Requests, gelten aber auch für die Integration der Versionsverwaltung mit entsprechend geänderten Variablennamen.

Eine Beispielkonfiguration für GitHub könnte wie folgt aussehen:

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

Wird verwendet als:

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

Alternativ kann das Python-Wörterbuch auch als Zeichenkette angegeben werden:

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

Oder den Pfad zu einer Datei, die das Python-Wörterbuch enthält:

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¶: Konfiguriert GitHub-Pull-Requests durch Ändern von GITHUB_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_GITLAB_USERNAME¶

WEBLATE_GITLAB_TOKEN¶

WEBLATE_GITLAB_HOST¶

WEBLATE_GITLAB_CREDENTIALS¶: Konfiguriert GitLab-Merge-Requests durch Ändern von GITLAB_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_GITEA_USERNAME¶

WEBLATE_GITEA_TOKEN¶

WEBLATE_GITEA_HOST¶

WEBLATE_GITEA_CREDENTIALS¶: Konfiguriert Gitea-Pull-Requests durch Ändern von GITEA_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_PAGURE_USERNAME¶

WEBLATE_PAGURE_TOKEN¶

WEBLATE_PAGURE_HOST¶

WEBLATE_PAGURE_CREDENTIALS¶: Konfiguriert Pagure-Merge-Requests durch Ändern von PAGURE_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_BITBUCKETSERVER_USERNAME¶

WEBLATE_BITBUCKETSERVER_TOKEN¶

WEBLATE_BITBUCKETSERVER_HOST¶

WEBLATE_BITBUCKETSERVER_CREDENTIALS¶: Konfiguriert Bitbucket-Server-Pull-Request durch Ändern von BITBUCKETSERVER_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_AZURE_DEVOPS_USERNAME¶

WEBLATE_AZURE_DEVOPS_ORGANIZATION¶

WEBLATE_AZURE_DEVOPS_TOKEN¶

WEBLATE_AZURE_DEVOPS_HOST¶

WEBLATE_AZURE_DEVOPS_CREDENTIALS¶: Konfiguriert Azure-DevOps-Pull-Request durch Ändern von AZURE_DEVOPS_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

Automatische Vorschlagseinstellungen¶

Geändert in Version 4.13: Automatische Vorschlagsdienste werden jetzt in der Bedienoberfläche konfiguriert, siehe Automatische Vorschläge.

Die vorhandenen Umgebungsvariablen werden bei der Migration auf Weblate 4.13 importiert, sie zu ändern hat jedoch keine weiteren Auswirkungen.

Authentifizierungseinstellungen¶

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¶

WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER¶

Konfiguration der LDAP-Authentifizierung.

Beispiel für direkte Bindung:

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

Beispiel für Suche und Bindung:

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

Beispiel für Vereinigungssuche und Bindung:

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

Beispiel mit Suche und Bindung gegen 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)

Siehe auch

Geheimnisse weitergeben, LDAP-Authentifizierung

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¶: Aktiviert GitHub-Authentifizierung.

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¶: Aktiviert GitHub-EE-Authentifizierung.

Bitbucket¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET¶: Aktiviert Bitbucket-Authentifizierung.

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Aktiviert 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¶: Aktiviert Google OAuth 2.

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: Aktiviert GitLab OAuth 2.

Gitea¶

WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶

WEBLATE_SOCIAL_AUTH_GITEA_KEY¶

WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶: Aktiviert die Gitea-Authentifizierung.

Azure Active Directory¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Aktiviert die Azure Active Directory-Authentifizierung, siehe Microsoft Azure Active Directory.

Azure Active Directory mit Mandantenunterstützung¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶: Aktiviert die Azure Active Directory-Authentifizierung mit Mandantenunterstützung, siehe 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¶: Aktiviert die Keycloak-Authentifizierung, siehe Dokumentation.

Linux-Anbieter¶

Sie können die Authentifizierung über die Authentifizierungsdienste von Linux-Anbietern aktivieren, indem Sie die folgenden Variablen auf einen beliebigen Wert setzen.

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¶: Aktiviert die Slack-Authentifizierung, siehe 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¶: Konfiguriert die allgemeine OpenID Connect-Integration.

Siehe auch

OIDC (OpenID Connect)

SAML¶

Selbstsignierte SAML-Schlüssel werden beim ersten Start des Containers automatisch erzeugt. Wenn Sie eigene Schlüssel verwenden möchten, legen Sie das Zertifikat und den privaten Schlüssel in /app/data/ssl/saml.crt und /app/data/ssl/saml.key ab.

WEBLATE_SAML_IDP_ENTITY_ID¶

WEBLATE_SAML_IDP_URL¶

WEBLATE_SAML_IDP_X509CERT¶

WEBLATE_SAML_IDP_IMAGE¶

WEBLATE_SAML_IDP_TITLE¶: SAML-Identitätsanbietereinstellungen, siehe SAML-Authentifizierung.

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-Attribut-Zuordnung.

Weitere Authentifizierungseinstellungen¶

WEBLATE_NO_EMAIL_AUTH¶: Deaktiviert die E-Mail-Authentifizierung, wenn auf einen beliebigen Wert gesetzt. Siehe Passwort-Authentifizierung deaktivieren.

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.

Einrichtung der PostgreSQL-Datenbank¶

Die Datenbank wird von docker-compose.yml erstellt, daher betreffen diese Einstellungen sowohl Weblate- als auch PostgreSQL-Container.

Siehe auch

Datenbankeinrichtung für Weblate

POSTGRES_PASSWORD¶: PostgreSQL-Passwort.

Siehe auch

Geheimnisse weitergeben

POSTGRES_USER¶: PostgreSQL-Benutzername.

POSTGRES_DB¶: PostgreSQL-Datenbankname.

POSTGRES_HOST¶: Hostname oder IP-Adresse des PostgreSQL-Servers. Der Standardwert ist database.

POSTGRES_PORT¶: PostgreSQL-Serverport. Der Standardwert ist none (verwendet den Standardwert).

POSTGRES_SSL_MODE¶: Konfiguriert, wie PostgreSQL SSL bei der Verbindung zum Server handhabt, für mögliche Auswahlen siehe SSL Mode Descriptions

POSTGRES_ALTER_ROLE¶: Konfiguriert den Namen der Rolle, der bei Migrationen geändert werden soll, siehe Weblate für die Verwendung von PostgreSQL konfigurieren.

POSTGRES_CONN_MAX_AGE¶

Added in version 4.8.1.

Die Lebensdauer einer Datenbankverbindung, als ganze Zahl von Sekunden. 0 verwenden, um Datenbankverbindungen am Ende jeder Anfrage zu schließen.

Geändert in Version 5.1: Das Standardverhalten ist eine unbegrenzte Anzahl von dauerhaften Datenbankverbindungen.

Die Aktivierung der Verbindungsaufrechterhaltung führt normalerweise zu mehr offenen Verbindungen zur Datenbank. Bitte passen Sie Ihre Datenbankkonfiguration vor der Aktivierung an.

Beispielkonfiguration:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Siehe auch

CONN_MAX_AGE, Persistent connections

POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶

Added in version 4.9.1.

Deaktiviert serverseitige Cursor in der Datenbank. Dies ist bei einigen pgbouncer-Einrichtungen notwendig.

Beispielkonfiguration:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Siehe auch

DISABLE_SERVER_SIDE_CURSORS, Transaction pooling and server-side cursors

WEBLATE_DATABASES¶: Added in version 5.1.

Diesen Wert auf false setzen, um die umgebungsbasierte Konfiguration der Datenbankverbindung zu deaktivieren. Überschreiben von Einstellungen des Daten-Volumes verwenden, um die Datenbankverbindung manuell zu konfigurieren.

MySQL- oder MariaDB-Server¶

Weder MySQL noch MariaDB können über Umgebungsvariablen konfiguriert werden. Siehe MySQL und MariaDB für Informationen zur Verwendung dieser Variablen mit Weblate. WEBLATE_DATABASES verwenden, um die Datenbankverbindung manuell zu konfigurieren.

Datenbanksicherung einstellen¶

Siehe auch

Ausgegebene Daten für Sicherungen

WEBLATE_DATABASE_BACKUP¶: Konfiguriert den täglichen Datenbankauszug mit DATABASE_BACKUP. Die Voreinstellung ist plain.

Caching-Server einrichten¶

Die Verwendung von Redis wird von Weblate dringend empfohlen und Sie müssen eine Redis-Instanz bereitstellen, wenn Sie Weblate in Docker ausführen.

Siehe auch

Caching einschalten

REDIS_HOST¶: Der Hostname oder die IP-Adresse des Redis-Servers. Der Standardwert ist cache.

REDIS_PORT¶: Der Port des Redis-Servers. Der Standardwert ist 6379.

REDIS_DB¶: Die Nummer der Redis-Datenbank, standardmäßig 1.

REDIS_PASSWORD¶: Das Redis Server-Passwort, nicht standardmäßig verwendet.

Siehe auch

Geheimnisse weitergeben

REDIS_TLS¶: Ermöglicht die Verwendung von SSL für Redis-Verbindungen.

REDIS_VERIFY_SSL¶: Kann verwendet werden, um die SSL-Zertifikatsüberprüfung für Redis-Verbindungen zu deaktivieren.

E-Mail-Server einrichten¶

Damit ausgehende E-Mails funktionieren, müssen Sie einen Mailserver bereitstellen.

Beispiel für eine TLS-Konfiguration:

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

Beispiel für eine SSL-Konfiguration:

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

Siehe auch

Ausgehende E-Mails konfigurieren

WEBLATE_EMAIL_HOST¶: Hostname oder IP-Adresse des Mailservers.

Siehe auch

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_SSL, WEBLATE_EMAIL_USE_TLS, EMAIL_HOST

WEBLATE_EMAIL_PORT¶: Mailserver-Port, standardmäßig 25.

Siehe auch

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: Benutzer der E-Mail-Authentifizierung.

Siehe auch

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶: Passwort für die E-Mail-Authentifizierung.

Siehe auch

Geheimnisse weitergeben, EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_USE_SSL¶: Ob eine implizite (sichere) TLS-Verbindung für die Kommunikation mit dem SMTP-Server verwendet werden soll. In den meisten E-Mail-Dokumentationen wird diese Art der TLS-Verbindung als SSL bezeichnet. Sie wird im Allgemeinen auf Port 465 eingesetzt. Wenn Sie Probleme haben, sehen Sie sich die explizite TLS-Einstellung WEBLATE_EMAIL_USE_TLS an.

Geändert in Version 4.11: Die SSL/TLS-Unterstützung wird automatisch auf der Grundlage des WEBLATE_EMAIL_PORT aktiviert.

Siehe auch

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_TLS, EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS¶: Ob eine (sichere) TLS-Verbindung verwendet werden soll, wenn mit dem SMTP-Server kommuniziert wird. Dies wird für explizite TLS-Verbindungen verwendet, im Allgemeinen auf Port 587 oder 25. Wenn Sie feststellen, dass Verbindungen hängen bleiben, sehen Sie sich die implizite TLS-Einstellung WEBLATE_EMAIL_USE_SSL an.

Geändert in Version 4.11: Die SSL/TLS-Unterstützung wird automatisch auf der Grundlage des WEBLATE_EMAIL_PORT aktiviert.

Siehe auch

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_SSL, EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND¶: Konfiguriert das Django-Backend, das für den Versand von E-Mails verwendet werden soll.

Siehe auch

E-Mail-Versand konfigurieren, EMAIL_BACKEND

WEBLATE_AUTO_UPDATE¶: Konfiguriert, ob und wie Weblate Repositorys aktualisieren soll.

Siehe auch

AUTO_UPDATE

Bemerkung

Dies ist eine boolesche Einstellung ("true" oder "false" verwenden).

Integration der Website¶

WEBLATE_GET_HELP_URL¶: Konfiguriert GET_HELP_URL.

WEBLATE_STATUS_URL¶: Konfiguriert STATUS_URL.

WEBLATE_LEGAL_URL¶: Konfiguriert LEGAL_URL.

WEBLATE_PRIVACY_URL¶: Konfiguriert PRIVACY_URL.

Sammeln von Fehlerberichten und Überwachen der Leistung¶

Es wird empfohlen, Fehler bei der Installation systematisch zu sammeln, siehe Sammeln von Fehlerberichten und Überwachen der Leistung.

Um die Unterstützung für Rollbar zu aktivieren, stellen Sie Folgendes ein:

ROLLBAR_KEY¶: Ihr Rollbar-Postserver-Zugangstoken.

ROLLBAR_ENVIRONMENT¶: Ihre Rollbar-Umgebung, standardmäßig production.

Um die Unterstützung für Sentry zu aktivieren, stellen Sie Folgendes ein:

SENTRY_DSN¶: Ihr Sentry-DSN, siehe SENTRY_DSN.

SENTRY_ENVIRONMENT¶: Ihre Sentry-Umgebung (optional), standardmäßig WEBLATE_SITE_DOMAIN.

SENTRY_TRACES_SAMPLE_RATE¶

Konfiguriert die Abtastrate für die Leistungsüberwachung. Auf 1 setzen, um alle Ereignisse zu verfolgen, 0 (Standard) deaktiviert die Verfolgung.

Beispiel:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5

Siehe auch

Sentry-Leistungsüberwachung,

SENTRY_PROFILES_SAMPLE_RATE¶

Konfiguriert die Abtastrate für die Profilüberwachung. Auf 1 setzen, um alle Ereignisse zu verfolgen, 0 (Standard) deaktiviert die Verfolgung.

Beispiel:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5

Siehe auch

Sentry-Profiling

SENTRY_SEND_PII¶: Konfiguriert SENTRY_SEND_PII.

Lokalisierungs-CDN¶

WEBLATE_LOCALIZE_CDN_URL¶

WEBLATE_LOCALIZE_CDN_PATH¶

Added in version 4.2.1.

Konfiguration für JavaScript-Lokalisierungs-CDN.

Der WEBLATE_LOCALIZE_CDN_PATH ist ein Pfad innerhalb des Containers. Er sollte auf dem dauerhaften Volume und nicht im flüchtigen Speicher gespeichert werden.

Eine der Möglichkeiten ist die Speicherung im Weblate-Datenverzeichnis:

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

Bemerkung

Sie sind für die Einrichtung der Bereitstellung der von Weblate erzeugten Dateien verantwortlich, es speichert nur die Dateien am konfigurierten Speicherort.

Siehe auch

HTML und JavaScript mit Weblate CDN übersetzen, LOCALIZE_CDN_URL, LOCALIZE_CDN_PATH

Ändern aktivierter Apps, Qualitätsprüfungen, Erweiterungen oder Autofixes¶

Die integrierte Konfiguration der aktivierten Qualitätsprüfungen, Erweiterungen oder Autofixes kann durch die folgenden Variablen angepasst werden:

WEBLATE_ADD_APPS¶

WEBLATE_REMOVE_APPS¶

WEBLATE_ADD_CHECK¶

WEBLATE_REMOVE_CHECK¶

WEBLATE_ADD_AUTOFIX¶

WEBLATE_REMOVE_AUTOFIX¶

WEBLATE_ADD_ADDONS¶

WEBLATE_REMOVE_ADDONS¶

Beispiel:

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

Siehe auch

CHECK_LIST, AUTOFIX_LIST, WEBLATE_ADDONS, INSTALLED_APPS

Container-Einstellungen¶

WEBLATE_WORKERS¶

Added in version 4.6.1.

Basisanzahl der im Container laufenden Worker-Prozesse. Wenn sie nicht festgelegt ist, wird sie automatisch beim Start des Containers anhand der Anzahl der verfügbaren CPU-Kerne ermittelt.

Wird zur Bestimmung von CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS und WEB_WORKERS verwendet. Sie können diese Einstellungen zur Feinabstimmung nutzen.

CELERY_MAIN_OPTIONS¶

CELERY_NOTIFY_OPTIONS¶

CELERY_MEMORY_OPTIONS¶

CELERY_TRANSLATE_OPTIONS¶

CELERY_BACKUP_OPTIONS¶

CELERY_BEAT_OPTIONS¶

Mit diesen Variablen können die Celery-Worker-Optionen angepasst werden. Es kann nützlich sein, die Parallelität anzupassen (--concurrency 16) oder eine andere Pool-Implementierung zu verwenden (--pool=gevent).

Standardmäßig basiert die Anzahl der gleichzeitigen Worker auf WEBLATE_WORKERS.

Beispiel:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Siehe auch

Celery-Worker-Optionen, Hintergrundaufgaben mit Celery

WEB_WORKERS¶

Konfiguriert, wie viele uWSGI-Worker ausgeführt werden sollen.

Der Standardwert ist WEBLATE_WORKERS.

Beispiel:

environment:
  WEB_WORKERS: 32

WEBLATE_SERVICE¶

Legt fest, welche Dienste innerhalb des Containers ausgeführt werden sollen. Verwenden Sie dies für Horizontale Skalierung.

Folgende Dienste sind definiert:

celery-beat: Celery-Aufgabenplaner, es sollte nur eine Instanz ausgeführt werden. Dieser Container ist auch für die Migrationen der Datenbankstruktur zuständig und sollte vor den anderen gestartet werden.
celery-backup: Celery-Worker für Sicherungen, es sollte nur eine Instanz laufen.
celery-celery: Allgemeiner Celery-Worker.
celery-memory: Übersetzungsspeicher Celery-Worker.
celery-notify: Benachrichtigungen Celery-Worker.
celery-translate: Automatische Übersetzung Celery-Worker.
web: Webserver.

Docker-Container-Volumes¶

Es gibt zwei Volumes (Daten und Cache), die vom Weblate-Container exportiert werden. Die anderen Service-Container (PostgreSQL oder Redis) verfügen ebenfalls über Datenvolumina, die jedoch in diesem Dokument nicht behandelt werden.

Das Daten-Volume wird verwendet, um dauerhafte Weblate-Daten wie geklonte Repositorys zu speichern oder die Weblate-Installation anzupassen.

Die Platzierung des Docker-Volumes auf dem Host-System hängt von Ihrer Docker-Konfiguration ab, aber normalerweise wird es in /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ gespeichert (der Pfad besteht aus dem Namen Ihres Docker-Compose-Verzeichnisses, dem Container und den Volume-Namen). Im Container wird es als /app/data eingehängt.

Das Cache-Volume wird als /app/cache gemountet und dient zum Speichern von statischen Dateien und CACHE_DIR. Sein Inhalt wird beim Start des Containers neu erstellt und das Volume kann mit einem ephemeren Dateisystem wie tmpfs eingebunden werden.

Wenn Sie die Volumes manuell erstellen, sollten die Verzeichnisse der UID 1000 gehören, da dies der im Container verwendete Benutzer ist.

Siehe auch

Dokumentation der Docker-Volumes

Schreibgeschütztes Root-Dateisystem¶

Added in version 4.18.

Wenn der Container mit einem schreibgeschützten Root-Dateisystem läuft, werden zwei zusätzliche tmpfs-Volumes benötigt - /tmp und /run.

Konfiguration über Umgebungsvariablen hinaus¶

Docker-Umgebungsvariablen sind dazu gedacht, die meisten Konfigurationseinstellungen, die für Weblate-Installationen von Bedeutung sind, sichtbar zu machen.

Wenn Sie eine Einstellung finden, die nicht als Umgebungsvariable verfügbar ist und Sie glauben, dass sie es sein sollte, können Sie fordern, dass sie in einer zukünftigen Version von Weblate verfügbar gemacht wird.

Wenn Sie eine Einstellung ändern müssen, die nicht als Docker-Umgebungsvariable verfügbar ist, können Sie dies trotzdem tun, entweder über das Daten-Volume oder durch Erweitern des Docker-Images.

Siehe auch

Weblate anpassen

Überschreiben von Einstellungen des Daten-Volumes¶

Sie können eine Datei unter /app/data/settings-override.py erstellen, d. h. in der Wurzel des Daten-Volume, um Einstellungen zu erweitern oder zu überschreiben, die durch Umgebungsvariablen definiert wurden.

Überschreiben von Einstellungen durch Erweitern des Docker-Images¶

Um Einstellungen auf der Ebene des Docker-Images statt des Daten-Volumes zu überschreiben:

Ein benutzerdefiniertes Python-Paket erstellen.
Ein Modul zum eigenen Paket hinzufügen, das alle Einstellungen von weblate.settings_docker importiert.

Innerhalb der Beispiel-Paketstruktur, die unter Erstellen eines Python-Moduls definiert ist, kann zum Beispiel eine Datei unter weblate_customization/weblate_customization/settings.py mit dem folgenden Anfangscode erstellt werden:
```
from weblate.settings_docker import *
```

Ein benutzerdefiniertes Dockerfile erstellen, das vom offiziellen Weblate-Docker-Image erbt, und dann das Paket installiert und die Umgebungsvariable DJANGO_SETTINGS_MODULE auf das Einstellungsmodul verweist:

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

Anstatt das offizielle Weblate-Docker-Image zu verwenden, sollte ein eigenes Image aus dieser Dockerfile-Datei erstellt werden.

Es gibt keine saubere Möglichkeit, dies mit docker-compose.override.yml zu tun. Sie könnten build: . zum weblate-Knoten in dieser Datei hinzufügen, aber dann wird Ihr benutzerdefiniertes Image als weblate/weblate in Ihrem System markiert, was problematisch sein könnte.

Anstatt also docker-compose.yml direkt unverändert aus dem offiziellen Repository zu verwenden und es durch docker-compose.override.yml zu erweitern, sollten Sie eine Kopie der offiziellen docker-compose.yml Datei erstellen und diese Kopie so bearbeiten, dass image: weblate/weblate durch build: . ersetzt wird.

Weitere Informationen zum Erstellen von Images aus der Quelle bei Verwendung von docker-compose finden Sie in der Compose-Datei-Build-Referenz.
Das eigene Einstellungsmodul erweitern, um Einstellungen zu definieren oder neu zu definieren.

Es können Einstellungen vor oder nach der obigen Importanweisung definiert werden, um festzulegen, welche Einstellungen Vorrang haben. Einstellungen, die vor der Importanweisung definiert wurden, können durch Umgebungsvariablen und die im Data-Volume definierte Einstellungsüberschreibungen überschrieben werden. Einstellungen, die nach der Importanweisung definiert werden, können nicht überschrieben werden.

Sie können auch noch weiter gehen. Zum Beispiel können Sie einige der Dinge reproduzieren, die weblate.docker_settings tut , wie z. B. Einstellungen als Umgebungsvariablen offenlegen oder das Überschreiben von Einstellungen aus Python-Dateien im Daten-Volume erlauben.

Ersetzen des Logos und anderer statischer Dateien¶

Die mit Weblate gelieferten statischen Dateien können überschrieben werden, indem sie in /app/data/python/customize/static abgelegt werden (siehe Docker-Container-Volumes). Zum Beispiel wird durch die Erstellung von /app/data/python/customize/static/favicon.ico das Favicon ersetzt.

Hinweis

Die Dateien werden beim Start des Containers an den entsprechenden Ort kopiert, so dass ein Neustart von Weblate erforderlich ist, wenn der Inhalt des Volumes geändert wurde.

Dieser Ansatz kann auch verwendet werden, um Weblate-Vorlagen außer Kraft zu setzen. Zum Beispiel können Rechtliche Grundlagen-Dokumente in /app/data/python/customize/templates/legal/documents platziert werden.

Alternativ können Sie auch ein eigenes Modul einbinden (siehe Weblate anpassen) und es zum Beispiel als separates Volume dem Docker-Container hinzufügen:

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

Konfigurieren des PostgreSQL-Servers¶

Der PostgreSQL-Container verwendet die Standardkonfiguration von PostgreSQL, welche die CPU-Kerne und den Speicher nicht effektiv nutzt. Es wird empfohlen, die Konfiguration anzupassen, um die Leistung zu verbessern.

Die Konfiguration kann wie in Datenbankkonfiguration unter https://hub.docker.com/_/postgres beschrieben angepasst werden. Die für Ihre Einsatzumgebung passende Konfiguration kann mit https://pgtune.leopard.in.ua/ erzeugt werden.

Container-Interna¶

Der Container verwendet supervisor, um einzelne Dienste zu starten. Im Falle von Horizontale Skalierung wird nur ein einzelner Dienst in einem Container gestartet.

Um den Servicestatus zu überprüfen, verwenden Sie:

docker compose exec --user weblate weblate supervisorctl status

Für jede Celery-Warteschlange gibt es eigene Dienste (siehe Hintergrundaufgaben mit Celery für Details). Die Verarbeitung einiger Aufgaben kann durch das Anhalten der entsprechenden Worker gestoppt werden:

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