Развёртывание статических файлов

Обработка статических файлов в рабочей среде

Основной порядок размещения статических файлов в рабочей среде прост: запустите команду collectstatic при изменении статических файлов, а затем организуйте перемещение каталога собранных статических файлов (STATIC_ROOT) на сервер статических файлов и их обработку. В зависимости от STATICFILES_STORAGE, файлы могут потребоваться переместить вручную в новое местоположение, или метод post_process класса Storage может позаботиться об этом.

Конечно, как и при всех задачах развёртывания, дьявол кроется в деталях. Каждая конфигурация рабочей среды будет немного отличаться, поэтому вам нужно будет адаптировать основной порядок под свои нужды. Ниже приведены несколько распространённых шаблонов, которые могут помочь.

Обработка сайта и статических файлов с одного сервера

Если вы хотите обрабатывать статические файлы с того же сервера, который уже обрабатывает ваш сайт, процесс может выглядеть следующим образом:

• Загрузите код на сервер развёртывания.
• На сервере запустите collectstatic, чтобы скопировать все статические файлы в STATIC_ROOT.
• Настройте веб-сервер для обработки файлов в STATIC_ROOT по адресу STATIC_URL. Например, вот как сделать это с Apache и mod_wsgi.

Вероятно, вам захочется автоматизировать этот процесс, особенно если у вас несколько веб-серверов. Существует множество способов автоматизации, но одним из вариантов, который нравится многим разработчикам Django, является Fabric.

Ниже, и в следующих разделах, мы покажем несколько примеров fabfile (т. е. скриптов Fabric), которые автоматизируют эти варианты развёртывания файлов. Синтаксис fabfile довольно простой, но здесь не будет рассматриваться; обратитесь к документации Fabric для получения полного объяснения синтаксиса.

Итак, fabfile для развёртывания статических файлов на нескольких веб-серверах может выглядеть примерно так:

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')

Обработка статических файлов с выделенного сервера

Большинство крупных сайтов Django используют отдельный веб-сервер — то есть, сервер, который не выполняет также Django — для обработки статических файлов. Этот сервер часто выполняет другой тип веб-сервера — более быстрый, но менее функциональный. Некоторые распространённые варианты — это:

• Nginx
• Упрощённая версия Apache

Настройка этих серверов выходит за рамки этого документа; обратитесь к документации каждого сервера для получения инструкций.

Поскольку ваш сервер статических файлов не будет выполнять Django, вам нужно будет изменить стратегию развёртывания примерно следующим образом:

• При изменении статических файлов запустите collectstatic локально.
• Загрузите локальный STATIC_ROOT на сервер статических файлов в каталог, который обрабатывается. rsync — распространённый выбор для этого этапа, так как он передает только изменённые части статических файлов.

Вот как это может выглядеть в 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,
    )

Обработка статических файлов с облачного сервиса или CDN

Ещё один распространённый приём — обработка статических файлов с облачного хранилища, например Amazon S3, и/или CDN (сетью доставки контента). Это позволяет вам игнорировать проблемы обработки статических файлов и часто приводит к более быстрому загрузке веб-страниц (особенно при использовании CDN).

При использовании этих сервисов базовый рабочий процесс будет выглядеть примерно так же, как и выше, за исключением того, что вместо использования rsync для передачи статических файлов на сервер, вам нужно будет передать статические файлы в облачное хранилище или CDN.

Существует множество способов сделать это, но если у провайдера есть API, настройка бэкенда хранилища файлов сделает процесс невероятно простым. Если вы написали или используете сторонний пользовательский бэкенд хранения, вы можете сказать collectstatic использовать его, установив STATICFILES_STORAGE в движок хранения.

Например, если вы написали бэкенд хранения S3 в myproject.storage.S3Storage, вы могли бы использовать его следующим образом:

STATICFILES_STORAGE = 'myproject.storage.S3Storage'

После этого всё, что вам нужно сделать, это запустить collectstatic, и ваши статические файлы будут переданы через ваш пакет хранения в S3. Если вам потребуется впоследствии переключиться на другого провайдера хранения, это может быть так же просто, как изменить настройку STATICFILES_STORAGE.

Подробные сведения о том, как написать один из этих бэкэндов, см. в разделе Написание пользовательской системы хранения. Доступны сторонние приложения, предоставляющие бэкэнды хранения для многих распространённых API облачного хранения файлов. Хорошей отправной точкой является обзор на djangopackages.org.

Дополнительная информация

Для получения полных подробностей обо всех настройках, командах, тегах шаблонов и других элементах, включённых в django.contrib.staticfiles, см. справочник по staticfiles.