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 :

• Envoyer votre code vers le serveur de déploiement.
• Sur le serveur, lancer collectstatic pour copier tous les fichiers statiques dans STATIC_ROOT.
• Configurer le serveur Web pour qu’il serve les fichiers de STATIC_ROOT sous l’URL STATIC_URL. Par exemple, voici comment faire cela avec Apache et mod_wsgi.

Ce processus devrait idéalement être automatisé, particulièrement si vous avez affaire à plusieurs serveurs Web.

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 :

• Nginx
• Une version allégée d”Apache

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.

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, vous pouvez utiliser un moteur personnalisé de stockage de fichiers pour intégrer le CDN à votre projet Django. 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 définissant staticfiles dans STORAGES.

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

STORAGES = {
    # ...
    "staticfiles": {"BACKEND": "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 serait possible de le faire en changeant uniquement staticfiles dans le réglage STORAGES.

Pour plus de détails sur l’écriture d’un moteur de stockage, consultez Écriture d’une classe de stockage personnalisée. 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.org.