Как запустить отладочный веб сервер django

Django development server и тестирование HTTPS

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

Первое, что пришло в голову, поднять полноценный веб-сервер (например, Apache) для разработки и тестирования, но что если не хочется отказываться от удобств и простоты использования встроенного веб-сервера Django?

Поиск в Интернете по запросу «django + https» выдал несколько статей датированных 2009 и 2012 годами, в которых для тестирования HTTPS предлагается использовать stunnel.

Данная статья является инструкцией полученной в результате настройки stunnel под среду разработки Django на Ubuntu 12.04.1 LTS x64.

Программная среда

• Ubuntu 12.04.1 LTS (x64)
• OpenSSL 1.0.1 14 Mar 2012
• Python 2.7.3
• virtualenv 1.8.4
• Django 1.5.1

Установка и настройка stunnel

Для начала необходимо установить stunnel (версии 4.х, ветка 3.х более не поддерживается):

Базовые настройки stunnel находятся в файле /etc/default/stunnel4 :

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

А вот то, что понадобится обязательно — сертификат X.509.

Генерация сертификата

…. Each SSL enabled daemon needs to present a valid X.509 certificate to the peer. It also needs a private key to decrypt the incoming data. The easiest way to obtain a certificate and a key is to generate them with the free OpenSSL package …

… The order of contents of the .pem file is important. It should contain the unencrypted private key first, then a signed certificate (not certificate request). There should be also empty lines after certificate and private key. Plaintext certificate information appended on the top of generated certificate should be discarded. So the file should look like this:

——BEGIN RSA PRIVATE KEY——
[encoded key]
——END RSA PRIVATE KEY——
[empty line]
——BEGIN CERTIFICATE——
[encoded certificate]
——END CERTIFICATE——
[empty line]

Для генерации приватного ключа и сертификата воспользуемся OpenSSL (должен присутствовать в Ubuntu 12.04.1):

Во время генерации необходимо ввести данные о владельце (коды стран для удобства).

На выходе получаем два файла private.key и stunnel.cert , которые необходимо объединить и добавить пустые строки согласно шаблона:

Теперь создадим файл конфигурации для туннеля.

Файл конфигурации

Пример файла конфигурации stunnel.conf-sample находится в /usr/share/doc/stunnel4/examples/ , а описание параметров можно посмотреть в man stunel4 или в документации. Плюс ко всему, раздел FAQ на сайте программы содержит некоторые полезные советы.

Создадим файл конфигурации в домашнем каталоге:

В нашем случая он имеет следующее содержимое:

Давайте проверим, что получилось?

Создание туннеля и запуск веб-сервера

Запустим stunnel и встроенный веб-сервер Django для тестового проекта (пустой проект, сразу после django-admin.py startproject ):

Переменная окружения HTTPS=on необходима для корректной симуляции HTTPS в Django, без нее метод request.is_secure() будет возвращать False.

Проверим «прослушиваемые» порты:

Туннель успешно создан — stunnel слушает на всех внешних интерфейсах порт 8443, а веб-сервер локальные соединения на порту 8000.

Для «уничтожения» туннеля подойдет команда killall :

Проверка работы

Откроем в браузере любой существующий на сервере URL, используя https:// вместо http:// . При первом запросе мы должны увидеть предупреждения о ненадежном сертификате, т.к. подписан он был нами лично, а не аккредитованным центром (Certificate Authority). После подтверждения исключения безопасности, перед нами появится запрошенная страница, полученная по протоколу HTTPS.

Было

Стало

Заключение

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

Хочу отметить, что на сайте stunnel присутствует версия для Windows и Android, так что попытаться собрать подобную схему можно и на этих операционных системах.

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

Под конец перечислю те преимущества и недостатки, которые отметил для себя, а также приведу список ссылок.

Преимущества

+ не требуется установка полноценного веб-сервера;
+ возможность построения туннелей для нескольких Django веб-серверов;
+ использование преймуществ встроенного веб-сервера.

Недостатки

— это не полноценный веб-сервер с поддержкой HTTPS;
— необходимость в установке и настройки дополнительного ПО;
— фактически веб-сервер Django обрабатывает HTTP запросы (см. логи ниже).

Writing your first Django app, part 1¶

Throughout this tutorial, we’ll walk you through the creation of a basic poll application.

It’ll consist of two parts:

• A public site that lets people view polls and vote in them.
• An admin site that lets you add, change, and delete polls.

We’ll assume you have Django installed already. You can tell Django is installed and which version by running the following command in a shell prompt (indicated by the $ prefix):

If Django is installed, you should see the version of your installation. If it isn’t, you’ll get an error telling “No module named django”.

This tutorial is written for Django 4.1, which supports Python 3.8 and later. If the Django version doesn’t match, you can refer to the tutorial for your version of Django by using the version switcher at the bottom right corner of this page, or update Django to the newest version. If you’re using an older version of Python, check What Python version can I use with Django? to find a compatible version of Django.

See How to install Django for advice on how to remove older versions of Django and install a newer one.

Where to get help:

If you’re having trouble going through this tutorial, please head over to the Getting Help section of the FAQ.

Creating a project¶

If this is your first time using Django, you’ll have to take care of some initial setup. Namely, you’ll need to auto-generate some code that establishes a Django project – a collection of settings for an instance of Django, including database configuration, Django-specific options and application-specific settings.

From the command line, cd into a directory where you’d like to store your code, then run the following command:

This will create a mysite directory in your current directory. If it didn’t work, see Problems running django-admin .

You’ll need to avoid naming projects after built-in Python or Django components. In particular, this means you should avoid using names like django (which will conflict with Django itself) or test (which conflicts with a built-in Python package).

Where should this code live?

If your background is in plain old PHP (with no use of modern frameworks), you’re probably used to putting code under the web server’s document root (in a place such as /var/www ). With Django, you don’t do that. It’s not a good idea to put any of this Python code within your web server’s document root, because it risks the possibility that people may be able to view your code over the web. That’s not good for security.

Put your code in some directory outside of the document root, such as /home/mycode .

Let’s look at what startproject created:

These files are:

• The outer mysite/ root directory is a container for your project. Its name doesn’t matter to Django; you can rename it to anything you like.
• manage.py : A command-line utility that lets you interact with this Django project in various ways. You can read all the details about manage.py in django-admin and manage.py .
• The inner mysite/ directory is the actual Python package for your project. Its name is the Python package name you’ll need to use to import anything inside it (e.g. mysite.urls ).
• mysite/__init__.py : An empty file that tells Python that this directory should be considered a Python package. If you’re a Python beginner, read more about packages in the official Python docs.
• mysite/settings.py : Settings/configuration for this Django project. Django settings will tell you all about how settings work.
• mysite/urls.py : The URL declarations for this Django project; a “table of contents” of your Django-powered site. You can read more about URLs in URL dispatcher .
• mysite/asgi.py : An entry-point for ASGI-compatible web servers to serve your project. See How to deploy with ASGI for more details.
• mysite/wsgi.py : An entry-point for WSGI-compatible web servers to serve your project. See How to deploy with WSGI for more details.

The development server¶

Let’s verify your Django project works. Change into the outer mysite directory, if you haven’t already, and run the following commands:

You’ll see the following output on the command line:

Ignore the warning about unapplied database migrations for now; we’ll deal with the database shortly.

You’ve started the Django development server, a lightweight web server written purely in Python. We’ve included this with Django so you can develop things rapidly, without having to deal with configuring a production server – such as Apache – until you’re ready for production.

Now’s a good time to note: don’t use this server in anything resembling a production environment. It’s intended only for use while developing. (We’re in the business of making web frameworks, not web servers.)

Now that the server’s running, visit http://127.0.0.1:8000/ with your web browser. You’ll see a “Congratulations!” page, with a rocket taking off. It worked!

Changing the port

By default, the runserver command starts the development server on the internal IP at port 8000.

If you want to change the server’s port, pass it as a command-line argument. For instance, this command starts the server on port 8080:

If you want to change the server’s IP, pass it along with the port. For example, to listen on all available public IPs (which is useful if you are running Vagrant or want to show off your work on other computers on the network), use:

Full docs for the development server can be found in the runserver reference.

Automatic reloading of runserver

The development server automatically reloads Python code for each request as needed. You don’t need to restart the server for code changes to take effect. However, some actions like adding files don’t trigger a restart, so you’ll have to restart the server in these cases.

Creating the Polls app¶

Now that your environment – a “project” – is set up, you’re set to start doing work.

Each application you write in Django consists of a Python package that follows a certain convention. Django comes with a utility that automatically generates the basic directory structure of an app, so you can focus on writing code rather than creating directories.

Projects vs. apps

What’s the difference between a project and an app? An app is a web application that does something – e.g., a blog system, a database of public records or a small poll app. A project is a collection of configuration and apps for a particular website. A project can contain multiple apps. An app can be in multiple projects.

Your apps can live anywhere on your Python path . In this tutorial, we’ll create our poll app in the same directory as your manage.py file so that it can be imported as its own top-level module, rather than a submodule of mysite .

To create your app, make sure you’re in the same directory as manage.py and type this command:

That’ll create a directory polls , which is laid out like this:

This directory structure will house the poll application.

Write your first view¶

Let’s write the first view. Open the file polls/views.py and put the following Python code in it:

This is the simplest view possible in Django. To call the view, we need to map it to a URL — and for this we need a URLconf.

To create a URLconf in the polls directory, create a file called urls.py . Your app directory should now look like:

In the polls/urls.py file include the following code:

The next step is to point the root URLconf at the polls.urls module. In mysite/urls.py , add an import for django.urls.include and insert an include() in the urlpatterns list, so you have:

The include() function allows referencing other URLconfs. Whenever Django encounters include() , it chops off whatever part of the URL matched up to that point and sends the remaining string to the included URLconf for further processing.

The idea behind include() is to make it easy to plug-and-play URLs. Since polls are in their own URLconf ( polls/urls.py ), they can be placed under “/polls/”, or under “/fun_polls/”, or under “/content/polls/”, or any other path root, and the app will still work.

You should always use include() when you include other URL patterns. admin.site.urls is the only exception to this.

You have now wired an index view into the URLconf. Verify it’s working with the following command:

Go to http://localhost:8000/polls/ in your browser, and you should see the text “Hello, world. You’re at the polls index.”, which you defined in the index view.

If you get an error page here, check that you’re going to http://localhost:8000/polls/ and not http://localhost:8000/.

The path() function is passed four arguments, two required: route and view , and two optional: kwargs , and name . At this point, it’s worth reviewing what these arguments are for.

path() argument: route ¶

route is a string that contains a URL pattern. When processing a request, Django starts at the first pattern in urlpatterns and makes its way down the list, comparing the requested URL against each pattern until it finds one that matches.

Patterns don’t search GET and POST parameters, or the domain name. For example, in a request to https://www.example.com/myapp/ , the URLconf will look for myapp/ . In a request to https://www.example.com/myapp/?page=3 , the URLconf will also look for myapp/ .

path() argument: view ¶

When Django finds a matching pattern, it calls the specified view function with an HttpRequest object as the first argument and any “captured” values from the route as keyword arguments. We’ll give an example of this in a bit.

path() argument: kwargs ¶

Arbitrary keyword arguments can be passed in a dictionary to the target view. We aren’t going to use this feature of Django in the tutorial.

path() argument: name ¶

Naming your URL lets you refer to it unambiguously from elsewhere in Django, especially from within templates. This powerful feature allows you to make global changes to the URL patterns of your project while only touching a single file.

When you’re comfortable with the basic request and response flow, read part 2 of this tutorial to start working with the database.

Написание вашего первого приложения Django, часть 1 ¶

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

Он будет состоять из двух частей:

• Общедоступный сайт, который позволяет людям просматривать опросы и голосовать в них.
• Сайт администратора, который позволяет добавлять, изменять и удалять опросы.

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

Если установлен Django, вы должны увидеть версию своей установки. В противном случае вы получите сообщение об ошибке «Нет модуля с именем django».

Это руководство написано для Django 3.2, который поддерживает Python 3.6 и новее. Если версия Django не совпадает, вы можете обратиться к руководству для вашей версии Django, используя переключатель версий в правом нижнем углу этой страницы, или обновить Django до последней версии. Если вы используете старую версию Python, проверьте, какую версию Python можно использовать с Django? чтобы найти совместимую версию Django.

См. Раздел Как установить Django, чтобы узнать, как удалить старые версии Django и установить новую.

Где получить помощь:

Если у вас возникли проблемы с прохождением этого руководства, перейдите в раздел « Получение справки » в FAQ.

Создание проекта ¶

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

Из командной строки cd в каталог, в котором вы хотите сохранить свой код, затем выполните следующую команду:

Это создаст mysite каталог в вашем текущем каталоге. Если не помогло, см. Проблемы с запуском django-admin .

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

Где должен жить этот код?

Если ваш опыт работы с простым старым PHP (без использования современных фреймворков), вы, вероятно, привыкли помещать код в корень документа веб-сервера (в таком месте, как /var/www ). С Django этого не сделать. Не рекомендуется помещать какой-либо из этого кода Python в корень документа вашего веб-сервера, поскольку это создает риск того, что люди смогут просматривать ваш код через Интернет. Это плохо для безопасности.

Поместите свой код в какой-нибудь каталог вне корня документа, например /home/mycode .

Посмотрим, что startproject создано:

• Внешний mysite/ корневой каталог — это контейнер для вашего проекта. Его имя не имеет значения для Django; вы можете переименовать его во что угодно.
• manage.py : Утилита командной строки, которая позволяет вам различными способами взаимодействовать с этим проектом Django. Вы можете прочитать все подробности manage.py в django-admin и manage.py .
• Внутренний mysite/ каталог — это фактический пакет Python для вашего проекта. Его имя — это имя пакета Python, который вам нужно будет использовать для импорта чего-либо внутри него (например mysite.urls ).
• mysite/__init__.py : Пустой файл, который сообщает Python, что этот каталог следует рассматривать как пакет Python. Если вы новичок в Python, узнайте больше о пакетах в официальных документах Python.
• mysite/settings.py : Настройки / конфигурация для этого проекта Django. Настройки Django расскажут вам все о том, как работают настройки.
• mysite/urls.py : Объявления URL для этого проекта Django; «оглавление» вашего сайта на Django. Вы можете узнать больше об URL-адресах в диспетчере URL- адресов .
• mysite/asgi.py : Точка входа для ASGI-совместимых веб-серверов для обслуживания вашего проекта. Подробнее см. Как развернуть с помощью ASGI .
• mysite/wsgi.py : Точка входа для WSGI-совместимых веб-серверов для обслуживания вашего проекта. Дополнительные сведения см. В разделе « Как развернуть с помощью WSGI» .

Сервер разработки ¶

Давайте проверим, что ваш проект Django работает. Перейдите во внешний mysite каталог, если вы еще этого не сделали, и выполните следующие команды:

Вы увидите следующий вывод в командной строке:

Пока не обращайте внимания на предупреждение о непримененных миграциях базы данных; мы займемся базой данных в ближайшее время.

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

Пришло время отметить: не используйте этот сервер в чем-либо, напоминающем производственную среду. Он предназначен только для использования во время разработки. (Мы занимаемся созданием веб-фреймворков, а не веб-серверов.)

Теперь, когда сервер запущен, зайдите на http://127.0.0.1:8000/ в своем веб-браузере. Вы увидите сообщение «Поздравляем!» страница, со взлетом ракеты. Это сработало!

По умолчанию runserver команда запускает сервер разработки на внутреннем IP-адресе через порт 8000.

Если вы хотите изменить порт сервера, передайте его в качестве аргумента командной строки. Например, эта команда запускает сервер на порту 8080:

Если вы хотите изменить IP-адрес сервера, передайте его вместе с портом. Например, чтобы прослушивать все доступные общедоступные IP-адреса (что полезно, если вы используете Vagrant или хотите продемонстрировать свою работу на других компьютерах в сети), используйте:

0 — это ярлык для 0.0.0.0 . Полную документацию по серверу разработки можно найти в runserver справочнике.

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

Создание приложения «Опросы» ¶

Теперь, когда ваша среда — «проект» — настроена, вы готовы приступить к работе.

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

Проекты против приложений

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

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

Чтобы создать приложение, убедитесь, что вы находитесь в том же каталоге, что manage.py и, и введите эту команду:

Это создаст каталог polls , который выглядит следующим образом:

В этой структуре каталогов будет размещено приложение опроса.

Напишите свой первый взгляд ¶

Напишем первое представление. Откройте файл polls/views.py и поместите в него следующий код Python:

Это самый простой вид из возможных в Django. Чтобы вызвать представление, нам нужно сопоставить его с URL-адресом — и для этого нам понадобится URLconf.

Чтобы создать URLconf в каталоге опросов, создайте файл с именем urls.py . Каталог вашего приложения теперь должен выглядеть так:

В polls/urls.py файл включаем следующий код:

Следующим шагом является указание корневого URLconf на polls.urls модуль. В mysite/urls.py добавьте импорт для django.urls.include и вставьте include() в urlpatterns список, чтобы у вас было:

include() Функция позволяет ссылку других URLconfs. Всякий раз, когда встречается Django include() , он отрезает любую часть URL-адреса, совпадающую до этого момента, и отправляет оставшуюся строку во включенный URLconf для дальнейшей обработки.

Идея include() состоит в том, чтобы упростить подключение URL-адресов по принципу plug-and-play. Поскольку опросы находятся в собственном URLconf ( polls/urls.py ), их можно разместить в «/ polls /», «/ fun_polls /», «/ content / polls /» или любом другом корневом пути, и приложение все равно будет Работа.

Вы всегда должны использовать, include() когда включаете другие шаблоны URL. admin.site.urls единственное исключение из этого.

Теперь вы подключили index представление к URLconf. Убедитесь, что он работает, с помощью следующей команды:

Перейдите по адресу http: // localhost: 8000 / polls / в своем браузере, и вы должны увидеть текст « Hello, world. Вы попали в индекс опросов. », Который вы определили в index представлении.

Страница не найдена?

Если вы получили здесь страницу с ошибкой, убедитесь, что вы переходите на http: // localhost: 8000 / polls /, а не на http: // localhost: 8000 / .

path() Функции передаются четыре аргумента, два необходимо: route и view и два опциональные: kwargs и name . На этом этапе стоит рассмотреть, для чего нужны эти аргументы.

path() аргумент: route ¶

route — строка, содержащая шаблон URL. При обработке запроса Django начинает с первого шаблона urlpatterns и продвигается вниз по списку, сравнивая запрошенный URL с каждым шаблоном, пока не найдет подходящий.

Шаблоны не ищут параметры GET и POST или имя домена. Например, в запросе к https://www.example.com/myapp/ URLconf будет искать myapp/ . В запросе к https://www.example.com/myapp/?page=3 URLconf также будет искать файлы myapp/ .

path() аргумент: view ¶

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

path() аргумент: kwargs ¶

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

path() аргумент: name ¶

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

Когда вы освоитесь с базовым потоком запросов и ответов, прочитайте часть 2 этого руководства, чтобы начать работу с базой данных.

Django Руководство часть 11: Разворачивание сайта на сервере

Теперь, когда вы создали (и протестировали) свой шикарный сайт LocalLibrary, у вас скорее всего, есть желание разместить его на публичном веб-сервере, чтобы он стал доступен через интернет персоналу и посетителям библиотеки. Данная статья даёт общее представление о том, каким образом подойти к поиску хостинга для размещения сайта, а также, что нужно сделать чтобы подготовить свой сайт к публикации.

Обзор

Даже когда разработка вашего сайта завершена (или «достаточно» завершена для начала публичного тестирования), то для публичного доступа вам надо его где-то разместить.

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

• Сделать несколько изменений в настройках проекта.
• Выбрать/Настроить окружение для хостинга приложения Django.
• Выбрать/Настроить окружение для размещения статических файлов.
• В целях обслуживания сайта настроить инфраструктуру для его развёртывания.

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

Что такое окружение развёртывания?

Окружение развёртывания — это среда, которое предоставляет сервер, на котором вы будете размещать свой веб-сайт для публичного запуска и доступа. Данное окружение включает в себя:

• Железо на котором будет запускаться сайт.
• Операционную систему (Linux, Windows).
• Языки программирования времени выполнения (скриптовые) и библиотеки, которые использует ваш сайт.
• Веб-сервер, используемый для обслуживания страниц и другого контента (Nginx, Apache).
• Сервер приложений, который передаёт «динамические» запросы между сайтом Django и веб-сервером.
• Базу данных, от которой зависит ваш сайт.

Примечание: У вас может быть потребность в обратном прокси, балансировщике загрузки и так далее.

Сервер может быть вашим собственным с подключением к интернету по скоростному каналу, но более общим подходом является применение «облачных решений». Что действительно имеет значение, так это то, что ваш код запускается на некотором удалённом компьютере (возможно и «виртуальном»), в хостинговом дата-центре. Удалённый сервер обычно предоставляет определённый доступ к компьютерным ресурсам (процессору, оперативной памяти, памяти на жёстких носителях и так далее) и соединение с интернетом за некоторую цену.

Такой тип удалённого доступа к вычислительному/сетевому железу называется Инфраструктура как Сервис (Infrastructure as a Service — IaaS). Множество IaaS поставщиков предлагают услуги по предустановке какой-либо операционной системы, на которую вы можете установить необходимые для вашего рабочего окружения компоненты. Другие поставщики предлагают вам выбрать уже готовые полноценные рабочие окружения, возможно, включающие в себя Django и настроенный веб-сервер.

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

Некоторые провайдеры поддерживают Django как часть своего предложения Платформа как Сервис (Platform as a Service — PaaS). При данном виде хостинга вам не нужно беспокоиться о большей части окружения (веб-сервере, сервере приложений, балансировщике загрузки), так как сама платформа берёт это на себя (включая все моменты, касающиеся роста и развития вашего приложения). В данном случае развёртывание приложения является достаточно простой задачей, — вам нужно сконцентрироваться только на вашем приложении, а не на инфраструктуре.

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

Примечание: Если вы выбираете хостинг с поддержкой Python/Django, то он должен иметь инструкцию по установке веб-сайта Django, учитывающую различные конфигурации веб-сервера, сервера приложений, обратного прокси и так далее (это не имеет значение, если вы выбрали PaaS). Например, существует множество инструкций «шаг-за-шагом» для различный конфигураций в Документации DigitalOcean по Django.

Выбор хостинг провайдера

Существует более 100 хорошо известных хостинг провайдеров, которые либо активно поддерживают, или работают с Django (их список можно увидеть в Django-дружественные хостинги). Данные поставщики предоставляют различные типы окружений (IaaS, PaaS), и различные уровни доступа к вычислительным и сетевым ресурсам, за разную цену.

Некоторые вещи на которые надо обратить внимание при выборе хостинга:

• Насколько требовательным к вычислительным ресурсам является ваш сайт.
• Уровень поддержки горизонтального (добавление большего количества машин) и вертикального масштабирования (переход на более мощное железо), а также стоимость всего этого.
• Где расположены дата-центры и, следовательно, откуда будет более быстрый доступ.
• Время непрерывной работы хостинга, а также время и количество простоя.
• Инструменты, которые предоставляются для управления сайтом — простота и безопасность их использования (SFTP и FTP).
• Встроенные фреймворки для мониторинга вашего сервера.
• Ограничения. Некоторые хостинги могут блокировать некоторые сервисы (например, электронную почту) . Другие предлагают только определённое количество часов «живого времени» за определённую цену, или небольшое количество места для данных.
• Преимущества. Некоторые провайдеры могут предложить бесплатные доменные имена и поддержку сертификатов SSL, которые, в других случаях, должны были бы купить.
• Что будет при истечении времени использования «бесплатного» хостинга, какова «стоимость» миграции на более «дорогие» тарифы и так далее?

Хорошей новостью является то, что для того, чтобы начать существует достаточное количество компаний, которые предоставляют пробные «бесплатные» тарифы типа «evaluation» (для пробы), «developer» (разработка), или «hobbyist» (хобби). Всегда существуют ресурсы с ограниченным окружением, при использовании которых вам надо беспокоиться лишь о том, что они могут быть доступны лишь в течении определённого периода времени. Тем не менее, они являются отличным решением для тестирования сайтов с небольшим трафиком в реальном окружении, а также могут предоставлять простой доступ к платным ресурсам, в случае необходимости. Наиболее популярными провайдерами являются Heroku, Python Anywhere, Amazon Web Services, Microsoft Azure и так далее.

Многие провайдеры имеют «basic» (базовый) тариф, предоставляющий достаточный уровень вычислительной мощности с небольшим количеством ограничений. Digital Ocean и Python Anywhere являются примерами провайдеров, которые предлагают относительно недорогой базовый тариф (от $5 до $10USD в месяц).

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

Подготовка веб-сайта к публикации

Скелет сайта был создан при помощи инструментов django-admin и manage.py, которые настроены таким образом, чтобы сделать разработку проще. Многие настройки файла проекта (определённых в settings.py) должны быть изменены перед публикацией сайта, либо из-за вопросов безопасности, либо производительности.

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

Критически важные настройки файла settings.py:

• DEBUG . При развёртывании сайта должен быть установлен в False ( DEBUG = False ). Тем самым, прекратится вывод важной отладочной информации.
• SECRET_KEY . Это большое случайное число, применяемое для защиты от CSRF. Важно, чтобы ключ, используемый в продакшене, не указывался в исходном коде, и/или не запрашивался с другого сервера. Django рекомендует размещать значение ключа либо в переменной окружения, или в файле с доступом только на чтение.

Давайте изменим приложение LocalLibrary таким образом, чтобы читать SECRET_KEY и DEBUG из переменных окружения, если те определены, иначе использовать значения по умолчанию.

Откройте /locallibrary/settings.py, закомментируйте исходное значение SECRET_KEY и добавьте новые строки, как указано ниже жирным. В течении разработки, никаких переменных окружения определено не было, таким образом будут использоваться значения по умолчанию (не имеет значения какой ключ вы используете в процессе разработки, поскольку при развёртывании проекта вы будете использовать другой).

Затем закомментируйте строку с настройкой DEBUG , а затем, добавьте новую, указанную ниже.

Значение DEBUG будет True по умолчанию и станет False , в том случае, если переменная окружения DJANGO_DEBUG будет проинициализирована пустой строкой, то есть, DJANGO_DEBUG=» .

Примечание: Было бы более понятным, если бы мы могли просто установить и снять с DJANGO_DEBUG непосредственно на True и False , напрямую, а не использовать «любую строку» или «пустую строку» (соответственно). К сожалению, значения переменных среды хранятся как строки Python и единственная строка, которая оценивается как False является пустой строкой (например, bool(»)==False ).

Весь перечень настроек для разворачивания вашего сайта находится по ссылке Deployment checklist (Django docs). Кроме того, вы можете получить список настроек, выполнив в терминале команду:

Пример: Установка LocalLibrary на Heroku

Данный раздел предоставляет демонстрацию того, как установить LocalLibrary на Heroku PaaS cloud.

Почему Heroku?

Heroku — один из самых продолжительных и популярных облачных сервисов PaaS. Первоначально он поддерживал только приложения Ruby, но теперь его можно использовать для размещения приложений из многих сред программирования, включая Django!

Мы выбираем для использования Heroku по нескольким причинам:

• У Heroku есть свободный уровень, который действительно свободен (хотя и с некоторыми ограничениями)
• Как PaaS, Heroku заботится о большой веб-инфраструктуре для нас. Это значительно облегчает работу, потому что вы не беспокоитесь о серверах, балансирах нагрузки, обратных прокси или любой другой веб-инфраструктуре, которую Heroku предоставляет нам под капотом.
• Хотя у этого есть некоторые ограничения, это не повлияет на это конкретное приложение. Например:
  • Heroku предоставляет только недолговечное хранилище, поэтому загруженные пользователем файлы нельзя безопасно хранить на самом Heroku.
  • Свободный уровень будет спать с неактивным веб-приложением, если в течение получаса не будет запросов.После этого сайт может занять несколько секунд, чтобы ответить, когда он проснулся.
  • Свободный уровень ограничивает время, в течение которого ваш сайт работает до определённого количества часов каждый месяц (не включая время, когда сайт «спит»).Это нормально для сайта с низким уровнем использования / демонстрации, но не подходит, если требуется 100% время безотказной работы.
  • Другие ограничения перечислены в Limits (документы Heroku).

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

  Как работает Heroku?

  Heroku запускает сайты Django внутри одного, или более, изолированных друг от друга «Dynos», которые являются виртуальными Unix-контейнерами, предоставляющими необходимое окружение для вашего приложения. Данные dynos полностью изолированы и имеют эфемерную файловую систему («короткоживущая» файловая система, которая полностью очищается и обновляется каждый раз, когда dyno перезапускается). Единственной сущностью, которую предоставляет dynos по умолчанию, является приложение по конфигурации переменных. Heroku внутри себя применяет балансировщик загрузки для распределения веб-трафика среди всех «веб»-dynos. Поскольку dynos изолированы, Heroku может масштабировать приложение горизонтально, просто добавляя больше dynos (хотя, конечно, у вас может появиться необходимость расширить базу данных для обработки дополнительных соединений).

  Файловая система эфемерна, поэтому вы не можете напрямую установить необходимые для вашего приложения сервисы (то есть, базы данных, очереди, системы кеширования, хранения, сервисы электронной почты и так далее). Взамен этого, Heroku предоставляет сервисы, доступные как независимые «дополнения» («add-ons») либо от самой Heroku, или от сторонних разработчиков. В тот момент когда ваше приложение запускается в системе, dynos получает доступ к сервисам, используя информацию, содержащуюся в переменных настройки вашего приложения.

  Для того, чтобы выполнить ваше приложение Heroku необходимо иметь возможность установить соответствующее окружение и зависимости, а также понимать как его (приложение) запустить. В случае приложений Django мы предоставляем соответствующую информацию в нескольких текстовых файлах:

  • runtime.txt: язык программирования и его версию.
  • requirements.txt: необходимые для Python компоненты, включая Django.
  • Procfile: Список процессов, которые будут выполнены для старта веб-приложения. Для Django это обычно сервер веб-приложений Gunicorn (скрипт .wsgi ).
  • wsgi.py: конфигурация WSGI для вызова нашего приложения Django в окружении Heroku.

  Разработчики Developers взаимодействуют с Heroku при помощи специального клиентского приложения/терминала, который сильно похож на bash-скрипт Unix. Оно позволяет вам загружать код, находящийся в git-репозитории, контроллировать выполняемые процессы, смотреть логи, устанавливать конфигурационные переменные и многое другое!

  Для того, чтобы заставить ваше приложение работать с Heroku, нам нужно разместить наше веб-приложение в git-репозитории, добавить, перечисленные ранее, файлы, подключить дополнение (add-on) базы данных и выполнить настройки для правильной работы со статическими файлами.

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

  Примечание: Инструкции, перечисленные ниже, соответствуют процессу работы с Heroku во время написания данной статьи (английской версии — прим. перев.). Если Heroku значительно изменит этот процесс, вы можете воспользоваться соответствующим описанием: Heroku начало работы с Django.

  На этом завершается краткий обзор начала работы с Heroku (более подробное руководство Как работает Heroku).

  Создание репозитория приложения на Github

  Heroku тесно интегрирована с системой управления версиями исходного кода git, используя её для загрузки / синхронизации любых изменений, которые вы вносите в живую систему. Он делает это, добавляя новый «удалённый» репозиторий heroku с именем heroku, указывающий на репозиторий для вашего источника в облаке Heroku. Во время разработки вы используете git для хранения изменений в вашем «master» репозитории. Когда вы хотите развернуть свой сайт, вы синхронизируете свои изменения в репозитории Heroku.

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

  Существует множество способов работы с git, но одним из самых простых является создание учётной записи в Github, создание репозитория там, а затем синхронизация с ним локально:

  1. Посетите https://github.com/ и создайте аккаунт.
  2. После входа в систему нажмите ссылку + в верхней панели инструментов и выберите Новый репозиторий.
  3. Заполните все поля на этой форме. Хотя они не являются обязательными, они настоятельно рекомендуются.
     • Введите имя нового репозитория (например django_local_library), и комментарий к репозиторию (например «Local Library website written in Django».
     • Нажмите на кнопку Add .gitignore и в появившемся списке выберите Python.
     • Выберите подходящую вам лицензию из списка Add license. Если не знаете для чего это — оставьте как было.
     • Установите галочку напротив Initialize this repository with a README.
  4. Нажмите кнопку Create repository, тем самым создав ваш репозиторий.
  5. Перейдите на страницу вашего репозитория. Там нажмите на зелёную кнопку Clone or download. Скопируйте URL из текстового поля из появившегося диалогового окна (Это будет похоже на: https://github.com/<your_git_user_id>/django_local_library.git ). Здесь <your_git_user_id> — это будет ваш id пользователя git.

  Когда ваш репозиторий будет создан — загрузите его себе на компьютер, следуя инструкции, описанной ниже:

  1. Установите git себе на компьютер (Вы можете найти версию для своей платформы здесь).
  2. Откройте командную строку (или терминал) и выполните в нём следующую команду, используя ссылку, которую вы получили с github:

  Последний шаг. Нужно скопировать ваше Django-приложение и добавить его файлы в новый репозиторий, используя git:

  1. Скопируйте ваше приложение в папку репозитория (все файлы с таким же уровнем, как у manage.py, БЕЗ папки проекта, в которой эти файлы находятся).
  2. Откройте файл с расширением .gitignore в текстовом редакторе, вставьте в самый его конец строки, приведённые ниже, а затем сохраните (этот файл «говорит» о файлах, которые не должны быть загружены в git по умолчанию).
  3. Откройте командную строку или терминал и используйте add команду с флагом -A . Эта команда сохранит изменения в репозиторий:

  Когда эти операции завершатся, вернитесь на страницу Github где вы создали свой репозиторий, обновите страницу, и убедитесь, что ваше приложение полностью загружено. При надобности обновить файлы на репозитории — повторите цикл ввода команд add/commit/push.

  Примечание: Это хороший момент для создания резервной копии вашего «ванильного» проекта — в то время как некоторые изменения, которые мы собираемся сделать в следующих разделах, могут быть полезны для развёртывания на любой платформе (или разработке), которые другие могут не использовать.

  Лучший способ сделать это — использовать git для управления вашими изменениями. С git вы можете не только вернуться к определённой старой версии, но и сохранить её в отдельной «ветке» ваших производственных изменений, and cherry-pick — выбрать любые изменения для перемещения между ветвями производства и развития. Изучение Git будет стоить усилий, но это выходит за рамки данной темы. Самый простой способ сделать это — просто скопировать файлы в другое место. Используйте тот подход, который наилучшим образом соответствует вашим знаниям git!

  Обновить приложение для Heroku

  В этой части говорится об изменениях, которые мы должны сделать на нашем приложении LocalLibrary, что бы оно работало на Heroku. В то время как документация «начало работы с Heroku с инструкциями Django» предполагает, что вы будете использовать Heroku client для запуска локальной среды разработки, наши изменения здесь совместимы с существующим сервером разработки Django и способами работы, которые мы уже узнали.

  Procfile

  Создайте файл с именем Procfile (без расширения) в корне нашего GitHub репозитории объявить типы процессов и точки входа приложения. Скопируйте в него следующий текст:

  «web:» сообщает Heroku, что это веб динамический и может быть отправлен HTTP-трафик. Процесс, который начнётся в этом динамически, — это gunicorn, который является популярным сервером веб-приложений, который рекомендует Heroku. Мы запускаем Gunicorn, используя конфигурационную информацию в модуле locallibrary.wsgi (созданный с помощью нашего скелета приложения: /locallibrary/wsgi.py).

  Gunicorn

  Gunicorn рекомендуемый http сервер с Django на Heroku (Как указано в Procfile выше). Это чистый python http сервер для WSGI приложений которые могут запускать множество параллельных python процессов в пределах одного динамического (посмотрите Deploying Python applications with Gunicorn для получения большей информации).

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

  Установка Gunicorn локально в командной строке используя пакетный менеджер pip (которые мы установили когда настраивали среду разработки):

  Настройка Базы Данных

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

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

  Информация о подключении базы данных предоставляется на web dyno, используя конфигурационную переменную с именем DATABASE_URL . Вместо того, чтобы жёстко кодировать эту информацию в Django, Heroku рекомендует разработчикам использовать dj-database-url пакет для анализа DATABASE_URL переменную окружения и автоматически преобразовать её в желаемый формат конфигурации Django. В дополнение к установке пакета dj-database-url нам также потребуется установить psycopg2, поскольку Django нуждается в этом, чтобы взаимодействовать с базами данных Postgres.

  dj-database-url (Django конфигурации базы данных из переменной окружения)

  Установите dj-database-url локально, чтобы он стал частью наших требований к настройке Heroku на удалённом сервере:

  settings.py

  Откройте /locallibrary/settings.py и скопируйте следующую конфигурацию в нижнюю часть файла:

  Примечание:

  • Мы все ещё будем использовать SQLite во время разработки, поскольку DATABASE_URL переменная среды не будет установлена на нашем компьютере разработки.
  • Значение conn_max_age=500 делает соединение постоянным, что намного эффективнее, чем воссоздавать соединение в каждом цикле запросов. Однако это необязательно и при необходимости можно удалить.

  psycopg2 (Python Postgres database support)

  Django нуждается в psycopg2 для работы с базами данных Postgres, и вам нужно будет добавить это в файл требований.txt для Heroku, чтобы установить это на удалённом сервере (как описано в разделе требований ниже).

  Django будет использовать нашу базу данных SQLite локально по умолчанию, поскольку переменная среды DATABASE_URL не задана в нашей локальной среде. Если вы хотите полностью перейти на Postgres и использовать нашу бесплатную базу данных Heroku для разработки и производства, то вы можете. Например, чтобы установить psycopg2 и его зависимости локально в системе на базе Linux, вы должны использовать следующие команды bash / terminal:

  Инструкции по установке для других платформ можно найти на веб-сайте psycopg2.

  Однако вам не нужно это делать — вам не нужно, чтобы PostGreSQL был активным на локальном компьютере, если вы передаёте его в Heroku в качестве требования в файле требований.txt (см. Ниже).

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

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

  Примечание: Обслуживание статических файлов через Django / веб-приложение неэффективно, потому что запросы должны проходить через ненужный дополнительный код (Django), а не обрабатываться непосредственно веб-сервером или полностью отдельным CDN. Хотя это не имеет значения для местного использования во время разработки, это будет иметь значительное влияние на производительность, если мы будем использовать тот же подход в производстве.

  Чтобы упростить размещение статических файлов отдельно от веб-приложения Django, Django предоставляет средство сбора данных для сбора этих файлов для развёртывания (имеется переменная параметров, определяющая, где файлы должны собираться при запуске collectstatic). Шаблоны Django относятся к месту размещения статических файлов относительно переменной параметров (STATIC_URL), так что это можно изменить, если статические файлы перемещаются на другой хост / сервер.

  Соответствующими параметрами настройки являются:

  STATIC_URL: это базовое расположение URL, из которого будут загружены статические файлы, например, на CDN. Это используется для переменной статического шаблона, доступ к которой осуществляется в нашем базовом шаблоне (см. Учебник по Django Part 5: Создание нашей домашней страницы). STATIC_ROOT: Это абсолютный путь к каталогу, в котором инструмент «collectstatic» Django будет собирать любые статические файлы, упомянутые в наших шаблонах. После их сбора они затем могут быть загружены в группу, где бы файлы не размещались. STATICFILES_DIRS: В этом списке перечислены дополнительные каталоги, в которых инструмент коллективного поиска Django должен искать статические файлы.

  settings.py

  Откройте /locallibrary/settings.py и скопируйте следующую конфигурацию в нижнюю часть файла. BASE_DIR уже должен быть определён в вашем файле (STATIC_URL, возможно, уже был определён в файле, когда он был создан. В то время как это не причинит вреда, вы также можете удалить дублируемую предыдущую ссылку).

  Фактически мы будем делать файл, используя библиотеку WhiteNoise, которую мы устанавливаем и настраиваем в следующем разделе.

  Для получения дополнительной информации см. Django и Static Assets (документы Heroku).

  WhiteNoise Существует множество способов обслуживания статических файлов на производстве (мы видели соответствующие настройки Django в предыдущих разделах). Heroku рекомендует использовать проект WhiteNoise для обслуживания статических активов непосредственно из Gunicorn в производстве.

  Примечание: Heroku автоматически вызывает collectstatic и готовит ваши статические файлы для использования WhiteNoise после того, как он загрузит ваше приложение. Посмотрите WhiteNoise документацию для объяснения того, как она работает, и почему реализация является относительно эффективным методом для обслуживания этих файлов.

  Шаги по настройке WhiteNoise для использования в проекте:

  WhiteNoise

  Установите WhiteNoise локально, используя следующую команду:

  settings.py

  Чтобы установить WhiteNoise в приложение Django, откройте /locallibrary/settings.py, найдите параметр MIDDLEWARE и добавьте WhiteNoiseMiddleware в верхней части списка, чуть ниже SecurityMiddleware:

  При желании вы можете уменьшить размер статических файлов при их обслуживании (это более эффективно). Просто добавьте следующее в конец /locallibrary/settings.py:

  Requirements

  Требования Python вашего веб-приложения должны храниться в файле requirements.txt в корневом каталоге вашего репозитория. После этого Heroku автоматически установит их при восстановлении вашей среды. Вы можете создать этот файл с помощью pip в командной строке (запустите в корне repo):

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

  Примечание: Убедитесь, что строка psycopg2, подобная приведённой выше, присутствует! Даже если вы не установили это локально, вы должны добавить это в requirements.txt.

  Среда выполнения

  Файл runtime.txt, если определён, говорит Heroku, какой язык программирования использовать. Создайте файл в корне репо и добавьте следующий текст:

  Примечание: Heroku поддерживает только небольшое количество Python runtimes. (на момент написания статьи, в том числе и выше). Heroku будет использовать поддерживаемую среду выполнения независимо от значения, указанного в этом файле.

  Сохраните изменения в Github и перепроверьте

  Далее мы сохраним все наши изменения в Github. В терминале (whist внутри нашего репозитория) введите следующие команды:

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

  Теперь мы должны быть готовы начать развёртывание LocalLibrary на Heroku.

  Получить аккаунт в heroku

  Чтобы начать использовать Heroku, вам сначала нужно создать учётную запись:

  • Перейдите www.heroku.com и нажмите SIGN UP FOR FREE кнопку.
  • Введите ваши данные, а затем нажмите CREATE FREE ACCOUNT. Вам будет предложено проверить свою учётную запись по адресу электронной почты для регистрации.
  • Нажмите ссылку активации учётной записи в электронной почте для регистрации. Вы вернётесь в свою учётную запись в веб-браузере.
  • Введите свой пароль и нажмите SET PASSWORD AND LOGIN.
  • Затем вы войдёте в систему и попадёте в приборную панель Heroku: https://dashboard.heroku.com/apps.

  Установка клиента

  Загрузите и установите клиент Heroku, следуя инструкциям Heroku здесь.

  После установки клиента вам будут доступны команды. Например, чтобы получить справку о клиенте:

  Создание и загрузка веб-сайта

  Чтобы создать приложение, мы запускаем команду «create» в корневом каталоге нашего репозитория. Это создаёт git remote («указатель на удалённый репозиторий»), названный heroku в нашей локальной среде git.

  Примечание: вы можете назвать удалённый, если хотите, указав значение после «create». Если вы этого не сделаете, вы получите случайное имя. Имя используется в URL-адресе по умолчанию.

  Затем мы можем подтолкнуть наше приложение в репозиторий heroku как показано ниже. Это позволит загрузить приложение, упаковать его в dyno, запустить collectstatic, и запустить сам сайт.

  Если нам повезёт, приложение «заработает» на сайте, но оно не будет работать должным образом, потому что мы не настроили таблицы базы данных для использования нашим приложением. Для этого нам нужно использовать команду heroku run и запустить «one off dyno» для выполнения операции переноса. Введите в терминал следующую команду:

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

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

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

  Управление аддонами

  Вы можете проверить дополнения в своём приложении, используя heroku addons команду. Это будет список всех аддонов, их ценовая категория и состояние.

  Здесь мы видим, что у нас есть только одна надстройка, база данных postgres SQL. Это бесплатно и автоматически создаётся при создании приложения. Вы можете открыть веб-страницу, чтобы более подробно изучить надстройку базы данных (или любое другое дополнение), используя следующую команду:

  Другие команды позволяют создавать, уничтожать, обновлять и понижать аддоны (используя аналогичный синтаксис для открытия). Для получения дополнительной информации см. Managing Add-ons (Heroku docs).

  Настройка переменных конфигурации

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

  Если вы вспомните из раздела, посвящённого getting the website ready to publish, мы должны установить переменные среды для DJANGO_SECRET_KEY и DJANGO_DEBUG . Давайте сделаем это сейчас.

  Примечание: Секретный ключ должен быть действительно секретным! Один из способов генерации нового ключа — создать новый проект Django ( django-admin startproject someprojectname ) а затем получить ключ, который генерируется для вас в его settings.py.

  Мы устанавливаем DJANGO_SECRET_KEY используя команду config:set (как показано ниже). Не забудьте использовать свой секретный ключ!

  Аналогично мы устанавливаем DJANGO_DEBUG :

  Если вы посетите веб-сайт сейчас, вы получите ошибку «Bad request» , потому что в ALLOWED_HOSTS надо внести параметры, если у вас DEBUG=False (в качестве меры безопасности). Откройте /locallibrary/settings.py и измените ALLOWED_HOSTS для включения вашего базового URL-адреса приложения (например, ‘locallibrary1234.herokuapp.com’) URL, который вы обычно используете на локальном сервере разработки.

  Затем сохраните настройки и передайте их в репозиторий Github и в Heroku:

  Примечание: После завершения обновления сайта на Heroku введите URL-адрес, который не существует (например, /catalog/doesnotexist/). Раньше это отображало бы подробную страницу отладки, но теперь вы должны просто увидеть простую страницу «Не найдено».

  Отладка

  Клиент Heroku предоставляет несколько инструментов для отладки:

  Если вам нужно больше информации, предоставленной здесь, вам нужно будет начать изучать Django Logging.

  Итоги

  Это конец этого руководства по настройке и развёртывании приложений Django, а также серия руководств по работе с Django. Надеемся, вы нашли их полезными. Вы можете проверить полностью проработанную версию по исходникам на Github. Следующий шаг — прочитать наши последние несколько статей, а затем завершить оценочную задачу.

  Читать:

  Что спрашивают на собеседовании c