静的ファイルの公開方法¶

revision-up-to:	17812 (1.4)

リリースノートを参照してください

Django の開発者は、ビューや、リクエストごとに新しくレンダリングされるテンプレートといった、 Web アプリケーションの動的な部分にもっぱら関心を持っています。しかし、 Web アプリケーションには静的なファイル ( 画像、CSS、JavaScriptなど ) も含まれています。完全な Web ページをレンダリングするためにはこういったファイルが必要です。

小さなプロジェクトではこのことは大きな問題になりません。 Web サーバが見つけられる場所で静的ファイルを単に管理することができるからです。しかし、もっと大きなプロジェクトで、特に複数のアプリケーションからなる場合は、各アプリケーションが持っている静的ファイルの集まりを複数扱うことになり、ややこしくなってきます。

django.contrib.staticfiles はまさにそのためにあります。これは静的なファイルを各アプリケーションから (さらに指定した別の場所からも) 一つの場所に集め、運用環境で公開しやすくするものです。

Note

もし django-staticfiles アプリケーションを使ったことがあるなら、 django.contrib.staticfiles はよく似たものに見えるでしょう。それはこの 2 つが本質的に同じコードだからです。 django.contrib.staticfiles は django-staticfiles として生まれ、 Django 1.3 に取り込まれました。

`django.contrib.staticfiles` を使う¶

基本的な使い方¶

staticfiles が見つけられる場所に静的ファイルを置いてください。

デフォルトでは、 INSTALLED_APPS に入っているアプリケーションの static/ サブディレクトリです。

おそらく、あなたのプロジェクトには特定のアプリケーションに結びついていない静的なファイルもあるでしょう。 STATICFILES_DIRS には、静的ファイルをロードする時にチェックすべきファイルシステム上のディレクトリを、タプルで記述します。

staticfiles がファイルを探す方法の詳細について知るには STATICFILES_FINDERS 設定のドキュメントを参照してください。
INSTALLED_APPS に django.contrib.staticfiles が入っていることを確認してください。

ローカル環境での開発で runserver を使っているか、 staticfiles_urlpatterns を URLconf に追加してあるなら、これでセットアップは終わりです。自動的に STATIC_URL で静的ファイルが公開されます。 ( newly created プロジェクトでは ) デフォルト設定が /static/ です。
きっとこれらのファイルをテンプレートで使いたいでしょう。一番簡単な方法はコンテキストプロセッサを使うことです。次のようなテンプレートを書けます:
```
<img src="{{ STATIC_URL }}images/hi.jpg" />
```
もっと詳しいことは staticfiles-in-templates に書いてあります。テンプレートタグを使う別の方法も 書かれています 。

ごく簡単に、静的ファイルのデプロイについて¶

ローカル環境での開発が終わり、プロジェクトをデプロイする準備ができたら:

STATIC_URL を静的なファイルを指すパブリックな URL に設定してください。 ( ほとんどの場合、デフォルト値である /static/ でうまく行きます )
STATIC_ROOT に、 collectstatic コマンドを使って静的なファイルを集めたいファイルシステム上のパスを設定してください。例えば:
```
STATIC_ROOT = "/home/jacob/projects/mysite.com/sitestatic"
```
collectstatic コマンドを実行してください:
```
./manage.py collectstatic
```
このコマンドは静的ファイルのストレージを漁って、見つけたファイルを STATIC_ROOT で与えられたディレクトリにコピーします。
STATIC_ROOT に含まれるファイルが STATIC_URL の場所で公開されるように Web サーバを設定しデプロイしてください。

staticfiles-production はいくつかのよくある静的ファイルのデプロイ手法に言及しています。

これらは基本です。設定オプションについてもっと深く知るには、さらに読むべきものがあります。設定やコマンド、またフレームワークに含まれる他のちょっとしたことを知るために、 staticfiles リファレンスを参照してください。

Note

Django の以前のバージョンでは、ユーザがアップロードしたファイルを置くための MEDIA_ROOT に静的なファイルも一緒に置かれ、どちらも MEDIA_URL で公開されていました。 staticfiles アプリケーションを使う目的の 1 つは、静的ファイルとユーザがアップロードしたファイルとを分けて管理することを簡単にするためです。

この理由から、 MEDIA_ROOT および MEDIA_URL は STATIC_ROOT および STATIC_URL とは別の値にしなければなりません。 MEDIA_ROOT に含まれるファイルを公開するには、自分で整理する必要があります。 staticfiles はユーザがアップロードしたファイルを全く扱わないのです。ただし、 MEDIA_ROOT のファイルを公開するために django.views.static.serve() ビューを使うことはできます。 staticfiles-other-directories を参照してください。

テンプレートから静的なファイルを参照する¶

テンプレートではいくつかの箇所で静的なファイルをリンクする必要があるでしょう。もちろん、テンプレートで静的ファイルを単にハードコードすることは可能です:

<img src="http://static.example.com/static/myimage.jpg" />

当然ながら、これでは深刻な問題がいくつかあります。開発環境ではうごきませんし、静的ファイルを公開する場所を変更するのが 非常に 困難です。例えばもし、コンテンツデリバリーネットワーク (CDN) を使うように切り替えたい場合、テンプレート全てを一つ一つ変更することになってしまいます。

もっと良い方法は STATIC_URL の値を直接テンプレートで使うことです。こうすると、一つの値を変更するだけで静的ファイルのサーバを切り替えることができます。ずっと良いですね！

Django にはこの設定値をテンプレートで使うための複数の方法があります。コンテキストプロセッサとテンプレートタグです。

コンテキストプロセッサを使う¶

組み込みのコンテキストプロセッサは簡単に使えます。 TEMPLATE_CONTEXT_PROCESSORS 設定に 'django.core.context_processors.static' が含まれていれば良いだけです。そしてデフォルトではそのようになっています。自ら設定を編集する場合は、こんな風になるでしょう:

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media',
    'django.core.context_processors.static',
    'django.contrib.auth.context_processors.auth',
    'django.contrib.messages.context_processors.messages',
)

これができれば STATIC_URL をテンプレートで参照できます:

<img src="{{ STATIC_URL }}images/hi.jpg" />

{{ STATIC_URL }} がテンプレートが使えなければ、おそらくテンプレートのレンダリングに RequestContext を使っていないためです。

手短に復習すると、コンテキストプロセッサは全てのテンプレートのコンテキストに変数を追加します。しかし、コンテキストプロセッサはテンプレートのレンダリングに RequestContext を使うことを要求します。 generic view を使えば自動的にそうなりますが、自作のビューでは明示的に RequestContext を使わなければなりません。これがどのように動くか知りたければ、コンテキストのサブクラス: RequestContext をチェックしてください。

別の方法は Django 本体に含まれる get_static_prefix テンプレートタグを使うことです。

テンプレートタグを使う¶

よりパワフルなツールが static テンプレートタグです。このタグは与えられた相対パスに対して、 STATICFILES_STORAGE ストレージの設定を使って URL を組み立てます。

{% load staticfiles %}
<img src="{% static "images/hi.jpg" %}" />

通常のコンテキスト変数を受け取ることもできます。例えば user_stylesheet 変数がテンプレートに渡されたとすると:

{% load staticfiles %}
<link rel="stylesheet" href="{% static user_stylesheet %}" type="text/css" media="screen" />

Note

Django コアセットのビルトインテンプレートタグに含まれる static テンプレートタグもあります。これは同じ引数を持ちますが、 STATIC_URL 設定と与えられたパスを単に urlparse.urljoin() に渡します。これはテンプレートを変更することなく簡単にストレージバックエンドを切り替えることができないという不利な点があります。ですので注意して staticfiles の static テンプレートタグを使いましょう。

開発中の静的ファイルの扱い方¶

このツールは基本的に、運用環境にうまく静的ファイルをデプロイするのを補助するために設計されています。これは普通、別途専用で用意された静的ファイルサーバのことですが、ローカルでの開発時に使うには大きなオーバーヘッドがかかります。そこで staticfiles アプリは 手軽でダーティなヘルパービュー を導入します。これによって開発中にローカルのファイルを使えるようになります。

ヘルパービューは自動で有効になっています。 runserver コマンドを使った時に STATIC_URL で静的ファイルを公開できます。

ローカル開発で他のサーバを使っている場合、このビューを有効にするには URLconf に 2 行追加する必要があります。 1 つめの行はファイルの先頭に、 2 つめの行は末尾に書きます:

from django.contrib.staticfiles.urls import staticfiles_urlpatterns

# ... URLconf の他の行がここに入ります

urlpatterns += staticfiles_urlpatterns()

この関数は STATIC_URL 設定を調べ、静的ファイルを適切に公開できるようにビューを設定します。アプリケーションディレクトリの中でどこを探せばいいかを django.contrib.staticfiles に教えるために、 STATICFILES_DIRS を設定するのを忘れないでください。

Warning

ローカル環境でのファイル公開は DEBUG が True の時にだけ動作します。

それはこのビューが ひどく非効率 で、おそらく セキュアでない ためです。このビューはローカル環境での開発だけを意図しており、 決して運用環境で使うべきではありません 。

加えて、 staticfiles_urlpatterns を使うと、 STATIC_URL 設定は空であったり http://static.example.com/ 完全な URL であったりできなくなります。

開発中の staticfiles の使い方についてもっと詳しく知るには staticfiles-development-view を参照してください。

他のディレクトリを公開する¶

serve(request, path, document_root, show_indexes=False)¶

プロジェクト内に含まれているものとは別のファイルもあるかもしれません。利便性のため、ローカル環境での開発で Django に公開させたいのではないでしょうか。 serve() ビューは指定したどんなディレクトリも公開できます。 (繰り返しますが、このビューは運用には耐えません。開発の補助としてだけ使ってください。運用環境ではこれらのファイルは実際のフロントエンドサーバで公開すべきです)

よくある例は MEDIA_ROOT にユーザがアップロードしたコンテンツです。 staticfiles は静的アセットを意図していて、ユーザがアップロードしたファイルのハンドリングは含まれていませんが、 URLconf に以下のような記述を追加することで MEDIA_ROOT を Django に公開させることができます:

from django.conf import settings

# ... URLconf の他の部分がここに入ります ...

if settings.DEBUG:
    urlpatterns += patterns('',
        url(r'^media/(?P<path>.*)$', 'django.views.static.serve', {
            'document_root': settings.MEDIA_ROOT,
        }),
   )

このスニペットは MEDIA_URL が '/media/' という値になっていることを仮定しています。 serve() を呼び出し、 URLconf と ( 必須の ) document_root パラメータをパスに渡します。

static(prefix, view='django.views.static.serve', **kwargs)¶

この URL パターンを定義するのはいささか大変になってくるので、 Django は小さな URL ヘルパー関数 static() を持っています。これは MEDIA_URL のようなプレフィックスと、 'django.views.static.serve' のようなドット区切りのビューへのパスをパラメータにとります。他の関数パラメータは透過的にビューに渡されます。

開発中に MEDIA_URL ('/media/') を公開する例です:

from django.conf import settings
from django.conf.urls.static import static

urlpatterns = patterns('',
    # ... the rest of your URLconf goes here ...
) + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Note

このヘルパー関数は、デバッグモードの中で、与えられたプレフィックスが ( 例 /static/) ローカルであって URL ( 例 http://static.example.com/) ではない時にだけ操作できます。

運用環境での静的ファイル公開¶

運用環境に静的ファイルを置くための基本原則はシンプルです。静的ファイルが変更された時には collectstatic コマンドを実行し、集められた静的ファイルのディレクトリ (STATIC_ROOT) を静的ファイルサーバに移動し、公開するために整理します。

もちろん、あらゆるデプロイタスクと同様、細部には悪魔がいます。運用環境ごとにセットアップには小さな違いがあり、基本原則を必要に合うように変えなければならないでしょう。以下はその助けになるかもしれないいくつかの共通パターンです。

一つのサーバでアプリケーションと静的ファイルを扱う¶

既にサイトを公開しているのと同じサーバで静的ファイルを公開したい場合、基本原則は以下のように変更されます:

デプロイサーバにコードを展開します。
そのサーバ上で collectstatic を実行し、全ての静的ファイルを STATIC_ROOT 内にコピーします。
Web サーバに STATIC_ROOT を教えます。例えば Apache と mod_wsgi での方法があります。

このプロセスはきっと自動化したくなるでしょう。特に複数の Web サーバを管理している時はそうです。この自動化を行う方法には色々ありますが、 Django を使う開発者には嬉しいであろう一つの方法が Fabric です。

以下とそれに続くセクションでは、いくつかの fabfiles (Fabric scripts のこと ) を示します。それらはファイルのデプロイ方法を自動化してくれます。 fabfile の文法はかなり直感的ですが、ここで網羅することはできません。 Fabric ドキュメントを読めば、文法の完全な説明が得られます。

静的ファイルを 2 つの Web サーバにデプロイする fabfile はこのようになるでしょう:

from fabric.api import *

# デプロイ先のホスト
env.hosts = ['www1.example.com', 'www2.example.com']

# プロジェクトコードが格納される場所
env.project_root = '/home/www/myproject'

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

専用のサーバで静的ファイルを公開する¶

大きな Django アプリケーションはたいてい別の Web サーバを静的ファイルの公開に使っているでしょう。そのサーバでは Django は動いていません。このサーバは別の種類の Web サーバ、速いがフル機能ではないものを使っていることが多いです。いくつか良い選択肢を挙げると:

lighttpd
Nginx
TUX
Cherokee
A stripped-down version of Apache

これらのサーバの設定方法はこのドキュメントの範囲を超えますので、説明はそれぞれのサーバの相当するドキュメントを調べてください。

静的ファイルサーバでは Django を動かせないでしょうから、デプロイ戦略を次のように変更する必要があります:

静的ファイルが変更された時、 collectstatic をローカルで実行します。
ローカルの STATIC_ROOT を静的ファイルサーバの公開ディレクトリにアップロードします。 rsync は変更されたファイルのビットだけを転送するだけで済むので、この手順の良い選択肢です。

fabfile はこのようになるでしょう:

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

# 静的ファイルがローカル環境で集められる場所
env.local_static_root = '/tmp/static'

# 静的ファイルがリモートで置かれる場所
env.remote_static_root = '/home/www/static.example.com'

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

クラウドサービスや CDN での静的ファイル公開¶

もう一つの一般的な手法は、静的ファイルを Amazon S3 のようなクラウドストレージプロバイダや、 CDN (content delivery network) で公開することです。これにより静的ファイル公開の問題を気にせずにすみ、またしばしば (CDN を使う場合は特に ) Web ページを高速にロードさせることができます。

これらのサービスを使う場合、基本的なワークフローは上の話と少し似ていますが、 rsync を使ってファイルをサーバに転送する代わりに、ストレージプロバイダや CDN に送らなければならないところが違います。

これを行う方法は様々ですが、プロバイダに API がある場合、カスタムファイルストレージバックエンドを使えば、手順が信じられないほどシンプルになります。 STATICFILES_STORAGE に、自分が書いた、あるいはサードパーティ製のカスタムストレージバックエンドを設定することにより、 collectstatic にそのバックエンドを使うように教えることができます。

例えば、 S3 ストレージバックエンドを myproject.storage.S3Storage に書いたとすると、このように使うことができます:

STATICFILES_STORAGE = 'myproject.storage.S3Storage'

こうすれば、 collectstatic をするだけで、静的ファイルはあなたのストレージパッケージを経て S3 にアップロードされます。もし後で別のストレージプロバイダに変更しなければならなくなっても、単に STATICFILES_STORAGE 設定を変更するだけで済みます。

カスタムファイルストレージバックエンドを書く方法の詳細はカスタムのストレージシステムを作成するにあります。

`django-staticfiles` からアップグレードする¶

django.contrib.staticfiles は元々 django-staticfiles として生まれました。もし django-staticfiles 1.0 以前 (0.3.4 など) から django.contrib.staticfiles にアップグレードしようとすると、いくつかの変更をしなければなりません:

アプリケーションの静的ファイルはそれぞれのアプリケーションの static ディレクトリになければなりません。 (django-staticfiles は media という少々混乱させる名前を使っていました)
コマンド build_static と resolve_static は今では collectstatic と findstatic という名前になっています。
設定 STATICFILES_PREPEND_LABEL_APPS, STATICFILES_MEDIA_DIRNAMES, STATICFILES_EXCLUDED_APPS は削除されました。
設定 STATICFILES_RESOLVERS は削除され、新しい STATICFILES_FINDERS に置き換えられました。
STATICFILES_STORAGE のデフォルトは staticfiles.storage.StaticFileStorage から staticfiles.storage.StaticFilesStorage にリネームされました。
ローカル環境で runserver を使う時 (DEBUG 設定が True の時) 、開発中の静的ファイル公開のために URLconf に何も追加する必要がなくなりました。

さらに学ぶためには¶

このドキュメントでは基本といくつかのよくある使用パターンについて説明しました。 django.contrib.staticfiles に含まれる全ての設定、コマンド、テンプレートタグ、その他について、完全な詳細を知るには staticfiles リファレンスを参照してください。

Django 1.4 documentation

静的ファイルの公開方法¶

`django.contrib.staticfiles` を使う¶

基本的な使い方¶

ごく簡単に、静的ファイルのデプロイについて¶

テンプレートから静的なファイルを参照する¶

コンテキストプロセッサを使う¶

テンプレートタグを使う¶

開発中の静的ファイルの扱い方¶

他のディレクトリを公開する¶

運用環境での静的ファイル公開¶

一つのサーバでアプリケーションと静的ファイルを扱う¶

専用のサーバで静的ファイルを公開する¶

クラウドサービスや CDN での静的ファイル公開¶

`django-staticfiles` からアップグレードする¶

さらに学ぶためには¶

Table Of Contents

前後のページ

現在のページ:

This Page

Last update:

Django 1.4 documentation

静的ファイルの公開方法¶

django.contrib.staticfiles を使う¶

基本的な使い方¶

ごく簡単に、静的ファイルのデプロイについて¶

テンプレートから静的なファイルを参照する¶

コンテキストプロセッサを使う¶

テンプレートタグを使う¶

開発中の静的ファイルの扱い方¶

他のディレクトリを公開する¶

運用環境での静的ファイル公開¶

一つのサーバでアプリケーションと静的ファイルを扱う¶

専用のサーバで静的ファイルを公開する¶

クラウドサービスや CDN での静的ファイル公開¶

django-staticfiles からアップグレードする¶

さらに学ぶためには¶

Last update:

`django.contrib.staticfiles` を使う¶

`django-staticfiles` からアップグレードする¶