path: root/files/ru/learn/server-side/django/deployment/index.html

---
title: 'Django Руководство часть 11: Разворачивание сайта на сервере'
slug: Learn/Server-side/Django/Deployment
tags:
  - Веб-сервер
  - Для начинающих
  - Разворачивание на сервере
  - Развёртывание Django
translation_of: Learn/Server-side/Django/Deployment
original_slug: Learn/Server-side/Django/Разворачивание
---
<div>{{LearnSidebar}}</div>

<div>{{PreviousMenuNext("Learn/Server-side/Django/Testing", "Learn/Server-side/Django/web_application_security", "Learn/Server-side/Django")}}</div>

<p class="summary">Теперь, когда вы создали (и протестировали) свой шикарный сайт <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">LocalLibrary</a>, у вас скорее всего, есть желание разместить его на публичном веб-сервере, чтобы он стал доступен через интернет персоналу  и посетителям библиотеки. Данная статья даёт общее представление о том, каким образом подойти к поиску хостинга для размещения сайта, а также, что нужно сделать чтобы подготовить свой сайт к публикации.</p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">Требования:</th>
   <td>Завершить изучение всех предыдущих частей руководства, включая <a href="/en-US/docs/Learn/Server-side/Django/Testing">Django Руководство часть 10:  Тестирование веб-приложений в Django</a>.</td>
  </tr>
  <tr>
   <th scope="row">Цель:</th>
   <td>Изучить, где и как вы можете развернуть приложение Django для публичного доступа.</td>
  </tr>
 </tbody>
</table>

<h2 id="Обзор">Обзор</h2>

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

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

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

<p>Данное руководство предоставляет небольшой обзор выбора хостинга, приготовления сайта к публичному размещению, а также практический пример установки сайта LocalLibrary на облачный сервис <a href="https://www.heroku.com/">Heroku</a>.</p>

<h2 id="Что_такое_окружение_развёртывания">Что такое окружение развёртывания?</h2>

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

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

<div class="note">
<p><strong>Примечание</strong>: У вас может быть потребность в обратном прокси, балансировщике загрузки и так далее.</p>
</div>

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

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

<div class="note">
<p><strong>Примечание:</strong> Готовые окружения могут сделать настройку вашего веб-сайта очень простой задачей, поскольку они имеют минимальную конфигурацию, однако, либо количество доступных опций может быть недостаточным, или они будут соответствовать устаревшей операционной системе. Часто, более предпочтительно установить необходимые компоненты самостоятельно, таким образом вы получите то, что вам необходимо, а в последующем, при обновлении системы, уже будете знать что нужно делать!</p>
</div>

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

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

<div class="note">
<p><strong>Примечание:</strong> Если вы выбираете хостинг с поддержкой Python/Django, то он должен иметь инструкцию по установке веб-сайта Django, учитывающую различные конфигурации веб-сервера, сервера приложений, обратного прокси и так далее (это не имеет значение, если вы выбрали PaaS). Например, существует множество инструкций "шаг-за-шагом" для различный конфигураций в <a href="https://www.digitalocean.com/community/tutorials?q=django">Документации DigitalOcean по Django</a>.</p>
</div>

<h2 id="Выбор_хостинг_провайдера">Выбор хостинг провайдера</h2>

<p>Существует более 100 хорошо известных хостинг провайдеров, которые либо активно поддерживают, или работают с Django (их список можно увидеть в <a href="https://djangofriendly.com/index.html">Django-дружественные хостинги</a>). Данные поставщики предоставляют различные типы окружений (IaaS, PaaS), и различные уровни доступа к вычислительным и сетевым ресурсам, за разную цену.</p>

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

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

<p>Хорошей новостью является то, что для того, чтобы начать существует достаточное количество компаний, которые предоставляют пробные "бесплатные" тарифы типа "evaluation" (для пробы), "developer" (разработка), или "hobbyist" (хобби). Всегда существуют ресурсы с ограниченным окружением, при использовании которых вам надо беспокоиться лишь о том, что они могут быть доступны лишь в течении определённого периода времени. Тем не менее, они являются отличным решением для тестирования сайтов с небольшим трафиком в реальном окружении, а также могут предоставлять простой доступ к платным ресурсам, в случае необходимости. Наиболее популярными провайдерами являются <a href="https://www.heroku.com/">Heroku</a>, <a href="https://www.pythonanywhere.com/">Python Anywhere</a>, <a href="http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-free-tier.html">Amazon Web Services</a>, <a href="https://azure.microsoft.com/en-us/pricing/details/app-service/">Microsoft Azure</a> и так далее.</p>

<p>Многие провайдеры имеют "basic" (базовый) тариф, предоставляющий достаточный уровень вычислительной мощности с небольшим количеством ограничений. <a href="https://www.digitalocean.com/">Digital Ocean</a> и <a href="https://www.pythonanywhere.com/">Python Anywhere</a> являются примерами провайдеров, которые предлагают относительно недорогой базовый тариф (от $5 до $10USD в месяц).</p>

<div class="note">
<p><strong>Примечание:</strong> Необходимо помнить, что цена не является единственным критерием выбора. Если ваш сайт успешен, то может так случиться, что масштабирование станет самым важным элементом вашего внимания при выборе услуг хостинга.</p>
</div>

<h2 id="Подготовка_веб-сайта_к_публикации">Подготовка веб-сайта к публикации</h2>

<p><a href="/en-US/docs/Learn/Server-side/Django/skeleton_website">Скелет сайта</a> был создан при помощи инструментов <em>django-admin</em> и <em>manage.py</em>, которые настроены таким образом, чтобы сделать разработку проще. Многие настройки файла проекта (определённых в <strong>settings.py</strong>) должны быть изменены перед публикацией сайта, либо из-за вопросов безопасности, либо производительности.</p>

<div class="note">
<p><strong>Примечание:</strong> Общепринятым решением является иметь отдельный файл <strong>settings.py</strong> для публикации, который импортирует важные настройки из внешних файлов, или из переменных окружения. Доступ к данному файлу должен быть ограничен, даже если остальная часть исходного кода доступна в публичном репозитории.</p>
</div>

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

<ul>
 <li><code>DEBUG</code>. При развёртывании сайта должен быть установлен в <code>False</code> (<code>DEBUG = False</code>). Тем самым, прекратится вывод  важной отладочной информации.</li>
 <li><code>SECRET_KEY</code>. Это большое случайное число, применяемое для защиты от CRSF. Важно, чтобы ключ, используемый в продакшене, не указывался в исходном коде, и/или не запрашивался с другого сервера. Django рекомендует размещать значение ключа либо в переменной окружения, или в файле с доступом только на чтение.
  <pre># Чтение SECRET_KEY из переменной окружения
import os
SECRET_KEY = os.environ['SECRET_KEY']

#ИЛИ

#Чтение ключа из файла
with open('/etc/secret_key.txt') as f:
    SECRET_KEY = f.read().strip()</pre>
 </li>
</ul>

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

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

<pre class="brush: python"># SECURITY WARNING: keep the secret key used in production secret!
# SECRET_KEY = 'cg#p$g+j9tax!#a3cup@1$8obt2_+&amp;k3q+pmu)5%asj6yjpkag'
<strong>import os</strong>
<strong>SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', 'cg#p$g+j9tax!#a3cup@1$8obt2_+&amp;k3q+pmu)5%asj6yjpkag')</strong>
</pre>

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

<pre class="brush: python"># SECURITY WARNING: don't run with debug turned on in production!
# DEBUG = True
<strong>DEBUG = bool( os.environ.get('DJANGO_DEBUG', True) )</strong>
</pre>

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

<div class="note">
<p><strong>Примечание</strong>: Было бы более понятным, если бы мы могли просто установить и снять с  <code>DJANGO_DEBUG</code> непосредственно на <code>True</code> и <code>False</code> , напрямую, а не использовать «любую строку» или «пустую строку» (соответственно). К сожалению, значения переменных среды хранятся как строки Python и единственная строка, которая оценивается как <code>False</code> является пустой строкой (например, <code>bool('')==False</code>).</p>
</div>

<p>Весь перечень настроек для разворачивания вашего сайта находится по ссылке <a href="https://docs.djangoproject.com/en/1.10/howto/deployment/checklist/">Deployment checklist</a> (Django docs). Кроме того, вы можете получить список настроек, выполнив в терминале команду:</p>

<pre class="brush: python">python3 manage.py check --deploy
</pre>

<h2 id="Пример_Установка_LocalLibrary_на_Heroku">Пример: Установка LocalLibrary на Heroku</h2>

<p>Данный раздел предоставляет демонстрацию того, как установить <em>LocalLibrary</em> на <a href="http://heroku.com">Heroku PaaS cloud</a>.</p>

<h3 id="Почему_Heroku">Почему Heroku?</h3>

<p><span id="result_box" lang="ru"><span>Heroku - один из самых продолжительных и популярных облачных сервисов PaaS.</span> <span>Первоначально он поддерживал только приложения Ruby, но теперь его можно использовать для размещения приложений из многих сред программирования, включая Django!</span></span></p>

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

<ul>
 <li><span id="result_box" lang="ru"><span>У Heroku есть <a href="https://www.heroku.com/pricing">свободный уровень</a>, который <em>действительно</em> свободен (хотя и с некоторыми ограничениями)</span></span></li>
 <li><span id="result_box" lang="ru"><span title="As a PaaS, Heroku takes care of a lot of the web infrastructure for us.">Как PaaS, Heroku заботится о большой веб-инфраструктуре для нас. </span><span title="This makes it much easier to get started, because you don't worry about servers, load balancers, reverse proxies, or any of the other web infrastructure that Heroku provides for us under the hood.
    ">Это значительно облегчает работу, потому что вы не беспокоитесь о серверах, балансирах нагрузки, обратных прокси или любой другой веб-инфраструктуре, которую Heroku предоставляет нам под капотом.</span></span></li>
 <li><span id="result_box" lang="ru"><span title="While it does have some limitations these will not affect this particular application.">Хотя у этого есть некоторые ограничения, это не повлияет на это конкретное приложение. </span><span title="For example:
        ">Например:</span></span>
  <ul>
   <li><span id="result_box" lang="ru"><span title="Heroku provides only short-lived storage so user-uploaded files cannot safely be stored on Heroku itself.
        ">Heroku предоставляет только недолговечное хранилище, поэтому загруженные пользователем файлы нельзя безопасно хранить на самом Heroku.</span></span></li>
   <li><span id="result_box" lang="ru"><span title="The free tier will sleep an inactive web app if there are no requests within a half hour period.">Свободный уровень будет спать с неактивным веб-приложением, если в течение получаса не будет запросов. </span><span title="The site may then take several seconds to respond when it is woken up.
        ">После этого сайт может занять несколько секунд, чтобы ответить, когда он проснулся.</span></span></li>
   <li><span id="result_box" lang="ru"><span title='The free tier limits the time that your site is running to a certain amount of hours every month (not including the time that the site is "asleep").'>Свободный уровень ограничивает время, в течение которого ваш сайт работает до определённого количества часов каждый месяц (не включая время, когда сайт «спит»). </span><span title="This is fine for a low use/demonstration site, but will not be suitable if 100% uptime is required.
        ">Это нормально для сайта с низким уровнем использования / демонстрации, но не подходит, если требуется 100% время безотказной работы.</span></span></li>
   <li>Другие ограничения перечислены в <a href="https://devcenter.heroku.com/articles/limits">Limits</a> (документы Heroku).</li>
  </ul>
 </li>
 <li><span id="result_box" lang="ru"><span title="Mostly it just works, and if you end up loving it, scaling your app is very easy.

">В основном это просто работает, и если вы в конечном итоге полюбите его, масштабирование вашего приложения будет очень простым.</span></span></li>
</ul>

<p><span id="result_box" lang="ru"><span title="While Heroku is perfect for hosting this demonstration it may not be perfect for your real website.">Хотя Heroku идеально подходит для проведения этой демонстрации, она может быть не идеальна для вашего реального сайта. </span><span title="Heroku makes things easy to set up and scale, at the cost of being less flexible, and potentially a lot more expensive once you get out of the free tier.">Heroku упрощает настройку и масштабирование за счёт меньшей гибкости и, возможно, обойдётся намного дороже, когда вы выходите из свободного уровня.</span></span></p>

<h3 id="Как_работает_Heroku">Как работает Heroku?</h3>

<p>Heroku запускает сайты Django внутри одного, или более,  изолированных друг от друга "<a href="https://devcenter.heroku.com/articles/dynos">Dynos</a>", которые являются виртуальными Unix-контейнерами, предоставляющими необходимое окружение для вашего приложения. Данные dynos полностью изолированы и имеют <em>эфемерную</em> файловую систему ("короткоживущая" файловая система, которая полностью очищается и обновляется каждый раз, когда dyno перезапускается). Единственной сущностью, которую предоставляет dynos по умолчанию, является приложение по <a href="https://devcenter.heroku.com/articles/config-vars">конфигурации переменных</a>. Heroku внутри себя применяет балансировщик загрузки для распределения веб-трафика среди всех "веб"-dynos. Поскольку dynos изолированы, Heroku может масштабировать приложение горизонтально, просто добавляя больше dynos (хотя, конечно, у вас может появиться необходимость расширить базу данных для обработки дополнительных соединений).</p>

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

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

<ul>
 <li><strong>runtime.txt</strong>:<strong> </strong>язык программирования и его версию.</li>
 <li><strong>requirements.txt</strong>: необходимые для Python компоненты, включая Django.</li>
 <li><strong>Procfile</strong>: Список процессов, которые будут выполнены для старта веб-приложения. Для Django это обычно сервер веб-приложений Gunicorn (скрипт <code>.wsgi</code>).</li>
 <li><strong>wsgi.py</strong>: конфигурация <a href="http://wsgi.readthedocs.io/en/latest/what.html">WSGI</a> для вызова нашего приложения Django в окружении Heroku.</li>
</ul>

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

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

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

<div class="note">
<p><strong>Примечание:</strong> Инструкции, перечисленные ниже, соответствуют процессу работы с Heroku во время написания данной статьи (английской версии - прим. перев.). Если Heroku значительно изменит этот процесс, вы можете воспользоваться соответствующим описанием: <a href="https://devcenter.heroku.com/articles/getting-started-with-python#introduction">Heroku начало работы с Django</a>.</p>
</div>

<p>На этом завершается краткий обзор начала работы с Heroku (более подробное руководство <a href="https://devcenter.heroku.com/articles/how-heroku-works">Как работает Heroku</a>).</p>

<h3 id="Создание_репозитория_приложения_на_Github">Создание репозитория приложения на Github</h3>

<p><span id="result_box" lang="ru"><span>Heroku тесно интегрирована с системой управления версиями исходного кода <strong>git</strong>, используя её для загрузки / синхронизации любых изменений, которые вы вносите в живую систему.</span> <span>Он делает это, добавляя новый «удалённый» репозиторий heroku с именем heroku, указывающий на репозиторий для вашего источника в облаке Heroku.</span> <span>Во время разработки вы используете <strong>git</strong> для хранения изменений в вашем «master» репозитории.</span> <span>Когда вы хотите развернуть свой сайт, вы синхронизируете свои изменения в репозитории Heroku.</span></span></p>

<div class="note">
<p><strong>Примечание:</strong> <span id="result_box" lang="ru"><span>Если вы привыкли следовать хорошей практике разработки программного обеспечения, вы, вероятно, уже используете git или какую-либо другую систему SCM.</span> <span>Если у вас уже есть git-репозиторий, вы можете пропустить этот шаг.</span></span></p>
</div>

<p><span id="result_box" lang="ru"><span>Существует множество способов работы с git, но одним из самых простых является создание учётной записи в <a href="https://github.com/">Github</a>, создание репозитория там, а затем синхронизация с ним локально:</span></span></p>

<ol>
 <li>Посетите <a href="https://github.com/">https://github.com/</a> и создайте аккаунт.</li>
 <li>После входа в систему нажмите ссылку + в верхней панели инструментов и выберите <strong>Новый репозиторий</strong>.</li>
 <li>Заполните все поля на этой форме. Хотя они не являются обязательными, они настоятельно рекомендуются.
  <ul>
   <li>Введите имя нового репозитория (например <em>django_local_library</em>), и комментарий к репозиторию (например "Local Library website written in Django".</li>
   <li>Нажмите на кнопку<em> <strong>Add .</strong></em><strong>gitignore </strong>и в появившемся списке выберите <strong>Python</strong>.</li>
   <li>Выберите подходящую вам лицензию из списка <em><strong>Add license. </strong></em>Если не знаете для чего это - оставьте как было.</li>
   <li>
    <p>Установите галочку напротив <em><strong>Initialize this repository with a README</strong>.</em></p>
   </li>
  </ul>
 </li>
 <li>Нажмите кнопку <strong>Create repository</strong>, тем самым создав ваш репозиторий.</li>
 <li>Перейдите на страницу вашего репозитория. Там нажмите на зелёную кнопку "<strong>Clone or download</strong>". Скопируйте URL  из текстового поля из появившегося диалогового окна (Это будет похоже на: <strong>https://github.com/<em>&lt;your_git_user_id&gt;</em>/django_local_library.git</strong>). Здесь <strong>&lt;your_git_user_id&gt; </strong>- это будет ваш id пользователя git.</li>
</ol>

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

<ol>
 <li>Установите git себе на компьютер (Вы можете найти версию для своей платформы <a href="https://git-scm.com/downloads">здесь</a>).</li>
 <li>Откройте командную строку (или терминал) и выполните в нём следующую команду, используя ссылку, которую вы получили с github:
  <pre class="brush: bash">git clone https://github.com/<strong><em>&lt;your_git_user_id&gt;</em></strong>/django_local_library.git
</pre>
  Это создаст подпапку (с содержанием вашего репозитория и именем вашего репозитория) внутри папки, в которой выполнялась команда.</li>
 <li>Перейдите в эту папку:
  <pre class="brush: bash">cd django_local_library.git</pre>
 </li>
</ol>

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

<ol>
 <li>Скопируйте ваше приложение в папку репозитория (все файлы с таким же уровнем, как у <strong>manage.py,</strong> <u><strong>БЕЗ </strong>папки проекта, в которой эти файлы находятся</u>).</li>
 <li>Откройте файл с расширением <strong>.gitignore </strong>в текстовом редакторе, вставьте в самый его конец строки, приведённые ниже, а затем сохраните (этот файл "говорит" о файлах, которые не должны быть  загружены в git по умолчанию).
  <pre># Text backup files
*.bak

#Database
*.sqlite3</pre>
 </li>
 <li>
  <p>Откройте командную строку или терминал и используйте <code>add</code> команду с флагом <code>-A</code>. Эта команда сохранит изменения в репозиторий:</p>

  <pre class="brush: bash"><code>git add -A</code></pre>
 </li>
 <li>Используйте команду <code>status</code>,  что бы убедиться, что все файлы, которые вы собираетесь добавить верны (вы хотите включить исходные файлы, а не бинарные файлы, временные файлы и т. д.). В консоль выведется что то вроде этого:
  <pre>&gt; git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD &lt;file&gt;..." to unstage)

        modified:   .gitignore
        new file:   catalog/__init__.py
        ...
        new file:   catalog/migrations/0001_initial.py
        ...
        new file:   templates/registration/password_reset_form.html</pre>
 </li>
 <li>Теперь, зафиксируйте файлы в локальном репозитории:
  <pre class="brush: bash">git commit -m "First version of application moved into github"</pre>
 </li>
 <li>Синхронизируете свой локальный репозиторий с сайтом Github:
  <pre>git push origin master</pre>
 </li>
</ol>

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

<div class="note">
<p><strong>Подсказка:</strong> Это хороший момент для создания резервной копии вашего «ванильного» проекта — в то время как некоторые изменения, которые мы собираемся сделать в следующих разделах, могут быть полезны для развёртывания на любой платформе (или разработке), которые другие могут не использовать.</p>

<p><em>Лучший способ</em> сделать это - использовать <em>git</em> для управления вашими изменениями. С <em>git</em> вы можете не только вернуться к определённой старой версии, но и сохранить её в отдельной «ветке» ваших производственных изменений, and cherry-pick - выбрать любые изменения для перемещения между ветвями производства и развития. <a href="https://help.github.com/articles/good-resources-for-learning-git-and-github/">Изучение Git</a> будет стоить усилий, но это выходит за рамки данной темы. Самый простой способ сделать это - просто скопировать файлы в другое место. Используйте тот подход, который наилучшим образом соответствует вашим знаниям git!</p>
</div>

<h3 id="Обновить_приложение_для_Heroku">Обновить приложение для Heroku </h3>

<p>В этой части говорится об изменениях, которые мы должны сделать на нашем приложении <em>LocalLibrary</em>, что бы оно работало на  Heroku. В то время как документация <a dir="ltr" href="https://devcenter.heroku.com/articles/getting-started-with-python" style="color: green;">"начало работы с Heroku с инструкциями Django"</a> предполагает, что вы будете использовать <a href="https://devcenter.heroku.com/articles/getting-started-with-python#set-up">Heroku client</a> для запуска локальной среды разработки, наши изменения здесь совместимы с существующим сервером разработки Django и способами работы, которые мы уже узнали.</p>

<h4 id="Procfile">Procfile</h4>

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

<pre>web: gunicorn locallibrary.wsgi --log-file -</pre>

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

<h4 id="Gunicorn">Gunicorn</h4>

<p><a href="http://gunicorn.org/">Gunicorn</a> рекомендуемый http сервер с Django на Heroku (Как указано в Procfile выше). Это чистый python http сервер для WSGI приложений  которые могут запускать множество параллельных python процессов в пределах одного динамического (посмотрите <a href="https://devcenter.heroku.com/articles/python-gunicorn">Deploying Python applications with Gunicorn</a> для получения большей информации).</p>

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

<p>Установка <em>Gunicorn</em> локально в командной строке используя пакетный менеджер <em>pip</em> (которые мы установили когда <a href="/en-US/docs/Learn/Server-side/Django/development_environment">настраивали среду разработки</a>):</p>

<pre class="brush: bash">pip3 install gunicorn
</pre>

<h4 id="Настройка_Базы_Данных">Настройка Базы Данных</h4>

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

<p>Механизм Heroku для обработки этой ситуации заключается в использовании <a href="https://elements.heroku.com/addons#data-stores">надстройки базы данных</a> и настройке веб-приложения с использованием информации из <a href="https://devcenter.heroku.com/articles/config-vars">переменной конфигурации среды</a>, установленной надстройкой. Существует множество опций базы данных, но мы будем использовать <a href="https://devcenter.heroku.com/articles/heroku-postgres-plans#plan-tiers">hobby уровень</a> в базе данных <em>postgres Heroku</em>, поскольку это бесплатно, поддерживается Django и автоматически добавляется в наши новые приложения Heroku при использовании бесплатного уровня динамического плана для хобби.</p>

<p>Информация о подключении базы данных предоставляется на web dyno, используя конфигурационную переменную с именем <code>DATABASE_URL</code>. Вместо того, чтобы жёстко кодировать эту информацию в Django, Heroku рекомендует разработчикам использовать <a href="https://warehouse.python.org/project/dj-database-url/">dj-database-url</a> пакет для анализа <code>DATABASE_URL</code> переменную окружения и автоматически преобразовать её в желаемый формат конфигурации Django. В дополнение к установке пакета <em>dj-database-url</em> нам также потребуется установить <a href="http://initd.org/psycopg/">psycopg2</a>, поскольку Django нуждается в этом, чтобы взаимодействовать с базами данных Postgres.</p>

<h5 id="dj-database-url_Django_конфигурации_базы_данных_из_переменной_окружения">dj-database-url (Django конфигурации базы данных из переменной окружения)</h5>

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

<pre>$ pip3 install dj-database-url
</pre>

<h5 id="settings.py">settings.py</h5>

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

<pre># Heroku: Update database configuration from $DATABASE_URL.
import dj_database_url
db_from_env = dj_database_url.config(conn_max_age=500)
DATABASES['default'].update(db_from_env)</pre>

<div class="note">
<p><strong>Примечание:</strong></p>

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

<h5 id="psycopg2_Python_Postgres_database_support">psycopg2 (Python Postgres database support)</h5>

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

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

<pre class="brush: bash"><code>sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib</code>
pip3 install psycopg2
</pre>

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

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

<h4 id="Обслуживание_статических_файлов_в_производстве"><strong>Обслуживание статических файлов в производстве</strong></h4>

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

<div class="note">
<p><strong>Примечание. </strong>Обслуживание статических файлов через Django / веб-приложение неэффективно, потому что запросы должны проходить через ненужный дополнительный код (Django), а не обрабатываться непосредственно веб-сервером или полностью отдельным CDN. Хотя это не имеет значения для местного использования во время разработки, это будет иметь значительное влияние на производительность, если мы будем использовать тот же подход в производстве.</p>
</div>

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

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

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

<h5 id="settings.py_2">settings.py</h5>

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

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

# The absolute path to the directory where collectstatic will collect static files for deployment.
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

# The URL to use when referring to static files (where they will be served from)
STATIC_URL = '/static/'
</pre>

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

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

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

<div class="note">
<p><strong>Примечание: </strong>Heroku автоматически вызывает collectstatic и готовит ваши статические файлы для использования WhiteNoise после того, как он загрузит ваше приложение. Посмотрите <a href="https://warehouse.python.org/project/whitenoise/">WhiteNoise</a> документацию для объяснения того, как она работает, и почему реализация является относительно эффективным методом для обслуживания этих файлов.</p>
</div>

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

<h5 id="WhiteNoise">WhiteNoise</h5>

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

<pre>$ pip3 install whitenoise
</pre>

<h5 id="settings.py_3">settings.py</h5>

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

<pre>MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    <strong>'whitenoise.middleware.WhiteNoiseMiddleware',</strong>
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
</pre>

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

<pre># Simplified static file serving.
# https://warehouse.python.org/project/whitenoise/
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
</pre>

<h4 id="Requirements">Requirements</h4>

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

<pre class="brush: bash">pip3 freeze &gt; requirements.txt</pre>

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

<pre>dj-database-url==0.4.1
Django==1.10.2
gunicorn==19.6.0
<strong>psycopg2==2.6.2</strong>
whitenoise==3.2.2
</pre>

<div class="note">
<p>Убедитесь, что строка  <strong>psycopg2</strong>, подобная приведённой выше, присутствует! Даже если вы не установили это локально, вы должны добавить это в <strong>requirements.txt</strong>.</p>
</div>

<h4 id="Среда_выполнения">Среда выполнения</h4>

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

<pre>python-3.5.2</pre>

<div class="note">
<p><strong>Примечание:</strong> Heroku поддерживает только небольшое количество <a href="https://devcenter.heroku.com/articles/python-support#supported-python-runtimes">Python runtimes</a>. (на момент написания статьи, в том числе и выше). Heroku будет использовать поддерживаемую среду выполнения независимо от значения, указанного в этом файле.</p>
</div>

<h4 id="Сохраните_изменения_в_Github_и_перепроверьте">Сохраните изменения в Github и перепроверьте</h4>

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

<pre class="brush: python">git add -A
git commit -m "Added files and changes required for deployment to heroku"
git push origin master</pre>

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

<pre class="brush: bash">python3 manage.py runserver</pre>

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

<h3 id="Получить_аккаунт_в_heroku">Получить аккаунт в heroku</h3>

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

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

<h3 id="Установка_клиента">Установка клиента</h3>

<p>Загрузите и установите клиент Heroku, следуя <a href="https://devcenter.heroku.com/articles/getting-started-with-python#set-up">инструкциям Heroku </a>здесь.</p>

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

<pre class="brush: bash">heroku help
</pre>

<h3 id="Создание_и_загрузка_веб-сайта">Создание и загрузка веб-сайта</h3>

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

<pre class="brush: bash">heroku create</pre>

<div class="note">
<p><strong>Примечание:</strong> вы можете назвать удалённый, если хотите, указав значение после «create». Если вы этого не сделаете, вы получите случайное имя. Имя используется в URL-адресе по умолчанию.</p>
</div>

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

<pre class="brush: bash">git push heroku master</pre>

<p>Если нам повезёт, приложение «заработает» на сайте, но оно не будет работать должным образом, потому что мы не настроили таблицы базы данных для использования нашим приложением. Для этого нам нужно использовать команду  <code>heroku run</code> и запустить "<a href="https://devcenter.heroku.com/articles/deploying-python#one-off-dynos">one off dyno</a>" для выполнения операции переноса. Введите в терминал следующую команду:</p>

<pre class="brush: bash">heroku run python manage.py migrate</pre>

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

<pre class="brush: bash">heroku run python manage.py createsuperuser</pre>

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

<pre class="brush: bash">heroku open</pre>

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

<h3 id="Управление_аддонами">Управление аддонами</h3>

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

<pre class="brush: bash">&gt;heroku addons

Add-on                                     Plan       Price  State
─────────────────────────────────────────  ─────────  ─────  ───────
heroku-postgresql (postgresql-flat-26536)  hobby-dev  free   created
 └─ as DATABASE</pre>

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

<pre class="brush: bash">heroku addons:open heroku-postgresql
</pre>

<p>Другие команды позволяют создавать, уничтожать, обновлять и понижать аддоны (используя аналогичный синтаксис для открытия). Для получения дополнительной информации см.  <a href="https://devcenter.heroku.com/articles/managing-add-ons">Managing Add-ons</a> (Heroku docs).</p>

<h3 id="Настройка_переменных_конфигурации">Настройка переменных конфигурации</h3>

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

<pre class="brush: bash">&gt;heroku config

=== locallibrary Config Vars
DATABASE_URL: postgres://uzfnbcyxidzgrl:j2jkUFDF6OGGqxkgg7Hk3ilbZI@ec2-54-243-201-144.compute-1.amazonaws.com:5432/dbftm4qgh3kda3</pre>

<p>Если вы вспомните из раздела, посвящённого  <a href="#Getting_your_website_ready_to_publish">getting the website ready to publish</a>, мы должны установить переменные среды для <code>DJANGO_SECRET_KEY</code> и <code>DJANGO_DEBUG</code>. Давайте сделаем это сейчас.</p>

<div class="note">
<p><strong>Примечание:</strong> Секретный ключ должен быть действительно секретным! Один из способов генерации нового ключа - создать новый проект Django (<code>django-admin startproject someprojectname</code>) а затем получить ключ, который генерируется для вас в его <strong>settings.py</strong>.</p>
</div>

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

<pre class="brush: bash">&gt;heroku config:set DJANGO_SECRET_KEY=eu09(ilk6@4sfdofb=b_2ht@vad*$ehh9-)3u_83+y%(+phh&amp;=

Setting DJANGO_SECRET_KEY and restarting locallibrary... done, v7
DJANGO_SECRET_KEY: eu09(ilk6@4sfdofb=b_2ht@vad*$ehh9-)3u_83+y%(+phh
</pre>

<p>Аналогично мы устанавливаем  <code>DJANGO_DEBUG</code>:</p>

<pre class="brush: bash">&gt;heroku config:set <code>DJANGO_DEBUG=''

Setting DJANGO_DEBUG and restarting locallibrary... done, v8</code></pre>

<p>Если вы посетите веб-сайт сейчас, вы получите ошибку "Bad request" , потому что в  <a href="https://docs.djangoproject.com/en/1.10/ref/settings/#allowed-hosts">ALLOWED_HOSTS</a> надо внести параметры, если у вас <code>DEBUG=False</code> (в качестве меры безопасности). Откройте <strong>/locallibrary/settings.py</strong> и измените <code>ALLOWED_HOSTS</code> для включения вашего базового URL-адреса приложения (например, 'locallibrary1234.herokuapp.com') URL, который вы обычно используете на локальном сервере разработки.</p>

<pre class="brush: python">ALLOWED_HOSTS = ['&lt;your app URL without the https:// prefix&gt;.herokuapp.com','127.0.0.1']
# For example:
# ALLOWED_HOSTS = ['fathomless-scrubland-30645.herokuapp.com','127.0.0.1']
</pre>

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

<pre class="brush: bash">git add -A
git commit -m 'Update ALLOWED_HOSTS with site and development server URL'
git push origin master
git push heroku master</pre>

<div class="note">
<p>После завершения обновления сайта на Heroku введите URL-адрес, который не существует (например,  <strong>/catalog/doesnotexist/</strong>). Раньше это отображало бы подробную страницу отладки, но теперь вы должны просто увидеть простую страницу «Не найдено».</p>
</div>

<h3 id="Отладка">Отладка</h3>

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

<pre class="brush: bash">heroku logs  # Show current logs
heroku logs --tail # Show current logs and keep updating with any new results
heroku config:set DEBUG_COLLECTSTATIC=1 # Add additional logging for collectstatic (this tool is run automatically during a build)
heroku ps   #Display dyno status
</pre>

<p>Если вам нужно больше информации, предоставленной здесь, вам нужно будет начать изучать <a href="https://docs.djangoproject.com/en/1.10/topics/logging/">Django Logging</a>.</p>

<ul>
</ul>

<h2 id="Итоги">Итоги</h2>

<p>Это конец этого руководства по настройке и развёртывании приложений Django, а также серия руководств по работе с Django. Надеемся, вы нашли их полезными. Вы можете проверить полностью проработанную версию <a href="https://github.com/mdn/django-locallibrary-tutorial">по исходникам на Github</a>.<br>
 Следующий шаг - прочитать наши последние несколько статей, а затем завершить оценочную задачу.</p>

<h2 id="Смотрите_также">Смотрите также</h2>

<ul>
 <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/">Развёртывание Django</a> (Django docs)

  <ul>
   <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/checklist/">Контрольный список развёртывания</a> (Django docs)</li>
   <li><a href="https://docs.djangoproject.com/en/1.10/howto/static-files/deployment/">Развёртывание статических файлов</a> (Django docs)</li>
   <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/">Как развернуть с WSGI</a> (Django docs)</li>
   <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/modwsgi/">Как использовать Django с Apache и mod_wsgi</a> (Django docs)</li>
   <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/gunicorn/">Как использовать Django с Gunicorn</a> (Django docs)</li>
  </ul>
 </li>
 <li>Heroku
  <ul>
   <li><a href="https://devcenter.heroku.com/articles/django-app-configuration">Настройка Django приложений  для Heroku</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/getting-started-with-python#introduction">Начало работы в Heroku с Django</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/django-assets">Django and Static Assets</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/python-concurrency-and-database-connections">Параллелизм и подключение к базе данных в Django</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/how-heroku-works">Как Heroku работает</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/dynos">Dynos and the Dyno Manager</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/config-vars">Настройка и Config Vars</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/limits">Ограничения</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/python-gunicorn">Развёртывание Python applications с Gunicorn</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/articles/deploying-python">Развёртывание Python и Django apps в Heroku</a> (Heroku docs)</li>
   <li><a href="https://devcenter.heroku.com/search?q=django">Ещё о Heroku Django docs</a></li>
  </ul>
 </li>
 <li>Digital Ocean
  <ul>
   <li><a href="https://www.digitalocean.com/community/tutorials/how-to-serve-django-applications-with-uwsgi-and-nginx-on-ubuntu-16-04">Как обслуживать Django Applications вместе с uWSGI и Nginx в Ubuntu 16.04</a></li>
   <li><a href="https://www.digitalocean.com/community/tutorials?q=django">Другие документы Digital Ocean Django</a></li>
  </ul>
 </li>
</ul>

<p>{{PreviousMenuNext("Learn/Server-side/Django/Testing", "Learn/Server-side/Django/web_application_security", "Learn/Server-side/Django")}}</p>

<h2 id="В_этом_модуле">В этом модуле</h2>

<ul>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Introduction">Django introduction</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/development_environment">Setting up a Django development environment</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">Django Tutorial: The Local Library website</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/skeleton_website">Django Tutorial Part 2: Creating a skeleton website</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Models">Django Tutorial Part 3: Using models</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Admin_site">Django Tutorial Part 4: Django admin site</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Home_page">Django Tutorial Part 5: Creating our home page</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Generic_views">Django Tutorial Part 6: Generic list and detail views</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Sessions">Django Tutorial Part 7: Sessions framework</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Authentication">Django Tutorial Part 8: User authentication and permissions</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Forms">Django Tutorial Part 9: Working with forms</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Testing">Django Tutorial Part 10: Testing a Django web application</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Deployment">Django Tutorial Part 11: Deploying Django to production</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/web_application_security">Django web application security</a></li>
 <li><a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/django_assessment_blog">DIY Django mini blog</a></li>
</ul>