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

Обновлено: 22.11.2024

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

В этом руководстве мы рассмотрим, как настроить статические файлы для локальной разработки, а затем для рабочей среды.

Местное развитие

Один проект Django часто содержит несколько приложений. По умолчанию Django ищет в каждом приложении статический каталог, содержащий статические файлы. Итак, если одно из ваших приложений называется blog, и вы хотите добавить в него файл CSS с именем base.css, вам нужно сначала создать новый каталог с именем blog/static, а затем добавить в него файл, чтобы расположение было blog/ статический/стиль.css .

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

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

В новой статической папке создайте подпапки для каждого типа статического файла, например css , js и img . В командной строке их можно добавить с помощью команды mkdir:

Теперь вы можете добавить все свои статические объекты. Таким образом, файл base.css будет находиться в static/css/base.css. Если вы используете Git для управления версиями и у вас еще нет готовых статических файлов, рекомендуется добавить файл-заполнитель .gitkeep в каждый каталог, чтобы Git подхватил их.

Если в этот момент вы запустите локальный веб-сервер — python manage.py runserver — стиль будет недоступен! И это потому, что статические ресурсы должны быть явно загружены в шаблоны.

Загрузка статических файлов в шаблоны

Загрузка статических файлов в шаблон выполняется в два этапа:

добавить вверху шаблона
добавьте тег шаблона с соответствующей ссылкой

Предположим, вы используете файл base.html в своем проекте блога. Внесение обоих обновлений будет выглядеть следующим образом:

Если вы сохраните и перезагрузите веб-страницу, вы увидите изменения. Добавление ссылок для изображений в папку img или JavaScript в папку js будет выглядеть следующим образом:

собирать статические данные

Локальный сервер Django будет обслуживать статические файлы, а рабочий сервер, такой как Gunicorn или uWSGI, — нет. Поэтому Django поставляется со встроенной командой collectstatic, которая компилирует все статические файлы в один каталог, подходящий для развертывания в рабочей среде. Конфигурация STATIC_ROOT устанавливает абсолютное местоположение этих собранных файлов, обычно называемых staticfiles. Последняя часть — STATICFILES_STORAGE, представляющая собой систему хранения файлов, используемую при сборе статических файлов с помощью команды collectstatic. По умолчанию неявно установлено значение django.contrib.staticfiles.storage.StaticFilesStorage .

Конечным результатом является то, что для статических файлов требуется четыре конфигурации, а команду python manage.py collectstatic необходимо запускать каждый раз при изменении, чтобы перекомпилировать все статические ресурсы в один каталог.

Обновите файл settings.py следующим образом:

Затем выполните команду python manage.py collectstatic .

Будет создан новый каталог staticfiles с папками для администратора (у встроенного администратора есть собственные статические файлы), staticfiles.json и любыми каталогами в вашей статической папке.

Если вы сейчас добавите новый статический файл в static , он будет доступен для локального использования. Это только для производства, где файл не будет присутствовать, если вы не запускаете python manage.py collectstatic каждый раз. По этой причине запуск collectstatic обычно добавляется в конвейеры развертывания и выполняется по умолчанию в Heroku.

Вкратце:

STATIC_URL — это URL-адрес статических файлов, расположенных в STATIC_ROOT
STATICFILES_DIRS сообщает Django где искать статические файлы в проекте Django, например статическую папку верхнего уровня
STATIC_ROOT — это расположение папки статических файлов при запуске collectstatic
STATICFILES_STORAGE – это система хранения файлов, используемая при сборе статических файлов с помощью команды collectstatic.

Производство

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

Затем в файле settings.py внесите три изменения:

добавьте белый шум в INSTALLED_APPS над встроенным приложением staticfiles
в разделе MIDDLEWARE добавьте новое WhiteNoiseMiddleware в третьей строке
изменить STATICFILES_STORAGE на использование WhiteNoise .

Это должно выглядеть следующим образом:

Вот оно! Снова запустите python manage.py collectstatic, чтобы файлы сохранялись с помощью WhiteNoise. А затем с уверенностью выполните развертывание на платформе хостинга по вашему выбору.

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

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

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

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

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

Возможно, вы захотите автоматизировать этот процесс, особенно если у вас несколько веб-серверов.

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

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

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

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

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

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

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

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

Например, если вы написали серверную часть хранилища S3 в myproject.storage.S3Storage, вы можете использовать ее с:

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

django.contrib.staticfiles собирает статические файлы из каждого из ваших приложений (и любых других мест, которые вы укажете) в единое место, которое можно легко обслуживать в рабочей среде.

Введение в приложение для статических файлов и некоторые примеры использования см. в разделе Как управлять статическими файлами (например, изображениями, JavaScript, CSS) . Инструкции по развертыванию статических файлов см. в разделе Как развертывать статические файлы .

Настройки¶

Подробнее о следующих настройках см. в настройках статических файлов:

Команды управления¶

django.contrib.staticfiles предоставляет три команды управления.

собирать статический ¶

Собирает статические файлы в STATIC_ROOT .

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

При последующих запусках collectstatic (если STATIC_ROOT не пустой) файлы копируются только в том случае, если их измененная отметка времени больше, чем отметка времени файла в STATIC_ROOT . Поэтому, если вы удаляете приложение из INSTALLED_APPS , рекомендуется использовать параметр collectstatic --clear для удаления устаревших статических файлов.

Поиск файлов осуществляется с помощью включенных средств поиска . По умолчанию выполняется поиск во всех местах, определенных в STATICFILES_DIRS, и в «статическом» каталоге приложений, указанном параметром INSTALLED_APPS.

Команда управления collectstatic вызывает метод post_process() хранилища STATICFILES_STORAGE после каждого запуска и передает список путей, найденных командой управления. Он также получает все параметры командной строки collectstatic . По умолчанию используется ManifestStaticFilesStorage.

По умолчанию собранные файлы получают разрешения от FILE_UPLOAD_PERMISSIONS, а собранные каталоги получают разрешения от FILE_UPLOAD_DIRECTORY_PERMISSIONS. Если вам нужны разные разрешения для этих файлов и/или каталогов, вы можете создать подкласс любого из классов хранения статических файлов и указать параметры file_permissions_mode и/или directory_permissions_mode соответственно. Например:

Затем установите для параметра STATICFILES_STORAGE значение 'path.to.MyStaticFilesStorage' .

НЕ запрашивайте у пользователя ввод любого рода.

--игнорировать ШАБЛОН , -i ШАБЛОН ¶

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

Делайте все, кроме изменения файловой системы.

Удалите существующие файлы, прежде чем пытаться скопировать исходный файл или создать ссылку на него.

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

Не вызывайте метод post_process() настроенной серверной части хранилища STATICFILES_STORAGE.

Не игнорируйте распространенные частные шаблоны в стиле глобусов 'CVS' , '.*' и '*~' .

Для получения полного списка параметров обратитесь к собственной справке команд, выполнив:

Настройка списка игнорируемых шаблонов¶

Список игнорируемых шаблонов по умолчанию, ['CVS', '.*', '*~'] , можно настроить более постоянным образом, чем предоставление параметра --ignore команды при каждом вызове collectstatic. Укажите собственный класс AppConfig, переопределите атрибут ignore_patterns этого класса и замените 'django.contrib.staticfiles' на путь к этому классу в настройках INSTALLED_APPS:

findstatic ¶

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

По умолчанию будут найдены все совпадающие местоположения. Чтобы вернуть только первое совпадение для каждого относительного пути, используйте параметр --first:

Это средство отладки; он покажет вам, какой именно статический файл будет собран для данного пути.

Установив для флага --verbosity значение 0, вы можете подавить дополнительный вывод и получить только пути:

С другой стороны, установив для флага --verbosity значение 2, вы можете получить все каталоги, в которых производился поиск:

сервер запуска ¶

Переопределяет основную команду runserver, если установлено приложение staticfiles, и добавляет автоматическое обслуживание статических файлов. Обработка файлов не выполняется через СРЕДНЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ .

Команда добавляет следующие параметры:

Используйте параметр --nostatic, чтобы полностью отключить показ статических файлов с помощью приложения staticfiles. Этот параметр доступен только в том случае, если приложение staticfiles находится в настройках вашего проекта INSTALLED_APPS.

Используйте параметр --insecure, чтобы принудительно обслуживать статические файлы с помощью приложения staticfiles, даже если параметр DEBUG имеет значение False . Используя это, вы признаете тот факт, что это крайне неэффективно и, вероятно, небезопасно. Это предназначено только для локальной разработки, никогда не должно использоваться в рабочей среде и доступно только в том случае, если приложение staticfiles находится в настройках вашего проекта INSTALLED_APPS.

Хранилища¶

Статикфилесстораже ¶

Подкласс серверной части хранилища FileSystemStorage, использующий параметр STATIC_ROOT в качестве базового местоположения в файловой системе и параметр STATIC_URL соответственно в качестве базового URL-адреса.

хранилище.StaticFilesStorage. post_process (пути, **параметры)¶

Если этот метод определен для хранилища, он вызывается командой управления collectstatic после каждого запуска и получает локальные хранилища и пути к найденным файлам в виде словаря, а также параметры командной строки. Он выдает кортежи из трех значений: original_path, обрабатываемый_путь, обрабатываемый. Значения пути — это строки, а обработано — логическое значение, указывающее, было ли значение подвергнуто постобработке, или исключение, если постобработка не удалась.

ManifestStaticFilesStorage использует это за кулисами, чтобы заменить пути их хешированными аналогами и соответствующим образом обновить кеш.

Хранилище манифестаStaticFilesStorage ¶

Подкласс серверной части хранилища StaticFilesStorage, который сохраняет имена файлов, которые он обрабатывает, добавляя хэш MD5 содержимого файла к имени файла. Например, файл css/styles.css также будет сохранен как css/styles.55e7cbb9ba48.css .

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

Бэкэнд хранилища автоматически заменяет пути, найденные в сохраненных файлах, совпадающие с другими сохраненными файлами, на путь кэшированной копии (с помощью метода post_process()). Регулярные выражения, используемые для поиска этих путей ( django.contrib.staticfiles.storage.HashedFilesMixin.patterns ), охватывают:

Правило @import и оператор url() для каскадных таблиц стилей.
Комментарий исходной карты в JavaScript.

Например, файл css/styles.css со следующим содержимым:

… будет заменен вызовом метода url() серверной части хранилища ManifestStaticFilesStorage, что в конечном итоге сохранит файл css/styles.55e7cbb9ba48.css со следующим содержимым:

Вы можете изменить расположение файла манифеста, используя собственный подкласс ManifestStaticFilesStorage, который задает аргумент manifest_storage. Например:

Добавлена поддержка поиска путей в комментариях исходной карты.

Добавлен аргумент manifest_storage.

Поскольку статические файлы могут ссылаться на другие статические файлы, пути которых необходимо заменить, может потребоваться несколько проходов замены путей, пока хэши файлов не сойдутся. Чтобы предотвратить бесконечный цикл из-за того, что хэши не сходятся (например, если «foo.css» ссылается на «bar.css», который ссылается на «foo.css»), существует максимальное количество проходов, прежде чем постобработка будет прекращена. В случаях с большим количеством ссылок может потребоваться большее количество проходов. Увеличьте максимальное количество проходов, создав подкласс ManifestStaticFilesStorage и задав атрибут max_post_process_passes. По умолчанию 5.

Чтобы включить ManifestStaticFilesStorage, необходимо убедиться, что выполнены следующие требования:

для параметра STATICFILES_STORAGE установлено значение 'django.contrib.staticfiles.storage.ManifestStaticFilesStorage'
для параметра DEBUG установлено значение False
вы собрали все свои статические файлы с помощью команды управления collectstatic

Поскольку создание хэша MD5 может снизить производительность вашего веб-сайта во время выполнения, staticfiles автоматически сохраняет сопоставление с хешированными именами для всех обработанных файлов в файле с именем staticfiles.json . Это происходит один раз, когда вы запускаете команду управления collectstatic.

Если файл не найден в манифесте staticfiles.json во время выполнения, возникает ошибка ValueError. Это поведение можно отключить, создав подкласс ManifestStaticFilesStorage и установив для атрибута manifest_strict значение False — несуществующие пути останутся без изменений.

Из-за необходимости запуска collectstatic это хранилище обычно не следует использовать при выполнении тестов, так как collectstatic не запускается как часть обычной настройки тестирования. Во время тестирования убедитесь, что для параметра STATICFILES_STORAGE установлено другое значение, например «django.contrib.staticfiles.storage.StaticFilesStorage» (по умолчанию).

storage.ManifestStaticFilesStorage. file_hash (name, content=None)¶

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

Смешивание файлов манифеста ¶

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

Добавлен аргумент manifest_storage.

Модуль поиска¶

У средств поиска staticfiles есть атрибут searched_locations, который представляет собой список путей к каталогам, в которых выполнялся поиск. Пример использования:

Другие помощники¶

Вне приложения staticfiles есть несколько других помощников для работы со статическими файлами:

Контекстный процессор django.template.context_processors.static(), который добавляет STATIC_URL к каждому контексту шаблона, отображаемому с помощью контекстов RequestContext.
Встроенный тег шаблона static, который принимает путь и объединяет его с префиксом static STATIC_URL . Если установлен django.contrib.staticfiles, вместо этого тег использует метод url() из STATICFILES_STORAGE.
Встроенный тег шаблона get_static_prefix, который заполняет переменную шаблона статическим префиксом STATIC_URL для использования в качестве переменной или напрямую.
Похожий тег шаблона get_media_prefix, который работает как get_static_prefix, но использует MEDIA_URL .

Представление разработки статического файла¶

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

Эта функция просмотра обслуживает статические файлы в процессе разработки.

Это представление будет работать, только если DEBUG имеет значение True .

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

Чтобы угадать типы содержимого обслуживаемых файлов, это представление опирается на модуль mimetypes из стандартной библиотеки Python, который, в свою очередь, опирается на файлы сопоставления базовой платформы. Если вы обнаружите, что это представление не возвращает правильные типы содержимого для определенных файлов, скорее всего, файлы карты платформы неверны или нуждаются в обновлении. Этого можно добиться, например, установив или обновив пакет mailcap в дистрибутиве Red Hat, поддержку mime в дистрибутиве Debian или изменив ключи в разделе HKEY_CLASSES_ROOT в реестре Windows.

Это представление автоматически включается сервером выполнения (если для параметра DEBUG установлено значение True ). Чтобы использовать представление с другим локальным сервером разработки, добавьте следующий фрагмент в конец конфигурации основного URL:

Обратите внимание, что начало шаблона ( r'^static/' ) должно быть вашей настройкой STATIC_URL.

Поскольку это немного сложно, есть также вспомогательная функция, которая сделает это за вас:

Это вернет правильный шаблон URL для обслуживания статических файлов в уже определенный список шаблонов. Используйте это так:

Это проверит ваш параметр STATIC_URL и соответствующим образом подключит представление для обслуживания статических файлов. Не забудьте правильно установить параметр STATICFILES_DIRS, чтобы django.contrib.staticfiles знал, где искать файлы помимо файлов в каталогах приложений.

Веб-сайтам обычно требуются дополнительные файлы, такие как изображения, файлы CSS и JavaScript, которые необходимы для полного отображения веб-страниц в браузере. В небольших проектах мы можем обойти это, предоставив абсолютные пути к нашим ресурсам или написав встроенные функции CSS и JavaScript в файлах HTML. Это не только противоречит лучшим практикам написания кода, но и становится затруднительным, когда мы работаем с большими проектами, особенно с несколькими приложениями.

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

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

Настройка статических файлов

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

Django предоставляет файлы django.contrib.staticfiles, которые помогут вам собирать статические файлы из каждого из ваших приложений (и любых других мест, которые вы укажете) в единое место, которое можно легко обслуживать в рабочей среде.

В вашем файле settings.py ваши INSTALLED_APPS должны выглядеть следующим образом:

STATIC_ROOT — это путь, определяющий, где будут собираться ваши статические файлы. Мы укажем абсолютный путь к STATIC_ROOT в settings.py .

Для этого мы воспользуемся функцией dirname() модуля os, чтобы получить имя каталога, в котором мы хотим разместить эти файлы, и определить путь:

Django имеет список средств поиска STATICFILES_FINDERS, которые он использует для поиска статических файлов. Одним из средств поиска по умолчанию является AppDirectoriesFinder, который ищет папку с именем static в каждом из ваших INSTALLED_APPS.

Например, если ваш проект содержит приложение с именем users , вы можете создать каталог, например имя_проекта/users/static/index.css, для добавления файлов CSS, связанных с этим приложением.

Несмотря на то, что это работает, лучше создать еще один подкаталог с именем вашего приложения, например, имя_проекта/users/static/users/index.css . Это важно, когда у нас есть два или более статических файла с похожими именами.

Предположим, что в каждом приложении есть файл index.css, содержащий разные стили CSS. Django будет искать первый index.css, который сможет найти в каталогах app/static/.Он не сможет различать различные index.css, которые есть в каждом статическом каталоге приложения. Вот почему мы создали подкаталог с именем приложения app/static/app/ .

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

Чтобы использовать общее место для всех статических файлов в каталоге вашего проекта, нам нужно настроить STATICFILES_DIRS для информирования Django о нашем новом каталоге, поскольку AppDirectoriesFinder будет искать статические файлы только в каталогах приложений. Мы также можем определить несколько местоположений для наших статических файлов.

Здесь можно определить статические папки отдельного проекта, если у вас их несколько:

Обратите внимание, что STATICFILES_DIRS будет работать, только если вы не удалите FileSystemFinder из STATICFILES_FINDERS.

Вкратце, наш файл settings.py включает в себя:

Статические файлы готовы к использованию в вашем проекте. Нам просто нужно загрузить тег статического шаблона, а затем использовать тег статического шаблона для создания URL-адреса для заданного относительного пути. Давайте посмотрим, как мы можем использовать статические файлы в нашем файле шаблона base.html:

Бесплатная электронная книга: Git Essentials

Ознакомьтесь с нашим практическим руководством по изучению Git, включающим передовые практики, общепринятые стандарты и памятку. Перестаньте гуглить команды Git и на самом деле изучите их!

В base.html включен шаблон head.html для правильного разделения, поскольку более крупные проекты обычно содержат длинный код в тегах head. Класс mainbtn для h1 определен в файле static/index.css. Фоновое изображение bg.jpg также присутствует в статическом каталоге.

head.html выглядит следующим образом:

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

Помимо указанных выше конфигураций, нам также необходимо фактически обслуживать статические файлы. Это автоматически выполняется командой runserver Django, если Debug = True. Вы должны использовать этот метод на этапе разработки, так как он прост, однако не рекомендуется для производства, поскольку он неэффективен и небезопасен.

Django поставляется со встроенной командой collecstatic . Он компилирует все статические файлы в один каталог STATIC_ROOT, который мы уже установили. Последняя часть — это механизм хранения, используемый при сборе статических файлов с помощью команды collectstatic. Механизм хранения можно настроить с помощью STATICFILES_STORAGE . У Django есть собственный механизм хранения, поэтому значение STATICFILES_STORAGE по умолчанию равно django.contrib.staticfiles.storage.StaticFilesStorage .

Статические файлы в производстве

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

Запускайте команду collectstatic всякий раз, когда изменяются статические файлы.
Организовать перемещение STATIC_ROOT на статический файловый сервер и его обслуживание

Метод post_process() класса Storage может позаботиться о втором шаге, но это действительно зависит от вашего механизма хранения, то есть STATICFILES_STORAGE .

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

Обслуживать статические файлы и сайт с одного сервера. Используйте этот метод, если вы хотите, чтобы ваши статические файлы обслуживались с сервера, на котором уже запущено ваше веб-приложение. Несмотря на потенциальную проблему с производительностью, это может быть экономически выгодно, поскольку вам нужно платить только за хостинг одного сервера. Для этого отправьте свой код на сервер развертывания, затем запустите collectstatic, чтобы скопировать все файлы в STATIC_ROOT. Наконец, настройте свой веб-сервер для обслуживания статических файлов по адресу STATIC_URL .

Обслуживание статических файлов с выделенного сервера. Наиболее распространенными вариантами выделенных серверов статических файлов являются nginx и урезанная версия Apache. Веб-приложение работает на совершенно другом сервере, а ваши статические файлы развертываются на выделенном сервере, что в целом обеспечивает более высокую производительность. Запускайте collectstatic локально всякий раз, когда изменяются статические файлы, затем поместите STATIC_ROOT в каталог вашего выделенного сервера, который обслуживается. Подробные инструкции см. в документации соответствующего сервера.

Обслуживание статических файлов из облачной службы. Еще одна распространенная тактика – предоставление статических файлов поставщиками облачных хранилищ, такими как Amazon, Microsoft Azure и Alibaba Cloud.

Давайте посмотрим, как мы можем использовать Amazon S3 для этой цели. Сначала установите две библиотеки Python с помощью следующих команд:

Библиотека boto3 — это общедоступный клиент API для доступа к Amazon S3 и другим веб-сервисам Amazon (AWS).Django-storages управляет серверными частями хранилища, такими как Amazon S3, OneDrive и т. д. Он подключается к встроенному API серверной части хранилища Django. Вам также нужно будет добавить хранилища в INSTALLED_APPS. Наш INSTALLED_APPS сейчас выглядит так:

После этого добавьте в файл settings.py следующие конфигурации:

Наконец, запустите python manage.py collectstatic, и вы закончите настройку Amazon S3 для ваших статических файлов.

Обслуживание статических файлов с помощью WhiteNoise

Люди часто не используют сторонние облачные сервисы, такие как Amazon S3, по нескольким причинам, включая платные подписки. WhiteNoise позволяет вашему проекту Django обслуживать свои собственные статические файлы, что делает его автономным модулем, который мы можем развернуть в любом месте, не завися от поставщиков услуг.

Хотя он работает с любым WSGI-совместимым веб-приложением, его проще всего настроить с помощью проекта Django.

Конфигурация для WhiteNoise

Давайте установим WhiteNoise с помощью:

В файле settings.py добавьте WhiteNoise в список ПРОМЕЖУТОЧНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ в следующем порядке:

Запустите python manage.py collectstatic .

Вот оно! Теперь вы можете развернуть свое веб-приложение на любой платформе хостинга, такой как Heroku.

Заключение

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

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

Читайте также: