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

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

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

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

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

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

• Загрузите свой код на сервер развёртывания.
• На сервере запустите collectstatic, чтобы скопировать все статические файлы в STATIC_ROOT.
• Настройте веб-сервер на обработку файлов из STATIC_ROOT по URL 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 на модуль хранения.

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

STATICFILES_STORAGE = 'myproject.storage.S3Storage'

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

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

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

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