L’idea di base per mettere in produzione i file statici consiste in due passaggi: eseguire il comando collectstatic quando i file statici cambiano, quindi fare in modo che la directory dei file statici raccolti (STATIC_ROOT) sia spostata nella directory statica del file server e servita. A seconda di STATICFILES_STORAGE, i file potrebbero dover essere spostati manualmente in una nuova posizione oppure potrebbe occuparsene il metodo post_process della classe Storage.
Così come tutti i task di deploy, il diavolo è nei dettagli. Ogni setup di produzione sarà differente, quindi dovrai adattare il piano di base per soddisfare le tue necessità. Ecco alcuni pattern che potrebbero essere di aiuto.
\nSe vuoi distribuire i tuoi file statici dallo stesso server che sta attualmente distribuendo il tuo sito, puoi procedere in questo modo:
\nInvia il codice al server di distribuzione.
Nel server, esegui collectstatic per copiare tutti i file statici in STATIC_ROOT.
Configura il tuo webserver per servire i file in STATIC_ROOT sotto la URL STATIC_URL. Per esempio, ecco come farlo con Apache e mod_wsgi.
Probabilmente vorrai automatizzare questo processo, in special modo se ha diversi web servers.
\nSiti Django più grandi usano un web server separato – uno che non sta facendo girare Django – per servire file statici. Questo server spesso fa girare un tipo diverso di web server – più veloce ma meno completo. Alcune scelte comuni sono:
\n\nLa configurazione di questi servers è al di là dello scopo di questo documento, consulta la documentazione dei rispettivi server per istruzioni.
\nDal momento che il tuo file server statico non eseguirà Django, dovrai modificare la strategia di distribuzione affinché sia qualcosa di simile:
\nQuando i tuoi file statici vengono modificati, lancia collectstatic localmente.
Spingere STATIC_ROOT fino al file server statico nella directory che viene servita.`rsync <https://rsync.samba.org/>`_ è una scelta comune per questo step perchè ha bisogno di trasferire solo i pezzi di file statici che non sono cambiati.
Un’altra tattica comune è servire i file statici da un provider cloud storage come Amazon S3 e/o CDN (content delivery network). Questo ti permette di ignorare il problema di servire i file statici e va spesso bene per pagine che devono caricarsi più velocemente (specialmente usando una CDN).
\nQuando utilizzi questi servizi, il flusso di lavoro assomiglierà a quello visto in precedenza, ad eccezione dell’utilizzo di rsync per trasferire i tuoi file statici al server, dovrai invece trasferire i tuoi file verso lo storage provider o verso la CDN.
Ci sono molti modi in cui puoi farlo, ma se il provider ha una API, puoi usare un backend personalizzato per lo storage dei file per integrare la CDN nel tuo progetto Django. Se hai scritto o stai usando un backend personalizzato di storage di terze parti, puoi dire a collectstatic di usarlo impostando STATICFILES_STORAGE allo storage engine.
Per esempio, e tu hai definito uno storage S3 come backend in myproject.storage.S3Storage, puoi utilizzarlo con:
STATICFILES_STORAGE = 'myproject.storage.S3Storage'\nUna volta fatto, tutto quel che devi fare è lanciare collectstatic ed i tuoi file statici saranno spostati attraverso il tuo storage fino ad S3. Se hai bisogno di cambiare storage provider in un secondo tempo, devi solo cambiare l’impostazione STATICFILES_STORAGE.
Per i dettagli su come potresti scrivere uno di questi backend, vedi Come scrivere una storage class personalizzata. Sono disponibili app di terze parti che forniscono backend di archiviazione per molte API di storage file comuni. Un buon punto di partenza è la panoramica su djangopackages.org.
\nPer avere dettagli completi su tutte le impostazioni, i comandi, i tag di template ed altri pezzi inclusi in django.contrib.staticfiles, visita la guida di riferimento di staticfiles.