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

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

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

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

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

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

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

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

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

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

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 является распространённым выбором для этой стадии, так как он передаёт только изменённые части статических файлов.

Вот как это может выглядеть в fabфайле:

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.com.

Узнайте больше

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