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

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

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

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

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

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

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

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

Ниже, и в следующих разделах, мы покажем несколько примеров fabfiles (т.е. скриптов 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.com.

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

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