Konfigurationsanweisungen¶
Weblate installieren¶
Wählen Sie je nach Ihren Gegebenheiten und Ihrer Erfahrung eine für Sie geeignete Installationsmethode:
Installation über Docker, empfohlen für Produktionssysteme.
Virtualenv-Installation, empfohlen für Produktionssysteme:
Installieren aus Quellen, empfohlen für die Entwicklung.
Architekturübersicht¶
- Webserver
Handling incoming HTTP requests, Bereitstellung statischer Dateien.
- Celery workers
Hintergrundaufgaben mit Celery are executed here.
Depending on your workload, you might want to customize the number of workers.
Use dedicated node when scaling Weblate horizontally.
- WSGI server
A WSGI server serving web pages to users.
Use dedicated node when scaling Weblate horizontally.
- Datenbank
PostgreSQL-Datenbankserver zum Speichern aller Inhalte, siehe Datenbankeinrichtung für Weblate.
Use dedicated database node for sites with hundreds of millions of hosted words.
- Redis
Redis-Server für Cache und Aufgabenwarteschlange, siehe Hintergrundaufgaben mit Celery.
Use dedicated node when scaling Weblate horizontally.
- File system
File system storage for storing VCS repositories and uploaded user data. This is shared by all the processes.
Use networked storage when scaling Weblate horizontally.
- E-mail server
SMTP server for outgoing e-mail, see Ausgehende E-Mails konfigurieren. It can be provided externally.
Hinweis
Installation über Docker enthält PostgreSQL und Redis, was die Installation erleichtert.
Softwareanforderungen¶
Betriebssystem¶
Von Weblate ist bekannt, dass es unter Linux, FreeBSD und macOS funktioniert. Andere Unix-ähnliche Systeme werden höchstwahrscheinlich auch funktionieren.
Weblate wird unter Windows nicht unterstützt. Aber es kann trotzdem funktionieren und Patches werden gerne angenommen.
Siehe auch
Architekturübersicht describes overall Weblate architecture and required services.
Python-Abhängigkeiten¶
Weblate is written in Python and supports Python
3.10 or newer. You can install dependencies using pip or from your
distribution packages, full list is available in requirements.txt.
Wichtigste Abhängigkeiten:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Django-REST-Framework
pip extra |
Python-Paket |
Weblate-Funktion |
|---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
MySQL oder MariaDB, siehe Datenbankeinrichtung für Weblate |
|
|
||
|
PostgreSQL, siehe Datenbankeinrichtung für Weblate |
|
|
||
|
Wenn Sie mit pip installieren, können Sie die gewünschten Funktionen direkt bei der Installation angeben:
pip install "Weblate[Postgres,Amazon,SAML]"
Oder Sie können Weblate mit allen optionalen Funktionen installieren:
pip install "Weblate[all]"
Oder Sie können Weblate ohne optionale Funktionen installieren:
pip install Weblate
Weitere Systemvoraussetzungen¶
Die folgenden Abhängigkeiten müssen auf dem System installiert sein:
Git- Pango, Cairo und zugehörige Header-Dateien sowie GObject-Introspektionsdaten
https://cairographics.org/, https://pango.gnome.org/, siehe Pango und Kairo
git-review(optional für Gerrit-Unterstützung)git-svn(optional für Subversion-Unterstützung)tesseract(nur erforderlich, wenn keine Binary Wheels von tesserocr für das System verfügbar sind)licensee(optional zur Erkennung der Lizenz beim Erstellen der Komponente)
Build-Zeit-Abhängigkeiten¶
Um einige der Python-Abhängigkeiten zu bauen, müssen Sie möglicherweise deren Abhängigkeiten installieren. Dies hängt davon ab, wie Sie sie installieren, also konsultieren Sie bitte die Dokumentation der einzelnen Pakete. Sie werden diese nicht benötigen, wenn Sie das vorgefertigte Wheels verwenden, während Sie pip installieren oder wenn Sie Distributionspakete verwenden.
Pango und Kairo¶
Weblate verwendet Pango und Cairo für die Darstellung von Bitmap-Widgets (siehe Übersetzung gezielt fördern) und für die Darstellung von Qualitätsprüfungen (siehe Schriftarten verwalten). Um die Python-Bindings dafür richtig zu installieren, müssen Sie zuerst die Systembibliotheken installieren – Sie brauchen sowohl Cairo als auch Pango, die wiederum GLib benötigen. Alle diese Bibliotheken sollten zusammen mit Entwicklungsdateien und GObject-Introspektionsdaten installiert werden.
Hardwareanforderungen¶
Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):
3 GB Arbeitsspeicher
2 CPU-Kerne
1 GB Speicherplatz
Bemerkung
Die tatsächlichen Anforderungen an Ihre Weblate-Installation hängen stark von der Größe der darin verwalteten Übersetzungen ab.
Memory usage¶
The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.
Hinweis
Für Systeme mit weniger Speicher als empfohlen, wird Celery-Einzelprozess einrichten empfohlen.
CPU usage¶
Many concurrent users increase the amount of needed CPU cores.
Storage usage¶
The typical database storage usage is around 300 MB per 1 million hosted words.
Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.
Nodes¶
For small and medium-sized sites (millions of hosted words), all Weblate components (see Architekturübersicht) can be run on a single node.
When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Datenbankeinrichtung für Weblate).
Überprüfen von Veröffentlichungssignaturen¶
Weblate-Versionen sind kryptografisch signiert mit Sigstore-Signaturen. Die Signaturen sind der GitHub-Veröffentlichung beigefügt.
Die Überprüfung kann mit dem Sigstore-Paket durchgeführt werden. Das folgende Beispiel verifiziert die Signatur der Version 5.4:
sigstore verify github \
--cert-identity https://github.com/WeblateOrg/weblate/.github/workflows/setup.yml@refs/tags/weblate-5.4 \
--bundle Weblate-5.4-py3-none-any.whl.sigstore \
Weblate-5.4-py3-none-any.whl
Dateisystemberechtigungen¶
Der Weblate-Prozess muss in der Lage sein, vom und ins Verzeichnis zu lesen und zu schreiben, in dem er Daten speichert – DATA_DIR. Alle Dateien in diesem Verzeichnis sollten dem Benutzer gehören, der alle Weblate-Prozesse ausführt (normalerweise WSGI und Celery, siehe Laufender Server und Hintergrundaufgaben mit Celery).
Die Standardkonfiguration platziert sie im selben Baum wie die Weblate-Quellen, aber Sie könnten es vorziehen, sie an einen besseren Ort zu verschieben, wie zum Beispiel: /var/lib/weblate.
Weblate versucht, diese Verzeichnisse automatisch zu erstellen, aber es wird scheitern, wenn es keine entsprechenden Rechte hat.
Sie sollten auch vorsichtig sein, wenn Sie Verwaltungsbefehle ausführen, da sie unter demselben Benutzer ausgeführt werden sollten, unter dem auch Weblate selbst läuft, da sonst die Berechtigungen für einige Dateien falsch sein könnten.
Im Docker-Container müssen alle Dateien im Volume /app/data dem Benutzer weblate innerhalb des Containers gehören (UID 1000).
Siehe auch
Datenbankeinrichtung für Weblate¶
Es wird empfohlen, Weblate mit einem PostgreSQL-Datenbankserver zu betreiben.
PostgreSQL 12 and higher is supported. PostgreSQL 15 or newer is recommended.
MySQL und MariaDB wird unterstützt, aber für Neuinstallationen nicht empfohlen.
Bemerkung
No other database servers are currently supported, but support for other Django supported databases should be possible to implement.
Siehe auch
Eine leistungsstarke Datenbank-Engine verwenden, Databases, Migration von anderen Datenbanken zu PostgreSQL
Datenbankverbindungen¶
In der Standardkonfiguration behält jeder Weblate-Prozess eine dauerhafte Verbindung zur Datenbank bei. Dauerhafte Verbindungen verbessern die Reaktionsfähigkeit von Weblate, erfordern jedoch möglicherweise mehr Ressourcen für den Datenbankserver. Bitte lesen Sie CONN_MAX_AGE und Persistent connections für weitere Informationen.
Weblate benötigt mindestens die folgende Anzahl an Verbindungen:
\((4 \times \mathit{nCPUs}) + 2\) für Celery-Prozesse
\(\mathit{nCPUs} + 1\) für WSGI-Worker
Dies gilt für die Docker-Container-Standardwerte und die Beispielkonfigurationen in dieser Dokumentation, jedoch werden sich die Zahlen ändern, wenn Sie die Anzahl der WSGI-Worker anpassen oder die Parallelität von Celery einstellen.
Der tatsächliche Grenzwert für die Anzahl der Datenbankverbindungen muss höher sein, um folgende Situationen zu berücksichtigen:
Verwaltungsbefehle benötigen ebenfalls ihre Verbindung.
Wenn ein Case-Prozess beendet wird (z. B. durch einen OOM-Killer), kann er die bestehende Verbindung bis zum Timeout blockieren.
PostgreSQL¶
PostgreSQL ist normalerweise die beste Wahl für Django-basierte Websites. Es ist die Referenzdatenbank, die für die Implementierung der Django-Datenbankschicht verwendet wird.
Bemerkung
Weblate verwendet die Trigram-Erweiterung, die in einigen Fällen separat installiert werden muss. Suchen Sie nach postgresql-contrib oder einem ähnlich benannten Paket.
Siehe auch
Erstellen einer Datenbank in PostgreSQL¶
Normalerweise ist es eine gute Idee, Weblate in einer separaten Datenbank und unter einem separaten Benutzerkonto laufen zu lassen:
# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"
# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate
# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate
Hinweis
Wenn Sie den Weblate-Benutzer nicht zu einem Superuser in PostgreSQL machen wollen, können Sie das weglassen. In diesem Fall müssen Sie einige der Migrationsschritte manuell als PostgreSQL-Superuser im Schema durchführen, das Weblate verwenden wird:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Weblate für die Verwendung von PostgreSQL konfigurieren¶
Das settings.py-Snippet für PostgreSQL:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.postgresql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# Name of role to alter to set parameters in PostgreSQL,
# use in case role name is different than user used for authentication.
# "ALTER_ROLE": "weblate",
# Database password
"PASSWORD": "password",
# Set to empty string for localhost
"HOST": "database.example.com",
# Set to empty string for default
"PORT": "",
# Persistent connections
"CONN_MAX_AGE": None,
"CONN_HEALTH_CHECKS": True,
}
}
Die Datenbankmigration führt ALTER ROLE für die von Weblate verwendete Datenbankrolle durch. In den meisten Fällen stimmt der Name der Rolle mit dem Benutzernamen überein. In komplexeren Einrichtungen unterscheidet sich der Rollenname vom Benutzernamen und Sie erhalten eine Fehlermeldung über eine nicht existierende Rolle während der Datenbankmigration (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Es ist bekannt, dass dies mit Azure Database for PostgreSQL passiert, aber es ist nicht auf diese Einsatzumgebung beschränkt. Bitte setzen Sie ALTER_ROLE, um den Namen der Rolle zu ändern, die Weblate während der Datenbankmigration ändern soll.
Siehe auch
MySQL und MariaDB¶
Warnung
Während MySQL und MariaDB in Weblate weiterhin unterstützt werden, liegt unser Hauptaugenmerk auf PostgreSQL. Es wird empfohlen, PostgreSQL für neue Installationen zu verwenden und bestehende Installationen zu PostgreSQL zu migrieren, siehe Migration von anderen Datenbanken zu PostgreSQL.
Einige Weblate-Funktionen werden mit PostgreSQL besser funktionieren. Dazu gehören die Suche und der Übersetzungsspeicher, die Volltextfunktionen in der Datenbank nutzen, wobei die PostgreSQL-Implementierung besser ist.
Weblate kann auch mit MySQL oder MariaDB verwendet werden, bitte lesen Sie MySQL notes und MariaDB notes für Hinweise zur Verwendung von Django mit diesen. Aufgrund der Einschränkungen wird empfohlen, PostgreSQL für neue Installationen zu verwenden.
Weblate benötigt MySQL mindestens in der Version 8 oder MariaDB mindestens in der Version 10.4.
Die folgende Konfiguration wird für Weblate empfohlen:
Verwenden Sie den Zeichensatz
utf8mb4, um die Darstellung höherer Unicode-Ebenen (zum Beispiel Emojis) zu ermöglichen.Konfigurieren Sie den Server mit
innodb_large_prefix, um längere Indizes für Textfelder zu ermöglichen.Setzen Sie die Isolationsstufe auf
READ COMMITTED.Der SQL-Modus sollte auf
STRICT_TRANS_TABLESeingestellt werden.
MySQL 8.x, MariaDB 10.5.x oder neuer haben eine vernünftige Standardkonfiguration, sodass keine Serveranpassung notwendig sein sollte und alles, was benötigt wird, clientseitig konfiguriert werden kann.
Unten ist ein /etc/my.cnf.d/server.cnf Beispiel für einen Server mit 8 GB RAM. Diese Einstellungen sollten für die meisten Installationen ausreichend sein. MySQL und MariaDB verfügen über Einstellungen, welche die Leistung Ihres Servers erhöhen, die aber nicht als notwendig erachtet werden, es sei denn, Sie planen, dass eine große Anzahl von Benutzern gleichzeitig auf das System zugreift. Einzelheiten hierzu finden Sie in der Dokumentation des jeweiligen Anbieters.
Um Probleme bei der Installation zu vermeiden, ist es absolut wichtig, dass die Einstellung innodb_file_per_table richtig gesetzt ist und MySQL/MariaDB neu gestartet wurde, bevor Sie Ihre Weblate-Installation starten.
[mysqld]
character-set-server = utf8mb4
character-set-client = utf8mb4
collation-server = utf8mb4_unicode_ci
datadir=/var/lib/mysql
log-error=/var/log/mariadb/mariadb.log
innodb_large_prefix=1
innodb_file_format=Barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=2G
sql_mode=STRICT_TRANS_TABLES
Hinweis
Falls Sie den Fehler #1071 - Specified key was too long; max key length is 767 bytes erhalten, aktualisieren Sie bitte Ihre Konfiguration, um die obigen Einstellungen innodb zu übernehmen und starten Sie Ihre Installation neu.
Hinweis
Falls Sie den Fehler #2006 - MySQL server has gone away erhalten, könnte die Konfiguration von CONN_MAX_AGE helfen.
Siehe auch
Weblate für die Verwendung von MySQL/MariaDB konfigurieren¶
Das settings.py-Snippet für MySQL und MariaDB:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.mysql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# Database password
"PASSWORD": "password",
# Set to empty string for localhost
"HOST": "127.0.0.1",
# Set to empty string for default
"PORT": "3306",
# In case you wish to use additional
# connection options
"OPTIONS": {},
}
}
Sie sollten auch das Benutzerkonto weblate in MySQL oder MariaDB erstellen, bevor Sie mit der Installation beginnen. Verwenden Sie dazu die folgenden Befehle:
GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
Siehe auch
Andere Konfigurationen¶
Ausgehende E-Mails konfigurieren¶
Weblate verschickt zu verschiedenen Anlässen E-Mails – zur Kontoaktivierung und zu verschiedenen vom Nutzer konfigurierten Benachrichtigungen. Hierfür benötigt es Zugang zu einem SMTP-Server.
Die Mailserver-Einrichtung wird mit diesen Einstellungen konfiguriert: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER und EMAIL_PORT. Ihre Namen sind ziemlich selbsterklärend, aber Sie können mehr Informationen in der Django-Dokumentation finden.
Hinweis
Falls Sie die Fehlermeldung erhalten, dass die Authentifizierung nicht unterstützt wird (z. B. SMTP AUTH extension not supported by server), liegt das wahrscheinlich daran, dass Sie eine unsichere Verbindung verwenden und der Server sich weigert, sich auf diese Weise zu authentifizieren. Versuchen Sie in diesem Fall EMAIL_USE_TLS zu aktivieren.
Hinter einem Reverse-Proxy ausführen¶
Mehrere Funktionen in Weblate sind darauf angewiesen, dass die IP-Adresse des Clients ermittelt werden kann. Dazu gehören Ratenbegrenzung, Spamschutz oder Audit-Protokoll.
In der Standardkonfiguration analysiert Weblate die IP-Adresse von REMOTE_ADDR, die durch den WSGI-Handler gesetzt wird.
Falls Sie einen Reverse-Proxy verwenden, enthält dieses Feld höchstwahrscheinlich dessen Adresse. Sie müssen Weblate so konfigurieren, dass es zusätzlichen HTTP-Headern vertraut und die IP-Adresse aus diesen analysiert. Dies kann nicht standardmäßig aktiviert werden, da dies bei Installationen, die keinen Reverse-Proxy verwenden, IP-Adress-Spoofing ermöglichen würde. Die Aktivierung von IP_BEHIND_REVERSE_PROXY dürfte für die meisten üblichen Installationen ausreichen, aber möglicherweise müssen Sie auch IP_PROXY_HEADER und IP_PROXY_OFFSET anpassen.
Eine weitere Sache, auf die Sie achten müssen, ist der Host-Header. Er sollte mit dem übereinstimmen, der als SITE_DOMAIN konfiguriert ist. Möglicherweise ist eine zusätzliche Konfiguration in Ihrem Reverse-Proxy erforderlich (verwenden Sie zum Beispiel ProxyPreserveHost On für Apache oder proxy_set_header Host $host; für nginx).
HTTP-Proxy¶
Weblate führt VCS-Befehle aus und diese akzeptieren die Proxy-Konfiguration aus der Einsatzumgebung. Es wird empfohlen, die Proxy-Einstellungen in settings.py zu definieren:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Siehe auch
Anpassen der Konfiguration¶
Siehe auch
Kopieren Sie weblate/settings_example.py nach weblate/settings.py und passen Sie es an Ihre Einrichtung an. Wahrscheinlich werden Sie die folgenden Optionen anpassen:
ADMINS
Liste der Website-Administratoren, die Benachrichtigungen erhalten sollen, wenn etwas schiefläuft, z. B. Benachrichtigungen über fehlgeschlagene Merges oder Django-Fehler.
Das Kontaktformular sendet auch an diese eine E-Mail, es sei denn,
ADMINS_CONTACTist konfiguriert.Siehe auch
ADMINS,ADMINS_CONTACT, Administratoren richtig konfigurieren
ALLOWED_HOSTS
Sie müssen hier die Hosts auflisten, die Ihre Website bedienen soll. Zum Beispiel:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternativ können Sie auch einen Platzhalter einfügen:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Konfigurieren Sie, wie Ihre Sitzungen gespeichert werden sollen. Wenn Sie die Standard-Datenbank-Backend-Engine beibehalten, sollten Sie Folgendes vorsehen: weblate clearsessions, um veraltete Sitzungsdaten aus der Datenbank zu entfernen.
Wenn Sie Redis als Cache verwenden (siehe Caching einschalten), ist es empfehlenswert, ihn auch für Sitzungen zu verwenden:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"Siehe auch
DATABASES
Verbindung zum Datenbankserver, bitte lesen Sie die Django-Dokumentation für weitere Details.
Siehe auch
DEBUG
Deaktivieren Sie dies für alle Produktionsserver. Wenn der Debugmodus aktiviert ist, zeigt Django den Benutzern im Falle eines Fehlers Backtraces an. Wenn Sie ihn deaktivieren, werden Fehler per E-Mail an
ADMINS(siehe oben) gesendet.Der Debugmodus verlangsamt Weblate auch, da Django in diesem Fall intern viel mehr Informationen speichert.
Siehe auch
DEFAULT_FROM_EMAIL
E-Mail-Absenderadresse für ausgehende E-Mails, z. B. Registrierungs-E-Mails.
Siehe auch
SECRET_KEY
Schlüssel, der von Django verwendet wird, um einige Informationen in Cookies zu signieren, siehe Geheimer Django-Schlüssel für weitere Informationen.
Siehe auch
SERVER_EMAIL
E-Mail, die als Absenderadresse für den Versand von E-Mails an den Administrator verwendet wird, z. B. für Benachrichtigungen über fehlgeschlagene Merges.
Siehe auch
Füllen der Datenbank¶
Nachdem Ihre Konfiguration fertig ist, können Sie migrate ausführen, um die Datenbankstruktur zu erstellen. Nun sollten Sie in der Lage sein, Übersetzungsprojekte über die Adminoberfläche zu erstellen.
Wenn Sie fertig sind, sollten Sie auch den Leistungsbericht in der Adminoberfläche überprüfen, der Ihnen Hinweise auf eine möglicherweise nicht optimale Konfiguration Ihrer Website gibt.
Siehe auch
Produktionseinrichtung¶
Für eine Produktionseinrichtung sollten Sie die in den folgenden Abschnitten beschriebenen Anpassungen vornehmen. Die kritischsten Einstellungen lösen eine Warnung aus, die durch ein Ausrufezeichen in der oberen Leiste angezeigt wird, wenn Sie als Superuser angemeldet sind:
Es wird auch empfohlen, die von Django ausgelösten Prüfungen zu kontrollieren (auch wenn Sie nicht alle korrigieren müssen):
weblate check --deploy
Sie können die gleiche Checkliste auch unter Leistungsbericht in der Verwaltungsoberfläche überprüfen.
Siehe auch
Debugmodus deaktivieren¶
Deaktivieren Sie den Debugmodus von Django (DEBUG) durch:
DEBUG = False
Wenn der Debugmodus aktiviert ist, speichert Django alle ausgeführten Abfragen und zeigt den Benutzern Rückverfolgungen von Fehlern an, was in einer Produktionsumgebung nicht erwünscht ist.
Siehe auch
Administratoren richtig konfigurieren¶
Setzen Sie die richtigen Administrator-Adressen in der Einstellung ADMINS, um festzulegen, wer E-Mails erhalten soll, wenn zum Beispiel auf dem Server etwas schiefläuft:
ADMINS = (("Your Name", "your_email@example.com"),)
Siehe auch
Seitendomain richtig einstellen¶
Passen Sie den Seitenname und die Seitendomain in der Adminoberfläche an, da sonst die Links in RSS oder Registrierungs-E-Mails nicht funktionieren. Dies wird mit SITE_DOMAIN konfiguriert, das den Namen der Seitendomain enthalten sollte.
Geändert in Version 4.2: Vor der Version 4.2 wurde stattdessen das Django Sites Framework verwendet, siehe The “sites” framework.
HTTPS richtig konfigurieren¶
Es wird dringend empfohlen, Weblate über das verschlüsselte HTTPS-Protokoll laufen zu lassen. Nachdem Sie es aktiviert haben, sollten Sie ENABLE_HTTPS in den Einstellungen setzen:
ENABLE_HTTPS = True
Hinweis
Vielleicht möchten Sie auch HSTS einrichten, siehe SSL/HTTPS für weitere Details.
SECURE_HSTS_SECONDS richtig einstellen¶
Wenn Ihre Website über SSL bereitgestellt wird, müssen Sie einen Wert für SECURE_HSTS_SECONDS in der settings.py setzen, um HTTP Strict Transport Security zu aktivieren. Standardmäßig ist dieser Wert auf 0 gesetzt, wie unten gezeigt.
SECURE_HSTS_SECONDS = 0
Wenn auf einen Integer-Wert ungleich Null gesetzt, setzt django.middleware.security.SecurityMiddleware den HTTP Strict Transport Security-Header auf alle Antworten, die ihn nicht bereits haben.
Warnung
Eine falsche Einstellung kann Ihre Website unwiderruflich (für einige Zeit) zerstören. Lesen Sie zuerst die HTTP Strict Transport Security Dokumentation.
Eine leistungsstarke Datenbank-Engine verwenden¶
Bitte verwenden Sie PostgreSQL für eine Produktionsumgebung, siehe Datenbankeinrichtung für Weblate für weitere Informationen.
Verwenden Sie einen benachbarten Standort für den Betrieb des Datenbankservers, da sonst die Netzwerkleistung oder -zuverlässigkeit Ihr Weblate-Erlebnis beeinträchtigen könnte.
Überprüfen Sie die Leistung des Datenbankservers oder passen Sie seine Konfiguration an, zum Beispiel mit PGTune.
Caching einschalten¶
Wenn möglich, verwenden Sie Redis von Django aus, indem Sie zum Beispiel die Konfigurationsvariable CACHES anpassen:
CACHES = {
"default": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://127.0.0.1:6379/0",
# If redis is running on same host as Weblate, you might
# want to use unix sockets instead:
# 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
"PARSER_CLASS": "redis.connection.HiredisParser",
},
}
}
Hinweis
Falls Sie die Redis-Einstellungen für den Cache ändern, müssen Sie diese möglicherweise auch für Celery anpassen, siehe Hintergrundaufgaben mit Celery.
Siehe auch
Avatar-Caching¶
Zusätzlich zum Caching von Django führt Weblate auch ein Caching von Avataren durch. Es wird empfohlen, für diesen Zweck einen separaten, dateibasierten Cache zu verwenden:
CACHES = {
"default": {
# Default caching backend setup, see above
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "unix:///var/run/redis/redis.sock?db=0",
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
"PARSER_CLASS": "redis.connection.HiredisParser",
},
},
"avatar": {
"BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
"LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
"TIMEOUT": 604800,
"OPTIONS": {
"MAX_ENTRIES": 1000,
},
},
}
E-Mail-Versand konfigurieren¶
Weblate verschickt zu verschiedenen Anlässen E-Mails und diese sollten eine korrekte Absenderadresse haben. Bitte konfigurieren Sie SERVER_EMAIL und DEFAULT_FROM_EMAIL so, dass sie zu Ihrer Einsatzumgebung passen, zum Beispiel:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Bemerkung
Um den Versand von E-Mails durch Weblate zu deaktivieren, setzen Sie EMAIL_BACKEND auf django.core.mail.backends.dummy.EmailBackend.
Dies deaktiviert alle E-Mails, einschließlich der E-Mails zur Registrierung oder zum Zurücksetzen des Passworts.
Einrichtung zulässiger Hosts¶
Django benötigt ALLOWED_HOSTS, um eine Liste von Domänennamen zu speichern, die Ihre Seite bedienen darf. Wenn Sie die Liste leer lassen, werden alle Anfragen blockiert.
Wenn dies nicht so konfiguriert ist, dass es zu Ihrem HTTP-Server passt, erhalten Sie Fehler wie Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
Hinweis
Auf Docker-Containern ist dies als WEBLATE_ALLOWED_HOSTS verfügbar.
Geheimer Django-Schlüssel¶
Die Einstellung SECRET_KEY wird von Django verwendet, um Cookies zu signieren. Sie sollten wirklich Ihren eigenen Wert erzeugen, anstatt den aus der Beispieleinrichtung zu verwenden.
Sie können einen neuen Schlüssel mittels weblate-generate-secret-key erzeugen, das mit Weblate ausgeliefert wird.
Siehe auch
Ausführen von Wartungsaufgaben¶
Für eine optimale Leistung ist es empfehlenswert, einige Wartungsaufgaben im Hintergrund laufen zu lassen. Dies wird automatisch von Hintergrundaufgaben mit Celery erledigt und umfasst die folgenden Aufgaben:
Konfigurationsintegritätsprüfung (stündlich).
Committen ausstehender Änderungen (stündlich), siehe Lazy Commits und
commit_pending.Aktualisieren von Komponentenwarnungen (täglich).
Remote-Branches aktualisieren (nachts), siehe
AUTO_UPDATE.Übersetzungsspeicher-Sicherung in JSON (täglich), siehe
dump_memory.Volltext- und Datenbankwartungsaufgaben (tägliche und wöchentliche Aufgaben), siehe
cleanuptrans.
System-Sprachumgebungen und -Kodierung¶
Die System-Sprachumgebungen sollten als UTF-8-fähig konfiguriert werden. Bei den meisten Linux-Distributionen ist dies die Standardeinstellung. Falls dies auf Ihrem System nicht der Fall ist, ändern Sie bitte die Sprachumgebungen auf die UTF-8-Variante.
Zum Beispiel, indem Sie /etc/default/locale bearbeiten und dort LANG="C.UTF-8" einstellen.
In einigen Fällen haben die einzelnen Dienste eine separate Konfiguration für Sprachumgebungen. Dies ist je nach Distribution und Webserver unterschiedlich, daher sollten Sie die Dokumentation Ihrer Webserver-Pakete daraufhin überprüfen.
Apache unter Ubuntu verwendet /etc/apache2/envvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache unter CentOS verwendet /etc/sysconfig/httpd (oder /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Client-Assets komprimieren¶
Weblate wird mit einer Reihe von JavaScript- und CSS-Dateien geliefert. Aus Leistungsgründen ist es sinnvoll, diese vor dem Senden an einen Client zu komprimieren. In der Standardkonfiguration wird dies im laufenden Betrieb auf Kosten eines geringen Overheads durchgeführt. Bei großen Installationen empfiehlt es sich, den Offline-Komprimierungsmodus zu aktivieren. Dies muss in der Konfiguration vorgenommen werden, und die Komprimierung muss bei jeder Aktualisierung von Weblate ausgelöst werden.
Der Konfigurationswechsel ist einfach, indem man django.conf.settings.COMPRESS_OFFLINE aktiviert und django.conf.settings.COMPRESS_OFFLINE_CONTEXT konfiguriert (letzteres ist bereits in der Beispielkonfiguration enthalten):
COMPRESS_OFFLINE = True
Bei jeder Bereitstellung müssen Sie die Dateien komprimieren, damit sie der aktuellen Version entsprechen:
weblate compress
Hinweis
Im offiziellen Docker-Image ist diese Funktion bereits aktiviert.
Laufender Server¶
Hinweis
Falls Sie keine Erfahrung mit den unten beschriebenen Diensten haben, sollten Sie Installation über Docker ausprobieren.
Sie benötigen mehrere Dienste, um Weblate auszuführen, die empfohlene Einrichtung besteht aus:
Datenbankserver (siehe Datenbankeinrichtung für Weblate)
Cache-Server (siehe Caching einschalten)
Frontend-Webserver für statische Dateien und SSL-Terminierung (siehe Bereitstellung statischer Dateien)
WSGI-Server für dynamische Inhalte (siehe Beispielkonfiguration für NGINX und uWSGI)
Celery für die Ausführung von Hintergrundaufgaben (siehe Hintergrundaufgaben mit Celery)
Bemerkung
Es gibt einige Abhängigkeiten zwischen den Diensten, zum Beispiel sollten Cache und Datenbank beim Starten von Celery- oder uwsgi-Prozessen bereits laufen.
In den meisten Fällen werden Sie alle Dienste auf einem einzigen (virtuellen) Server laufen lassen, aber wenn Ihre Installation stark ausgelastet ist, können Sie die Dienste aufteilen. Die einzige Einschränkung dabei ist, dass Celery- und Wsgi-Server Zugriff auf DATA_DIR benötigen.
Bemerkung
Der WSGI-Prozess muss unter demselben Benutzer wie der Celery-Prozess ausgeführt werden, sonst werden die Dateien im DATA_DIR mit unterschiedlichen Besitzverhältnissen gespeichert, was zu Laufzeitproblemen führt.
Siehe auch Dateisystemberechtigungen und Hintergrundaufgaben mit Celery.
Webserver ausführen¶
Die Ausführung von Weblate unterscheidet sich nicht von der Ausführung anderer Django-basierter Programme. Django wird normalerweise als uWSGI oder fcgi ausgeführt (siehe Beispiele für verschiedene Webserver unten).
Zu Testzwecken können Sie den in Django integrierten Webserver verwenden:
weblate runserver
Warnung
VERWENDEN SIE DIESEN SERVER NICHT IN EINER PRODUKTIONSUMGEBUNG. Er hat keine Sicherheits- oder Leistungstests durchlaufen. Siehe auch Django-Dokumentation zu runserver.
Hinweis
Der integrierte Django-Server stellt statische Dateien nur mit aktiviertem DEBUG bereit, da er nur für die Entwicklung gedacht ist. Für den produktiven Einsatz beachten Sie bitte die WSGI-Einstellungen in Beispielkonfiguration für NGINX und uWSGI, Beispielkonfiguration für Apache, Beispielkonfiguration für Apache und Gunicorn und Bereitstellung statischer Dateien.
Bereitstellung statischer Dateien¶
Django muss seine statischen Dateien in einem einzigen Verzeichnis sammeln. Um dies zu tun, führen Sie weblate collectstatic --noinput aus. Dadurch werden die statischen Dateien in ein Verzeichnis kopiert, das durch die Einstellung STATIC_ROOT festgelegt ist (dies ist standardmäßig ein static-Verzeichnis innerhalb von CACHE_DIR).
Es wird empfohlen, statische Dateien direkt von Ihrem Webserver bereitzustellen, was Sie für die folgenden Pfade verwenden sollten:
/static/Stellt statische Dateien für Weblate und die Adminoberfläche bereit (definiert durch
STATIC_ROOT)./media/Wird für Medien-Uploads durch Benutzer (z. B. Bildschirmfotos) verwendet.
/favicon.icoSollte umgeschrieben werden, um eine Regel zur Bereitstellung von
/static/favicon.icoumzuschreiben.
Richtlinie zur Inhaltssicherheit¶
Die Standardkonfiguration von Weblate aktiviert die Middleware weblate.middleware.SecurityMiddleware, die sicherheitsbezogene HTTP-Header wie Content-Security-Policy oder X-XSS-Protection setzt. Diese sind standardmäßig so eingerichtet, dass sie mit Weblate und seiner Konfiguration zusammenarbeiten, aber dies muss möglicherweise an Ihre Einsatzumgebung angepasst werden.
Siehe auch
CSP_SCRIPT_SRC,
CSP_IMG_SRC,
CSP_CONNECT_SRC,
CSP_STYLE_SRC,
CSP_FONT_SRC
Beispielkonfiguration für NGINX und uWSGI¶
Um einen produktiven Webserver zu betreiben, verwenden Sie den mit Weblate installierten WSGI-Wrapper (in der virtuellen Umgebung wird er als ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py installiert). Vergessen Sie nicht, den Python-Suchpfad auch in virtualenv zu setzen (zum Beispiel mit virtualenv = /home/user/weblate-env in uWSGI).
In der folgenden Konfiguration wird Weblate als uWSGI unter dem NGINX-Webserver ausgeführt.
Konfiguration für NGINX (auch verfügbar als weblate/examples/weblate.nginx.conf):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location /media/ {
# DATA_DIR/media/
alias /home/weblate/data/media/;
expires 30d;
}
location / {
include uwsgi_params;
# Needed for long running operations in admin interface
uwsgi_read_timeout 3600;
# Adjust based to uwsgi configuration:
uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
# uwsgi_pass 127.0.0.1:8080;
}
}
Konfiguration für uWSGI (auch verfügbar als weblate/examples/weblate.uwsgi.ini):
#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins = python3
master = true
protocol = uwsgi
socket = 127.0.0.1:8080
wsgi-file = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py
# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path = /path/to/weblate
# In case you're using virtualenv uncomment this:
virtualenv = /home/weblate/weblate-env
# Needed for OAuth/OpenID
buffer-size = 8192
# Reload when consuming too much of memory
reload-on-rss = 250
# Increase number of workers for heavily loaded sites
workers = 8
# Enable threads for Sentry error submission
enable-threads = true
# Child processes do not need file descriptors
close-on-exec = true
# Avoid default 0000 umask
umask = 0022
# Run as weblate user
uid = weblate
gid = weblate
# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true
# Enable uWSGI stats server
# stats = :1717
# stats-http = true
# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true
Siehe auch
Beispielkonfiguration für Apache¶
Es wird empfohlen, prefork MPM zu verwenden, wenn WSGI mit Weblate genutzt wird.
Die folgende Konfiguration lässt Weblate als WSGI laufen, Sie müssen mod_wsgi aktiviert haben (verfügbar als weblate/examples/apache.conf):
#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# DATA_DIR/media/
Alias /media/ /home/weblate/data/media/
<Directory /home/weblate/data/media/>
Require all granted
</Directory>
# Path to your Weblate virtualenv
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Bemerkung
Weblate erfordert Python 3, also stellen Sie bitte sicher, dass Sie die Python 3-Variante des modwsgi verwenden. Normalerweise ist es als separates Paket verfügbar, zum Beispiel libapache2-mod-wsgi-py3.
Verwenden Sie die passende Python-Version, um Weblate zu installieren.
Beispielkonfiguration für Apache und Gunicorn¶
Die folgende Konfiguration führt Weblate in Gunicorn und Apache 2.4 aus (verfügbar als weblate/examples/apache.gunicorn.conf):
#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# DATA_DIR/media/
Alias /media/ /home/weblate/data/media/
<Directory /home/weblate/data/media/>
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/https_cert.cert
SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
SSLProxyEngine On
ProxyPass /favicon.ico !
ProxyPass /static/ !
ProxyPass /media/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Siehe auch
Weblate unter Pfad ausführen¶
Es wird empfohlen, prefork MPM zu verwenden, wenn WSGI mit Weblate genutzt wird.
Eine beispielhafte Apache-Konfiguration für die Bereitstellung von Weblate unter /weblate. Wiederum unter mod_wsgi (auch verfügbar als weblate/examples/apache-path.conf):
# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later
#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /weblate/static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# DATA_DIR/media/
Alias /weblate/media/ /home/weblate/data/media/
<Directory /home/weblate/data/media/>
Require all granted
</Directory>
# Path to your Weblate virtualenv
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Zusätzlich müssen Sie weblate/settings.py anpassen:
URL_PREFIX = "/weblate"
Hintergrundaufgaben mit Celery¶
Weblate verwendet Celery, um regelmäßige Aufgaben und Hintergrundaufgaben auszuführen. Sie sollten einen Celery-Dienst laufen lassen, der diese ausführt. Er ist zum Beispiel für die folgenden Vorgänge zuständig (diese Liste ist nicht vollständig):
Empfang von Webhooks von externen Diensten (siehe Benachrichtigungs-Hooks).
Durchführung regelmäßiger Wartungsaufgaben wie Sicherungen, Bereinigungen, tägliche Erweiterungen oder Aktualisierungen (siehe Sichern und Verschieben von Weblate,
BACKGROUND_TASKS, Erweiterungen).Ausführung von Automatische Übersetzung.
Zusammenfassungs-Benachrichtigungen senden.
Auslagerung aufwendiger Vorgänge aus dem WSGI-Prozess.
Übergabe ausstehender Änderungen (siehe Lazy Commits).
Eine typische Einrichtung mit Redis als Backend sieht wie folgt aus:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Siehe auch
Sie sollten auch den Celery-Worker starten, um die Aufgaben zu verarbeiten und geplante Aufgaben zu starten. Dies kann direkt auf der Befehlszeile erfolgen (was vor allem beim Debuggen oder Entwickeln nützlich ist):
./weblate/examples/celery start
./weblate/examples/celery stop
Bemerkung
Der Celery-Prozess muss unter demselben Benutzer wie der WSGI-Prozess ausgeführt werden, sonst werden die Dateien im DATA_DIR mit unterschiedlichen Besitzverhältnissen gespeichert, was zu Laufzeitproblemen führt.
Siehe auch Dateisystemberechtigungen und Hintergrundaufgaben mit Celery.
Ausführen von Celery-Aufgaben in der WSGI im Eager-Modus¶
Bemerkung
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 Committen ausstehender Änderungen, Zusammenfassungs-Benachrichtigungen oder Sicherungen).
Für Entwicklungszwecke möchten Sie vielleicht eine Eager-Konfiguration verwenden, die alle Aufgaben an Ort und Stelle verarbeitet:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Celery als Systemdienst ausführen¶
Höchstwahrscheinlich werden Sie Celery als Daemon laufen lassen wollen, und das wird in Daemonization behandelt. Für die gebräuchlichste Linux-Konfiguration mit systemd können Sie die Beispieldateien verwenden, die, wie im Ordner examples unten aufgelistet, geliefert werden.
Die Systemd-Unit muss als /etc/systemd/system/celery-weblate.service abgelegt werden:
[Unit]
Description=Celery Service (Weblate)
After=network.target
[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
-A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
--logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
--pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
-A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
--logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
[Install]
WantedBy=multi-user.target
Umgebungskonfiguration als :file:`/etc/default/celery-weblate`abzulegen:
# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"
# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"
# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"
# Extra command-line arguments to the worker,
# increase concurrency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
--queues:notify=notify --prefetch-multiplier:notify=10 \
--queues:memory=memory --prefetch-multiplier:memory=10 \
--queues:translate=translate --prefetch-multiplier:translate=4 \
--concurrency:backup=1 --queues:backup=backup --prefetch-multiplier:backup=2"
# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
# and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"
Zusätzliche Konfiguration für die Rotation der Celery-Logs mit logrotate, die als /etc/logrotate.d/celery abgelegt wird:
# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Regelmäßige Aufgaben mit Celery Beat¶
Weblate wird mit integrierten Einstellungen für geplante Aufgaben geliefert. Sie können jedoch zusätzliche Aufgaben in settings.py definieren, siehe zum Beispiel Lazy Commits.
Die Aufgaben sollen vom Celery-Beats-Daemon ausgeführt werden. Wenn er nicht richtig funktioniert, läuft er möglicherweise nicht oder seine Datenbank wurde beschädigt. Überprüfen Sie in einem solchen Fall die Startprotokolle von Celery, um die Ursache herauszufinden.
Celery-Status überwachen¶
Sie können die aktuelle Länge der Celery-Aufgabenwarteschlangen in der Verwaltungsoberfläche finden oder Sie können celery_queues auf der Befehlszeile verwenden. Falls die Warteschlange zu lang wird, erhalten Sie auch einen Konfigurationsfehler in der Adminoberfläche.
Warnung
Die Celery-Fehler werden standardmäßig nur im Celery-Log protokolliert und sind für den Benutzer nicht sichtbar. Falls Sie einen Überblick über solche Fehler haben möchten, wird empfohlen, Sammeln von Fehlerberichten und Überwachen der Leistung zu konfigurieren.
Celery-Einzelprozess einrichten¶
Wenn Sie über sehr wenig Speicher verfügen, sollten Sie die Anzahl der Weblate-Prozesse reduzieren. Alle Celery-Aufgaben können in einem einzigen Prozess ausgeführt werden:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Warnung
Dies wird sich spürbar auf die Leistung von Weblate auswirken.
Weblate überwachen¶
Weblate stellt die URL /healthz/ zur Verfügung, die für einfache Gesundheitsprüfungen verwendet werden kann, zum Beispiel mit Kubernetes. Der Docker-Container verfügt über integrierte Gesundheitsprüfungen, die diese URL verwenden.
Zur Überwachung der Metriken von Weblate können Sie den GET /api/metrics/ API-Endpunkt verwenden.
Siehe auch
Wie überprüft man ob Weblate richtig eingerichtet ist?, Celery-Status überwachen,`Weblate-Plugin für Munin <https://github.com/WeblateOrg/munin>`_
Sammeln von Fehlerberichten und Überwachen der Leistung¶
Weblate kann, wie jede andere Software auch, ausfallen. Um nützliche Fehlermeldungen zu sammeln, empfehlen wir die Nutzung von Drittanbieter-Diensten, um solche Informationen zu sammeln. Dies ist besonders nützlich bei fehlgeschlagenen Celery-Aufgaben, die sonst nur Fehler in den Logs melden würden und über die Sie nicht benachrichtigt werden. Weblate bietet Unterstützung für die folgenden Dienste:
Sentry¶
Weblate hat integrierte Unterstützung für Sentry. Um sie zu nutzen, genügt es, SENTRY_DSN in der settings.py zu setzen:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Sentry kann auch verwendet werden, um die Leistung von Weblate zu überwachen, indem Traces und Profile für einen bestimmten Prozentsatz von Operationen gesammelt werden. Dies kann mit SENTRY_TRACES_SAMPLE_RATE und SENTRY_PROFILES_SAMPLE_RATE konfiguriert werden.
Siehe auch
Rollbar¶
Weblate hat integrierte Unterstützung für Rollbar. Um sie zu nutzen, genügt es, den Anweisungen für Rollbar-Notifier für Python zu folgen.
Kurz gesagt, Sie müssen settings.py anpassen:
# Add rollbar as last middleware:
MIDDLEWARE = [
# … other middleware classes …
"rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]
# Configure client access
ROLLBAR = {
"access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
"client_token": "POST_CLIENT_ITEM_ACCESS_TOKEN",
"environment": "development" if DEBUG else "production",
"branch": "main",
"root": "/absolute/path/to/code/root",
}
Alles andere wird automatisch integriert, Sie werden jetzt sowohl server- als auch clientseitige Fehler sammeln.
Bemerkung
Die Fehlerprotokollierung umfasst auch Ausnahmen, die zwar anstandslos behandelt wurden, aber auf ein Problem hinweisen könnten, wie z. B. das fehlgeschlagene Analysieren einer hochgeladenen Datei.
Migration von Weblate auf einen anderen Server¶
Die Migration von Weblate auf einen anderen Server sollte ziemlich einfach sein, es speichert jedoch Daten an wenigen Orten, die Sie sorgfältig migrieren sollten. Der beste Ansatz ist, Weblate für die Migration zu stoppen.
Migration der Datenbank¶
Abhängig von Ihrem Datenbank-Backend haben Sie mehrere Möglichkeiten, die Datenbank zu migrieren. Der einfachste Ansatz ist die Verwendung datenbankeigener Tools, da diese normalerweise am effektivsten sind (z. B. mysqldump oder pg_dump). Alternativ können Sie auch die Replikation verwenden, falls Ihre Datenbank dies unterstützt.
Siehe auch
Migration zwischen Datenbanken, beschrieben in Migration von anderen Datenbanken zu PostgreSQL.
Migration der VCS-Repositorys¶
Die VCS-Repositorys, die unter DATA_DIR gespeichert sind, müssen ebenfalls migriert werden. Sie können sie einfach kopieren oder rsync verwenden, um die Migration effektiver durchzuführen.
Sonstige Anmerkungen¶
Vergessen Sie nicht, andere Dienste zu verschieben, die Weblate möglicherweise verwendet hat, wie Redis, Cron-Jobs oder benutzerdefinierte Authentifizierungs-Backends.