Instructies voor configureren¶
Weblate installeren¶
Kies, afhankelijk van uw instellingen en ervaring, een voor u toepasselijke methode om te installeren:
Installeren met Docker, aanbevolen voor productie-instellingen.
Installeren met virtualenv, aanbevolen voor productie-instellingen:
Installeren uit bronnen, aanbevolen voor ontwikkeling.
Overzicht architectuur¶
- Webserver
Afhandeling van inkomende HTTP-verzoeken, Statische bestanden serveren.
- Celery-werkers
Achtergrondtaken met Celery worden hier uitgevoerd.
Afhankelijk van uw werklast wilt u misschien het aantal werkers aanpassen.
Gebruik de toegewezen node bij het horizontaal op schaal brengen van Weblate.
- WSGI-server
Een WSGI-server serveert webpagina’s aan gebruikers.
Gebruik de toegewezen node bij het horizontaal op schaal brengen van Weblate.
- Database
PostgreSQL databaseserver voor het opslaan van alle inhoud, bekijk Instellingen database voor Weblate.
Gebruik een toegewezen node voor de database voor sites met honderden miljoenen gehoste woorden.
- Redis
Redis-server voor cache en wachtrij voor taken, bekijk Achtergrondtaken met Celery.
Gebruik de toegewezen node bij het horizontaal op schaal brengen van Weblate.
- Bestandssysteem
Opslag in bestandssysteem voor het opslaan van opslagruimten van het VCS en geüploade gebruikersgegevens. Dit wordt gedeeld door alle processen.
Gebruik opslag in een netwerk bij het horizontaal schalen van Weblate.
- E-mailserver
SMTP-server voor uitgaande e-mail, bekijk Configureren van uitgaande e-mail. Het kan extern worden verschaft.
Hint
Installeren met Docker bevat PostgreSQL en Redis, wat het installeren gemakkelijker maakt.
Software vereisten¶
Besturingssysteem¶
Weblate werkt goed op Linux, FreeBSD en macOS. Andere op Unix gelijkende systemen zullen zeer waarschijnlijk ook goed werken.
Weblate wordt niet ondersteund op Windows. Maar het zou nog steeds kunnen werken en patches worden met vreugde geaccepteerd.
Zie ook
Overzicht architectuur beschrijft de algehele architectuur van Weblate en de vereiste services.
Python afhankelijkheden¶
Weblate is geschreven in Python en ondersteunt Python 3.11 of nieuwer. U kunt afhankelijkheden installeren met pip of vanuit de pakketten van uw distributie, de volledige lijst is beschikbaar in requirements.txt.
Meest opvallende afhankelijkheden:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Django REST Framework
Specificatie optionele afhankelijkheden |
Python pakketten |
Weblate mogelijkheid |
|---|---|---|
|
||
|
||
|
||
|
||
|
||
|
Google Cloud Translation Advanced met ondersteuning voor woordenlijst |
|
|
||
|
||
|
MySQL of MariaDB, bekijk Instellingen database voor Weblate |
|
|
||
|
PostgreSQL, bekijk Instellingen database voor Weblate |
|
|
||
|
Integreren van SAML 2 IDP in Weblate |
|
|
Hosted Weblate integratie |
|
|
Hosted Weblate integratie |
|
|
WSGI-server voor Weblate |
|
|
Bij het installeren met pip, kunt u direct de gewenste mogelijkheden specificeren bij het installeren:
uv pip install "weblate[Postgres,Amazon,SAML]"
Of u kunt Weblate installeren met alle optionele mogelijkheden:
uv pip install "weblate[all]"
Of u kunt Weblate installeren zonder optionele mogelijkheden:
uv pip install weblate
Andere systeemvereisten¶
De volgende afhankelijkheden moeten op het systeem zijn geïnstalleerd:
Git- Pango, Cairo en gerelateerde header-bestanden en GObject introspectie-gegevens
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, see Pango en Cairo
git-review(optioneel voor ondersteuning voor Gerrit)git-svn(optioneel voor ondersteuning van Subversion)tesseract(alleen nodig als tesserocr binaire wheels niet beschikbaar zijn voor uw systeem)licensee(optioneel voor detecteren van licentie bij maken van onderdeel)
Afhankelijkheden tijdens bouwen¶
U zou misschien, om enkele van de Python afhankelijkheden te bouwen, enkele van hun afhankelijkheden moeten installeren. Dit is afhankelijk van de manier waarop u ze installeert, raadpleeg dus uw individuele pakketten voor documentatie. U heeft deze niet nodig als u vooraf gebouwde Wheels gebruikt tijdens het installeren met pip of als u pakketten van distributies gebruikt.
Pango en Cairo¶
Weblate gebruikt Pango en Cairo voor het renderen van bitmapwidgets (bekijk De vertaling promoten) en controles voor renderen (bekijk Lettertypen beheren). U moet, om de bindingen voor Python hiervoor juist te installeren, eerst systeembibliotheken installeren - u heeft zowel Cairo als Pango nodig, die op hun beurt GLib nodig hebben. Deze zouden allemaal moeten worden geïnstalleerd met ontwikkkelingsbestanden en GObject introspectiegegevens.
Hardware vereisten¶
Weblate zou zonder problemen moeten kunnen worden uitgevoerd op elke hedendaagse hardware, het volgende is de minimale configuratie die is vereist om Weblate uit te voeren als een enkele host (Weblate, database en webserver):
3 GB RAM
2 CPU-bronnen
1 GB opslagruimte
Notitie
Feitelijke vereisten voor uw installatie van Weblate kunnen enorm variëren, gebaseerd op de grootte van de vertalingen die erin beheerd moeten worden.
Geheugengebruik¶
Hoe meer geheugen hoe beter - het wordt gebruikt voor cachen op alle niveaus (bestandssysteem, database en Weblate). Voor honderden vertaalonderdelen wordt ten minste 4 GB RAM aanbevolen.
Hint
Voor systemen met minder geheugen dan aanbevolen, wordt Opstelling een-proces Celery aanbevolen.
CPU-gebruik¶
Veel gelijktijdige gebruikers verhogen het aantal benodigde CPU-bronnen.
Opslaggebruik¶
Het gewoonlijke gebruik voor opslag van de database ligt rond de 300 MB per 1 miljoen gehoste woorden.
Opslagruimte die nodig is voor gekloonde opslagruimten varieert, maar Weblate probeert hun grootte minimaal te houden door oppervlakkig te klonen.
Knooppunt¶
Voor kleine en gemiddelde sites (miljoenen gehoste woorden), kunnen alle onderdelen van Weblate (bekijk Overzicht architectuur) worden uitgevoerd op ene enkel knooppunt.
Wanneer u groeit naar honderden miljoenen gehoste woorden, wordt aanbevolen om een toegewezen knooppunt voor de database te hebben (bekijk Instellingen database voor Weblate).
Verifiëren van handtekeningen van uitgaven¶
Uitgaven van Weblate zijn cryptografisch ondertekend met Sigstore handtekeningen. De handtekeningen zijn gekoppeld aan de uitgave op GitHub.
Verificatie kan worden uitgevoerd met het sigstore-pakket. Het volgende voorbeeld verifieert de handtekening van de uitgave 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
Rechten voor bestandssysteem¶
Het proces van Weblate moet in staat zijn te lezen en schrijven naar de map waarin de gegevens worden bewaard - DATA_DIR. Alle bestanden binnen die map zouden eigendom moeten zijn van en kunnen worden geschreven door de gebruiker die alle processen van Weblate uitvoert (gewoonlijk WSGI en Celery, bekijk Server uitvoeren en Achtergrondtaken met Celery).
De standaard configuratie plaatst ze in dezelfde boom als de bronnen voor Weblate, het zou echter uw voorkeur kunnen hebben deze te verplaatsen naar een betere locatie, zoals: /var/lib/weblate.
Weblate probeert om deze mappen automatisch te maken, maar dat zal mislukken als het geen rechten heeft om dit te doen.
U zou ook voorzichtig moeten zijn bij het uitvoeren van Opdrachten voor beheer, omdat dat moet worden uitgevoerd onder dezelfde gebruiker als die welke Weblate zelf uitvoert, anders zouden rechten voor bepaalde bestanden misschien verkeerd zijn.
In de Docker container moeten alle bestanden in het volume /app/data eigendom zijn van de gebruiker weblate binnen de container (UID 1000).
Zie ook
Instellingen database voor Weblate¶
Aanbevolen wordt om Weblate uit te voeren met een PostgreSQL databaseserver.
PostgreSQL 13 en hoger wordt ondersteund. PostgreSQL 15 of nieuwer wordt aanbevolen.
MySQL en MariaDB wordt ondersteund, maar wordt niet aanbevolen voor nieuwe installaties.
Notitie
Momenteel worden geen andere databaseservers ondersteund, maar ondersteuning voor andere door Django ondersteunde databases zou mogelijk geïmplementeerd moeten kunnen worden.
Zie ook
Een krachtig databaseprogramma gebruiken, Databases, Migreren vanuit andere databases naar PostgreSQL
Databaseverbindingen¶
In de standaard configuratie behoudt elk proces van Weblate een blijvende verbinding met de database. Blijvende verbindingen verbeteren de reactie door Weblate, maar zouden meer bronnen voor de databaseserver kunnen vereisen. Raadpleeg CONN_MAX_AGE en Persistent connections voor meer informatie.
Weblate heeft ten minste het volgende aantal verbindingen nodig:
\((4 \times \mathit{nCPUs}) + 2\) voor processen van Celery
\(\mathit{nCPUs} + 1\) voor werkers van WSGI
Dit is van toepassing op Docker container standaarden en voorbeeld configuraties die worden verschaft in deze documentatie, maar de aantallen zullen wijzigen als u het aantal werkers voor WSGI aanpast of het parallellisme van Celery aanpast.
De feitelijke limiet voor het aantal databaseverbindingen moet hoger zijn om rekening te houden met de volgende situaties:
Opdrachten voor beheer heeft ook zijn verbinding nodig.
Als het proces case wordt beëindigd (bijvoorbeeld door OOM killer), zou het de bestaande verbinding kunnen blokkeren tot time-out.
PostgreSQL¶
PostgreSQL is gewoonlijk de beste keuze voor op Django gebaseerde sites. Het is de verwijzingsdatabase die wordt gebruikt voor het implementeren van de databaselaag voor Django.
Notitie
Weblate gebruikt de extensie trigram die in sommige gevallen afzonderlijk moet worden geïnstalleerd. Zoek naar postgresql-contrib of een soortgelijk genaamd pakket.
Zie ook
Een database maken in PostgreSQL¶
Het is gewoonlijk een goed idee om Weblate uit te voeren in een afzonderlijke database, en afzonderlijk gebruikersaccount:
# 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
Hint
Als u de gebruiker van Weblate geen superuser in PostgreSQL wilt maken, kun u dat weglaten. In dat geval zult u enkele stappen voor de migratie handmatig moeten uitvoeren, omdat een superuser van PostgreSQL in het schema Weblate zal gebruiken:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Weblate configureren om PostgreSQL te gebruiken¶
De snipper uit settings.py voor PostgreSQL:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.postgresql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# Configures name of the PostgreSQL role to alter during the database migration
# "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,
}
}
De migratie van de database voert uit ALTER ROLE op de rol van de database die wordt gebruikt door Weblate. In de meeste gevallen komt de naam van de rol overeen met de gebruikersnaam. In meer complexe opstellingen is de naam van de rol een andere dan de gebruikersnaam, en zult u een fout krijgen over een niet bestaande rol tijdens het migreren van de database (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Bekend is dat dit gebeurt met Azure Database voor PostgreSQL, maar het is niet beperkt tot die omgeving. Stel ALTER_ROLE in om de naam van de rol te wijzigen die Weblate zou moeten wijzigen tijdens het migreren van de database.
Zie ook
MySQL en MariaDB¶
Waarschuwing
Hoewel ondersteuning voor MySQL en MariaDB nog steeds wordt onderhouden in Weblate, ligt onze primaire focus op PostgreSQL. Aanbevolen wordt om PostgreSQL te gebruiken voor nieuwe installaties, en om bestaande installaties te migreren naar PostgreSQL, bekijk Migreren vanuit andere databases naar PostgreSQL.
Sommige mogelijkheden van Weblate zullen beter presteren met PostgreSQL. Dit omvat zoeken en vertaalgeheugen, die beide de mogelijkheden voor volledige tekst in de database gebruiken en de implementatie van PostgreSQL daarin is superieur.
Weblate kan ook worden gebruikt met MySQL of MariaDB, bekijk MySQL notes en MariaDB notes voor valkuilen bij het gebruiken van Django daarbij. Vanwege de beperkingen wordt aanbevolen om PostgreSQL te gebruiken voor nieuwe installaties.
Weblate vereist ten minste MySQL 8 of ten minste MariaDB 10.5.
De volgende configuratie wordt aanbevolen voor Weblate:
Gebruik de tekenset
utf8mb4om weergave van de hogere vlakken in Unicode mogelijk te maken (bijvoorbeeld emoji’s).Configureer de server met
innodb_large_prefixom langere indices voor tekstvelden mogelijk te maken.Stel het niveau voor isoleren in op
READ COMMITTED.De modus voor SQL zou moeten zijn ingesteld op
STRICT_TRANS_TABLES.
MySQL 8.x, MariaDB 10.5.x of nieuwer hebben een redelijke standaard configuratie, zodat aanpassen van de server niet nodig zou zijn en alles wat nodig zou kunnen zijn kan worden geconfigureerd aan de kant van de cliënt.
Hieronder staat een voorbeeld /etc/my.cnf.d/server.cnf voor een server met 8 GB RAM. Deze instellingen zouden voldoende moeten zijn voor de meeste installaties. MySQL en MariaDB zijn zo af te stemmen dat de prestaties van uw server worden verhoogd, maar die worden geacht niet nodig te zijn, tenzij u van plan bent om tegelijkertijd grote aantallen gebruikers toe te laten tot het systeem. Bekijk de verscheidene documentatie van verkopers voor deze details.
Het is absoluut kritisch voor het verminderen van problemen bij het installeren dat de instelling innodb_file_per_table juist is ingesteld en dat MySQL/MariaDB opnieuw wordt gestart voordat u Weblate installeert.
[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
Hint
In het geval dat u de fout #1071 - Specified key was too long; max key length is 767 bytes krijgt, werk uw configuratie bij door de instellingen innodb van hierboven op te nemen en start uw installatie opnieuw.
Hint
In het geval dat u de fout #2006 - MySQL server has gone away krijgt, zou configureren van CONN_MAX_AGE kunnen helpen.
Zie ook
Weblate configureren om te gebruiken met MySQL/MariaDB¶
De snipper uit settings.py voor MySQL en 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": {},
}
}
U zou ook het gebruikersaccount weblate in MySQL of MariaDB moeten maken voordat u de installatie begint. Gebruik de opdrachten hieronder om dat te doen:
GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
Zie ook
Andere configuraties¶
Configureren van uitgaande e-mail¶
Weblate verzendt e-mails bij verschillende gebeurtenissen - voor het activeren van een account en bij verscheidene notificaties die worden geconfigureerd door gebruikers. Hiervoor heeft het toegang nodig tot een SMTP-server.
Het instellen van de mailserver wordt geconfigureerd met deze instellingen: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER en EMAIL_PORT. Hun namen verklaren zichzelf voldoende, maar u kunt meer informatie vinden in de documentatie van Django.
Hint
In het geval u een fout krijgt over niet ondersteunde authenticatie (bijvoorbeeld SMTP AUTH extension not supported by server), wordt dat heel waarschijnlijk veroorzaakt door een onveilige verbinding te gebruiken en de server weigert op die manier te authenticeren. Probeer in een dergelijk geval EMAIL_USE_TLS in te schakelen.
Uitvoeren achter een omgekeerde proxy¶
Verscheidene mogelijkheden in Weblate vertrouwen erop een cliënt IP-adres op te kunnen halen. Dit omvat Opvraaglimiet gebruiken, Spambeveiliging of Revisielogboek.
Weblate parst het IP-adres vanuit het REMOTE_ADDR dat is ingesteld door de afhandeling van WSGI. Dit zou leeg kunnen zijn (als een socket wordt gebruikt voor WSGI) of een omgekeerd proxy-adres kunnen bevatten, dus Weblate heeft een aanvullende kop HTTP nodig met het IP-adres van de cliënt.
Instellen van IP_BEHIND_REVERSE_PROXY zou genoeg kunnen zijn voor de meest gewone opstellingen, maar u zou misschien IP_PROXY_HEADER en IP_PROXY_OFFSET ook moeten aanpassen (gebruik WEBLATE_IP_PROXY_HEADER en WEBLATE_IP_PROXY_OFFSET in de container van Docker).
Hint
Deze configuratie kan niet ingeschakeld worden, omdat dat het voor het IP-adres mogelijk zou maken om te spoofen op installaties die geen juist geconfigureerde omgekeerde proxy hebben.
Een ander ding dat moet worden verzorgd is de kop Host. Het zou overeen moeten komen met dat wat is geconfigureerd als SITE_DOMAIN. Aanvullende configuratie in uw omgekeerde proxy zou misschien nodig kunnen zijn (gebruik bijvoorbeeld ProxyPreserveHost On voor Apache of proxy_set_header Host $host; met nginx).
Zie ook
Spambeveiliging,
Opvraaglimiet gebruiken,
Revisielogboek,
Voorbeeld configuratie voor NGINX en uWSGI,
Voorbeeld configuratie voor NGINX en Gunicorn,
Voorbeeld configuratie voor Apache,
Voorbeeld configuratie voor Apache en Gunicorn,
IP_BEHIND_REVERSE_PROXY,
IP_PROXY_HEADER,
IP_PROXY_OFFSET,
SECURE_PROXY_SSL_HEADER,
WEBLATE_IP_PROXY_HEADER,
WEBLATE_IP_PROXY_OFFSET
HTTP proxy¶
Weblate voert geen opdrachten voor VCS uit en die accepteren de proxyconfiguratie uit de omgeving. De aanbevolen benadering is om de instellingen voor de proxy te definiëren in settings.py:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Zie ook
Configuratie aanpassen¶
Zie ook
Kopieer weblate/settings_example.py naar weblate/settings.py en pas het aan zodat het overeen komt met uw opstelling. U zult waarschijnlijk de volgende opties willen veranderen:
ADMINS
Lijst met beheerders van de site om notificaties te ontvangen als er iets mis gaat, bijvoorbeeld notificaties voor mislukte samenvoegingen, of fouten in Django.
Contactformulier verzendt hier ook e-mail over, tenzij
ADMINS_CONTACTis geconfigureerd.
ALLOWED_HOSTS
U moet dit instellen met de vermelding van de hosts die uw site wordt geacht te serveren. Bijvoorbeeld:
ALLOWED_HOSTS = ["demo.weblate.org"]Als alternatief kunt u een jokerteken opnemen:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Configureer hoe uw sessies zullen worden opgeslagen. In het geval dat u de standaard backend van het database-programma behoud, zou u: weblate clearsessions in het schema moeten opnemen om gegevens van verouderde sessies uit de database te verwijderen.
Als u Redis gebruikt als cache (bekijk Cachen inschakelen) wordt aanbevolen om het ook voor sessies te gebruiken:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
DATABASES
Connectiviteit met de databaseserver, controleer de documentatie van Django voor meer details.
DEBUG
Schakel dit voor alle productieservers uit. Met de modus debug ingeschakeld, zal Django, in het geval van fouten, sporen die terugvoeren naar die fouten aan gebruikers sturen, wanneer u het uitschakelt zullen de fouten per e-mail worden verzonden aan
ADMINS(zie boven).Modus Debug vertraagt ook Weblate, omdat Django in dat geval veel meer informatie intern opslaat.
Zie ook
DEFAULT_FROM_EMAIL
E-mailadres afzender voor uitgaande e-mail, bijvoorbeeld e-mails voor het registreren.
Zie ook
SECRET_KEY
Sleutel, gebruikt door Django, om enige informatie te tekenen in cookies, bekijk Django geheime sleutel voor meer informatie.
Zie ook
SERVER_EMAIL
E-mail, gebruikt als afzenderadres, voor het sturen van e-mails aan de beheerder, bijvoorbeeld notificaties voor mislukt samenvoegen.
Zie ook
De database vullen¶
Nadat uw configuratie voltooid is, kunt u migrate uitvoeren om de structuur van de database te maken. Nu zou u in staat moeten zijn vertaalprojecten te maken met de beheerinterface.
Als u daar eenmaal klaar mee bent zou u ook Prestatieverslag in de beheerinterface moeten controleren, dat u hints zal geven over potentiële niet optimale configuratie voor uw site.
Zie ook
Productie opstelling¶
Voor een productie opstelling zou u aanpassingen moeten uitvoeren die zijn beschreven in de volgende gedeelten. De meest kritische instellingen zullen een waarschuwing activeren, die wordt aangegeven door een uitroepteken in de bovenste balk indien ingelogd als een superuser:
Ook wordt aanbevolen de controles te inspecteren die worden geactiveerd door Django (hoewel u ze niet allemaal zou hoeven te repareren):
weblate check --deploy
U kunt ook precies dezelfde controlelijst bekijken in Prestatieverslag van de Beheerinterface.
Zie ook
Modus Debug uitschakelen¶
Schakel de modus Debug van Django uit (DEBUG) met:
DEBUG = False
Met de modus Debug ingeschakeld slaat Django alle uitgevoerde query’s op en laat gebruikers sporen zien die terugvoeren naar fouten, wat in een productie opstelling niet gewenst is.
Zie ook
Juist geconfigureerde beheerders¶
Stel de correcte adressen voor de beheerders in voor de instelling ADMINS om te definiëren wie e-mails moet ontvangen als er iets mis gaat met de server, bijvoorbeeld:
ADMINS = (("Your Name", "your_email@example.com"),)
Zie ook
Correcte domein site instellen¶
Pas de naam van de site en het domein aan in de beheerinterface, anders zullen koppelingen in RSS of e-mails voor registreren niet werken. Dit wordt geconfigureerd met SITE_DOMAIN wat de domeinnaam van de site zou moeten bevatten.
Veranderd in versie 4.2: Voorafgaande aan de uitgave 4.2 werd in plaats daarvan het framewerk sites van Django gebruikt, bekijk The “sites” framework.
Configureer HTTPS correct¶
Sterk aanbevolen wordt om Weblate uit te voeren met het versleutelde protocol HTTPS. Na het inschakelen daarvan zou u ENABLE_HTTPS moeten instellen in de instellingen:
ENABLE_HTTPS = True
Hint
U zou misschien ook HSTS willen instellen, bekijk SSL/HTTPS voor meer details.
SECURE_HSTS_SECONDS juist instellen¶
Als uw site wordt geserveerd over SSL, moet u een waarde overwegen voor SECURE_HSTS_SECONDS in settings.py om HTTP Strict Transport Security in te schakelen. Standaard is het ingesteld op 0, zoals hieronder weergegeven.
SECURE_HSTS_SECONDS = 0
Indien ingesteld op een niet nul waarde Integer, stelt django.middleware.security.SecurityMiddleware de kop HTTP Strict Transport Security in voor alle antwoorden die dat nog niet hebben.
Waarschuwing
Verkeerd instellen hiervan kan onomkeerbaar (voor enige tijd) uw site verstoren. Lees eerst de documentatie HTTP Strict Transport Security.
Een krachtig databaseprogramma gebruiken¶
Gebruik PostgreSQL voor een productieomgeving, bekijk Instellingen database voor Weblate voor meer informatie.
Gebruik een aanliggende locatie voor het uitvoeren van de databaseserver, anders zouden de prestaties van het netwerk of de betrouwbaarheid ervan uw ervaring met Weblate kunnen ruïneren.
Controleer de prestaties van de databaseserver of pas zijn configuratie aan, door bijvoorbeeld PGTune te gebruiken.
Cachen inschakelen¶
Gebruik, indien mogelijk, Redis vanuit Django door de variabele voor de configuratie CACHES aan te passen, bijvoorbeeld:
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",
},
}
}
Hint
In het geval u instellingen van Redis voor de cache wijzigt, moet u ze misschien ook voor Celery aanpassen, bekijk Achtergrondtaken met Celery.
Zie ook
Cachen avatar¶
In aanvulling op het cachen van Django, voert Weblate ook cachen van avatars uit. Aanbevolen wordt om hiervoor een afzonderlijke, door bestanden gesteunde, cache te gebruiken:
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,
},
},
}
Verzenden van e-mail configureren¶
Weblate moet e-mails kunnen verzenden bij verscheidene gelegenheden, en deze e-mails zouden juiste afzenderadres moeten hebben, configureer SERVER_EMAIL en DEFAULT_FROM_EMAIL om overeen te komen met uw omgeving, bijvoorbeeld:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Notitie
Stel, om het verzenden van e-mails door Weblate uit te schakelen, EMAIL_BACKEND in op django.core.mail.backends.dummy.EmailBackend.
Dit zal alle aflevering van e-mail uitschakelen, inclusief e-mails voor registreren of herstellen van wachtwoorden.
Instellen van toegestane hosts¶
Django vereist ALLOWED_HOSTS om een lijst te bevatten van domeinnamen die uw site mag serveren, leeg laten zal alle verzoeken blokkeren.
In het geval dit niet is geconfigureerd om overeen te komen met uw server van HTTP, zult u fouten krijgen als Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
Hint
Op de Docker container is dit beschikbaar als WEBLATE_ALLOWED_HOSTS.
Django geheime sleutel¶
De instelling SECRET_KEY wordt door Django gebruikt om cookies te ondertekenen, en u zou echt uw eigen waarde moeten genereren, in plaats van die uit de voorbeeld opstelling te gebruiken.
U kunt een nieuwe sleutel maken met weblate-generate-secret-key dat met Weblate wordt meegeleverd.
Zie ook
Onderhoudstaken uitvoeren¶
Voor optimale prestaties is het een goed idee om enkele onderhoudstaken op de achtergrond uit te voeren. Dit wordt automatisch gedaan door Achtergrondtaken met Celery en behandelt de volgende taken:
Gezondheidscontrole configuratie (elk uur).
Openstaande wijzigingen doorvoeren (elk uur), bekijk Vetraagd indienen en
commit_pending.Alarmen voor onderdelen bijwerken (dagelijks).
Takken op afstand bijwerken (‘s nachts), bekijk
AUTO_UPDATE.Back-up vertaalgeheugen naar JSON (dagelijks), bekijk
dump_memory.Onderhoudstaken voor volledige tekst en database (dagelijkse en wekelijkse taken), bekijk
cleanuptrans.
Systeemlocalen en codering¶
De systeemlocalen zouden moeten zijn geconfigureerd naar die welke geschikt zijn voor UTF-8. Op de meeste distributies voor Linux is dat de standaard instelling. In het geval dat het voor uw systeem niet het geval is, wijzig locales naar de variant UTF-8.
Bijvoorbeeld door /etc/default/locale te bewerken en daar in te stellen LANG="C.UTF-8".
In sommige gevallen hebben de individuele services afzonderlijke configuratie voor locales. Dit varieert tussen distributie en webservers, dus controleer de documentatie van de pakketten voor uw webserver daarop.
Apache op Ubuntu gebruikt /etc/apache2/envvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache op CentOS gebruikt /etc/sysconfig/httpd (of /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Comprimeren toebehoren cliënt¶
Weblate komt met heel veel bestanden voor JavaScript en CSS. Om redenen van prestaties is het goed om ze te comprimeren voordat ze naar een cliënt worden verzonden. In de standaard configuratie wordt dit direct uitgevoerd ten koste van een kleine extra belasting. Op grote installaties wordt aanbevolen om de offline modus voor comprimeren in te schakelen. Dat moet worden gedaan in de configuratie en de compressie moet worden geactiveerd bij elke upgrade van Weblate.
Het inschakelen in de configuratie is eenvoudig door django.conf.settings.COMPRESS_OFFLINE in te schakelen en django.conf.settings.COMPRESS_OFFLINE_CONTEXT te configureren (de laatste is al opgenomen in de voorbeeldconfiguratie):
COMPRESS_OFFLINE = True
Bij elke uitrol moet u de bestanden comprimeren om overeen te komen met de huidige versie:
weblate compress
Hint
De officiële Docker image heeft deze mogelijkheid al ingeschakeld.
Server uitvoeren¶
Hint
In het geval u geen ervaring hebt met de services die hieronder beschreven worden, zou u misschien Installeren met Docker willen proberen.
U zult verschillende services nodig hebben om Weblate uit te voeren, de aanbevolen opstelling bestaat uit:
Databaseserver (bekijk Instellingen database voor Weblate)
Cacheserver (bekijk Cachen inschakelen)
Frontend webserver voor statische bestanden en beëindigen van SSL (bekijk Statische bestanden serveren)
WSGI-server voor dynamische inhoud (bekijk Voorbeeld configuratie voor NGINX en uWSGI)
Celery voor het uitvoeren van taken op de achtergrond (bekijk Achtergrondtaken met Celery)
Notitie
Er bestaan enkele afhankelijkheden tussen de services, cache en database zouden bijvoorbeeld moeten worden uitgevoerd bij het opstarten van Celery of uWSGI-processen.
In de meeste gevallen zult u alle services uitvoeren op een enkele (virtuele) server, maar voor het geval uw installatie nogal vol is, kunt u de services opsplitsen. De enige beperking hierin is dat Celery- en WSGI-servers toegang nodig hebben tot DATA_DIR.
Notitie
Het proces van WSGI moet worden uitgevoerd onder dezelfde gebruiker als die voor het proces van Celery, anders zullen bestanden in de DATA_DIR worden opgeslagen met gemixte eigenaren, wat leidt tot problemen tijdens uitvoering.
Bekijk ook Rechten voor bestandssysteem en Achtergrondtaken met Celery.
Webserver uitvoeren¶
Uitvoeren van Weblate is niet anders dan het uitvoeren van enig ander op Django gebaseerd programma. Django wordt gewoonlijk uitgevoerd als WSGI of fcgi (bekijk voorbeelden voor de verschillende webservers hieronder).
U kunt, om te testen, de ingebouwde webserver in Django gebruiken:
weblate runserver
Waarschuwing
GEBRUIK DEZE SERVER NIET IN EEN PRODUCTIE OPSTELLING. Het heeft niet voldoende beveiligingstesten ondergaan of prestatietesten. Bekijk ook de documentatie van Django op runserver.
Hint
De ingebouwde server van Django serveert statische bestanden alleen met DEBUG ingeschakeld, omdat het alleen voor ontwikkeling is bedoeld. Voor gebruik in productie, bekijk de opstellingen voor WSGI in Voorbeeld configuratie voor NGINX en uWSGI, Voorbeeld configuratie voor Apache, Voorbeeld configuratie voor Apache en Gunicorn, en Statische bestanden serveren.
Statische bestanden serveren¶
Django moet zijn statische bestanden verzamelen in een enkele map. Voer, om dat te doen, weblate collectstatic --noinput uit. Dat zal de statische bestanden kopiëren naar een map die wordt gespecificeerd door de instelling STATIC_ROOT (dit is standaard een map static binnen CACHE_DIR).
Aanbevolen wordt om statische bestanden direct vanaf uw webserver te serveren, u zou dat moeten gebruiken voor de volgende paden:
/static/Serveert statische bestanden voor Weblate en de beheerinterface (die wordt gedefinieerd door
STATIC_ROOT)./media/Gebruikt voor uploaden van gebruikersmedia (bijv. schermafdrukken).
/favicon.icoZou moeten worden herschreven om een regel te herschrijven om te serveren
/static/favicon.ico.
Beleid beveiliging inhoud¶
De standaard configuratie van Weblate schakelt middleware weblate.middleware.SecurityMiddleware in die op beveiliging gerelateerde HTTP-koppen, zoals Content-Security-Policy of X-XSS-Protection, instelt. Deze worden standaard ingesteld om te werken met Weblate en zijn configuratie, maar dit zou aanpassingen kunnen vergen voor uw omgeving.
Voorbeeld configuratie voor NGINX en Gunicorn¶
De volgende configuratie voert Weblate met Gunicorn onder de webserver NGINX (ook beschikbaar als weblate/examples/weblate.nginx.gunicorn.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 / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://unix:/run/gunicorn.sock;
proxy_read_timeout 3600;
}
}
Voorbeeld configuratie voor NGINX en uWSGI¶
Gebruik, om de productie webserver uit te voeren, de WSGI-wrapper die wordt geïnstalleerd met Weblate (in het geval van een virtuele omgeving is dit geïnstalleerd als ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py). Vergeet niet om het zoekpad naar Python naar uw virtualenv ook in te stellen (bijvoorbeeld met virtualenv = /home/user/weblate-env in uWSGI).
De volgende configuratie voert Weblate als uWSGI uit onder de webserver NGINX.
Configuratie voor NGINX (ook beschikbaar 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;
}
}
Configuratie voor uWSGI (ook beschikbaar 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
Zie ook
Voorbeeld configuratie voor Apache¶
Aanbevolen wordt om MPM vooraf te forken bij het gebruiken van WSGI met Weblate.
De volgende configuratie voert Weblate uit als WSGI, u moet mod_wsgi hebben ingeschakeld (beschikbaar 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>
Notitie
Weblate vereist Python 3, zorg er dus voor dat u de variant voor Python 3 van modwsgi uitvoert. Gewoonlijk is die beschikbaar als een afzonderlijk pakket, bijvoorbeeld libapache2-mod-wsgi-py3.
Gebruik de overeenkomende versie van Python om Weblate te installeren.
Voorbeeld configuratie voor Apache en Gunicorn¶
De volgende configuratie voert Weblate uit in Gunicorn en Apache 2.4 (beschikbaar 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>
Voorbeeld configuratie om Gunicorn op te starten¶
Weblate heeft wsgi optionele afhankelijkheid (bekijk Python afhankelijkheden) dat alles zal installeren dat u nodig hebt om Gunicorn uit te kunnen voeren. Bij het installeren van Weblate kunt u het specificeren als:
uv pip install Weblate[all,wsgi]
Als u Gunicorn eenmaal hebt geïnstalleerd, kunt u het uitvoeren. Dat wordt gewoonlijk gedaan op het systeemniveau. De volgende voorbeelden laten zien hoe op te starten via systemd:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
--preload \
--timeout 3600 \
--graceful-timeout 3600 \
--worker-class=gthread \
--workers=2 \
--threads=16 \
--bind unix:/run/gunicorn.sock \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
Zie ook
Weblate uitvoeren onder pad¶
Aanbevolen wordt om MPM vooraf te forken bij het gebruiken van WSGI met Weblate.
Een voorbeeldconfiguratie voor Apache om Weblate te serveren onder /weblate. Opnieuw met mod_wsgi (ook beschikbaar 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>
Aanvullend dient u weblate/settings.py aan te passen:
URL_PREFIX = "/weblate"
Achtergrondtaken met Celery¶
Weblate gebruikt Celery om normale en achtergrondtaken uit te voeren. U wordt geacht een service voor Celery uit te voeren die deze zal uitvoeren. Het is bijvoorbeeld verantwoordelijk voor het afhandelen van de volgende bewerkingen (deze lijst is niet voledig):
Webhooks ontvangen van externe services (bekijk Notificatie-hooks).
Uitvoeren van normale onderhoudstaken, zoals back-ups, opschonen, dagelijkse add-ons of bijwerkingen (bekijk Weblate back-uppen en verplaatsen,
BACKGROUND_TASKS, Add-ons).Uitvoeren van Automatische vertaling.
Samengevatte notificaties versturen.
Lossen van uitgebreide bewerkingen uit het proces van WSGI.
Openstaande wijzigingen doorvoeren (bekijk Vetraagd indienen).
Een normale opstelling met Redis als backend ziet eruit als dit:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
U zou ook de werker van Celery moeten starten om de taken te verwerken en geplande taken te starten, dit kan direct worden gedaan op de opdrachtregel (die meestal nuttig is bij debuggen of ontwikkelen):
./weblate/examples/celery start
./weblate/examples/celery stop
Notitie
Het proces van Celery moet worden uitgevoerd onder dezelfde gebruiker als het proces van WSGI, anders zullen bestanden in de DATA_DIR worden opgeslagen met gemixte eigenaren, wat leidt tot problemen tijdens uitvoering.
Bekijk ook Rechten voor bestandssysteem en Server uitvoeren.
Uitvoeren van taken van Celery in de modus eager met WSGI¶
Notitie
Dit zal een enorme impact op de prestaties van de webinterface hebben, en zal mogelijkheden verstoren die afhankelijk zijn van normale activatie (bijvoorbeeld het indienen van openstaande wijzigingen, samengevatte notificaties, of back-ups).
Voor ontwikkeling zou u misschien de configuratie eager willen gebruiken, die alle taken op hun plaats verwerkt:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Celery uitvoeren als systeemservice¶
Meest waarschijnlijk is dat u Celery wilt uitvoeren als een daemon en dat wordt behandeld in Daemonization. Voor de meest voorkomende opstelling in Linux met systemd, kunt u de voorbeeldbestanden gebruiken die worden meegeleverd in de map examples die hieronder zijn vermeld.
Systemd eenheid om te worden geplaatst als /etc/systemd/system/celery-weblate.service:
[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
Configuratie van de omgeving om te worden geplaatst als /etc/default/celery-weblate:
# 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"
Aanvullende configuratie om logs van Celery te roteren met logrotate om te worden geplaatst als /etc/logrotate.d/celery:
# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Periodieke taken met Celery beat¶
Weblate komt met een ingebouwde opstelling voor geplande taken. Het schema voor de taak wordt opgeslagen in de database en taken worden uitgevoerd door de Celery beat daemon.
Hint
U kunt aanvullende taken definiëren in settings.py, bekijk bijvoorbeeld Vetraagd indienen.
Status Celery monitoren¶
U kunt de huidige lengte van de wachtrij voor taken van Celery vinden in de Beheerinterface of u kunt celery_queues op de opdrachtregel gebruiken. In het geval de rij te lang wordt, zult u ook een configuratiefout in de beheerinterface krijgen.
Waarschuwing
De fouten voor Celery worden standaard alleen gelogd in het log van Celery en zijn niet zichtbaar voor de gebruiker. In het geval u overzicht wilt houden op dergelijke mislukkingen, wordt aanbevolen om Foutrapporten verzamelen en prestaties monitoren te configureren.
Opstelling een-proces Celery¶
In het geval u een erg beperkt geheugen hebt, zou u misschien het aantal processen van Weblate willen beperken. Alle taken voor Celery kunnen in een proces worden uitgevoerd met:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Een installatie met Docker kan worden geconfigureerd om een opstelling van een-proces Celery te gebruiken door CELERY_SINGLE_PROCESS in te stellen.
Waarschuwing
Dit zal een niet te missen impact op de prestaties van Weblate hebben.
Weblate monitoren¶
Weblate verschaft de URL /healthz/ om te worden gebruikt in eenvoudig controles voor de gezondheid, bijvoorbeeld met Kubernetes. De Docker container heeft een ingebouwde controle voor de gezondheid met deze URL.
Voor het monitoren van metrieken van Weblate kunt u het API-eindpunt GET /api/metrics/ gebruiken.
Foutrapporten verzamelen en prestaties monitoren¶
Weblate, net als elke andere software, kan falen. Voor het verzamelen van nuttige statistieken voor mislukkingen bevelen wij services van derde partijen aan om dergelijke informatie te verzamelen. Dit is speciaal nuttige bij falende taken van Celery, die anders alleen in de logs zouden worden gerapporteerd en u zou er geen notificatie voor ontvangen. Weblate heeft ondersteuning voor de volgende services:
Sentry¶
Weblate heeft ingebouwde ondersteuning voor Sentry. Het is voldoende, om het te gebruiken, om SENTRY_DSN in te stellen in settings.py:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Sentry kan ook worden gebruikt om de prestaties van Weblate te monitoren door sporen en profielen te monitoren voor een gedefinieerd percentage bewerkingen. Dit kan worden geconfigureerd met SENTRY_TRACES_SAMPLE_RATE en SENTRY_PROFILES_SAMPLE_RATE.
Rollbar¶
Weblate heeft ingebouwde ondersteuning voor Rollbar. Het is voldoende, om te gebruiken, de instructies te volgen voor Rollbar notificatie voor Python.
In het kort, u moet settings.py aanpassen:
# 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",
"environment": "development" if DEBUG else "production",
"branch": "main",
"root": "/absolute/path/to/code/root",
}
Alle andere dingen zijn automatisch geïntegreerd, u zult nu zowel fouten van de kant van de server als van de cliënt ontvangen.
Notitie
Loggen van fouten bevat ook uitzonderingen die gracieus werden afgehandeld, maar zouden een probleem aan kunnen duiden - zoals het mislukt parsen van een geüpload bestand.
Graylog-logbeheer¶
Added in version 5.9.
Weblate kan worden geconfigureerd om te loggen met het TCP-protocol GELF. Dit werd ontwikkeld voor integratie met Graylog, maar kan worden gebruikt met elk conform platform voor loggen.
Het sjabloon voor de configuratie is opgenomen in de Voorbeeld configuratie, voor Docker kan dit worden geconfigureerd met WEBLATE_LOG_GELF_HOST.
Weblate migreren naar een andere server¶
Migreren van Weblate naar een andere server zou behoorlijk gemakkelijk moeten zijn, het slaat echter gegevens op in een paar locaties die u met zorg zou moeten migreren. De beste benadering is om Weblate af te sluiten voor de migratie.
Database migreren¶
Afhankelijk van de backend van uw database, zou u misschien verschillende opties kunnen hebben voor het migreren van de database. De meest rechtstreekse benadering is om de eigen gereedschappen van de database te gebruiken, omdat die gewoonlijk meestal het meest effectief zijn (bijv. mysqldump of pg_dump). Als alternatief kunt u repliceren gebruiken als uw database dat ondersteunt.
Zie ook
Migreren tussen databases beschreven in Migreren vanuit andere databases naar PostgreSQL.
Opslagruimten VCS migreren¶
De opslagruimten voor VCS die zijn opgeslagen onder DATA_DIR moeten ook worden gemigreerd. U kunt ze eenvoudigweg kopiëren of rsync gebruiken om de migratie meer effectief uit te voeren.
Andere opmerkingen¶
Vergeet niet om andere services die Weblate gebruikt zou kunnen hebben te verplaatsen, zoals Redis, Cron jobs of aangepaste backends voor authenticatie.