The basic outline of putting static files into production consists of two\nsteps: run the collectstatic command when static files change, then\narrange for the collected static files directory (STATIC_ROOT) to be\nmoved to the static file server and served. Depending on the staticfiles\nSTORAGES alias, files may need to be moved to a new location\nmanually or the post_process method of\nthe 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.
\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.
There’s any number of ways you might do this, but if the provider has an API,\nyou can use a custom file storage backend\nto integrate the CDN with your Django project. If you’ve written or are using a\n3rd party custom storage backend, you can tell collectstatic to use\nit by setting staticfiles in STORAGES.
Per esempio, e tu hai definito uno storage S3 come backend in myproject.storage.S3Storage, puoi utilizzarlo con:
STORAGES = {\n # ...\n "staticfiles": {"BACKEND": "myproject.storage.S3Storage"}\n}\nOnce that’s done, all you have to do is run collectstatic and your\nstatic files would be pushed through your storage package up to S3. If you\nlater needed to switch to a different storage provider, you may only have to\nchange 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.
\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.