Installation über Docker#
Mit der Bereitstellung von Weblate per 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 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.
Dies hat schwerwiegende Auswirkungen auf die Leistung der Weboberfläche und beeinträchtigt Funktionen, die von regelmäßigen Auslösern abhängen (z. B. das Übertragen ausstehender Änderungen, Digest-Benachrichtigungen oder Sicherungen).
Bemerkung
Die tatsächlichen Anforderungen an Ihre Weblate-Installation hängen stark von der Größe der darin verwalteten Übersetzungen ab.
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.
Klonen Sie das Weblate-Docker-Repository:
git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker cd weblate-docker
Erstellen Sie eine Datei
docker-compose.override.yml
mit Ihren Einstellungen. 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
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 Umgebung und Ihren Erwartungen entspricht:
Tag-Name |
Beschreibung |
Anwendungsfall |
---|---|---|
|
Stabile Version von Weblate, entspricht der neuesten getaggten Version |
Fortlaufende Updates in einer Produktionsumgebung |
|
Stabile Weblate-Version |
Fortlaufende Updates innerhalb einer Hauptversion in einer Produktionsumgebung |
|
Stabile Weblate-Version |
Fortlaufende Updates innerhalb einer Unterversion in einer Produktionsumgebung |
|
Stabile Weblate-Version |
Gut definierter Einsatz in einer Produktionsumgebung |
|
Stabile Weblate-Version mit Entwicklungsänderungen im Docker-Container (z. B. aktualisierte Abhängigkeiten) |
Fortlaufende Updates in einer Staging-Umgebung |
|
Stabile Weblate-Version mit Entwicklungsänderungen im Docker-Container (z. B. aktualisierte Abhängigkeiten) |
Gut definierter Einsatz in einer Staging-Umgebung |
|
Weblate-Entwicklungsversion von Git |
Fortlaufende Updates zum Testen kommender Weblate-Funktionen |
|
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
, das das Zertifikat enthält, einschließlich aller erforderlichen CA-Zertifikatessl/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 Port-Weiterleitung für HTTPS in den Docker Compose Override 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 Umgebung.
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.
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
Entfernen des PostgreSQL-Volumes:
docker compose rm -v database docker volume remove weblate-docker_postgres-data
Passen Sie
docker-compose.yml
an, 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_DATABASE
übereinstimmt.(Optional) Aktualisieren Sie das Passwort für den Weblate-Benutzer. 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_DATABASE
ü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 Mitarbeitervorgänge 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 Arbeitskräfte zu reduzieren:
environment:
WEBLATE_WORKERS: 2
Sie können auch individuelle Arbeitskräftekategorien 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#
Neu 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.
Passing secrets#
Neu in Version 5.0.
Weblate container supports passing secrets as files. To utilize that, append
_FILE
suffix to the environment variable and pass secret file via Docker.
Related docker-compose.yml
might look like:
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
Allgemeine Einstellungen#
- WEBLATE_DEBUG#
Konfiguriert den Debugmodus von Django mit
DEBUG
.Beispiel:
environment: WEBLATE_DEBUG: 1
Siehe auch
- WEBLATE_LOGLEVEL#
Legt die Ausführlichkeit der Protokollierung fest. Auf
DEBUG
setzen, um ausführlichere Protokolle zu erhalten.Der Standardwert ist
INFO
wennWEBLATE_DEBUG
ausgeschaltet ist,DEBUG
wird verwendet, wenn der Debugmodus eingeschaltet ist.For more silent logging use
ERROR
orWARNING
.
- 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
- 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 (sieheWEBLATE_ADMIN_PASSWORD
für weitere Informationen dazu).Beispiel:
environment: WEBLATE_ADMIN_NAME: Weblate admin WEBLATE_ADMIN_EMAIL: noreply@example.com
- 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
undWEBLATE_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.
- WEBLATE_SERVER_EMAIL#
Die E-Mail-Adresse, von der aus Fehlermeldungen gesendet werden.
Siehe auch
- WEBLATE_DEFAULT_FROM_EMAIL#
Legt die Adresse für ausgehende E-Mails fest.
Siehe auch
- 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
- 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#
Neu 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, verwenden Sie die Umgebungsvariable
TZ
.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
- WEBLATE_INTERLEDGER_PAYMENT_POINTERS#
Neu 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
- 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 setztIP_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
aufHTTP_X_FORWARDED_FOR
abgebildet werden.Beispiel:
environment: WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
- 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
- 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
undREMOVE
ä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_GITHUB_USERNAME#
- WEBLATE_GITHUB_TOKEN#
- WEBLATE_GITHUB_HOST#
Konfiguriert die Integration von GitHub-Pull-Requests durch Ändern von
GITHUB_CREDENTIALS
.Siehe auch
- WEBLATE_GITLAB_USERNAME#
- WEBLATE_GITLAB_TOKEN#
- WEBLATE_GITLAB_HOST#
Konfiguriert die Integration von GitLab-Merge-Requests durch Ändern von
GITLAB_CREDENTIALS
.Beispiel:
WEBLATE_GITLAB_USERNAME=weblate WEBLATE_GITLAB_HOST=gitlab.com WEBLATE_GITLAB_TOKEN=token
Siehe auch
- WEBLATE_GITEA_USERNAME#
- WEBLATE_GITEA_TOKEN#
- WEBLATE_GITEA_HOST#
Konfiguriert die Integration von Gitea-Pull-Requests durch Ändern von
GITEA_CREDENTIALS
.Siehe auch
- WEBLATE_PAGURE_USERNAME#
- WEBLATE_PAGURE_TOKEN#
- WEBLATE_PAGURE_HOST#
Konfiguriert die Integration von Pagure-Merge-Requests durch Ändern von
PAGURE_CREDENTIALS
.Siehe auch
- WEBLATE_BITBUCKETSERVER_USERNAME#
- WEBLATE_BITBUCKETSERVER_TOKEN#
- WEBLATE_BITBUCKETSERVER_HOST#
Konfiguriert die Integration von Bitbucket-Server-Pull-Requests durch Ändern von
BITBUCKETSERVER_CREDENTIALS
.Siehe auch
- 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
- WEBLATE_SIMPLIFY_LANGUAGES#
Konfiguriert die Richtlinie zur Sprachvereinfachung, siehe :setting:‘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 Verbreitung 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
- 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
Content-Security-Policy
HTTP-Headers.
- 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#
Neu 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#
Neu in Version 4.11.
Konfiguriert die API-Ratenbegrenzung. Der Standardwert ist
100/day
für anonyme und5000/hour
für authentifizierte Benutzer.Siehe auch
- WEBLATE_ENABLE_HOOKS#
Neu in Version 4.13.
Konfiguriert
ENABLE_HOOKS
.
- WEBLATE_ENABLE_AVATARS#
Neu in Version 4.6.1.
Konfiguriert
ENABLE_AVATARS
.
- WEBLATE_AVATAR_URL_PREFIX#
Neu in Version 4.15.
Konfiguriert
AVATAR_URL_PREFIX
.
- WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH#
Neu in Version 4.9.
Konfiguriert
LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH
.
- WEBLATE_SSH_EXTRA_ARGS#
Neu in Version 4.9.
Konfiguriert
SSH_EXTRA_ARGS
.
- WEBLATE_BORG_EXTRA_ARGS#
Neu 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#
Neu in Version 4.14.1.
Konfiguriert
ENABLE_SHARING
.
- WEBLATE_EXTRA_HTML_HEAD#
Neu in Version 4.15.
Konfiguriert
EXTRA_HTML_HEAD
.
- WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE#
Neu in Version 4.15.
Konfiguriert
PRIVATE_COMMIT_EMAIL_TEMPLATE
.
- WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN#
Neu in Version 4.15.
Konfiguriert
PRIVATE_COMMIT_EMAIL_OPT_IN
.
- WEBLATE_UNUSED_ALERT_DAYS#
Neu in Version 4.17.
Konfiguriert
UNUSED_ALERT_DAYS
.
- WEBLATE_CORS_ALLOWED_ORIGINS#
Neu 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#
Neu 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.
Automatische Vorschlagseinstellungen#
Geändert in Version 4.13: Automatische Vorschlagsdienste werden jetzt in der Benutzeroberfläche konfiguriert, siehe Automatische Vorschläge konfigurieren.
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
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 :ref:‘azure-auth‘.
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 <https://github.com/python-social-auth/social-core/blob/master/social_core/backends/keycloak.py>‘_.
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#
OpenID Connect#
Neu 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
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 :ref:‘saml-auth‘.
- WEBLATE_SAML_ID_ATTR_NAME#
- WEBLATE_SAML_ID_ATTR_USERNAME#
- WEBLATE_SAML_ID_ATTR_EMAIL#
- WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID#
Neu 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.
Einrichtung der PostgreSQL-Datenbank#
Die Datenbank wird von docker-compose.yml
erstellt, daher betreffen diese Einstellungen sowohl Weblate- als auch PostgreSQL-Container.
Siehe auch
- POSTGRES_PASSWORD#
PostgreSQL-Passwort.
Siehe auch
- POSTGRES_USER#
PostgreSQL-Benutzername.
- POSTGRES_DATABASE#
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#
Neu in Version 4.8.1.
Die Lebensdauer einer Datenbankverbindung als ganze Zahl von Sekunden. Verwenden Sie 0, um Datenbankverbindungen am Ende jeder Anfrage zu schließen (dies ist das Standardverhalten).
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
- POSTGRES_DISABLE_SERVER_SIDE_CURSORS#
Neu 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
Einstellungen für die Datenbanksicherung#
Siehe auch
- WEBLATE_DATABASE_BACKUP#
Konfiguriert den täglichen Datenbank-Dump mit
DATABASE_BACKUP
. Die Voreinstellung istplain
.
Einrichtung eines Caching-Servers#
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
- 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
- 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.
Einrichtung eines E-Mail-Servers#
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
- WEBLATE_EMAIL_HOST#
Hostname oder IP-Adresse des Mailservers.
- WEBLATE_EMAIL_PORT#
Mailserver-Port, standardmäßig 25.
Siehe auch
- WEBLATE_EMAIL_HOST_USER#
Benutzer der E-Mail-Authentifizierung.
Siehe auch
- WEBLATE_EMAIL_HOST_PASSWORD#
Passwort für die E-Mail-Authentifizierung.
Siehe auch
- 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_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_BACKEND#
Konfiguriert das Django-Backend, das für den Versand von E-Mails verwendet werden soll.
Siehe auch
- WEBLATE_AUTO_UPDATE#
Konfiguriert, ob und wie Weblate Repositorys aktualisieren soll.
Siehe auch
Bemerkung
Dies ist eine boolesche Einstellung (verwenden Sie
"true"
oder"false"
).
Integration der Website#
- WEBLATE_GET_HELP_URL#
Konfiguriert
GET_HELP_URL
.
- WEBLATE_STATUS_URL#
Konfiguriert
STATUS_URL
.
- WEBLATE_PRIVACY_URL#
Konfiguriert
PRIVACY_URL
.
Fehlerberichterstattung#
Es wird empfohlen, Fehler bei der Installation systematisch zu sammeln, siehe Sammeln von Fehlerberichten.
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.
- 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
- 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
Lokalisierung CDN#
- WEBLATE_LOCALIZE_CDN_URL#
- WEBLATE_LOCALIZE_CDN_PATH#
Neu in Version 4.2.1.
Konfiguration für JavaScript-Lokalisierung 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 generierten Dateien verantwortlich, es speichert nur die Dateien am konfigurierten Speicherort.
Ä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
Container-Einstellungen#
- WEBLATE_WORKERS#
Neu in Version 4.6.1.
Basisanzahl der im Container laufenden Arbeitsprozesse. 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
undWEB_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
- 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 Backups, 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
Schreibgeschütztes Root-Dateisystem#
Neu 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
Ü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:
Fügen Sie ein Modul zu Ihrem Paket hinzu, das alle Einstellungen von
weblate.settings_docker
importiert.Innerhalb der Beispiel-Paketstruktur, die unter Erstellen eines Python-Moduls definiert ist, könnten Sie zum Beispiel eine Datei unter
weblate_customization/weblate_customization/settings.py
mit dem folgenden Anfangscode erstellen:from weblate.settings_docker import *
Erstellen Sie ein benutzerdefiniertes
Dockerfile
, das vom offiziellen Weblate-Docker-Image erbt, dann Ihr Paket installiert und die UmgebungsvariableDJANGO_SETTINGS_MODULE
auf Ihr 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, erstellen Sie ein benutzerdefiniertes Image aus dieser
Dockerfile
-Datei.Es gibt keine saubere Möglichkeit, dies mit
docker-compose.override.yml
zu tun. Sie könntenbuild: .
zu demweblate
Knoten in dieser Datei hinzufügen, aber dann wird Ihr benutzerdefiniertes Image alsweblate/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 durchdocker-compose.override.yml
zu erweitern, sollten Sie eine Kopie der offiziellendocker-compose.yml
Datei erstellen und Ihre Kopie so bearbeiten, dassimage: weblate/weblate
durchbuild: .
ersetzt wird.Weitere Informationen zum Erstellen von Images aus der Quelle bei Verwendung von
docker-compose
finden Sie in der ‚Compose-Datei-Build-Referenz’_.Erweitern Sie Ihr benutzerdefiniertes Einstellungsmodul, um Einstellungen zu definieren oder neu zu definieren.
Sie können Einstellungen vor oder nach der obigen Importanweisung definieren, um festzulegen, welche Einstellungen Vorrang haben. Vor der Importanweisung definierte Einstellungen können durch Umgebungsvariablen und im Data-Volume definierte Einstellungsüberschreibungen außer Kraft gesetzt 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 Umgebung passende Konfiguration kann mit https://pgtune.leopard.in.ua/ generiert 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 Status der Dienste 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). Sie können die Verarbeitung einiger Aufgaben stoppen, indem Sie den entsprechenden Worker stoppen:
docker compose exec --user weblate weblate supervisorctl stop celery-translate