TOC

Как настроить масштабируемое приложение Django с базами данных и пространствами, управляемыми DigitalOcean

Вступление

Django - это мощная веб-инфраструктура, которая может помочь вам быстро запустить приложение или веб-сайт Python. Он включает в себя несколько удобных функций, таких как object-relational mapper, API-интерфейс Python и настраиваемый административный интерфейс для вашего приложения. Он также включает в себя caching framework и поощряет чистый дизайн приложения через его https://docs.djangoproject.com/en/2.1/topics/http. / urls / [URL Dispatcher] и Template system.

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

В этом руководстве мы расширим эту настройку, выгружая статические файлы, такие как таблицы стилей Javascript и CSS, в пространство DigitalOcean и, при необходимости, доставляя их, используя C ontent D elivery N etwork или CDN, который хранит эти файлы ближе к конечным пользователям, чтобы сократить время передачи. Мы также будем использовать DigitalOcean Managed PostgreSQL database в качестве нашего хранилища данных, чтобы упростить уровень данных и избежать необходимости настраивать масштабируемую базу данных PostgreSQL вручную.

Предпосылки

Перед тем, как вы начнете с этим руководством, у вас должно быть следующее:

  • Свежий экземпляр сервера Ubuntu 18.04 с базовым брандмауэром и пользователем без полномочий root с настроенными привилегиями + sudo +. Вы можете узнать, как настроить это, запустив Initial Server Setup с Ubuntu 18.04.

  • Управляемый DigitalOcean кластер PostgreSQL. Чтобы узнать, как создать кластер, обратитесь к документации по DigitalOcean Managed Databases.

  • Пространство DigitalOcean для хранения статических файлов проекта Django и набора ключей доступа для этого пространства. Чтобы узнать, как создать пространство, обратитесь к документации по продукту How to Create Spaces и узнайте, как создавать ключи доступа для пространств, обратитесь к Sharing Access to Spaces с ключами доступа.

  • Nginx установлен, защищен и настроен на вашем сервере для работы с выбранным вами доменным именем. Для получения дополнительной информации о настройке записей A и защите вашей установки Nginx с помощью Let’s Encrypt см. Https://www.digitalocean.com/community/tutorials/how-to-secure-nginx. -with-let-s-encrypt-on-ubuntu-18-04 [Как защитить Nginx с помощью Let’s Encrypt в Ubuntu 18.04].

Шаг 1 - Установка пакетов из репозитория Ubuntu

Для начала мы загрузим и установим все нужные нам элементы из репозиториев Ubuntu. Мы будем использовать менеджер пакетов Python + pip +, чтобы установить дополнительные компоненты чуть позже.

Нам нужно сначала обновить локальный индекс пакетов + apt +, а затем загрузить и установить пакеты.

В этом руководстве мы будем использовать Django с * Python 3 *. Чтобы установить необходимые библиотеки, войдите на свой сервер и введите:

sudo apt update
sudo apt install python3-pip python3-dev libpq-dev curl postgresql-client

Это установит + pip +, файлы разработки Python, необходимые для сборки Gunicorn, заголовочные файлы libpq, необходимые для сборки http://initd.org/psycopg/ [+ Pyscopg +] PostgreSQL Python-адаптера, и команду PostgreSQL- линия клиента.

Нажмите + Y +, а затем + ENTER +, когда будет предложено начать загрузку и установку пакетов.

Далее мы настроим базу данных для работы с нашим приложением Django.

Шаг 2 - Создание базы данных PostgreSQL и пользователя

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

Чтобы начать, возьмите * Параметры соединения * для своего кластера, перейдя к * Базы данных * на Cloud Control Panel и щелкнув по своей базе данных. Вы должны увидеть окно * Сведения о соединении *, содержащее некоторые параметры для вашего кластера. Запишите это вниз.

Вернитесь в командную строку, войдите в свой кластер, используя эти учетные данные и клиент + psql + PostgreSQL, который мы только что установили:

psql -U  -h  -p  -d  -set=sslmode=require

При появлении запроса введите пароль, отображаемый рядом с именем пользователя Postgres, и нажмите + ENTER +.

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

Сначала создайте базу данных для вашего проекта с именем + polls +:

CREATE DATABASE polls;

Теперь мы можем переключиться на базу данных + polls +:

\c polls;

Далее создайте базу данных пользователя для проекта. Убедитесь, что вы выбрали безопасный пароль:

CREATE USER  WITH PASSWORD '';

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

Мы устанавливаем кодировку по умолчанию на + UTF-8 +, что ожидает Django. Мы также устанавливаем схему изоляции транзакции по умолчанию «read commit», которая блокирует чтение из незафиксированных транзакций. Наконец, мы устанавливаем часовой пояс. По умолчанию наши проекты Django будут настроены на использование + UTC. Это все рекомендации из https://docs.djangoproject.com/en/2.0/ref/databases/#optimizing-postgresql-s-configuration так же самого проекта Django].

Введите следующие команды в приглашении PostgreSQL:

ALTER ROLE  SET client_encoding TO 'utf8';
ALTER ROLE  SET default_transaction_isolation TO 'read committed';
ALTER ROLE  SET timezone TO 'UTC';

Теперь мы можем предоставить нашему новому пользователю доступ для администрирования нашей новой базы данных:

GRANT ALL PRIVILEGES ON DATABASE polls TO ;

Когда вы закончите, выйдите из приглашения PostgreSQL, набрав:

\q

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

На следующем шаге мы установим «+ virtualenv +» и создадим виртуальную среду Python для нашего проекта Django.

Шаг 3 - Создание виртуальной среды Python для вашего проекта

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

Для этого нам сначала нужен доступ к команде + virtualenv +. Мы можем установить это с помощью + pip +.

Обновите + pip + и установите пакет, набрав:

sudo -H pip3 install --upgrade pip
sudo -H pip3 install virtualenv

С установленным + virtualenv + мы можем создать каталог для хранения наших виртуальных сред Python и создать его для использования с приложением Django + polls +.

Создайте каталог с именем + envs + и перейдите в него:

mkdir envs
cd envs

В этом каталоге создайте виртуальную среду Python с именем + polls +, набрав:

virtualenv polls

Это создаст каталог с именем + polls + в каталоге + envs +. Внутри он установит локальную версию Python и локальную версию + pip +. Мы можем использовать это для установки и настройки изолированной среды Python для нашего проекта.

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

source polls/bin/activate

Ваше приглашение должно измениться, чтобы указать, что вы сейчас работаете в виртуальной среде Python. Это будет выглядеть примерно так: + (опросы) @: ~ / $ +.

Когда ваша виртуальная среда активна, установите Django, Gunicorn и адаптер + psycopg2 + PostgreSQL с локальным экземпляром + pip +:

pip install django gunicorn psycopg2-binary

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

Шаг 4 - Создание приложения Django для опросов

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

В этом руководстве мы пропустим шаги учебника и просто клонируем окончательное приложение из сообщества DigitalOcean django-polls repo.

Если вы хотите выполнить шаги вручную, создайте каталог с именем + django-polls + в вашем домашнем каталоге и перейдите в него:

cd
mkdir django-polls
cd django-polls

Оттуда вы можете следовать учебному руководству Writing ваше первое приложение Django из официальной документации Django. Когда вы закончите, перейдите на https://www.digitalocean.com/community/tutorials/how-to-set-up-a-scalable-django-app-with-digitalocean-managed-databases-and-spaces# step-5-% E2% 80% 94-setting-the-app-settings [Шаг 5].

Если вы просто хотите клонировать готовое приложение, перейдите в свой домашний каталог и используйте + git +, чтобы клонировать репозиторий django-polls:

cd
git clone https://github.com/do-community/django-polls.git

+ cd + в него и вывести содержимое каталога:

cd django-polls
ls

Вы должны увидеть следующие объекты:

OutputLICENSE  README.md  manage.py  mysite  polls  templates

+ manage.py + - это основная утилита командной строки, используемая для управления приложением. + polls + содержит код приложения + polls +, а + mysite + содержит код и настройки области проекта. + templates + содержит пользовательские файлы шаблонов для административного интерфейса. Чтобы узнать больше о структуре и файлах проекта, обратитесь к Creating[Creating Project из официальной документации Django.

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

Шаг 5 - Настройка параметров приложения

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

Начните с открытия файла настроек в вашем текстовом редакторе:

nano ~/django-polls/mysite/settings.py

Начните с поиска директивы + ALLOWED_HOSTS +. Это определяет список адресов или доменных имен, которые вы хотите использовать для подключения к экземпляру Django. Входящий запрос с заголовком * Host *, которого нет в этом списке, вызовет исключение. Django требует, чтобы вы установили это, чтобы предотвратить определенный класс уязвимости безопасности.

В квадратных скобках перечислите IP-адреса или доменные имена, связанные с вашим сервером Django. Каждый элемент должен быть указан в цитатах с записями, разделенными запятой. Ваш список также будет включать + localhost +, так как вы будете проксировать соединения через локальный экземпляр Nginx. Если вы хотите включить запросы для всего домена и любых поддоменов, добавьте точку к началу записи.

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

~ / Джанго-опросы / MySite / settings.py

. . .

# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['', '', , 'localhost']

. . .

Далее найдите раздел файла, который настраивает доступ к базе данных. Это начнется с + DATABASES +. Конфигурация в файле предназначена для базы данных SQLite. Мы уже создали базу данных PostgreSQL для нашего проекта, поэтому нам нужно настроить эти параметры.

Мы скажем Django использовать адаптер базы данных + psycopg2 +, который мы установили с помощью + pip +, вместо стандартного движка SQLite. Мы также будем повторно использовать * Параметры соединения *, указанные в https://www.digitalocean.com/community/tutorials/how-to-set-up-a-scalable-django-app-with-digitalocean-managed-databases- и-пробелы # step-2-% E2% 80% 94-creation-the-postgresql-database-and-user [Шаг 2]. Вы всегда можете найти эту информацию в разделе «Управляемые базы данных» на панели управления DigitalOcean Cloud.

Обновите файл настройками вашей базы данных: имя базы данных (+ polls +), имя пользователя базы данных, пароль пользователя базы данных, а также базы данных + host + и + port +. Обязательно замените специфичные для базы данных вашими собственными данными:

~ / Джанго-опросы / MySite / settings.py

. . .

DATABASES = {
   'default': {
       'ENGINE': 'django.db.backends.',
       'NAME': 'polls',
       'USER': '',
       'PASSWORD': '',
       'HOST': '',
       'PORT': '',
   }
}

. . .

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

~ / Джанго-опросы / MySite / settings.py

. . .

STATIC_URL = '/static/'

Сохраните и закройте файл, когда вы закончите.

На этом этапе вы настроили параметры базы данных, безопасности и статических файлов проекта Django. Если вы с самого начала следовали учебнику + polls + и не клонировали репозиторий GitHub, вы можете перейти на https://www.digitalocean.com/community/tutorials/how-to-set-up-a-scalable -django-app-with-digitalocean-управляемые базы данных и пространства # step-6-% E2% 80% 94-testing-the-app [Шаг 6]. Если вы клонировали репозиторий GitHub, остается еще один дополнительный шаг.

Файл настроек Django содержит переменную + SECRET_KEY +, которая используется для создания хэшей для различных объектов Django. Важно, чтобы для него было установлено уникальное, непредсказуемое значение. Переменная + SECRET_KEY + была удалена из репозитория GitHub, поэтому мы создадим новую, используя функцию, встроенную в пакет Python + django +, называемую + get_random_secret_key () +. Из командной строки откройте интерпретатор Python:

python

Вы должны увидеть следующий вывод и запрос:

OutputPython 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Импортируйте функцию + get_random_secret_key + из пакета Django, затем вызовите функцию:

from django.core.management.utils import get_random_secret_key
get_random_secret_key()

Скопируйте полученный ключ в буфер обмена.

Выйдите из интерпретатора Python, нажав + CTRL + D +.

Затем снова откройте файл настроек в вашем текстовом редакторе:

nano ~/django-polls/mysite/settings.py

Найдите переменную + SECRET_KEY + и вставьте ключ, который вы только что сгенерировали:

~ / Джанго-опросы / MySite / settings.py

. . .

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = ''

. . .

Сохраните и закройте файл.

Теперь мы протестируем приложение локально, используя сервер разработки Django, чтобы убедиться, что все настроено правильно.

Шаг 6 - Тестирование приложения

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

Перейдите в базовый каталог проекта и создайте исходную схему базы данных в нашей базе данных PostgreSQL, используя команды + makemigrations + и + migrate +:

cd django-polls
./manage.py makemigrations
./manage.py migrate

+ makemigrations + создаст миграции или изменения схемы базы данных на основе изменений, внесенных в модели Django. + migrate + будет применять эти миграции к схеме базы данных. Чтобы узнать больше о миграции в Django, обратитесь к Migrations из официальной документации Django.

Создайте административного пользователя для проекта, набрав:

./manage.py createsuperuser

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

Мы можем собрать весь статический контент в каталог, который мы настроили, набрав:

./manage.py collectstatic

Затем статические файлы будут помещены в каталог с именем + static + в каталоге вашего проекта.

Если вы следовали руководству по первоначальной настройке сервера, у вас должен быть брандмауэр UFW, защищающий ваш сервер. Чтобы протестировать сервер разработки, нам нужно разрешить доступ к порту, который мы будем использовать.

Создайте исключение для порта + 8000 +, набрав:

sudo ufw allow 8000

Тестирование приложения с использованием сервера разработки Django

Наконец, вы можете протестировать свой проект, запустив сервер разработки Django с помощью этой команды:

./manage.py runserver 0.0.0.0:8000

В веб-браузере перейдите к доменному имени или IP-адресу сервера, за которым следуют +: 8000 + и путь + polls +:

http://:8000/polls

Вы должны увидеть интерфейс приложения Опросы:

изображение: https: //assets.digitalocean.com/articles/scalable_django/polls_app.png [Интерфейс приложения для опросов]

Чтобы проверить интерфейс администратора, посетите доменное имя или IP-адрес вашего сервера, затем +: 8000 + и путь к интерфейсу администратора:

http://:8000/admin

Вы должны увидеть окно аутентификации администратора приложения Опросы:

изображение: https: //assets.digitalocean.com/articles/scalable_django/polls_admin.png [Страница аутентификации администратора опроса]

Введите административное имя пользователя и пароль, которые вы создали с помощью команды + createuperuser +.

После аутентификации вы можете получить доступ к административному интерфейсу приложения Опросы:

изображение: https: //assets.digitalocean.com/articles/scalable_django/polls_admin_main.png [Главный интерфейс администратора опросов]

Когда вы закончите изучение, нажмите + CTRL-C + в окне терминала, чтобы выключить сервер разработки.

Тестирование приложения с помощью Gunicorn

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

gunicorn --bind 0.0.0.0:8000 mysite.wsgi

Это запустит Gunicorn на том же интерфейсе, на котором работал сервер разработки Django. Вы можете вернуться и снова протестировать приложение.

Мы передали Gunicorn модуль, указав относительный путь к файлу Django + wsgi.py +, точке входа в наше приложение. Этот файл определяет функцию с именем + application +, которая связывается с приложением. Чтобы узнать больше о спецификации WSGI, нажмите https://www.digitalocean.com/community/tutorials/how-to-set-up-uwsgi-and-nginx-to-serve-python-apps-on-ubuntu-14. -04 # определения и-концепция [здесь].

Когда вы закончите тестирование, нажмите + CTRL-C + в окне терминала, чтобы остановить Gunicorn.

Теперь мы будем выгружать статические файлы приложения в DigitalOcean Spaces.

Шаг 7 - Выгрузка статических файлов в пространства DigitalOcean

На данный момент Gunicorn может обслуживать наше приложение Django, но не его статические файлы. Обычно мы настраиваем Nginx для обслуживания этих файлов, но в этом руководстве мы разгрузим их в DigitalOcean Spaces, используя плагин https://django-storages.readthedocs.io/en/latest/ [+ django-storages +] , Это позволяет легко масштабировать Django за счет централизации статического контента и освобождения ресурсов сервера. Кроме того, вы можете доставить этот статический контент, используя CDN DigitalOcean Spaces.

Полное руководство по разгрузке статических файлов Django в хранилище объектов см. По адресу How для настройки хранилища объектов. с Джанго.

Установка и настройка + django-хранилищ +

Начнем с установки пакета + django-storages + Python. Пакет + django-storages + предоставляет Django бэкэнд-хранилище + S3Boto3Storage +, который использует библиотеку + boto3 + для загрузки файлов в любую S3-совместимую службу хранения объектов.

Для начала установите пакеты + django-storages и` + boto3 + Python, используя + pip`:

pip install django-storages boto3

Затем снова откройте файл настроек Django вашего приложения:

nano ~/django-polls/mysite/settings.py

Перейдите вниз к разделу + INSTALLED_APPS + файла и добавьте + storages + в список установленных приложений:

~ / Джанго-опросы / MySite / settings.py

. . .

INSTALLED_APPS = [
   . . .
   'django.contrib.staticfiles',

]

. . .

Прокрутите файл вниз до «+ STATIC_URL », который мы ранее изменили. Теперь мы перезапишем эти значения и добавим новые внутренние параметры ` S3Boto3Storage +`. Удалите код, который вы ввели ранее, и добавьте следующие блоки, которые включают информацию о доступе и местоположении для вашего пространства. Не забудьте заменить выделенные значения вашей собственной информацией:

~ / Джанго-опросы / MySite / settings.py

. . .

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/2.1/howto/static-files/

AWS_ACCESS_KEY_ID =
AWS_SECRET_ACCESS_KEY =

AWS_STORAGE_BUCKET_NAME =
AWS_S3_ENDPOINT_URL =
AWS_S3_OBJECT_PARAMETERS = {
   'CacheControl': 'max-age=86400',
}
AWS_LOCATION = 'static'
AWS_DEFAULT_ACL = 'public-read'

STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'

STATIC_URL = '{}/{}/'.format(AWS_S3_ENDPOINT_URL, AWS_LOCATION)
STATIC_ROOT = 'static/'

Мы определяем следующие элементы конфигурации:

  • + AWS_ACCESS_KEY_ID +: идентификатор ключа доступа для пространства, который вы создали в предварительных условиях учебника. Если вы не создали набор ключей доступа, обратитесь к Sharing Доступ к пространствам с помощью ключей доступа.

  • + AWS_SECRET_ACCESS_KEY +: секретный ключ для пространства DigitalOcean.

  • + AWS_STORAGE_BUCKET_NAME +: Ваше имя в DigitalOcean Space.

  • + AWS_S3_ENDPOINT_URL +: URL-адрес конечной точки, используемый для доступа к службе хранения объектов. Для DigitalOcean это будет что-то вроде + https: // nyc3.digitaloceanspaces.com + в зависимости от области Space.

  • + AWS_S3_OBJECT_PARAMETERS + Устанавливает заголовки элементов управления кэшем для статических файлов.

  • + AWS_LOCATION +: определяет каталог в области хранения объектов, в который будут помещены все статические файлы.

  • + AWS_DEFAULT_ACL +: определяет список контроля доступа (ACL) для статических файлов. Установка его в + public-read + гарантирует, что файлы будут публично доступны для конечных пользователей.

  • + STATICFILES_STORAGE +: Устанавливает бэкэнд хранилища, который Django будет использовать для выгрузки статических файлов. Этот бэкэнд должен работать с любым S3-совместимым бэкэндом, включая DigitalOcean Spaces.

  • + STATIC_URL +: указывает базовый URL-адрес, который Django должен использовать при создании URL-адресов для статических файлов. Здесь мы объединяем URL конечной точки и подкаталог статических файлов, чтобы создать базовый URL для статических файлов.

  • + STATIC_ROOT +: указывает, где собирать статические файлы локально, прежде чем копировать их в хранилище объектов.

Сохраните и закройте файл, когда вы закончите редактирование.

С этого момента, когда вы запускаете + collectstatic +, Django будет загружать статические файлы вашего приложения в Space. Когда вы запустите Django, он начнет обслуживать статические ресурсы, такие как CSS и Javascript, из этого пространства.

В следующем разделе мы включим CDN для этого пространства и дополнительно настроим собственный поддомен для CDN пространства. Это ускорит доставку статических файлов вашего проекта Django, перехватывая их через географически распределенную сеть пограничных серверов. Чтобы узнать больше о CDN, обратитесь к Using CDN для ускорения доставки статического контента. Если вы не хотите включать CDN Spaces, перейдите к https://www.digitalocean.com/community/tutorials/how-to-set-up-a-scalable-django-app-with-digitalocean-managed- Базы данных и пробелы # configuring-cors-headers [Конфигурирование заголовков CORS].

Включение CDN (необязательно)

Чтобы активировать статическую доставку файлов через CDN DigitalOcean Spaces, начните с включения CDN для вашего DigitalOcean Space. Чтобы узнать, как это сделать, обратитесь к How to Spaces CDN из документации по продукту DigitalOcean.

Если вы хотите использовать custom domain с пробелами CDN, создайте запись CNAME поддомена и соответствующие сертификаты SSL, выполнив следующие действия. How, чтобы настроить конечную точку CDN Spaces с поддоменом.

Настоятельно рекомендуется использовать собственный домен с CDN Spaces. Это значительно улучшит поисковую оптимизацию (SEO) для вашего сайта, сохраняя URL-адреса ваших выгруженных ресурсов аналогичными URL-адресам вашего сайта Django. Чтобы использовать пользовательский домен с CDN Spaces, необходимо сначала добавить домен в свою учетную запись DigitalOcean. Чтобы узнать, как это сделать, обратитесь к How для добавления доменов.

После того, как вы включили CDN для своего Пространства и при необходимости создали для него собственный поддомен, перейдите к своему Пространству с помощью Cloud Control Panel. Вы должны увидеть новую ссылку * Endpoints * под своим именем пространства:

изображение: https: //assets.digitalocean.com/articles/scalable_django/spaces_endpoints.png [Список конечных точек пространства]

Эти конечные точки должны содержать ваше имя пространства. Если вы создали собственный поддомен для CDN Spaces, этот список будет содержать дополнительную конечную точку с именем * Subdomain *.

Конечная точка * Edge * направляет запросы на объекты Spaces через CDN, максимально обслуживая их из пограничного кэша. Запишите эту конечную точку * Edge *, так как мы будем использовать ее для настройки плагина + django-storages +. Если вы создали поддомен для CDN Spaces, конечная точка * Subdomain * является псевдонимом для этой конечной точки * Edge *.

Затем отредактируйте файл настроек Django вашего приложения еще раз:

nano ~/django-polls/mysite/settings.py

Перейдите вниз к разделу «Статические файлы», который мы недавно изменили. Добавьте параметр + AWS_S3_CUSTOM_DOMAIN +, чтобы сконфигурировать конечную точку CDN плагина + django-storages + и обновить параметр + STATIC_URL +, чтобы использовать эту новую конечную точку CDN:

~ / Джанго-опросы / MySite / settings.py

. . .

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/2.1/howto/static-files/

# Moving static assets to DigitalOcean Spaces as per:
# https://www.digitalocean.com/community/tutorials/how-to-set-up-object-storage-with-django
AWS_ACCESS_KEY_ID = 'your_spaces_access_key'
AWS_SECRET_ACCESS_KEY = 'your_spaces_secret_key'

AWS_STORAGE_BUCKET_NAME = 'your_space_name'
AWS_S3_ENDPOINT_URL = 'spaces_endpoint_URL'

AWS_S3_OBJECT_PARAMETERS = {
   'CacheControl': 'max-age=86400',
}
AWS_LOCATION = 'static'
AWS_DEFAULT_ACL = 'public-read'

STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'

STATIC_URL = '{}/{}/'.format(, AWS_LOCATION)
STATIC_ROOT = 'static/'

Здесь замените +pace_edge_endpoint_URL + конечной точкой Edge, которую вы только что отметили, усекая префикс + https: // +. Например, если URL-адрес конечной точки Edge равен + https: //.cdn.digitalocean space.com +, для + AWS_S3_CUSTOM_DOMAIN должно быть установлено значение` + .cdn.digitaloceanspaces.com + `.

Если вы создали собственный субдомен, замените +pace_edge_endpoint_URL + на конечную точку пользовательского субдомена, обрезав префикс + https: // +. Например, если URL-адрес конечной точки субдомена + https: //. Example.com +, + AWS_S3_CUSTOM_DOMAIN + должен быть установлен в + .example.com +.

Когда вы закончите, сохраните и закройте файл.

Когда вы запускаете Django, он теперь будет обслуживать статический контент, используя CDN для вашего DigitalOcean Space.

Прежде чем мы проверим, что все это работает правильно, нам нужно настроить заголовки Cross-Origin Resource Sharing (CORS) для наших файлов Spaces или доступ к определенным статическим ресурсам может быть запрещен вашим веб-браузером. Если вы используете собственный поддомен с CDN Spaces для того же домена, что и Django, вы можете перейти к https://www.digitalocean.com/community/tutorials/how-to-set-up-a-scalable-django -app-with-digitalocean-managed-database-and-space # тестирование-пространства-статическая доставка файлов [Тестирование доставки статических файлов].

Настройка заголовков CORS

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

Для начала перейдите на страницу * Настройки * вашего Пространства с помощью Панели управления облаком:

изображение: https: //assets.nyc3.cdn.digitaloceanspaces.com/spaces/settings.png [Снимок экрана вкладки «Настройки»]

В разделе * CORS Configurations * нажмите * Добавить *.

image: https: //assets.nyc3.cdn.digitaloceanspaces.com/spaces/cors-options.png [Расширенные настройки CORS]

Здесь, под * Origin *, введите источник подстановочного знака, + * +

В разделе «Разрешенные методы» выберите * GET *.

Нажмите * Добавить заголовок * и в появившемся текстовом поле введите + Access-Control-Allow-Origin.

Установите * Access Control Max Age * на + 600 +, чтобы заголовок, который мы только что создали, истекал каждые 10 минут.

Нажмите * Сохранить параметры *.

Отныне объекты в вашем Пространстве будут содержать соответствующие заголовки ответов + Access-Control-Allow-Origin, что позволяет современным защищенным веб-браузерам извлекать эти файлы между доменами.

Доставка статических файлов в пространствах тестирования

Сейчас мы проверим, правильно ли Django обслуживает статические файлы из нашего пространства DigitalOcean.

Перейдите в каталог приложений Django:

cd ~/django-polls

Отсюда выполните + collectstatic + для сбора и загрузки статических файлов в ваше пространство DigitalOcean:

python manage.py collectstatic

Вы должны увидеть следующий вывод:

OutputYou have requested to collect static files at the destination
location as specified in your settings.

This will overwrite existing files!
Are you sure you want to do this?

Type 'yes' to continue, or 'no' to cancel:

Введите + yes + и нажмите + ENTER для подтверждения.

Вы должны увидеть результат, как показано ниже

Output121 static files copied.

Это подтверждает, что Django успешно загрузил статические файлы приложения + polls + в ваш Space. Вы можете перейти к своему пространству с помощью Cloud Control Panel и просмотреть файлы в каталоге + static +.

Далее мы проверим, что Django переписывает соответствующие URL.

Запустите сервер Gunicorn:

gunicorn --bind 0.0.0.0:8000 mysite.wsgi

В веб-браузере посетите доменное имя или IP-адрес вашего сервера, за которым следуют +: 8000 + и + / admin +:

http://:8000/admin

Вы должны снова увидеть окно аутентификации администратора приложения Опросы, на этот раз с правильным стилем.

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

Чтобы сделать это с помощью Google Chrome, щелкните правой кнопкой мыши страницу и выберите * Inspect *.

Вы должны увидеть следующее окно:

изображение: https: //assets.digitalocean.com/articles/scalable_django/chrome_dev_tools.png [Окно Chrome Dev Tools]

Отсюда, нажмите * Sources * на панели инструментов. В списке исходных файлов в левой панели вы должны увидеть + / admin / login + в домене вашего сервера Django и + static / admin + в конечной точке CDN вашего Space. В + static / admin + вы должны увидеть каталоги + css и` + fonts`.

Это подтверждает, что таблицы стилей и шрифты CSS правильно обслуживаются из CDN вашего Space.

Когда вы закончите тестирование, нажмите + CTRL-C + в окне терминала, чтобы остановить Gunicorn.

Вы можете отключить вашу активную виртуальную среду Python, введя + deactivate +:

deactivate

Ваш запрос должен вернуться к нормальной жизни.

На этом этапе вы успешно выгружали статические файлы с вашего сервера Django и обслуживаете их из хранилища объектов. Теперь мы можем перейти к настройке Gunicorn для автоматического запуска в качестве системной службы.

Шаг 8 - Создание системных сокетов и служебных файлов для Gunicorn

В https://www.digitalocean.com/community/tutorials/how-to-set-up-a-scalable-django-app-with-digitalocean-managed-databases-and-spaces#step-6-%E2% 80% 94-testing-the-app [Шаг 6] Мы проверили, что Gunicorn может взаимодействовать с нашим приложением Django, но мы должны реализовать более надежный способ запуска и остановки сервера приложений. Для этого мы создадим файлы службы systemd и сокетов.

Сокет Gunicorn будет создан при загрузке и будет прослушивать соединения. Когда происходит соединение, systemd автоматически запускает процесс Gunicorn для обработки соединения.

Начните с создания и открытия файла сокета systemd для Gunicorn с привилегиями + sudo +:

sudo nano /etc/systemd/system/gunicorn.socket

Внутри мы создадим раздел + [Unit] + для описания сокета, раздел + [Socket] + для определения местоположения сокета и раздел + [Install] +, чтобы убедиться, что сокет создан в нужное время. Добавьте следующий код в файл:

/etc/systemd/system/gunicorn.socket

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

Сохраните и закройте файл, когда вы закончите.

Затем создайте и откройте файл службы systemd для Gunicorn с привилегиями + sudo + в вашем текстовом редакторе. Имя файла службы должно совпадать с именем файла сокета, за исключением расширения:

sudo nano /etc/systemd/system/gunicorn.service

Начните с раздела + [Unit] +, который определяет метаданные и зависимости. Мы разместим здесь описание нашего сервиса и сообщим системе init, что запускать его нужно только после достижения цели сети. Поскольку наш сервис опирается на сокет из файла сокета, нам нужно включить директиву + Требуется +, чтобы указать эту связь:

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

Далее мы откроем раздел + [Service] +. Мы определим пользователя и группу, под которой мы хотим работать. Мы дадим право нашей учетной записи обычного пользователя на процесс, поскольку он владеет всеми соответствующими файлами. Мы передадим групповое владение группе + www-data, чтобы Nginx мог легко общаться с Gunicorn.

Затем мы наметим рабочий каталог и укажем команду для запуска сервиса. В этом случае нам нужно будет указать полный путь к исполняемому файлу Gunicorn, который устанавливается в нашей виртуальной среде. Мы свяжем процесс с сокетом Unix, который мы создали в каталоге + / run +, чтобы процесс мог взаимодействовать с Nginx. Мы записываем все данные в стандартный вывод, чтобы процесс + journald + мог собирать журналы Gunicorn. Мы также можем указать здесь любые дополнительные настройки Gunicorn, например, количество рабочих процессов. Здесь мы запускаем Gunicorn с 3 рабочими процессами.

Добавьте следующий раздел «Сервис» в файл. Не забудьте заменить имя пользователя, указанное здесь, своим именем пользователя:

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=
Group=www-data
WorkingDirectory=/home//django-polls
ExecStart=/home//envs/polls/bin/gunicorn \
         --access-logfile - \
         --workers 3 \
         --bind unix:/run/gunicorn.sock \
         mysite.wsgi:application

Наконец, мы добавим раздел + [Install] +. Это скажет systemd, с чем связать этот сервис, если мы включим его при загрузке. Мы хотим, чтобы эта служба запускалась, когда обычная многопользовательская система запущена и работает:

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=
Group=www-data
WorkingDirectory=/home//django-polls
ExecStart=/home//envs/polls/bin/gunicorn \
         --access-logfile - \
         --workers 3 \
         --bind unix:/run/gunicorn.sock \
         mysite.wsgi:application

[Install]
WantedBy=multi-user.target

На этом наш сервисный файл systemd завершен. Сохраните и закройте его сейчас.

Теперь мы можем запустить и включить сокет Gunicorn. Это создаст файл сокета в + / run / gunicorn.sock + сейчас и при загрузке. Когда будет установлено соединение с этим сокетом, systemd автоматически запустит + gunicorn.service для его обработки:

sudo systemctl start gunicorn.socket
sudo systemctl enable gunicorn.socket

Мы можем подтвердить, что операция прошла успешно, проверив наличие файла сокета.

Проверка на наличие файла сокета Gunicorn

Проверьте статус процесса, чтобы узнать, успешно ли он начался:

sudo systemctl status gunicorn.socket

Вы должны увидеть следующий вывод:

OutputFailed to dump process list, ignoring: No such file or directory
● gunicorn.socket - gunicorn socket
  Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor preset: enabled)
  Active: active (running) since Tue 2019-03-05 19:19:16 UTC; 1h 22min ago
  Listen: /run/gunicorn.sock (Stream)
  CGroup: /system.slice/gunicorn.socket

Mar 05 19:19:16 django systemd[1]: Listening on gunicorn socket.

Затем проверьте наличие файла + gunicorn.sock + в каталоге + / run +:

file /run/gunicorn.sock
Output/run/gunicorn.sock: socket

Если команда + systemctl status + указала, что произошла ошибка, или если вы не нашли файл + gunicorn.sock + в каталоге, это означает, что сокет Gunicorn был создан неправильно. Проверьте журналы сокета Gunicorn, набрав:

sudo journalctl -u gunicorn.socket

Перед тем, как продолжить, еще раз посмотрите на файл + / etc / systemd / system / gunicorn.socket +.

Тестирование активации сокета

В настоящее время, если вы только запустили модуль + gunicorn.socket, то` + gunicorn.service ie` не будет активным, поскольку сокет еще не получил никаких подключений. Вы можете проверить это, набрав:

sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon
  Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)

Чтобы проверить механизм активации сокета, мы можем отправить соединение к сокету через + curl +, набрав:

curl --unix-socket /run/gunicorn.sock localhost

Вы должны увидеть вывод HTML из вашего приложения в терминале. Это указывает на то, что Gunicorn запущен и может обслуживать ваше приложение Django. Чтобы убедиться, что служба Gunicorn работает, введите:

sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon
  Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
  Active: active (running) since Tue 2019-03-05 20:43:56 UTC; 1s ago
Main PID: 19074 (gunicorn)
   Tasks: 4 (limit: 4915)
  CGroup: /system.slice/gunicorn.service
          ├─19074 /home/sammy/envs/polls/bin/python3 /home/sammy/envs/polls/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock mysite.wsgi:application
          ├─19098 /home/sammy/envs/polls/bin/python3 /home/sammy/envs/polls/bin/gunicorn
. . .

Mar 05 20:43:56 django systemd[1]: Started gunicorn daemon.
Mar 05 20:43:56 django gunicorn[19074]: [2019-03-05 20:43:56 +0000] [19074] [INFO] Starting gunicorn 19.9.0
. . .
Mar 05 20:44:15 django gunicorn[19074]:  - - [05/Mar/2019:20:44:15 +0000] "GET / HTTP/1.1" 301 0 "-" "curl/7.58.0"

Если выходные данные + curl или выходные данные` + systemctl status` показывают, что возникла проблема, проверьте в журналах дополнительную информацию:

sudo journalctl -u gunicorn

Вы также можете проверить файл + / etc / systemd / system / gunicorn.service + на наличие проблем. Если вы внесете изменения в этот файл, обязательно перезагрузите демон, чтобы перечитать определение сервиса и перезапустить процесс Gunicorn:

sudo systemctl daemon-reload
sudo systemctl restart gunicorn

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

Шаг 8 - Настройка HTTPS Nginx и прохождения прокси-сервера Gunicorn

Теперь, когда Gunicorn настроен более надежно, нам нужно настроить Nginx для шифрования соединений и передачи трафика процессу Gunicorn.

Если вы выполнили предварительные требования и настроили Nginx с помощью Let Encrypt, у вас уже должен быть файл блока сервера, соответствующий вашему домену, доступный вам в каталоге + sites-available + Nginx. Если нет, следуйте How для защиты Nginx с помощью Let’s Encrypt on Ubuntu 18.04 и вернемся к этому шагу.

Прежде чем редактировать этот файл блока сервера ++, мы сначала удалим файл блока сервера + default +, который выкатывается по умолчанию после установки Nginx:

sudo rm /etc/nginx/sites-enabled/default

Теперь мы изменим файл блока сервера ++, чтобы передавать трафик в Gunicorn вместо страницы по умолчанию + index.html +, настроенной на предварительном этапе.

Откройте файл блока сервера, соответствующий вашему домену, в вашем редакторе:

sudo nano /etc/nginx/sites-available/

Вы должны увидеть что-то вроде следующего:

/etc/nginx/sites-available/example.com

server {

       root /var/www//html;
       index index.html index.htm index.nginx-debian.html;

       server_name ;

       location / {
               try_files $uri $uri/ =404;
       }

   listen [::]:443 ssl ipv6only=on; # managed by Certbot
   listen 443 ssl; # managed by Certbot
   ssl_certificate /etc/letsencrypt/live//fullchain.pem; # managed by Certbot
   ssl_certificate_key /etc/letsencrypt/live//privkey.pem; # managed by Certbot
   include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
   ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
   if ($host = ) {
       return 301 https://$host$request_uri;
   } # managed by Certbot


       listen 80;
       listen [::]:80;

       server_name ;
   return 404; # managed by Certbot


}

Это комбинация файла блока сервера по умолчанию, созданного в https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-18-04#step-5-setting-up- server-blocks- (рекомендуется) [Как установить Nginx в Ubuntu 18.04], а также дополнения, автоматически добавляемые Let’s Encrypt. Мы собираемся удалить содержимое этого файла и записать новую конфигурацию, которая перенаправляет HTTP-трафик на HTTPS и перенаправляет входящие запросы в сокет Gunicorn, который мы создали на предыдущем шаге.

Если вы хотите, вы можете сделать резервную копию этого файла, используя + cp +. Выйдите из вашего текстового редактора и создайте резервную копию с именем + example.com.old +:

sudo cp /etc/nginx/sites-available/ /etc/nginx/sites-available/.old

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

Начните с вставки в следующий блок, который перенаправляет HTTP-запросы на порт + 80 + на HTTPS:

/etc/nginx/sites-available/example.com

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name _;
   return 301 https://$request_uri;
}

Здесь мы прослушиваем HTTP-запросы IPv4 и IPv6 на порт + 80 + и отправляем заголовок ответа 301, чтобы перенаправить запрос на порт HTTPS + 443 +, используя домен ++. Это также перенаправит прямые HTTP-запросы на IP-адрес сервера.

После этого блока добавьте следующий блок кода конфигурации, который обрабатывает HTTPS-запросы для домена + example.com +:

/etc/nginx/sites-available/example.com

. . .
server {
   listen [::]:443 ssl ipv6only=on;
   listen 443 ssl;
   server_name ;

   # Let's Encrypt parameters
   ssl_certificate /etc/letsencrypt/live//fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live//privkey.pem;
   include /etc/letsencrypt/options-ssl-nginx.conf;
   ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

   location = /favicon.ico { access_log off; log_not_found off; }

   location / {
       proxy_pass         http://unix:/run/gunicorn.sock;
       proxy_redirect     off;

       proxy_set_header   Host              $http_host;
       proxy_set_header   X-Real-IP         $remote_addr;
       proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
       proxy_set_header   X-Forwarded-Proto https;
   }
}

Здесь мы сначала прослушиваем порт + 443 + для запросов, поступающих в домены ++ и + www. +.

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

Строка + location = / favicon.ico + указывает Nginx игнорировать любые проблемы с поиском значка.

Последний блок + location = / + инструктирует Nginx передавать запросы к сокету Gunicorn, настроенному в https://www.digitalocean.com/community/tutorials/how-to-set-up-a-scalable-django- приложение-с-цифровыми-управляемыми-базами данных-и-пространствами # step-8-% E2% 80% 94-создание-systemd-сокетов-и-файлов-сервисов для gunicorn [Шаг 8]. Кроме того, он добавляет заголовки для информирования вышестоящего сервера Django о том, что запрос был перенаправлен, и для предоставления ему различных свойств запроса.

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

/etc/nginx/sites-available/example.com

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name _;
   return 301 https://$request_uri;
}
server {
       listen [::]:443 ssl ipv6only=on;
       listen 443 ssl;
       server_name ;

       # Let's Encrypt parameters
       ssl_certificate /etc/letsencrypt/live//fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live//privkey.pem;
       include /etc/letsencrypt/options-ssl-nginx.conf;
       ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

       location = /favicon.ico { access_log off; log_not_found off; }

       location / {
         proxy_pass         http://unix:/run/gunicorn.sock;
         proxy_redirect     off;

         proxy_set_header   Host              $http_host;
         proxy_set_header   X-Real-IP         $remote_addr;
         proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
         proxy_set_header   X-Forwarded-Proto https;
       }
}

Сохраните и закройте файл, когда вы закончите.

Проверьте свою конфигурацию Nginx на наличие синтаксических ошибок, набрав:

sudo nginx -t

Если ваша конфигурация не содержит ошибок, перезапустите Nginx, набрав:

sudo systemctl restart nginx

Теперь вы сможете посетить домен или IP-адрес вашего сервера, чтобы просмотреть приложение. Ваш браузер должен использовать безопасное HTTPS-соединение для подключения к бэкэнду Django.

Чтобы полностью защитить наш проект Django, нам нужно добавить пару параметров безопасности в его файл + settings.py +. Снова откройте этот файл в вашем редакторе:

nano ~/django-polls/mysite/settings.py

Прокрутите до конца файла и добавьте следующие параметры:

~ / Джанго-опросы / MySite / settings.py

. . .

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_SSL_REDIRECT = True

Эти настройки сообщают Django о том, что вы включили HTTPS на своем сервере, и инструктируют его использовать «безопасные» куки. Чтобы узнать больше об этих настройках, обратитесь к SSL/HTTPS section https://docs.djangoproject.com/en/ 2.1 / themes / security / # security-in-django [Безопасность в Django].

Когда вы закончите, сохраните и закройте файл.

Наконец, перезапустите Gunicorn:

sudo systemctl restart gunicorn

На этом этапе вы настроили Nginx для перенаправления HTTP-запросов и передачи этих запросов в Gunicorn. HTTPS теперь должен быть полностью включен для вашего проекта и приложения Django. Если вы столкнулись с ошибками, это обсуждение на https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-18 -04 # устранение неполадок-nginx-and-gunicorn [устранение неполадок Nginx и Gunicorn] может помочь.

Заключение

В этом руководстве вы настраиваете и настраиваете масштабируемое приложение Django, работающее на сервере Ubuntu 18.04. Эта настройка может быть реплицирована на несколько серверов для создания высокодоступной архитектуры. Кроме того, это приложение и его конфигурация могут быть упакованы в контейнеры с помощью Docker или другого контейнера времени выполнения для упрощения развертывания и масштабирования. Эти контейнеры затем могут быть развернуты в кластер контейнеров, например Kubernetes. В следующей серии Tutorial мы рассмотрим, как создать и модернизировать это приложение Django + polls +, чтобы оно могло работать в кластере Kubernetes.

В дополнение к статическим файлам вы также можете выгружать файлы Django Media в хранилище объектов. Чтобы узнать, как это сделать, обратитесь к https://www.caktusgroup.com/blog/2014/11/10/Using-Amazon-S3-to-store-your-Django-sites-static-and-media-files/ Использование Amazon S3 для хранения статических и мультимедийных файлов вашего сайта Django. Вы можете также рассмотреть возможность сжатия статических файлов для дальнейшей оптимизации их доставки конечным пользователям. Для этого вы можете использовать плагин Django, такой как Django compressor.

Related