Déploiement des fichiers statiques

Voir aussi

Pour une introduction à l’utilisation de django.contrib.staticfiles, lisez Gestion des fichiers statiques (par ex. images, JavaScript, CSS).

Service des fichiers statiques en production

La procédure de base de la mise en production des fichiers statiques est simple : lancer la commande collectstatic lors de changements de fichiers statiques, puis s’occuper de déplacer le répertoire des fichiers statiques rassemblés (STATIC_ROOT) vers le serveur de fichiers statiques afin qu’ils soient accessibles. En fonction de STATICFILES_STORAGE, il se peut que les fichiers doivent être déplacés manuellement vers un nouvel emplacement, ou alors c’est la méthode post_process de la classe Storage qui prend cela en charge.

Naturellement, comme pour toute tâche de déploiement, le diable est dans les détails. Chaque configuration de production est légèrement différente, il faut donc adapter la procédure de base à chaque situation. Vous trouverez ci-dessous quelques cas fréquents qui peuvent vous aider.

Site et fichiers statiques sur le même serveur

Si vous souhaitez servir les fichiers statiques à partir du même serveur qui s’occupe déjà de votre site, le processus peut ressembler à ceci :

Il est souhaitable d’automatiser ce processus, surtout si vous vous occupez de plusieurs serveurs Web. Il existe plusieurs façons de procéder à cette automatisation, mais l’une des options que beaucoup de développeurs Django affectionnent est Fabric.

Ci-dessous et dans les sections suivantes, nous montrerons quelques exemples de fichiers fabfiles (scripts Fabric) qui automatisent ces options de déploiement de fichiers. La syntaxe d’un fichier fabfile est relativement explicite, mais nous n’aborderons pas ce thème ici ; consultez la documentation de Fabric pour des explications complètes sur la syntaxe.

Ainsi, un fichier fabfile pour déployer des fichiers statiques vers plusieurs serveurs Web pourrait ressembler à ceci :

from fabric.api import *

# Hosts to deploy onto
env.hosts = ['www1.example.com', 'www2.example.com']

# Where your project code lives on the server
env.project_root = '/home/www/myproject'

def deploy_static():
    with cd(env.project_root):
        run('./manage.py collectstatic -v0 --noinput')

Fichiers statiques sur un serveur dédié

La plupart des gros sites Django utilisent un serveur Web séparé (c’est-à-dire qui n’héberge pas Django) pour servir les fichiers statiques. Ce serveur utilise fréquemment un autre type de serveur Web, plus rapide mais moins riche en fonctions. Voici quelques choix populaires :

La configuration de ces serveurs n’est pas dans le thème de ce document ; référez-vous à la documentation du serveur concerné pour toute information supplémentaire.

Comme votre serveur de fichiers statiques ne fera pas tourner Django, vous devrez modifier la stratégie de déploiement pour qu’elle ressemble à ceci :

  • Lorsque des fichiers statiques sont modifiés, lancer collectstatic localement.

  • Envoyer le contenu local de STATIC_ROOT vers le serveur de fichiers statiques dans le répertoire qui est servi. rsync est un choix courant à cette étape car seuls les parties modifiées des fichiers statiques doivent être transférées.

Voici à quoi ça pourrait ressembler dans un fichier fabfile :

from fabric.api import *
from fabric.contrib import project

# Where the static files get collected locally. Your STATIC_ROOT setting.
env.local_static_root = '/path/to/static'

# Where the static files should go remotely
env.remote_static_root = '/home/www/static.example.com'

@roles('static')
def deploy_static():
    local('./manage.py collectstatic')
    project.rsync_project(
        remote_dir=env.remote_static_root,
        local_dir=env.local_static_root,
        delete=True,
    )

Fichiers statiques sur un service cloud ou un CDN

Une autre tactique fréquente est de servir les fichiers statiques à partir d’un fournisseur de stockage en nuage (cloud) comme Amazon S3 ou un CDN (« content delivery network », réseau de fourniture de contenu). Cela vous permet d’oublier les problèmes liés au service de fichiers statiques et peut souvent accélérer le chargement des pages Web (particulièrement en ce qui concerne les CDN).

Quand vous utilisez ces services, le processus de base ressemble un peu à ce qui a été montré ci-dessus, sauf qu’à la place d’utiliser rsync pour transférer les fichiers statiques vers le serveur, il est nécessaire de transférer les fichiers statiques chez le fournisseur de stockage ou le CDN.

Ceci peut se faire de plusieurs manières, mais si le fournisseur propose une API, un moteur personnalisé de stockage de fichiers pourrait grandement faciliter ce processus. Si vous avez écrit un moteur personnalisé de stockage ou que vous en utilisez un de tierce partie, vous pouvez indiquer à collectstatic de l’utiliser en renseignant STATICFILES_STORAGE.

Par exemple, si vous avez écrit un moteur de stockage S3 dans myproject.storage.S3Storage, voici comment le configurer :

STATICFILES_STORAGE = 'myproject.storage.S3Storage'

Après cela, tout ce qu’il vous reste à faire est de lancer collectstatic et vos fichiers statiques seront envoyés vers S3 par l’intermédiaire de votre paquet de stockage. Si vous deviez ultérieurement passer à un autre fournisseur de stockage, il se pourrait que le seul changement nécessaire soit une modification du réglage STATICFILES_STORAGE.

Pour plus de détails sur l’écriture d’un moteur de stockage, consultez Écriture d’un système de stockage personnalisé. Il existe des applications de tierce partie offrant des moteurs de stockage pour de nombreuses API de stockage de fichiers. Un bon point de départ est l’aperçu général sur djangopackages.com.

En savoir plus

Pour des détails complets sur tous les réglages, les commandes, les balises de gabarit et les autres fonctions de django.contrib.staticfiles, consultez la référence de staticfiles.

Back to Top