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
Die folgenden Beispiele gehen davon aus, dass Sie eine funktionierende Docker-Umgebung haben, in der docker-compose
installiert ist. Anweisungen hierzu finden Sie in der Docker-Dokumentation.
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.
Geändert in Version 2.15-2: Die Einrichtung hat sich kürzlich geändert, vorher gab es einen separaten Webserver-Container, seit 2.15-2 ist der Webserver in den Weblate-Container eingebettet.
Geändert in Version 3.7.1-6: Im Juli 2019 (beginnend mit dem Tag 3.7.1-6) werden die Container nicht als Root-Benutzer ausgeführt. Dadurch hat sich der exponierte Port von 80 auf 8080 geändert.
Siehe auch
Auswählen des Docker-Hub-Tags
Sie können die folgenden Tags auf Docker Hub verwenden. Eine vollständige Liste der verfügbaren Tags finden Sie unter https://hub.docker.com/r/weblate/weblate/tags/.
Tag-Name |
Beschreibung |
Anwendungsfall |
---|---|---|
|
Stabile Version von Weblate, entspricht der neuesten getaggten Version |
Fortlaufende Updates 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.
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
Neu in Version 3.8-3.
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;
listen [::]:443;
server_name <SITE_URL>;
ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;
location / {
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
}
}
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.10-1: Seit Weblate 4.10-1 verwendet der Docker-Container Django 4.0, was PostgreSQL 10 oder neuer erfordert. Bitte aktualisieren Sie es vor dem Upgrade von Weblate. Siehe Upgrade von 4.0 auf 4.10 und 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 --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 postgres
(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 postgres -c "ALTER USER weblate WITH PASSWORD 'weblate'"
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 erzeugten 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.
Ein Beispiel-Setup 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.
Allgemeine Einstellungen
- WEBLATE_DEBUG
Konfiguriert den Debugmodus von Django mit
DEBUG
.Beispiel:
environment: WEBLATE_DEBUG: 1
Siehe auch
- WEBLATE_LOGLEVEL
Konfiguriert die Ausführlichkeit der Protokollierung.
- 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_ADMIN_PASSWORD_FILE
Legt den Pfad zu einer Datei fest, die das Passwort für den Benutzer Administrator enthält.
Siehe auch
- 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
Konfigurieren Sie über
REGISTRATION_ALLOW_BACKENDS
, welche Authentifizierungsmethoden zum Erstellen eines neuen Kontos verwendet werden können.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.
- 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
.
- 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_CORS_ALLOWED_ORIGINS
Neu in Version 4.16.
CORS-Anfragen von verschiedenen Stellen zulassen.
Beispiel:
environment: WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org
- CLIENT_MAX_BODY_SIZE
Neu in Version 4.16.3.
Configures maximal body size accepted by the built-in web server.
environment: CLIENT_MAX_BODY_SIZE: 200m
Hinweis
This variable intentionally lacks
WEBLATE_
prefix as it is shared with third-party container used in Automatische SSL-Zertifikate mit Let’s Encrypt.
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_BIND_PASSWORD_FILE
Pfad zu der Datei, die das LDAP-Server-Verbindungskennwort enthält.
Siehe auch
- 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.
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‘.
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.
- POSTGRES_PASSWORD_FILE
Pfad zu der Datei, die das PostgreSQL-Passwort enthält. Verwendung als Alternative zu POSTGRES_PASSWORD.
- 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
Konfigurieren Sie, 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-Setups 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, der Standardwert ist
1
.
- REDIS_PASSWORD
Das Redis Server-Passwort, nicht standardmäßig verwendet.
- REDIS_PASSWORD_FILE
Pfad zu der Datei, die das Passwort für den Redis-Server enthält.
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_HOST_PASSWORD_FILE
Pfad zu der Datei, die das Kennwort für die E-Mail-Authentifizierung enthält.
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-Zugriffstoken.
- 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).
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
Neu in Version 3.8-5.
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 Sie die Celery-Worker-Optionen anpassen. 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
Konfigurieren Sie, 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
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 Erstellung 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
Neu in Version 3.8-5.
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 Anpassen von Weblate) 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, die 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