Vedi anche
Per una introduzione all’uso di django.contrib.staticfiles
, vedi Come gestire file statici (Es. immagini, JavaScript, CSS).
The basic outline of putting static files into production consists of two
steps: run the collectstatic
command when static files change, then
arrange for the collected static files directory (STATIC_ROOT
) to be
moved to the static file server and served. Depending the staticfiles
STORAGES
alias, files may need to be moved to a new location
manually or the post_process
method of
the Storage
class might take care of that.
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.
Se vuoi distribuire i tuoi file statici dallo stesso server che sta attualmente distribuendo il tuo sito, puoi procedere in questo modo:
collectstatic
per copiare tutti i file statici in STATIC_ROOT
.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.
Siti 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:
La configurazione di questi servers è al di là dello scopo di questo documento, consulta la documentazione dei rispettivi server per istruzioni.
Dal momento che il tuo file server statico non eseguirà Django, dovrai modificare la strategia di distribuzione affinché sia qualcosa di simile:
collectstatic
localmente.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).
Quando 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.
There’s any number of ways you might do this, but if the provider has an API,
you can use a custom file storage backend
to integrate the CDN with your Django project. If you’ve written or are using a
3rd party custom storage backend, you can tell collectstatic
to use
it by setting staticfiles
in STORAGES
.
Per esempio, e tu hai definito uno storage S3 come backend in myproject.storage.S3Storage
, puoi utilizzarlo con:
STORAGES = {
# ...
"staticfiles": {"BACKEND": "myproject.storage.S3Storage"}
}
Once that’s done, all you have to do is run collectstatic
and your
static files would be pushed through your storage package up to S3. If you
later needed to switch to a different storage provider, you may only have to
change staticfiles
in the STORAGES
setting.
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.
The STORAGES
setting was added.
Per 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.
mag 03, 2024