サイトと静的ファイルを同じサーバから配信する¶

静的ファイルをすでにサイトを配信しているのと同じサーバから配信したい場合、配信の手順は次のようになります。

• デプロイするサーバにコードを push する。
• サーバ側で、 collectstatic を実行することで、すべての静的ファイルを STATIC_ROOT で設定したディレクトリに集める。
• STATIC_ROOT に置かれたファイルを STATIC_URL から配信するように、Web サーバの設定を行う。たとえば、Apache と mod_wsgi を使用している場合、Apache と mod_wsgi を使用したファイルの配信 が参考になると思います。

複数の Web サーバーがある場合は、おそらくこのプロセスを自動化したいと思うでしょう。

専用のサーバから静的ファイルを配信する¶

ほとんどの大規模な Django サイトでは、静的ファイルの配信に別の Web サーバ（つまり Django を動かしていないサーバ）を使っています。このサーバは、多くの場合、別のタイプの Web サーバを実行しています。高速で、機能が限定的なものです。よくある選択肢は下記です:

• Nginx
• Apache の機能縮小版

これらのサーバの設定方法は、このドキュメントの範囲外です。それぞれのサーバのドキュメントを参考に設定してください。

静的ファイルサーバでは Django が実行されていないので、次のようにデプロイの戦略を変更する必要があります。

• 静的ファイルが変更されたら、ローカル側で collectstatic を実行する。
• ローカルの STATIC_ROOT を静的ファイルサーバのファイル配信ディレクトリに push します。これには通常、rsync を使います。変更された静的ファイルだけを転送できるからです。

クラウドサービスや CDN から静的ファイルを配信する¶

もう1つの一般的な方法は、AmazonのS3やCDN（コンテンツ・デリバリー・ネットワーク）のようなクラウドストレージから静的ファイルを配信することです。これにより、静的ファイルを配信する際の問題を無視することができ、多くの場合、Webページの読み込みが速くなります（特にCDNを使用する場合）。

これらのサービスを使う場合でも、基本的なワークフローは上で説明した通りです。ただし、rsync を使って静的ファイルをサーバに転送する代わりに、ストレージプロバイダや CDN に転送する必要があります。

そのための方法はいろいろありますが、プロバイダが API を提供している場合、カスタムのファイルストレージバックエンド を使って Django プロジェクトと CDN を統合できます。独自に作成したカスタムストレージバックエンドを使用している場合や、サードパーティのカスタムストレージバックエンドを使用している場合は、STORAGES に staticfiles を設定することで collectstatic にそれを使うよう指示できます。

たとえば、S3 storage backend を myproject.storage.S3Storage としてすでに書いていれば、次のように書くだけでこのストレージを利用できます。

STORAGES = {
    # ...
    "staticfiles": {"BACKEND": "myproject.storage.S3Storage"}
}

これが完了したら、 collectstatic を実行するだけで、静的ファイルがストレージパッケージを通して S3 にプッシュされます。後で別のストレージプロバイダに切り替える必要がある場合は、 STORAGES 設定の staticfiles を変更するだけです。

これらのバックエンドの書き方の詳細については カスタムのストレージクラスを書く を参照してください。多くの一般的なファイルストレージ API 用のストレージバックエンドを提供するサードパーティアプリがあります。良い出発点は djangopackages.org の overview です。