Рубрики
Без рубрики

Понять Джанго: Обслуживание статических файлов

В предыдущем понять статью Django, я описал, как Django дает нам инструменты для запуска кода для любых … Теги с Python, Django, Static.

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

Какие статические файлы?

Статические файлы – это файлы, которые не изменяются при запуске вашего приложения.

Эти файлы много делают для улучшения вашего приложения, но они не генерируются динамически вашим веб-сервером Python. В типичном веб-приложении ваши наиболее распространенные статические файлы будут следующими типами:

  • Каскадные листы стиля, CSS
  • JavaScript
  • Картинки

Имейте в виду, что, хотя Django будет служить этим файлам статически, на месте для создания файлов может быть сложный процесс. Например, современные приложения JavaScript часто имеют сложные процессы, использующие инструменты сборки JavaScript, такие как WebPack Чтобы построить окончательные файлы JavaScript, которые обслуживаются пользователям.

Статические файлы имеют решающее значение для вашего проекта Django, потому что современная веб-сайт требует больше, чем динамически сгенерированная разметка HTML. Вы посещаете любой веб-сайт, который имеет Ноль Стайлинг его HTML? Эти виды сайтов существуют и могут быть удивительными для быстрого инструмента, но большинство пользователей ожидают, что веб-сайты будут эстетически приятными. Для нас это означает, что мы должны быть готовы включить некоторые стайлинг CSS как минимум.

Давайте посмотрим на некоторую конфигурацию, чтобы увидеть, где статические файлы живут в вашем проекте, затем начните работать с некоторыми примерами.

Конфигурация

Чтобы использовать статические файлы в вашем проекте, вам нужно django.contrib.staticfiles Приложение в вашем проекте Stall_apps список. Это еще одно из приложений Django Deamango по умолчанию, которое Django будет включать, если вы начнете с startproject команда.

StaticFiles Приложение имеет горстку Настройки Что нам нужно рассмотреть, чтобы начать.

Я собираюсь сделать ту же рекомендацию о статических файлах, так как я делал с шаблонами. Я рекомендую вам создать статический Каталог в корне вашего проекта для удержания ваших статических файлов. Точно так же шаблоны, StaticFiles Приложение будет искать статический Справочники в каждом из ваших приложений Django для поиска файлов, но мне проще работать и располагают статическими файлами, если они все в одном каталоге.

Чтобы установить эту настройку работать, используйте StaticFiles_Dirs параметр. Этот параметр рассказывает Django любые дополнительные места для статических файлов, кроме поиска статический каталог в каждом приложении.

# project/settings.py

...

STATICFILES_DIRS = [os.path.join(BASE_DIR, "static")]

Далее мы можем определить префикс Path URL, который Django будет использовать, когда он обслуживает статический файл. Давайте скажем, у вас есть Site.csss В корне вашего проекта статический каталог. Вы, вероятно, не хотите, чтобы файл был доступен как mysite.com/site.css Отказ Для этого будет означать, что статические файлы могут конфликт с пути URL, которые ваше приложение может потребоваться направить на вид. Static_url Настройка позволяет нам пространство пространства наших статических файлов и, как Дзэн Питона говорит:

Пространства имен – это одна отчетная идея – давайте сделаем больше тех!

# project/settings.py

...

STATICFILES_DIRS = [os.path.join(BASE_DIR, "static")]
STATIC_URL = '/static/'

С Static_url Набор, мы можем получить доступ к Site.csss от mysite.com/static/site.css .

Есть еще одна важная обстановка, которую нам нужно установить, и это называется Static_root Отказ Когда мы развертываем наш проект Django, Django хочет найти все статические файлы из одного каталога. Причина этого предназначена для эффективности. Django можно найти через все приложение статический Справочники и любые каталоги набора в StaticFiles_dirs. Всякий раз, когда он ищет файл для обслуживания, но это было бы медленно.

Вместо этого Django поставит все статические файлы в один каталог, чтобы поиск файла – это поиск через одно файловое дерево. Мы посмотрим на то, как это происходит в разделе развертывания позже в этой статье.

Как только мы установим Static_root Django будет иметь желаемое местоположение для статических файлов. Если вы установите путь где-то в своем репозитории, не забудьте поставить этот путь в свой .gitignore. Если вы используете контроль версий с Гит (И я настоятельно рекомендую вам сделать!). Я служил мой Static_root к StaticFiles. каталог.

# project/settings.py

...

STATICFILES_DIRS = [os.path.join(BASE_DIR, "static")]
STATIC_ROOT = os.path.join(BASE_DIR, "staticfiles")
STATIC_URL = '/static/'

Теперь, когда мы знаем, как настроить статические файлы, мы готовы посмотреть, как использовать их в нашем коде Django.

Работа со статическими файлами

Основной способ работы со статическими файлами – это тег шаблона. статический Тег шаблона поможет сделать правильный URL для статического файла для вашего сайта.

Вот пример шаблона для рассмотрения:

{% load static %}




  


  
Example of static template tag!

В этом примере я предполагаю, что есть CSS. каталог в моем статический каталог с Site.csss файл внутри. Django сделает этот шаблон тег как /static/css/site.css в самом базовом формате. Мы также должны отметить, что мне нужно было включить {% Загрузить статические%} Чтобы гарантировать, что статический Тег шаблона был доступен.

На практике я считаю, что это нагрузка Требование кусает меня все время. К счастью, TemplateSyntaxError что Django будет поднять, обеспечивает хорошее представление о том, как исправить эту проблему. Исключение говорит: «Вы забыли зарегистрироваться или загрузить этот тег? «Насколько полезно разработчикам Django, чтобы сказать нам, что мы, вероятно, не хватаем!

Так как мы знаем, что Static_url это /статический/ из раздела конфигурации, почему бы я не заканчиваю путь тега ссылки в /static/css/site.css ? Вы могли бы, и это может работать, но вы, вероятно, столкнулись с некоторыми долгосрочными проблемами.

  • Что, если вы когда-нибудь хотели изменить Static_url ? Может быть, вы хотите изменить его на что-то короче /S/ . Если вы жесткокодируете имя, теперь у вас есть более одного места для изменения.
  • Используя некоторые дополнительные функции, Django может изменить имя файла на что-то уникальное, добавив хеш к имени файла. С хардкодированным путем /static/css/site.css. , это может привести к реакции 404, если Django ожидает уникального имени вместо этого. Посмотрим, что уникальное имя предназначено для следующего раздела.

Мы должны помнить, чтобы использовать статический тег так же, как мы используем URL Тег, когда мы хотим разрешить путь URL Django. Обе эти теги помогают избежать твердых путей кодирования, которые могут измениться.

Менее обычно, мы можем обратиться к статическому файлу из кода Python. Вы можете сделать это, позвонив статический Функция определена в том же месте, что и статический Функция метки шаблона, но функция не расположена, где вы можете ожидать ее. Вместо того чтобы импортировать из StaticFiles Приложение Django определяет эти функции в django.templatetags.Static Отказ

Например, если вы хотите обслуживать представление JSON, который подает клиентское приложение JavaScript путь к файлу CSS, вы можете написать:

# application/views.py

from django.http import JsonResponse
from django.templatetags.static import static

def get_css(request):
    return JsonResponse({'css': static('css/site.css')})

В моем годах опыта в качестве разработчика Django я видел только статический используется в представлениях несколько раз. статический наверняка более широко используется в шаблонах.

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

Соображения развертывания

В разделе конфигурации мы видели Static_root вариант. Этот параметр будет собирать все статические файлы в один каталог, но Когда Это делает это? И как работают статические файлы, когда работаем в режиме разработки и у вас нет всех файлов в Static_root. место расположения?

При развертывании вашего приложения на сервер один важный параметр для отключения является Отладка параметр. Если Отладка включен, все виды секретных данных могут утечка от вашего приложения, поэтому разработчики Django ожидать Отладка быть Ложь для вашего живого сайта. Из-за этого ожидания определенные части Джанго ведут себя по-разному, когда Отладка Изменения и StaticFiles. Приложение это одна такая часть.

Когда Отладка это Правда и вы используете Runserver Команда для запуска веб-сервера Development, Django будет искать файлы с помощью набора «Finders» всякий раз, когда пользователь запрашивает статический файл. Эти искатели определяются StaticFiles_finders Настройка, какая по умолчанию:

[
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]

Как вы могли догадаться, FileSystemfinder Ищете какие-либо статические файлы, найденные в каталоге файловой системы, который мы перечислили в StaticFiles_Dirs Отказ Appdirectoriesfinder ищет статические файлы в статический Справочник каждого приложения Django, которое у вас есть. Вы можете увидеть, как это медленно, когда вы понимаете, что Django будет проходить через Лен (StaticFiles_dirs) + len (установленные_apps)

Чтобы сделать весь этот процесс быстрее, мы включаем Отладка к Ложь . Когда Отладка это Ложь , все медленные механизмы, которые ищут файлы на протяжении всего вашего проекта для статических файлов, выключены. Джанго выглядит только в Static_root каталог для файлов.

Так как искатели выключены, когда Отладка это Правда мы должны убедиться, что Static_root заполнен всеми правильными файлами. Чтобы поставить все статические файлы на место, вы можете использовать коллекционирование команда.

коллекционирование Скопируйте все файлы, которые он обнаруживает итерацию через каждый поиск и собирал файлы из каких списков поиска. В моем примере ниже мой каталог проекта Django является MyProject и я настроил Static_root к StaticFiles Отказ

$ ./manage.py collectstatic

42 static files copied to '/Users/matt/myproject/staticfiles'.

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

Можем ли мы сделать это лучше? Вы делаете ставку!

Оптимизация производительности в Django

StaticFiles Есть еще одна обстановка, которую стоит рассмотреть. Я не упомянул об этом в разделе конфигурации, потому что это не критическая настройка, чтобы сделать статические файлы работать, но мы готовы к настройке, как мы думаем о оптимизации.

Последние настройки, которые мы рассмотрим, это StaticFiles_Storage параметр. Этот параметр контролирует, как статические файлы хранятся и доступны Django. Мы можем захотеть изменить StaticFiles_Storage повысить эффективность применения. Самое большое повышение, которое мы можем получить от этой настройки, обеспечит кэширование файлов.

В идеальном мире ваше приложение будет иметь только для того, чтобы обслуживать статический файл именно один Время в браузере пользователя. В этом сценарии, если приложение необходимо снова использовать файл, то браузер повторно использует кэшированный Файл, который он уже получен. Вызов, который у нас есть, это то, что статические файлы (по иронии судьбы?) изменение с течением времени.

Скажите, например, вы изменили Site.csss изменить стиль приложения. Вы не захотите браузер повторно использовать старую версию, потому что не хватает последних и самых больших изменений, которые вы сделали. Как мы получаем выгоду от того, чтобы сообщить браузеру кэшировать файл в течение длительного времени, чтобы быть максимально эффективным, пока все еще имея гибкость для внесения изменений и заставить браузер пользователя получать новую версию файла?

«Хитрость» – служить «отпечатку пальцев» версии файла. В рамках процесса развертывания мы хотели бы однозначно идентифицировать каждый файл с какой-то информацией о версии. Простой способ для компьютера сделать это – принять содержимое файла и рассчитать хеш-значение. Мы можем иметь код взять Site.csss Рассчитайте хеш и генерируйте файл с тем же содержимым, но с другим именем файла сайт.abcd1234.css. Если ABCD1234 Был генерируемая хеш-ценность.

Следующая часть процесса заключается в том, чтобы сделать шаблон рендеринга использовать site.abcd1234.css название. Помните, как мы использовали статический Шаблон тег вместо жесткообразных /static/css/site.css ? Этот пример – это отличная причина, по которой мы это сделали. Используя статический Тег, django может сделать имя файла, которое включает в себя хеш вместо того, чтобы использовать только Site.csss Отказ

Последний бит, который приносит эту схему вместе, – это рассказать браузеру кэш Cache site.abcd1234.css В течение очень длительного времени, отправив определенный заголовок кэширования в ответ HTTP.

Теперь мы получили лучшее из обоих миров.

  • Если пользователь извлекивает сайт.abcd1234.css. Их браузер будет держать его в течение длительного времени и никогда не нужно загружать его снова. Это может повторно использовать каждый раз, когда пользователь посещает страницу в вашем приложении.
  • Если мы когда-нибудь изменим Site.csss Затем процесс развертывания может генерировать новый файл, такой как site.ef567890.css Отказ Когда пользователь делает запрос, HTML будет включать в себя новую версию, их браузер не будет его в кэше, а браузер загрузит новую версию с вашими новыми изменениями.

Здорово! Как мы получим это и сколько работы это потребует? Ответ возвращается к StaticFiles_Storage Настройка и инструмент под названием Whitenoise (возьми!? «Белый шум» это «Статический». Хар Хар).

Whitenoise – довольно удивительная часть программного обеспечения. Библиотека будет справиться с этим Весь Схема кэширования, которую я описал выше.

Чтобы настроить Whitenoise, вы устанавливаете его с помощью PIP Установить Whitenoise Отказ Тогда вам нужно изменить свой Промежуточное программное обеспечение Список и StaticFiles_Storage настройки.

# project/settings.py

...

MIDDLEWARE = [
  'django.middleware.security.SecurityMiddleware',
  'whitenoise.middleware.WhiteNoiseMiddleware',
  # ...
]

STATICFILES_STORAGE = \
    'whitenoise.storage.CompressedManifestStaticFilesStorage'

Вот об этом! С этой настройкой Whitenoise сделает кучу работы во время коллекционирование команда. Библиотека будет генерировать отдельные файлы, такие как site.abcd1234.css , и он будет генерировать сжатые версии этих файлов, используя алгоритм сжатия GZIP (и, необязательно, алгоритм сжатия бротлей). Thoese дополнительные файлы выглядят как site.abcd1234.css.gz или site.abcd1234.css.br .

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

Как браузер пользователя делает запрос на отпечаток пальцев, браузер может включать в себя заголовок запроса, чтобы указать, какие сжатые форматы могут обрабатывать. Отправка сжатых файлов – путь быстрее, чем отправлять несжатые файлы через сеть. Whitenoise будет прочитать соответствующего заголовка и попытаться ответить на версию GZIP или Brotli.

Схема, которую я описал, является не единственным способом обработки статических файлов. На самом деле, есть несколько компромиссов, чтобы подумать:

  1. Здание с Whitenoise означает, что нам нужно только развернуть одно приложение, и пусть Python обрабатывает всю обработку. 2. Python, для всех его преимуществ, не самый быстрый язык программирования. Выход из Python для обслуживания ваших статических запросов будет работать медленнее, чем некоторые другие методы. Кроме того, процессы вашего веб-сервера должны проводить время, обслуживание статических файлов, а не полностью посвященных динамическим запросам.

Оптимизация производительности с обратным прокси

Альтернативный подход к использованию Django для обслуживания статических файлов – использовать другую программу в качестве Обратный прокси Отказ Эта настройка сложнее, но она может предложить лучшую производительность, если вам это нужно. Обратный прокси – это программное обеспечение, которое находится между вашими пользователями и сервером приложений Django. CloudFlare имеет хорошая статья Если вы хотите понять, почему «обратное» находится на имя.

Если вы настроите обратный прокси, вы можете попросить его обрабатывать много вещей, включая пути URL, приходящие к домену вашего сайта. Это где Static_root и коллекционирование полезны за пределами Джанго. Вы можете установить обратный прокси для обслуживания всех файлов, которые Django собирает Static_root Отказ

Процесс примерно:

  1. Беги коллекционирование Чтобы поставить файлы в Static_root Отказ 2 Настройте обратный прокси, чтобы обрабатывать любой узор URL, который начинается с Static_url (вспомнить /статический/ в качестве примера) и передайте эти запросы к структуре каталога Static_root Отказ 3. Все, что не похоже на статический файл (например, /учетные записи/логин/ ), делегирован на сервер приложений работает Django.

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

Если этот вид установки обращается к вам, один такой обратный прокси, который вы можете рассмотреть, это Nginx Отказ Конфигурация Nginx находится за пределами объема этой серии, но есть много солидных учебных пособий, которые покажут, как настроить приложение Django с Nginx.

Резюме

В этой статье мы покрыты статическими файлами.

Мы посмотрели на:

  • Как настроить статические файлы
  • Способ работы со статическими файлами
  • Как обрабатывать статические файлы при развертывании вашего сайта в Интернет

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

  • Почему кто-нибудь хочет написать автоматизированные тесты
  • Какие тесты полезны для приложения Django
  • Какие инструменты вы можете использовать, чтобы сделать тестирование Полегче

Если вы хотите следовать с серией, пожалуйста, не стесняйтесь подписаться на мою рассылку, где я объявляю весь мой новый контент. Если у вас есть другие вопросы, вы можете связаться со мной онлайн в Twitter, где я @mblayman Отказ

Оригинал: “https://dev.to/mblayman/understand-django-serving-static-files-37if”

Читайте ещё по теме: