Come distribuire file statici

Vedi anche

Per una introduzione all’uso di django.contrib.staticfiles, vedi Come gestire file statici (Es. immagini, JavaScript, CSS).

Distribuire file statici in produzione

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.

Distribuire il sito ed i file statici dallo stesso server

Se vuoi distribuire i tuoi file statici dallo stesso server che sta attualmente distribuendo il tuo sito, puoi procedere in questo modo:

Probabilmente vorrai automatizzare questo processo, in special modo se ha diversi web servers.

Distribuire file statici da un server dedicato

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:

  • Quando 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.

Distribuire file statici da un servizio cloud o da una CDN

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.

Per saperne di più

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.

Lista dei controlli per la distribuzione
Come autenticarsi usando REMOTE_USER
Back to Top