Konfigurationsanweisungen

Weblate installieren

Wählen Sie je nach Ihren Gegebenheiten und Ihrer Erfahrung eine für Sie geeignete Installationsmethode:

Architekturübersicht

digraph architecture { graph [fontname="sans-serif", fontsize=10, newrank=true, rankdir=LR, splines=ortho ]; node [fontname="sans-serif", fontsize=10, height=0, margin=.15, shape=box ]; edge [fontname="sans-serif", fontsize=10 ]; subgraph cluster_thirdparty { graph [color=lightgrey, label="Third-party services", style=filled ]; mt [label="Machine translation", style=dotted]; sentry [label="Sentry\nError collection", style=dotted]; mail [label="E-mail server"]; auth [label="SSO\nAuthentication provider", style=dotted]; } subgraph cluster_ingress { graph [color=lightgrey, label=Ingress, style=filled ]; web [label="Web server", shape=hexagon]; } subgraph cluster_weblate { graph [color=lightgrey, label="Weblate code-base", style=filled ]; celery [fillcolor="#144d3f", fontcolor=white, label="Celery workers", style=filled]; wsgi [fillcolor="#144d3f", fontcolor=white, label="WSGI server", style=filled]; } subgraph cluster_services { graph [color=lightgrey, label=Services, style=filled ]; redis [label="Redis\nTask queue\nCache", shape=cylinder]; db [label="PostgreSQL\nDatabase", shape=cylinder]; fs [label=Filesystem, shape=cylinder]; } web -> wsgi; web -> fs; celery -> mt [style=dotted]; celery -> sentry [style=dotted]; celery -> mail; celery -> redis; celery -> db; celery -> fs; wsgi -> mt [style=dotted]; wsgi -> sentry [style=dotted]; wsgi -> auth [style=dotted]; wsgi -> redis; wsgi -> db; wsgi -> fs; }

Web server

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

https://www.djangoproject.com/

Celery

https://docs.celeryq.dev/

Translate Toolkit

https://toolkit.translatehouse.org/

translation-finder

https://github.com/WeblateOrg/translation-finder

Python Social Auth

https://python-social-auth.readthedocs.io/

Django-REST-Framework

https://www.django-rest-framework.org/

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

https://git-scm.com/

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)

https://pypi.org/project/git-review/

git-svn (optional für Subversion-Unterstützung)

https://git-scm.com/docs/git-svn

tesseract (nur erforderlich, wenn keine Binary Wheels von tesserocr für das System verfügbar sind)

https://github.com/tesseract-ocr/tesseract

licensee (optional zur Erkennung der Lizenz beim Erstellen der Komponente)

https://github.com/licensee/licensee

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).

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.

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

PostgreSQL notes

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.

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_TABLES eingestellt 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.

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;

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"

Anpassen der Konfiguration

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_CONTACT ist konfiguriert.

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"

DATABASES

Verbindung zum Datenbankserver, bitte lesen Sie die Django-Dokumentation für weitere Details.

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.

DEFAULT_FROM_EMAIL

E-Mail-Absenderadresse für ausgehende E-Mails, z. B. Registrierungs-E-Mails.

Siehe auch

DEFAULT_FROM_EMAIL

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

SECRET_KEY

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

SERVER_EMAIL

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.

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:

../_images/admin-wrench.webp

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.

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.

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"),)

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.

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

SECRET_KEY

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'

Verwenden der benutzerdefinierten Zertifizierungsstelle

Weblate prüft SSL-Zertifikate bei HTTP-Anfragen. Wenn Sie eine benutzerdefinierte Zertifizierungsstelle verwenden, der in den Standardpaketen nicht vertraut wird, müssen Sie ihr Zertifikat als vertrauenswürdig hinzufügen.

Der bevorzugte Ansatz ist, dies auf Systemebene zu tun. Bitte lesen Sie die Dokumentation Ihrer Distribution für weitere Details (unter Debian kann dies zum Beispiel durch das Ablegen des CA-Zertifikats in /usr/local/share/ca-certificates/ und dem Ausführen von update-ca-certificates erfolgen).

Sobald dies geschehen ist, vertrauen die Systemprogramme dem Zertifikat, so auch Git.

Für Python-Code müssen Sie die Anfragen so konfigurieren, dass das System-CA-Bundle anstelle des mitgelieferten Pakets verwendet wird. Dies kann erreicht werden, indem der folgende Ausschnitt in settings.py eingefügt wird (der Pfad ist Debian-spezifisch):

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

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:

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.ico

Sollte umgeschrieben werden, um eine Regel zur Bereitstellung von /static/favicon.ico umzuschreiben.

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.

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

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>

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):

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

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.

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.

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.