製品で静的 (static) ファイルを配置する基本的な流れは、次のように単純なものです。まず、静的ファイルが変更された時に、collectstatic コマンドを実行します。そして、静的ファイル用のサーバへ移動する、収集 (collect) された静的ファイルのディレクトリ (STATIC_ROOT) を用意し、ファイルを配信 (serve) できるようにします。setting:STATICFILES_STORAGE の設定によっては、ファイルを手動で新しい場所へ移動する必要があるかもしれません。ただし、Storage クラスの post_process メソッドが面倒を見てくれる場合もあります。
どんなデプロイのタスクでも、悪魔は細部に宿るものです。(訳注: Devil's in the detail。神は細部に宿る (God is in the detail) から派生したことわざ) それぞれの製品ごとにセットアップには僅かな違いがあるものなので、基本的な流れに沿うように多少の手直しが必要になるかもしれません。以下によくあるパターンを紹介しているので、参考にしてください。
\n静的ファイルをすでにサイトを配信しているのと同じサーバから配信したい場合、配信の手順は次のようになります。
\nデプロイするサーバにコードを push する。
サーバ側で、 collectstatic を実行することで、すべての静的ファイルを STATIC_ROOT で設定したディレクトリに集める。
STATIC_ROOT に置かれたファイルを STATIC_URL から配信するように、Web サーバの設定を行う。たとえば、Apache と mod_wsgi を使用している場合、Apache と mod_wsgi を使用したファイルの配信 が参考になると思います。
きっとあなたは、このプロセスを自動化したくなりますよね。特に複数の Web サーバを管理しているならなおさらです。この自動化を達成するには様々な方法がありますが、Django 利用者には Fabric が人気です。
\n以下、続く数セクションで、fabfile (たとえば、Fabric スクリプト) の例をいくつかお見せします。fabfile によって、上で説明したファイルのデプロイを自動化できます。fabfile のシンタックスはひと目で分かるほど簡単なものですが、ここでは説明しないので、完全な文法について知りたければ、Fabric's documentation を参照してください。
\nそれでは、2台の Web サーバへ静的ファイルをデプロイする fabfile は、次のようになります。
\nfrom fabric.api import *\n\n# Hosts to deploy onto\nenv.hosts = ['www1.example.com', 'www2.example.com']\n\n# Where your project code lives on the server\nenv.project_root = '/home/www/myproject'\n\ndef deploy_static():\n with cd(env.project_root):\n run('./manage.py collectstatic -v0 --noinput')\n比較的大きな Django サイトでは、Django を実行しているのとは異なる専用のサーバを用意して、静的ファイルを配信するのがふつうです。こうした専用サーバでは、高速なサーバや機能を限定したサーバなど、普通の Web サーバとは異なる種類のサーバを利用します。よくある選択肢としては、次のものが挙げられます。
\n\nこれらのサーバの設定方法は、このドキュメントの範囲外です。それぞれのサーバのドキュメントを参考に設定してください。
\n静的ファイルサーバでは Django が実行されていないので、次のようにデプロイの戦略を変更する必要があります。
\n静的ファイルが変更されたら、ローカル側で collectstatic を実行する。
ローカル側の STATIC_ROOT を静的ファイルサーバのファイル配信ディレクトリにアップロードします。これには、rsync を使用するのが一般的です。rsync を利用すれば、変更された静的ファイルの情報だけを転送することができます。
以上の手順を fabfile にすると、次のようになります。
\nfrom fabric.api import *\nfrom fabric.contrib import project\n\n# Where the static files get collected locally. Your STATIC_ROOT setting.\nenv.local_static_root = '/path/to/static'\n\n# Where the static files should go remotely\nenv.remote_static_root = '/home/www/static.example.com'\n\n@roles('static')\ndef deploy_static():\n local('./manage.py collectstatic')\n project.rsync_project(\n remote_dir=env.remote_static_root,\n local_dir=env.local_static_root,\n delete=True,\n )\nAnother common tactic is to serve static files from a cloud storage provider\nlike Amazon's S3 and/or a CDN (content delivery network). This lets you\nignore the problems of serving static files and can often make for\nfaster-loading Web pages (especially when using a CDN).
\nこれらのサービスを使う場合でも、基本的なワークフローは上で説明した通りです。ただし、rsync を使って静的ファイルをサーバに転送する代わりに、ストレージプロバイダや CDN に転送する必要があります。
そのための方法はいろいろありますが、プロバイダが API を提供している場合、custom file storage backend を使えば、プロセスを非常に簡単にすることができます。すでに自分でこれを書いているか、サードパーティの custom file storage backend を使っているなら、STATICFILES_STORAGE をストレージエンジンに設定するだけで、collectstatic でストレージプロバイダを使用することができます。
たとえば、S3 storage backend を myproject.storage.S3Storage としてすでに書いていれば、次のように書くだけでこのストレージを利用できます。
STATICFILES_STORAGE = 'myproject.storage.S3Storage'\n一度これを設定すれば、あとは collectstatic を実行するだけで、ストレージパッケージ経由で静的ファイルを S3 へアップロードすることができます。後で別のストレージプロバイダに乗り換えることになったとしても、STATICFILES_STORAGE の設定を書き換えるだけで、簡単にプロバイダを変更できます。
バックエンドの書き方については、詳しくは Writing a custom storage system を参照してください。しかし、よく利用されるファイルストレージの API については、すでにサードパーティのアプリが書かれています。それらを探すには次のサイトをチェックしてください。 overview at djangopackages.com.
\nすべての設定、コマンド、テンプレートタグなどの詳細と、django.contrib.staticfiles に含まれているその他の機能については、staticfiles リファレンス を読んでください。