Konfigurationsinstruktioner¶
Installera Weblate¶
Välj en lämplig installationsmetod utifrån din konfiguration och erfarenhet:
Installera med Docker, rekommenderas för produktionsmiljöer.
Virtualenv-installation, rekommenderas för produktionsmiljöer:
Installera från källor, rekommenderas för utveckling.
Arkitekturöversikt¶
- Webbserver
Hantera inkommande HTTP-förfrågningar, Servering av statiska filer.
- Selleriarbetare
Bakgrundsuppgifter med Celery exekveras här.
Beroende på din arbetsbelastning kan du behöva anpassa antalet arbetare.
Använd dedikerad nod vid horisontell skalning av Weblate.
- WSGI-server
En WSGI-server som levererar webbsidor till användare.
Använd dedikerad nod vid horisontell skalning av Weblate.
- Databas
PostgreSQL-databasserver för lagring av allt innehåll, se Databasinställningar för Weblate.
Använd dedikerad databasnod för webbplatser med hundratals miljoner värdord.
- Datastore
Nyckel/värde-databas såsom Valkey eller Redis-server för cache och uppgiftskö, se Bakgrundsuppgifter med Celery.
Använd dedikerad nod vid horisontell skalning av Weblate.
- Filsystem
Filsystemlagring för lagring av VCS-arkiv och uppladdade användardata. Detta delas av alla processer.
Använd nätverkslagring när du skalar Weblate horisontellt.
- E-postserver
SMTP-server för utgående e-post, se Konfigurera utgående e-post. Den kan tillhandahållas externt.
Råd
Installera med Docker innehåller PostgreSQL och Valkey, vilket underlättar installationen.
Programvarukrav¶
Operativsystem¶
Weblate fungerar på Linux, FreeBSD och macOS. Andra Unix-liknande system kommer troligen också att fungera.
Weblate stöds inte på Windows. Men det kan fortfarande fungera och patchar tas gärna emot.
Se även
Arkitekturöversikt beskriver Weblates övergripande arkitektur och nödvändiga tjänster.
Python-beroenden¶
Weblate är skrivet i Python och stöder Python 3.12 eller nyare. Du kan installera beroenden med pip eller från dina distributionspaket. En fullständig lista finns i requirements.txt.
De mest anmärkningsvärda beroendena:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Django REST Framework
Valfri beroendespecifikator |
Python-paket |
Weblate-funktion |
|---|---|---|
|
||
|
||
|
||
|
||
|
Google Cloud Translation Advanced med stöd för ordlista |
|
|
||
|
||
|
MySQL eller MariaDB, se Databasinställningar för Weblate |
|
|
||
|
PostgreSQL, se Databasinställningar för Weblate |
|
|
||
|
Integrera SAML 2 IDP i Weblate |
|
|
Hostad Weblate-integration |
|
|
Hostad Weblate-integration |
|
|
wsgi-server för Weblate |
|
|
När du installerar med pip kan du direkt ange önskade funktioner vid installationen:
uv pip install "weblate[Postgres,Amazon,SAML]"
Eller så kan du installera Weblate med alla valfria funktioner:
uv pip install "weblate[all]"
Eller så kan du installera Weblate utan några valfria funktioner:
uv pip install weblate
Felsökning av pip-installation¶
ERROR: Dependency 'gobject-introspection-2.0' is required but not found.Det installerade paketet
PyGobjectkan inte hitta ett matchande GObject Introspection-bibliotek -gobject-introspection-2.0.Äldre versioner stöds inte längre av Weblate.
ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)Detta beror på att binärpaket som distribueras via PyPI är inkompatibla med distributionen. För att lösa detta måste du bygga om paketet på ditt system:
uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?Detta är ett känt problem med xmlsec-paketet, se https://github.com/xmlsec/python-xmlsec/issues/314.
lxml & xmlsec libxml2 library version mismatchPaketen
lxmlochxmlsecmåste byggas mot enlibxml2. Du bör bygga dem lokalt för att undvika detta problem:uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec
Övriga systemkrav¶
Följande beroenden måste installeras på systemet:
Git- Pango, Cairo och relaterade huvudfiler samt GObject-introspektionsdata
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, se Pango och Kairo
git-review(valfritt för Gerrit-stöd)git-svn(valfritt för Subversion-stöd)tesseract(krävs endast om tesserocr binära hjul inte är tillgängliga för ditt system)
Beroenden vid byggtiden¶
För att bygga vissa av Python-beroenden kan du behöva installera deras beroenden. Detta beror på hur du installerar dem, så se dokumentationen för de enskilda paketen. Du behöver inte dessa om du använder förkompilerade Wheels när du installerar med pip eller när du använder distributionspaket.
Pango och Kairo¶
Weblate använder Pango och Cairo för att rendera bitmap-widgets (se Bygga upp översättningsgemenskapen) och rendera kontroller (se Hantera teckensnitt). För att korrekt installera Python-bindningar för dessa måste du först installera systembibliotek – du behöver både Cairo och Pango, som i sin tur behöver GLib. Alla dessa bör installeras med utvecklingsfiler och GObject-introspektionsdata.
Hårdvarukrav¶
Weblate bör fungera utan problem på all modern hårdvara. Nedan anges den minimikonfiguration som krävs för att köra Weblate på en enda värd (Weblate, databas och webbserver):
3 GB RAM-minne
2 CPU-kärnor
1 GB lagringsutrymme
Observera
De faktiska kraven för din installation av Weblate varierar kraftigt beroende på storleken på de översättningar som hanteras i den.
Använt minne¶
Ju mer minne desto bättre – det används för caching på alla nivåer (filsystem, databas och Weblate). För hundratals översättningskomponenter rekommenderas minst 4 GB RAM-minne.
Råd
För system med mindre minne än rekommenderat rekommenderas Enkelprocess-konfiguration av Celery.
CPU-användning¶
Många samtidiga användare ökar behovet av CPU-kärnor.
Lagringsutnyttjande¶
Den typiska databaslagringsanvändningen är cirka 300 MB per 1 miljon lagrade ord.
Lagringsutrymmet som behövs för klonade arkiv varierar, men Weblate försöker hålla storleken minimal genom att göra ytliga kloner.
Noder¶
För små och medelstora webbplatser (miljoner värdord) kan alla Weblate-komponenter (se Arkitekturöversikt) köras på en enda nod.
När du växer till hundratals miljoner lagrade ord rekommenderas det att ha en dedikerad nod för databasen (se Databasinställningar för Weblate).
Verifiera signaturer för utgivningar¶
Weblate-utgåvor är kryptografiskt signerade med Sigstore-signaturer. Signaturerna bifogas GitHub-utgåvan.
Verifieringen kan utföras med hjälp av sigstore package. Följande exempel verifierar signaturen för 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
Filssystemets behörigheter¶
Weblate-processen måste kunna läsa och skriva till den katalog där den lagrar data - DATA_DIR. Alla filer i denna katalog ska ägas av och vara skrivbara för den användare som kör alla Weblate-processer (vanligtvis WSGI och Celery, se Körande server och Bakgrundsuppgifter med Celery).
Standardkonfigurationen placerar dem i samma träd som Weblate-källorna, men du kanske föredrar att flytta dem till en bättre plats, till exempel: /var/lib/weblate.
Weblate försöker skapa dessa kataloger automatiskt, men det misslyckas om det inte har behörighet att göra det.
Du bör också vara försiktig när du kör Ledningskommandon, eftersom det bör köras under samma användare som Weblate själv körs under, annars kan behörigheterna för vissa filer bli felaktiga.
I Docker-containern måste alla filer i volymen /app/data ägas av användaren weblate i containern (UID 1000).
Se även
Databasinställningar för Weblate¶
Det rekommenderas att köra Weblate med en PostgreSQL-databasserver.
PostgreSQL 13 och högre stöds. PostgreSQL 15 eller nyare rekommenderas.
MySQL och MariaDB stöds, men rekommenderas inte för nya installationer.
Uppmärksamma
Stödet för MySQL och MariaDB övervägs att tas bort. Se https://github.com/WeblateOrg/weblate/issues/16140 för mer information.
Observera
Inga andra databasservrar stöds för närvarande, men stöd för andra Django-stödda databaser bör vara möjligt att implementera.
Databasanslutningar¶
I standardkonfigurationen upprätthåller varje Weblate-process en permanent anslutning till databasen. Permanenta anslutningar förbättrar Weblates responsivitet, men kan kräva mer resurser för databasservern. Se CONN_MAX_AGE och Persistent connections för mer information.
Weblate behöver minst följande antal anslutningar:
\((4 \times \mathit{nCPUs}) + 2\) för Celery-processer
\(\mathit{nCPUs} + 1\) för WSGI-arbetare
Detta gäller standardinställningarna för Docker-containrar och exempelkonfigurationerna i denna dokumentation, men siffrorna kommer att ändras när du anpassar antalet WSGI-arbetare eller justerar parallelliteten i Celery.
Den faktiska gränsen för antalet databasanslutningar måste vara högre för att ta hänsyn till följande situationer:
Ledningskommandon behöver också deras anslutning.
Om processprocessen avbryts (till exempel av OOM-killer) kan den blockera den befintliga anslutningen tills tidsgränsen löper ut.
PostgreSQL¶
PostgreSQL är vanligtvis det bästa valet för Django-baserade webbplatser. Det är referensdatabasen som används för att implementera Djangos databaslager.
Observera
Weblate använder trigram-tillägg som i vissa fall måste installeras separat. Leta efter postgresql-contrib eller ett paket med liknande namn.
Se även
Skapa en databas i PostgreSQL¶
Det är vanligtvis en bra idé att köra Weblate i en separat databas och med ett separat användarkonto:
# 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
Råd
Om du inte vill göra Weblate-användaren till superanvändare i PostgreSQL kan du utelämna det. I så fall måste du utföra vissa migreringssteg manuellt som superanvändare i PostgreSQL i det schema som Weblate kommer att använda:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Konfigurera Weblate för att använda PostgreSQL¶
settings.py-snippet för 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,
}
}
Databasmigreringen utför ALTER ROLE på den databasroll som används av Weblate. I de flesta fall matchar rollens namn användarnamnet. I mer komplexa installationer skiljer sig rollnamnet från användarnamnet, och du kommer att få ett felmeddelande om en icke-existerande roll under databasmigreringen (psycopg2.errors.UndefinedObject: rollen "weblate@hostname" finns inte). Detta är känt för att inträffa med Azure Database for PostgreSQL, men det är inte begränsat till denna miljö. Ställ in ALTER_ROLE för att ändra namnet på den roll som Weblate ska ändra under databasmigreringen.
Se även
MySQL och MariaDB¶
Uppmärksamma
Stödet för MySQL och MariaDB övervägs att tas bort. Se https://github.com/WeblateOrg/weblate/issues/16140 för mer information.
Varning
Även om MySQL och MariaDB fortfarande stöds i Weblate, är vårt huvudfokus PostgreSQL. Vi rekommenderar att du använder PostgreSQL för nya installationer och migrerar befintliga installationer till PostgreSQL, se Migrera från andra databaser till PostgreSQL.
Vissa Weblate-funktioner fungerar bättre med PostgreSQL. Detta gäller bland annat sökning och översättningsminne, som båda använder fulltextfunktioner i databasen, och PostgreSQL-implementeringen är överlägsen.
Weblate kan också användas med MySQL eller MariaDB. Se MySQL notes och MariaDB notes för varningar om användning av Django med dessa. På grund av begränsningarna rekommenderas det att använda PostgreSQL för nya installationer.
Weblate kräver MySQL minst 8 eller MariaDB minst 10.5.
Följande konfiguration rekommenderas för Weblate:
Använd teckenuppsättningen
utf8mb4för att möjliggöra representation av högre Unicode-plan (till exempel emojis).Konfigurera servern med
innodb_large_prefixför att tillåta längre index på textfält.Ställ in isoleringsnivån till
READ COMMITTED.SQL-läget bör ställas in på
STRICT_TRANS_TABLES.
MySQL 8.x, MariaDB 10.5.x eller nyare har rimliga standardinställningar, så att ingen serverjustering bör behövas och allt som behövs kan konfigureras på klientsidan.
Nedan följer ett exempel /etc/my.cnf.d/server.cnf för en server med 8 GB RAM. Dessa inställningar bör vara tillräckliga för de flesta installationer. MySQL och MariaDB har inställningar som ökar serverns prestanda, men dessa anses inte nödvändiga om du inte planerar att ha ett stort antal samtidiga användare som använder systemet. Se dokumentationen från de olika leverantörerna för mer information om detta.
Det är absolut nödvändigt att minska problemen vid installationen genom att se till att inställningen innodb_file_per_table är korrekt inställd och att MySQL/MariaDB startas om innan du påbörjar installationen av Weblate.
[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
Råd
Om du får felmeddelandet #1071 - Angiven nyckel var för lång; maximal nyckellängd är 767 byte, uppdatera din konfiguration så att den inkluderar inställningarna för innodb ovan och starta om installationen.
Råd
Om du får felmeddelandet #2006 - MySQL-servern har försvunnit kan det hjälpa att konfigurera CONN_MAX_AGE.
Se även
Konfigurera Weblate för att använda MySQL/MariaDB¶
settings.py-snippet för MySQL och 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": {},
}
}
Du bör också skapa användarkontot weblate i MySQL eller MariaDB innan du påbörjar installationen. Använd kommandona nedan för att göra det:
GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
Se även
Andra konfigurationer¶
Konfigurera utgående e-post¶
Weblate skickar ut e-postmeddelanden vid olika tillfällen – för aktivering av konton och olika meddelanden som konfigurerats av användarna. För detta behöver det tillgång till en SMTP-server.
E-postservern konfigureras med hjälp av följande inställningar: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER och EMAIL_PORT. Deras namn är ganska självförklarande, men du kan hitta mer information i Djangos dokumentation.
Råd
Om du får ett felmeddelande om att autentiseringen inte stöds (till exempel SMTP AUTH-tillägg stöds inte av servern), beror det troligen på att du använder en osäker anslutning och servern vägrar att autentisera på detta sätt. Försök att aktivera EMAIL_USE_TLS i sådana fall.
Körning bakom omvänd proxy¶
Flera funktioner i Weblate är beroende av att korrekta HTTP-rubriker skickas till Weblate. När du använder omvänd proxy, se till att nödvändig information skickas korrekt.
För att felsöka denna konfiguration kan du titta på HTTP-miljö i Prestandarapport.
- Klientens IP-adress
Detta behövs för Hastighetsbegränsande eller Granskningslogg.
Weblate analyserar IP-adressen från
REMOTE_ADDR, som ställs in av WSGI-hanteraren. Denna kan vara tom (vid användning av socket för WSGI) eller innehålla en omvänd proxyadress, så Weblate behöver en extra HTTP-header med en klient-IP-adress.Att aktivera
IP_BEHIND_REVERSE_PROXYbör vara tillräckligt för de vanligaste inställningarna, men du kan behöva justeraIP_PROXY_HEADERochIP_PROXY_OFFSETockså (användWEBLATE_IP_PROXY_HEADERochWEBLATE_IP_PROXY_OFFSETi Docker-containern).Råd
Denna konfiguration kan inte aktiveras som standard, eftersom det skulle möjliggöra IP-adressförfalskning på installationer som inte har en korrekt konfigurerad omvänd proxy.
- Serverns värdnamn
Host-rubriken ska matcha det som är konfigurerat som
SITE_DOMAIN. Ytterligare konfiguration kan behövas i din omvända proxy (använd till exempelProxyPreserveHost Onför Apache ellerproxy_set_header Host $host;med nginx).Råd
Fel vid CSRF-verifiering orsakas ofta av en diskrepans mellan Host-rubriken och konfigurerade
SITE_DOMAIN.- Klientprotokoll
Om rätt protokoll inte godkänns kan Weblate hamna i en omdirigeringsloop när det försöker uppgradera klienten till HTTPS. Se till att det exponeras korrekt av den omvända proxyn som X-Forwarded-Proto.
Denna rubrik måste sedan konfigureras i
SECURE_PROXY_SSL_HEADER(settings.py) ellerWEBLATE_SECURE_PROXY_SSL_HEADER(Docker-miljö).Viktigt
Header-värdet är skiftlägeskänsligt i konfigurationen, så
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_CUSTOM_PROTO,httpsochWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_CUSTOM_PROTO,HTTPSär inte utbytbara.Råd
Om du får felmeddelandet ”För många omdirigeringar” från webbläsaren beror det troligen på att det faktiska protokollet (HTTPS) inte stämmer överens med det som Weblate observerar.
Förändrat i version 5.13: Protokollproxyhuvudena hanteras automatiskt av gunicorn i standardkonfigurationen, men andra WSGI-servrar har en säkrare konfiguration och kräver en explicit inställning av detta.
Sedan Weblate 5.13 använder Docker-containern granian och kräver nu en explicit konfiguration av
WEBLATE_SECURE_PROXY_SSL_HEADER.
Se även
HTTP-proxy¶
Weblate utför VCS-kommandon och dessa accepterar proxykonfiguration från miljön. Det rekommenderade tillvägagångssättet är att definiera proxyinställningar i settings.py:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Se även
Justera konfigurationen¶
Se även
Kopiera weblate/settings_example.py till weblate/settings.py och anpassa den efter din konfiguration. Du kommer troligen att vilja justera följande alternativ:
ADMINS
Lista över webbplatsadministratörer som ska få meddelanden när något går fel, till exempel meddelanden om misslyckade sammanslagningar eller Django-fel.
Kontaktformuläret skickar även e-post om dessa, såvida inte
ADMINS_CONTACTär konfigurerat.
ALLOWED_HOSTS
Du måste ställa in detta för att lista de värdar som din webbplats ska betjäna. Till exempel:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternativt kan du inkludera jokertecken:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Konfigurera hur dina sessioner ska lagras. Om du behåller standarddatabasmotorn bör du schemalägga weblate clearsessions för att ta bort gamla sessionsdata från databasen.
Om du använder Valkey eller Redis som cache (se Konfigurera cache) rekommenderas det att du använder det även för sessioner:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
DATABASES
Anslutning till databasserver, se Djangos dokumentation för mer information.
DEBUG
Inaktivera detta för alla produktionsservrar. När felsökningsläget är aktiverat visar Django backtraces för användarna vid fel. När du inaktiverar det skickas felmeddelanden via e-post till
ADMINS(se ovan).Felsökningsläget gör också Weblate långsammare, eftersom Django lagrar mycket mer information internt i detta fall.
Se även
DEFAULT_FROM_EMAIL
E-postadress för utgående e-post, till exempel registreringsmeddelanden.
Se även
SECRET_KEY
Nyckel som används av Django för att signera viss information i cookies. Se Djangos hemliga nyckel för mer information.
Se även
SERVER_EMAIL
E-postadress som används som avsändaradress för att skicka e-postmeddelanden till administratören, till exempel meddelanden om misslyckade sammanslagningar.
Se även
Fylla databasen¶
När konfigurationen är klar kan du köra migrate för att skapa databasstrukturen. Nu bör du kunna skapa översättningsprojekt med hjälp av administratörsgränssnittet.
När du är klar bör du också kontrollera Prestandarapporten i administratörsgränssnittet, som ger dig tips om potentiella icke-optimala konfigurationer på din webbplats.
Produktionsuppsättning¶
För en produktionsmiljö bör du göra de justeringar som beskrivs i följande avsnitt. De mest kritiska inställningarna utlöser en varning, som indikeras med ett utropstecken i den övre fältet om du är inloggad som superanvändare:
Det rekommenderas också att kontrollera de kontroller som utlöses av Django (även om du kanske inte behöver åtgärda alla):
weblate check --deploy
Du kan också granska samma checklista på Prestandarapport i Hanteringsgränssnitt.
Se även
Inaktivera felsökningsläge¶
Inaktivera Djangos felsökningsläge (DEBUG) genom att:
DEBUG = False
När felsökningsläget är aktiverat lagrar Django alla utförda frågor och visar användarna backtraces av fel, vilket inte är önskvärt i en produktionsmiljö.
Se även
Konfigurera administratörer korrekt¶
Ange rätt administratörsadresser i inställningen ADMINS för att definiera vem som ska ta emot e-postmeddelanden om något går fel på servern, till exempel:
ADMINS = (("Your Name", "your_email@example.com"),)
Se även
Ställ in rätt webbplatsdomän¶
Justera webbplatsens namn och domän i administratörsgränssnittet, annars kommer länkar i RSS eller registreringsmejl inte att fungera. Detta konfigureras med hjälp av SITE_DOMAIN som ska innehålla webbplatsens domännamn.
Förändrat i version 4.2: Före version 4.2 användes istället Djangos webbplatsramverk, se The “sites” framework.
Konfigurera HTTPS korrekt¶
Det rekommenderas starkt att köra Weblate med det krypterade HTTPS-protokollet. Efter att ha aktiverat det bör du ställa in ENABLE_HTTPS i inställningarna:
ENABLE_HTTPS = True
Råd
Du kanske också vill konfigurera HSTS. Se SSL/HTTPS för mer information.
Ställ in SECURE_HSTS_SECONDS korrekt¶
Om din webbplats används via SSL måste du överväga att ange ett värde för SECURE_HSTS_SECONDS i settings.py för att aktivera HTTP Strict Transport Security. Som standard är det inställt på 0, som visas nedan.
SECURE_HSTS_SECONDS = 0
Om den är inställd på ett heltal som inte är noll, ställer django.middleware.security.SecurityMiddleware in HTTP Strict Transport Security-rubriken på alla svar som inte redan har den.
Varning
Om du ställer in detta felaktigt kan det orsaka irreversibla skador (under en viss tid) på din webbplats. Läs först dokumentationen HTTP Strict Transport Security.
Använd en kraftfull databasmotor¶
Uppmärksamma
Stödet för MySQL och MariaDB övervägs att tas bort. Se https://github.com/WeblateOrg/weblate/issues/16140 för mer information.
Använd PostgreSQL för en produktionsmiljö, se Databasinställningar för Weblate för mer information.
Använd en närliggande plats för att köra databasservern, annars kan nätverksprestandan eller tillförlitligheten förstöra din upplevelse av Weblate.
Kontrollera databasserverns prestanda eller justera dess konfiguration, till exempel med hjälp av PGTune.
Konfigurera cache¶
Om möjligt, använd Valkey eller Redis från Django genom att justera konfigurationsvariabeln CACHES, till exempel:
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",
},
}
}
Råd
Om du ändrar inställningarna för cachen kan du behöva justera dem även för Celery, se Bakgrundsuppgifter med Celery.
Avatar-cachning¶
Förutom caching av Django utför Weblate även caching av avatarer. Det rekommenderas att använda en separat, filbaserad cache för detta ändamål:
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,
},
},
}
Konfigurera e-postutskick¶
Weblate behöver skicka e-postmeddelanden vid flera tillfällen, och dessa e-postmeddelanden ska ha en korrekt avsändaradress. Konfigurera SERVER_EMAIL och DEFAULT_FROM_EMAIL så att de passar din miljö, till exempel:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Observera
För att inaktivera e-postutskick via Weblate, ställ in EMAIL_BACKEND till django.core.mail.backends.dummy.EmailBackend.
Detta kommer att inaktivera alla e-postleveranser, inklusive registrerings- eller lösenordsåterställningsmeddelanden.
Tillåtna värdar inställning¶
Django kräver att ALLOWED_HOSTS innehåller en lista över domännamn som din webbplats får betjäna. Om du lämnar den tom kommer alla förfrågningar att blockeras.
Om detta inte är konfigurerat för att matcha din HTTP-server kommer du att få felmeddelanden som Ogiltig HTTP_HOST-rubrik: '1.1.1.1'. Du kan behöva lägga till '1.1.1.1' till ALLOWED_HOSTS.
Råd
På Docker-containern är detta tillgängligt som WEBLATE_ALLOWED_HOSTS.
Djangos hemliga nyckel¶
Inställningen SECRET_KEY används av Django för att signera cookies, och du bör verkligen generera ditt eget värde istället för att använda det från exempelkonfigurationen.
Du kan generera en ny nyckel med hjälp av weblate-generate-secret-key som medföljer Weblate.
Se även
Kör underhållsuppgifter¶
För optimal prestanda är det en bra idé att köra vissa underhållsuppgifter i bakgrunden. Detta görs automatiskt av Bakgrundsuppgifter med Celery och omfattar följande uppgifter:
Konfigurationshälsokontroll (varje timme).
Bekräfta väntande ändringar (varje timme), se Lata åtaganden och
commit_pending.Uppdatering av komponentvarningar (dagligen).
Uppdatera fjärrgrenar (varje natt), se
AUTO_UPDATE.Säkerhetskopiering av översättningsminne till JSON (dagligen), se
dump_memory.Fulltext- och databasunderhållsuppgifter (dagliga och veckovisa uppgifter), se
cleanuptrans.
Systemets lokaliseringar och kodning¶
Systemets lokaliseringar bör konfigureras till UTF-8-kompatibla. På de flesta Linux-distributioner är detta standardinställningen. Om så inte är fallet på ditt system, ändra lokaliseringarna till UTF-8-varianten.
Till exempel genom att redigera /etc/default/locale och ställa in LANG="C.UTF-8" där.
I vissa fall har enskilda tjänster separata inställningar för lokalisering. Detta varierar mellan distributioner och webbservrar, så kontrollera dokumentationen för dina webbserverpaket för mer information.
Apache på Ubuntu använder /etc/apache2/envvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache på CentOS använder /etc/sysconfig/httpd (eller /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Komprimering av klientresurser¶
Weblate levereras med en rad JavaScript- och CSS-filer. Av prestandaskäl är det bra att komprimera dem innan de skickas till en klient. I standardkonfigurationen görs detta direkt med en liten extra kostnad. Vid stora installationer rekommenderas det att aktivera offlinekomprimeringsläget. Detta måste göras i konfigurationen och komprimeringen måste aktiveras vid varje uppgradering av Weblate.
Konfigurationsomkopplaren är enkel genom att aktivera django.conf.settings.COMPRESS_OFFLINE och konfigurera django.conf.settings.COMPRESS_OFFLINE_CONTEXT (det senare ingår redan i exempelkonfigurationen):
COMPRESS_OFFLINE = True
Vid varje distribution måste du komprimera filerna så att de matchar den aktuella versionen:
weblate compress
Råd
Den officiella Docker-bilden har redan denna funktion aktiverad.
Körande server¶
Råd
Om du inte har erfarenhet av tjänsterna som beskrivs nedan kan du prova Installera med Docker.
Du behöver flera tjänster för att köra Weblate. Den rekommenderade konfigurationen består av:
Databasserver (se Databasinställningar för Weblate)
Cache-server (se Konfigurera cache)
Frontend-webbserver för statiska filer och SSL-avslutning (se Servering av statiska filer)
WSGI-server för dynamiskt innehåll (se Exempelkonfiguration för NGINX och uWSGI)
Celery för att utföra bakgrundsuppgifter (se Bakgrundsuppgifter med Celery)
Observera
Det finns vissa beroenden mellan tjänsterna, till exempel bör cache och databas vara igång när Celery- eller uwsgi-processer startas.
I de flesta fall kommer du att köra alla tjänster på en enda (virtuell) server, men om din installation är tungt belastad kan du dela upp tjänsterna. Den enda begränsningen för detta är att Celery- och Wsgi-servrarna behöver åtkomst till DATA_DIR.
Observera
WSGI-processen måste köras under samma användare som Celery-processen, annars kommer filer i DATA_DIR att lagras med blandad äganderätt, vilket leder till problem vid körning.
Se även Filssystemets behörigheter och Bakgrundsuppgifter med Celery.
Körande webbserver¶
Att köra Weblate skiljer sig inte från att köra något annat Django-baserat program. Django körs vanligtvis som WSGI eller fcgi (se exempel för olika webbservrar nedan).
För teständamål kan du använda den inbyggda webbservern i Django:
weblate runserver
Varning
ANVÄND INTE DENNA SERVER I EN PRODUKTIONSMILJÖ. Den har inte genomgått säkerhetsgranskningar eller prestandatester. Se även Django-dokumentationen om runserver.
Råd
Djangos inbyggda server hanterar endast statiska filer med DEBUG aktiverat, eftersom den endast är avsedd för utveckling. För produktionsanvändning, se WSGI-inställningar:
Servering av statiska filer¶
Förändrat i version 5.15.2: /media/ används inte längre för att visa skärmdumpar.
Django måste samla sina statiska filer i en enda katalog. För att göra detta, kör weblate collectstatic --noinput. Detta kopierar de statiska filerna till en katalog som anges av inställningen STATIC_ROOT (standard är en katalog med namnet static i CACHE_DIR).
Det rekommenderas att servera statiska filer direkt från din webbserver. Du bör använda detta för följande sökvägar:
/static/Serverar statiska filer för Weblate och administratörsgränssnittet (från definierat av
STATIC_ROOT)./favicon.icoBör skrivas om för att skriva om en regel för att betjäna
/static/favicon.ico.
Se även
Innehållssäkerhetspolicy¶
Standardkonfigurationen för Weblate aktiverar mellanprogrammet weblate.middleware.SecurityMiddleware, som ställer in säkerhetsrelaterade HTTP-rubriker som Content-Security-Policy eller X-XSS-Protection. Dessa är som standard inställda för att fungera med Weblate och dess konfiguration, men kan behöva anpassas för din miljö.
Exempel på konfiguration för NGINX och Granian¶
Följande konfiguration kör Weblate med Granian NGINX-webbserver:
#
# 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 / {
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://127.0.0.1:8888;
proxy_read_timeout 3600;
}
}
Exempel på konfiguration för NGINX och Gunicorn¶
Följande konfiguration kör Weblate med Gunicorn under NGINX-webbservern (finns även som 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 / {
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;
}
}
Exempelkonfiguration för NGINX och uWSGI¶
För att köra produktionswebbservern, använd WSGI-wrapper som installerats med Weblate (i virtuell miljö är den installerad som ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py). Glöm inte att ställa in Python-sökvägen till din virtualenv också (till exempel med virtualenv = /home/user/weblate-env i uWSGI).
Följande konfiguration kör Weblate som uWSGI under NGINX-webbservern.
Konfiguration för NGINX (finns även som 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 / {
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 (finns även som 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
Se även
Exempel på konfiguration för Apache¶
Det rekommenderas att använda prefork MPM när du använder WSGI med Weblate.
Följande konfiguration kör Weblate som WSGI. Du måste ha aktiverat mod_wsgi (finns som 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>
# 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>
Observera
Weblate kräver Python 3, så se till att du kör Python 3-varianten av modwsgi. Vanligtvis finns den tillgänglig som ett separat paket, till exempel libapache2-mod-wsgi-py3.
Använd motsvarande Python-version för att installera Weblate.
Exempelkonfiguration för Apache och Gunicorn¶
Följande konfiguration kör Weblate i Gunicorn och Apache 2.4 (tillgänglig som 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>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/https_cert.cert
SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
SSLProxyEngine On
ProxyPass /favicon.ico !
ProxyPass /static/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Exempel på konfiguration för att starta Granian¶
Weblate har wsgi som valfri beroende (se Python-beroenden) som installerar allt du behöver för att köra Granian. När du installerar Weblate kan du ange det som:
uv pip install Weblate[all,wsgi]
När du har installerat Granian kan du köra det. Detta görs vanligtvis på systemnivå. Följande exempel visar hur man startar via systemd:
[Unit]
Description=granian daemon
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
--no-ws \
--workers-max-rss 350 \
--interface wsgi \
--workers 2 \
--backpressure 16 \
--runtime-threads 8 \
--runtime-mode mt \
--port 8888 \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
~
Exempelkonfiguration för att starta Gunicorn¶
Gunicorn måste installeras separat:
uv pip install gunicorn
När du har installerat Gunicorn kan du köra det. Detta görs vanligtvis på systemnivå. Följande exempel visar hur man startar 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
Se även
Kör Weblate under sökvägen¶
Det rekommenderas att använda prefork MPM när du använder WSGI med Weblate.
Ett exempel på Apache-konfiguration för att köra Weblate under /weblate. Återigen med hjälp av mod_wsgi (finns även som weblate/examples/apache-path.conf):
#
# 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>
# 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>
Dessutom måste du justera weblate/settings.py:
URL_PREFIX = "/weblate"
Bakgrundsuppgifter med Celery¶
Weblate använder Celery för att utföra regelbundna uppgifter och bakgrundsuppgifter. Du ska köra en Celery-tjänst som utför dessa uppgifter. Den ansvarar till exempel för följande operationer (listan är inte fullständig):
Ta emot webhooks från externa tjänster (se Aviseringskopplingar).
Utföra regelbundna underhållsuppgifter såsom säkerhetskopiering, rensning, dagliga tillägg eller uppdateringar (se Säkerhetskopiera och flytta Weblate,
BACKGROUND_TASKS, Tillägg).Skicka sammanfattande meddelanden.
Avlasta dyra operationer från WSGI-processen.
Bekräfta väntande ändringar (se Lata åtaganden).
En typisk konfiguration med Valkey eller Redis som backend ser ut så här:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Du bör också starta Celery-arbetaren för att bearbeta uppgifterna och starta schemalagda uppgifter. Detta kan göras direkt på kommandoraden (vilket oftast är användbart vid felsökning eller utveckling):
./weblate/examples/celery start
./weblate/examples/celery stop
Observera
Celery-processen måste köras under samma användare som WSGI-processen, annars kommer filer i DATA_DIR att lagras med blandad ägarskap, vilket leder till problem vid körning.
Se även Filssystemets behörigheter och Körande server.
Utföra Celery-uppgifter i WSGI med eager-läge¶
Observera
Detta kommer att ha en allvarlig inverkan på webbgränssnittets prestanda och kommer att störa funktioner som är beroende av regelbundna utlösare (till exempel att bekräfta väntande ändringar, sammanfattande aviseringar eller säkerhetskopieringar).
För utveckling kan du använda ivrig konfiguration, som bearbetar alla uppgifter på plats:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Kör Celery som systemtjänst¶
Troligtvis vill du köra Celery som en daemon, vilket beskrivs i Daemonization. För den vanligaste Linux-konfigurationen med systemd kan du använda exempelfilerna i mappen examples som anges nedan.
Systemd-enhet som ska placeras som /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
Miljökonfiguration som ska placeras som /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. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
--queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
--queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
--queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
--queues:backup=backup --concurrency:backup=1 --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"
Ytterligare konfiguration för att rotera Celery-loggar med logrotate som ska placeras som /etc/logrotate.d/celery:
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Periodiska uppgifter med Celery beat¶
Weblate har en inbyggd funktion för schemalagda uppgifter. Uppgiftsschemat lagras i databasen och uppgifterna utförs av Celery beat-daemon.
Råd
Du kan definiera ytterligare uppgifter i settings.py, se till exempel Lata åtaganden.
Övervakning av Celery-status¶
Du kan se den aktuella längden på Celery-uppgiftsköerna i Hanteringsgränssnitt eller använda celery_queues på kommandoraden. Om kön blir för lång får du också ett konfigurationsfel i admin-gränssnittet.
Varning
Celery-fel loggas som standard endast i Celery-loggen och är inte synliga för användaren. Om du vill ha en översikt över sådana fel rekommenderas det att konfigurera Insamling av felrapporter och övervakning av prestanda.
Enkelprocess-konfiguration av Celery¶
Om du har mycket begränsat minne kan du minska antalet Weblate-processer. Alla Celery-uppgifter kan utföras i en enda process med hjälp av:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
En installation som använder Docker kan konfigureras för att använda en enkelprocess-Celery-konfiguration genom att ställa in CELERY_SINGLE_PROCESS.
Varning
Detta kommer att ha en märkbar inverkan på Weblates prestanda.
Övervakning av Weblate¶
Weblate tillhandahåller URL:en /healthz/ som kan användas för enkla hälsokontroller, till exempel med Kubernetes. Docker-containern har en inbyggd hälsokontroll som använder denna URL.
För att övervaka mätvärden för Weblate kan du använda API-ändpunkten GET /api/metrics/.
Insamling av felrapporter och övervakning av prestanda¶
Weblate kan, precis som all annan programvara, drabbas av fel. För att samla in användbar information om fel rekommenderar vi att du använder tjänster från tredje part för att samla in sådan information. Detta är särskilt användbart vid fel i Celery-uppgifter, som annars endast skulle rapportera felet till loggarna utan att du får någon avisering om det. Weblate har stöd för följande tjänster:
Sentry¶
Weblate har inbyggt stöd för Sentry. För att använda det räcker det att ställa in SENTRY_DSN i settings.py:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Sentry kan också användas för att övervaka Weblates prestanda genom att samla in spår och profiler för en definierad procentandel av operationerna. Detta kan konfigureras med hjälp av SENTRY_TRACES_SAMPLE_RATE och SENTRY_PROFILES_SAMPLE_RATE.
Rollbar¶
Weblate har inbyggt stöd för Rollbar. För att använda det räcker det att följa instruktionerna för Rollbar notifier för Python.
Kort sagt måste du justera settings.py:
# 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",
}
Allt annat integreras automatiskt, och du kommer nu att samla in både server- och klientsidefel.
Observera
Felregistrering omfattar även undantag som hanterats på ett korrekt sätt, men som kan tyda på ett problem – till exempel misslyckad analys av en uppladdad fil.
Graylog logghantering¶
Added in version 5.9.
Weblate kan konfigureras för att logga med hjälp av GELF TCP-protokollet. Detta utvecklades för Graylog-integration, men kan användas med alla kompatibla loggningsplattformar.
Konfigurationsmallarna finns i Exempel på konfiguration. För Docker kan detta konfigureras med WEBLATE_LOG_GELF_HOST.
Migrera Weblate till en annan server¶
Att migrera Weblate till en annan server bör vara ganska enkelt, men det lagrar data på flera platser som du bör migrera noggrant. Det bästa sättet är att stoppa Weblate under migreringen.
Migrering av databas¶
Beroende på din databasbackend kan du ha flera alternativ för att migrera databasen. Det enklaste sättet är att använda databasens egna verktyg, eftersom de oftast är mest effektiva (t.ex. mysqldump eller pg_dump). Alternativt kan du använda replikering om din databas stöder det.
Se även
Migrering mellan databaser beskrivs i Migrera från andra databaser till PostgreSQL.
Migrera VCS-arkiv¶
VCS-arkiven som lagras under DATA_DIR måste också migreras. Du kan helt enkelt kopiera dem eller använda rsync för att göra migreringen mer effektivt.
Övriga anmärkningar¶
Glöm inte att flytta andra tjänster som Weblate kan ha använt, såsom Valkey, Redis, Cron-jobb eller anpassade autentiseringsbackends.