Den grundläggande beskrivningen av att sätta statiska filer i produktion består av två steg: kör kommandot collectstatic när statiska filer ändras, ordna sedan så att den samlade katalogen för statiska filer (STATIC_ROOT) flyttas till servern för statiska filer och serveras. Beroende på aliaset staticfiles STORAGES kan filer behöva flyttas till en ny plats manuellt eller så kan metoden post_process i klassen Storage ta hand om det.
Som med alla driftsättningsuppgifter ligger djävulen i detaljerna. Varje produktionsinstallation kommer att vara lite annorlunda, så du måste anpassa den grundläggande skissen för att passa dina behov. Nedan finns några vanliga mönster som kan vara till hjälp.
\nOm du vill servera dina statiska filer från samma server som redan serverar din webbplats kan processen se ut ungefär som följer:
\nSkicka upp din kod till deployment-servern.
På servern kör du collectstatic för att kopiera alla statiska filer till STATIC_ROOT.
Konfigurera din webbserver så att den serverar filerna i STATIC_ROOT under URL:en STATIC_URL. Här är till exempel hur man gör detta med Apache och mod_wsgi.
Du kommer förmodligen att vilja automatisera den här processen, särskilt om du har flera webbservrar.
\nDe flesta större Django-webbplatser använder en separat webbserver - dvs. en som inte också kör Django - för att servera statiska filer. Denna server kör ofta en annan typ av webbserver - snabbare men mindre fullfjädrad. Några vanliga val är:
\n\nKonfigurationen av dessa servrar omfattas inte av detta dokument; se respektive servers dokumentation för instruktioner.
\nEftersom din statiska filserver inte kommer att köra Django måste du ändra distributionsstrategin så att den ser ut ungefär som följer:
\nNär dina statiska filer ändras kör du collectstatic lokalt.
Skicka din lokala STATIC_ROOT upp till den statiska filservern till den katalog som serveras. rsync är ett vanligt val för det här steget eftersom det bara behöver överföra de delar av statiska filer som har ändrats.
En annan vanlig taktik är att servera statiska filer från en molnlagringsleverantör som Amazons S3 och/eller ett CDN (content delivery network). Detta gör att du kan ignorera problemen med att servera statiska filer och kan ofta ge snabbare laddning av webbsidor (särskilt när du använder ett CDN).
\nNär du använder dessa tjänster ser det grundläggande arbetsflödet ut ungefär som ovan, förutom att du istället för att använda rsync för att överföra dina statiska filer till servern måste överföra de statiska filerna till lagringsleverantören eller CDN.
Det finns ett antal olika sätt att göra detta på, men om leverantören har ett API kan du använda custom file storage backend för att integrera CDN med ditt Django-projekt. Om du har skrivit eller använder en anpassad lagringsbackend från tredje part kan du berätta för collectstatic att använda den genom att ställa in staticfiles i STORAGES.
Om du till exempel har skrivit en S3-lagringsbackend i myproject.storage.S3Storage kan du använda den med:
STORAGES = {\n # ...\n "staticfiles": {"BACKEND": "myproject.storage.S3Storage"}\n}\nNär det är gjort är allt du behöver göra att köra collectstatic och dina statiska filer kommer att skjutas genom ditt lagringspaket upp till S3. Om du senare behöver byta till en annan lagringsleverantör kan du bara behöva ändra staticfiles i inställningen STORAGES.
För detaljer om hur du skriver en av dessa backends, se Så här skriver du en anpassad lagringsklass. Det finns appar från tredje part som tillhandahåller lagringsbackends för många vanliga API:er för fillagring. En bra startpunkt är översikten på djangopackages.org.
\nFör fullständig information om alla inställningar, kommandon, malltaggar och andra delar som ingår i django.contrib.staticfiles, se the staticfiles reference.