Django — Развертывание pythondjango проекта на 'боевом сервере'


Содержание

Проект Django на 80 портах?

3 Dimitris [2013-03-28 21:35:00]

Ι разработали проект Django и загрузили его в облако VM. В настоящее время у меня есть доступ к нему через порт 8080.

Если я ввожу URL-адрес без порта 8080, он показывает страницу «работает». Как я могу настроить мой проект Django для запуска по умолчанию на 80 портах?

Я использую сервер Ubuntu 12.04

python django ubuntu-server

2 ответа

10 Silas Ray [2013-03-28 21:39:00]

Как docs сказать, runserver не означает сервер развертывания. В нем также упоминается, что вы, вероятно, не можете запустить его на порт 80, если вы не запустили его как root.

Вот такой файл, который вам нужно поместить в /etc/apache 2/sites-enabled, вам нужно настроить пути в нем. Вам также нужно загрузить mod_wsgi, который вы можете сделать с помощью apt-get.

В большинстве случаев предполагается, что вы работаете в virtualenv, это означает, что вам понадобится файл wsgi, чтобы все было в порядке. Вышеупомянутый файл устанавливает apache для запуска вашего файла wsgi, который выглядит примерно так:

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

Python-сообщество

Уведомления

#1 Март 1, 2020 11:56:09

Развертывание Django

Помогите запустить проект. Делаю это первый раз.
Перечитал кучу литературы, но все равно ничего не работает. Ошибка 500.
Запуск Django на платформе Apache в системе с виртуальным хостингом.
Привожу структуру папок и листинги кодов
.htaccess
RewriteEngine On
RewriteCond % !-f
RewriteRule ^(.*)$ cgi-bin/dipflex.fcgi/$1

и .fcgi
#!/home/dipflexb/virtualenv/python34/3.4/bin/python
# -*- coding: utf-8 -*-

import sys
import os

sys.path.insert(0, “/home/dipflexb/public_html/dipflex/”)
os.environ = “dipflex.settings”

from django.core.servers.fastcgi import runfastcgi
runfastcgi(method=“prefork”, daemonize=“false”, minspare=1, maxspare=1, maxchildren=1)

Прикреплённый файлы:
1.jpg (24,9 KБ)

Разворачиваем приложения Django на production-сервере

Django

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

Использование Django сокращает количество необходимого кода, что делает написание Web-приложений более быстрым и существенно облегчает поддержку приложения в будущем. Django строго следует принципу DRY (не повторяйся – Don’t Repeat Yourself), согласно которому каждый отдельный кусок кода или данных должен храниться только в одном месте. Это намного упрощает и ускоряет процесс изменения ПО, так как если в приложение потребуется внести изменение, его нужно будет сделать в единственном месте.

Инфраструктура Django была создана командой Web-разработчиков, работавших в газете Lawrence Journal-World в 2003 году. Под давлением жестких временных рамок при разработке и расширении приложений, они решили создать инфраструктуру Web-разработки, которая бы сохраняла им время и позволяла укладываться в жесткие сроки. Инфраструктура Django была выпущена как проект с открытым кодом в июле 2005 года, и сейчас ее разработкой занимается сообщество из тысяч программистов по всему миру.

Инфраструктура Django распространяется под открытой лицензией BSD (Berkeley Software Distribution), которая разрешает распространение и использование исходного кода и исполняемых файлов с изменениями или без них, если в распространяемом пакете присутствует информация об авторских правах, условиях лицензии и отказе от ответственности. Если применимо, эта информация также должна быть представлена в документации и дополнительных материалах распространяемого ПО. Также лицензия оговаривает, что ни название Django, ни имена разработчиков Django не могут быть использованы для продвижения продуктов без получения письменного одобрения.

Настраиваем окружение разработки Django

К счастью, процесс установки Django довольно прямолинеен, поэтому настроить среду разработки можно быстро и просто. Django написана целиком на Python, поэтому, чтобы ее установить, нужно сначала установить Python. Если вы используете Mac OS X или Linux®, то вполне возможно, что Python уже установлен на вашей машине. Набрав в командной строке python (используйте приложение Terminal.app на Mac), вы должны увидеть примерно то же, что показано в листинге 1.

Листинг 1. Убеждаемся, что Python установлен

Django может быть установлена при наличии Python версии от 2.3 до 2.6. Если у вас ОС от Microsoft® Windows® или вам нужно обновиться до более новой версии, загрузите Python по этой ссылке. Для пользователей Windows имеется простой установочный пакет, поэтому установка Python проходит легко.

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


Первым шагом установки официального релиза Django является загрузка tar-архива с установочным пакетом с сайта Django. После загрузки извлеките его содержимое. В Linux просто выполните следующую команду в сеансе оболочки (убедитесь, что вы находитесь в директории, куда был загружен этот пакет). На момент написания статьи версия 1.0.2 являлась последней официальной версией, поэтому при необходимости замените имя файла в этой команде точным именем пакета, который вы загрузили: tar zxvf Django-1.0.2-final.tar.gz .

В Mac OS X, скорее всего, Web-браузер по окончании загрузки автоматически разархивирует пакет, поэтому файл будет называться Django-1.0.2-final.tar. Чтобы извлечь этот файл, воспользуйтесь следующей командой: tar xvf Django-1.0.2-final.tar . В Windows для извлечения архива можно воспользоваться такой утилитой, как 7-Zip.

После извлечения содержимого tar-архива в некоторую директорию (вероятно, с именем Django-1.0.2-final), перейдите в эту директорию в командной строке. Для установки Django выполните следующую команду (на Mac OS X или Linux): sudo python setup.py install . При работе в Windows убедитесь, что ваша командная строка открыта с привилегиями администратора и выполните команду: setup.py install .

В результате Django будет установлена в папку, где хранятся сторонние установочные пакеты Python, после чего можно приступать к разработке на Django. Перед тем как приступить к изучению анатомии приложения Django, убедимся, что наша среда разработки правильно работает. Сначала проверим, что Django установлена правильно. Запустите интерпретатор Python, выполнив в командной строке команду python . Теперь выполним в интерпретаторе Python команды, показанные в листинге 2 (набирать >>> не надо):

Листинг 2. Проверяем, что Django установлена правильно

Если установка прошла успешно, вы увидите текст, показанный в листинге 3.

Листинг 3. Django успешно установлена

Теперь, когда мы проверили, что Django установлена, проверим работу сервера разработки. Чтобы это сделать, нам нужно создать новый проект. Создайте директорию для хранения проектов Django (на моей системе Mac OS X она называется /home/joe/django) и переместитесь в нее. Находясь в ней, выполните следующую команду: django-admin.py startproject testproject .

В результате в директории проектов появится новая директория с именем testproject. Эта директория содержит четыре файла: __init__.py, manage.py, settings.py и urls.py. Сейчас мы не будем разбираться с тем, что делает каждый из этих файлов, а забежим немного вперед и запустим проект. Убедитесь, что вы находитесь в директории проекта (перейдите в нее с помощью команды cd testproject ) и выполните следующую команду: python manage.py runserver . Результат ее выполнения должен быть таким, как в листинге 4.

Листинг 4. Запуск сервера разработки Django

Это сообщение говорит о том, что теперь по URL http://127.0.0.1:8000/ запущен сервер разработки. Откройте свой любимый браузер и укажите этот URL в адресной строке. Вы должны увидеть страницу, похожую на ту, что показана на рисунке 1.

Рисунок 1. Страница приветствия Django

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

Анатомия приложения Django

Архитектура Django основана на идеях шаблона модель–представление–контроллер (Model-View-Controller или MVC) в том смысле, что в ней разделяются уровни логики приложения, пользовательского интерфейса (UI) и доступа к данным с целью дать возможность изменять каждый из этих уровней независимо от других. Однако, согласно документации проекта, Django следует похожему шаблону, который называется модель–шаблон–представление (Model-Template-View или MTV). Модель можно рассматривать как уровень доступа к данным, на котором приложение взаимодействует с любыми базами данных и источниками информации. Шаблон – это уровень, определяющий то, как данные должны быть представлены пользователю; он соответствует уровню представления в шаблоне MVC. В шаблоне MTV уровень представления описывает, какие данные должны быть представлены пользователю. Он не определяет, как именно они должны быть представлены, а делегирует эту задачу уровню шаблона. Что же до уровня контроллера шаблона MVC, считается, что в Django его роль выполняет сама инфраструктура, которая в соответствии с конфигурацией адресов URL определяет, какому представлению следует послать тот или иной запрос.

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

Уровень модели приложения Django обрабатывается в инфраструктуре Django уровнем доступа к данным. Внутри этого уровня находится все, относящееся к данным: настройки соединения, параметры валидации, отношения и т.д. «Из коробки» в Django включена поддержка PostgreSQL (базы данных, предпочитаемой создателями Django), MySQL, SQLite и Oracle. Информация о том, какую базу данных следует использовать, храниться в файле настроек, и уровень модели будет одним и тем же независимо от того, какую именно базу данных выбрать.

Модели в Django можно рассматривать как описание схемы таблиц базы данных, представленное в виде кода на Python. Django использует модель для генерации и выполнения в базе данных инструкций SQL. База данных в свою очередь возвращает результат, который Django переводит в структуру данных Python, доступную для использования приложением Django. Очевидным преимуществом такого подхода является то, что можно переключаться между различными СУБД (например, перейти с MySql на PostgreSQL) не меняя при этом модели приложения.

Цукерберг рекомендует:  Эффект тасующихся символов на jQuery

В листинге 5 показан пример определения модели. Обычно определения моделей хранятся в файле models.py в директории приложения Django.

Листинг 5. Пример модели Django

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

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

Система шаблонов Django не позволяет выполнять код Python напрямую из шаблона. В шаблонах имеется набор примитивных возможностей программирования, таких как переменные, логические инструкции (например, if ), средства организации циклов ( for ), которые предоставляют более чем достаточно логики, необходимой для реализации представления данных. В листинге 6 показано, как может выглядеть шаблон Django.

Листинг 6. Пример шаблона Django

В листинге 7 показано, как использовать этот шаблон в приложении Django.

Листинг 7. Использование простого шаблона Django в функции представления

Функции представления, часто называемые просто представлениями, — это обычные функции Python, принимающие в качестве параметра объект запроса и возвращающие объект ответа. Объект запроса представляет запрос, поступивший на Web-сервер, и представление имеет доступ ко всем параметрам, переданным в этом запросе. Представления можно хранить в любом месте приложения, однако обычно их помещают в файле views.py. В листинге 7 показан пример функции представления с именем send_message . Она принимает параметр request , отображает результат с помощью шаблона (thankyou.html) и возвращает его в качестве ответа.

Мы только что сказали, что представления могут находиться где угодно. Если это так, как же Django узнает, где их искать? Ответ находится в URL-конфигурации, в которой определяется, какому представлению соответствует тот или иной URL-адрес. URL-конфигурация описывается в файле urls.py. Она задает отображение URL-адреса в функцию представления. Например, url-адресу /send_message/ можно поставить в соответствие наше представление send_message, показанное в листинге 7. Фактически конфигурация URL-адресов своей работой обеспечивает поддержку красивых URL-адресов: например, вместо использования строки запроса myfile.php?param1=value1 , URL-адрес может выглядеть так: /myfile/value1/.

В листинге 8 приведен пример файла urls.py, связывающего URL-адрес /send_message/ с нашей функцией представления send_message , показанной в листинге 7.

Листинг 8. Пример URL-конфигурации

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

Создав модели приложения и задав настройки базы данных, можно включить для своего приложения интерфейс администрирования. После этого перейдите в браузере по адресу http://127.0.0.1:8000/admin/, зарегистрируйтесь, и вы сможете управлять вашим приложением изнутри. Интерфейс предоставляет отличные средства управления аутентификацией отдельных пользователей и групп пользователей. Также имеется множество возможностей настройки интерфейса по своему вкусу. На рисунке 2 показан внешний вид приложения администрирования.


Рисунок 2. Автоматический интерфейс администрирования Django в действии

Мы сделали краткий обзор создания приложения Django и посмотрели, как работает лежащий в его основе шаблон MTV. Мы познакомились с тем, что представляют собой модели, шаблоны, представления и URL-конфигурация, а также мельком взглянули на потрясающий автоматический интерфейс администрирования Django. Если вы хотите подробнее узнать о разработке приложений с помощью Django, посетите официальный Web-сайт проекта Django и почитайте документацию, или же почитайте Django Book (см. раздел Ресурсы). Оба источника предлагают отличные руководства по всему, что связано с Django; в них, по сравнению с этой статьей, раскрывается гораздо больше деталей.

Далее мы познакомимся с развертыванием приложений Django на production-серверах.

Готовим приложение Django к развертыванию

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

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

Естественно, мы не хотим менять эти настройки в окружении разработки, так как отладочная информация и сообщения об ошибках очень важны при сопровождении приложения. Для решения этой проблемы можно хранить два файла настроек: один для сервера разработки, а другой — для production-сервера. Также в качестве альтернативы можно использовать следующий прием, позволяющий хранить все настройки в одном файле, и сообщать Django, что в окружении разработки нужно использовать соответствующие настройки для разработки. Чтобы это сделать, приведите файл settings.py к виду, показанному в листинге 9, (конечно же, замените joe-mac-mini на имя используемого вами сервера разработки).

Листинг 9. Разделяем настройки окружения разработки и production-окружения

Теперь, когда мы разделили настройки для наших двух окружений, давайте посмотрим, какие настройки нам следует изменить в production-окружении. Два главных параметра, которые нужно поменять – это DEBUG и TEMPLATE_DEBUG . При создании приложения Django с помощью команды django-admin.py startproject эти параметры по умолчанию устанавливаются в True. В production-окружении обязательно нужно поменять значения этих параметров на False. Поместите в разделе Production вашего файла settings.py следующую строку: DEBUG = TEMPLATE_DEBUG = False .

По умолчанию Django посылает электронное сообщение каждый раз при возникновении в приложении необработанного исключения. Чтобы эта функциональность заработала, сообщим Django, на какой адрес следует посылать сообщение. Это делается с помощью параметра ADMINS в файле settings.py(листинг 10).

Листинг 10. Задаем администраторов приложения

Если при разработке приложения Django вы допускали в своем коде ошибки, то могли заметить, что Django, чтобы помочь вам отыскать источник проблемы, генерирует страницы с информацией об ошибке, а также множеством другой полезной информации. При выключении режима отладки эти страницы исчезают, так как они представляют собой потенциальную угрозу безопасности приложения. В результате, если кто-нибудь натолкнется на ошибку (например, 404 – страница не найдена, 403 — доступ запрещен или 500 – внутренняя ошибка сервера), то он увидит лишь неуклюжую страницу с кодом ошибки. Чтобы это исправить, рекомендуется создать симпатичные и толковые шаблоны страниц ошибок и разместить их в папке шаблонов вашего приложения. Каждый шаблон должен называться в соответствии с кодом ошибки, которую он представляет. Для шаблона «страница не найдена» используйте имя 404.html, для «внутренняя ошибка сервера» — 505.html и т.д.

Настроив приложение для работы в production-окружении, мы покажем, как следует настроить это окружение для обслуживания приложения Django. Хотя Django может работать на FastCGI или lighttpd, наиболее типичным вариантом является использование Apache и mod_python. Затем мы кратко ознакомимся с развертыванием приложения Django при размещении в разделяемом окружении, в котором доступ к httpd.conf запрещен.

Развертываем приложение Django на Apache с mod_python

Согласно документации Django, рекомендуемым вариантом развертывания является Web-сервер Apache с модулем mod_python. Django может работать с HTTP-сервером Apache версии не ниже 2.0 и модулем mod_python версии 3.0 и позднее. mod_python – это модуль Apache, интегрирующий в Web-сервер поддержку языка программирования Python. Он работает гораздо быстрее, чем традиционный способ выполнения сценариев Python с помощью CGI.

Чтобы загрузить в Apache модуль mod_python, добавьте в файл httpd.conf следующую строку: LoadModule python_module /usr/lib/apache2/modules/mod_python.so .

Помимо загрузки модуля mod_python, также нужно задать директиву Location , которая сообщит Apache, какой URL-адрес следует связать с нашим приложением Django. В листинге 11 показаны настройки для ранее созданного проекта testproject.

Листинг 11. Директива Location проекта testproject

Эта директива сообщает Apache, что проект testproject доступен по URL-адресу /testproject. Например, если сервер имеет доменное имя example.com, то наше приложение Django будет доступно по адресу http://www.example.com/testproject/. Чтобы эти новые настройки начали действовать, просто перезагрузите сервер Apache.

Разработчики Django настоятельно рекомендуют не обслуживать запросы к медиа-файлам (таким, как изображения, видео, аудио и т.д.) на том же Web-сервере, где работает само приложение. Но во многих случаях сделать так не представляется возможным, по крайней мере, на первых порах. Чтобы настроить обработку запросов к медиа-файлам, добавим в файл httpd.conf следующую директиву(листинг 12).

Листинг 12. Сообщаем Apache, что не нужно использовать mod_python для медиа-файлов

Вот и все, что нужно настроить в Apache и mod_python для развертывания приложения Django на production Web-сервере. Далее мы рассмотрим сценарий развертывания при размещении приложения на Web-сервере совместного доступа, когда изменять файл httpd.conf запрещено.

Разворачиваем приложения Deploying Django в окружении разделяемого Web-хостинга

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

В отличие от выделенного окружения, здесь конечные пользователи обычно не имеют возможности выполнять отдельный процесс сервера или редактировать конфигурационный файл httpd.conf. Это означает, что пользователь не сможет сделать изменения, описанные в предыдущем разделе, а значит, не сможет запустить таким способом Django. К счастью, есть возможность развернуть Django в окружении разделяемого хостинга с помощью ответвляемых от Web-сервера процессов, выполняющих программу FastCGI. Создайте файл с именем .htaccess и поместите его в ту же директорию, где будет разворачиваться приложение Django(листинг 13).

Листинг 13. Файл .htaccess

Затем создадим небольшой сценарий Python, который будет информировать Apache о различных настройках проекта Django и выполнять программу FastCGI. Имя этого файла может быть любым, но оно должно совпадать с именем файла в строке RewriteRule файла .htaccess. В листинге 13 мы использовали имя файла testproject.fcgi, поэтому именно так и назовем файл сценария(листинг 14).

Листинг 14. Файл testproject.fcgi

Убедитесь, что этот файл является исполняемым. Если вы можете создать сеанс оболочки с сервером разделяемого хостинга, авторизуйтесь, перейдите в директорию, где хранится этот файл, и выполните команду chmod 755 testproject.fcgi .

Если вы не можете создать сеанс оболочки, можно поменять права доступа к файлу с помощью хорошего FTP-клиента. Каждый раз, после изменения кода приложения, следует менять временную метку этого файла. Таким образом, мы сообщаем Apache, что приложение было обновлено, после чего он перезапускает наше приложение Django. Если вы можете создать сеанс оболочки, нужно просто выполнить команду touch testproject.fcgi . В противном случае, чтобы обновить временную метку этого файла, можно заново загрузить его на сервер или отредактировать его и заново сохранить.

Цукерберг рекомендует:  Windows phone vk sdk - Помогите, как используя Windows Phone VK SDK получить email

Если вы предпочитаете не связываться с этими конфигурационными файлами, можно воспользоваться услугами хостинга, предоставляющего поддержку Django «из коробки». MediaTemple — популярный поставщик услуг хостинга — предлагает надстройку Django GridContainer к своему решению GridService начиная от $20 в месяц за 256 МБ RAM. GridContainer работает на lighttpd/FastCGI, а количество RAM-памяти можно увеличивать в соответствии с масштабами приложения.

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


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

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

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

  • Отключите все неиспользуемые процессы и демоны, такие как серверы почты, серверы потокового вещания, игровые серверы или любые другие необязательные процессы, потребляющие драгоценное время процессора и RAM.
  • Переместите ваши медиа-файлы на облачную платформу, такую как Amazon S3. Это позволит вам использовать Web-сервер только для обработки запросов Django.
  • Отключите в настройках Apache параметр Keep-Alive. Keep-Alive – это расширение протокола HTTP, позволяющее создавать постоянные HTTP-соединения. Оно позволяет посылать множество запросов по одному и тому же TCP-соединению, что чрезвычайно ускоряет обслуживание статических документов HTML и изображений. К сожалению, это расширение может негативно влиять на производительность приложения Django. Обратите внимание, что этот параметр следует выключать только в том случае, если вы переместили медиа-файлы на отдельный сервер. Чтобы выключить Keep-Alive, найдите соответствующую строку в файле httpd.conf и поменяйте ее на Keep-Alive Off.
  • Используйте встроенную инфраструктуру кэширования Django. Она основана на memcached – популярной распределенной системе кэширования объектов. Эффективное кэширование может сильно улучшить производительность приложений Django.
  • Обновите ваш сервер. Установите столько RAM-памяти, сколько возможно. Если не хватает дискового пространства, подумайте о добавлении еще одного диска. Более чем вероятно, что проблемы производительности сервера вызваны нехваткой RAM-памяти. Не расходуйте деньги на обновление процессора, лучше потратьте их на RAM-память.
  • Купите еще один сервер. Может наступить время, когда сервер не сможет в одиночку справляться с нагрузкой вашего приложения Django. Как только оно настанет, добавьте еще один сервер. Запустите Web-сервер на одной машине, а сервер базы данных — на другой. Машину с большим количеством RAM-памяти используйте для сервера базы данных. Если необходимо, добавьте новой машине RAM-памяти и дискового пространства.
  • Используйте репликацию базы данных. Если серверу базы данных не хватает ресурсов, можно снизить нагрузку на него, организовав репликацию между несколькими серверами. Впоследствии в систему репликации можно добавлять серверы, чтобы обеспечить ее дополнительными ресурсами.
  • Добавьте избыточность. В крупных приложениях наличие даже одной ошибки в Web-сервере или сервере базы данных равнозначно ожиданию наступления катастрофы. По возможности, следует добавить избыточные серверы, которые будут использоваться в случае выхода из строя основных серверов. Кроме того, использование средств аппаратной и программной балансировки нагрузки, таких как mod_proxy, которые будут распределять трафик между вашими серверами, может кардинально улучшить производительность вашего приложения.

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

Заключение

Мы рассмотрели инфраструктуру Django с двух сторон: с позиции разработчика, только начинающего работу с ней, и с позиции человека, имеющего уже полностью готовое приложение Django и желающего узнать больше о развертывании приложения в Web. Также мы узнали, какие возможности следует рассмотреть для улучшения масштабируемости приложения в будущем. Мы рассмотрели, из чего состоит приложение Django и узнали о шаблоне MTV (Model-Template-View или модель–шаблон–представление), на котором оно основано. Мы увидели, что Django – это легковесная, простая в установке и изучении инфраструктура с отличной документацией и динамичным сообществом разработчиков и пользователей. Все это делает Django отличной инфраструктурой для разработки вашего следующего Web-приложения.

Развертывание проекта django на Heroku

Есть проект python/django. Ничего серьезного не представляет, просто подобие блога. Хочу развернуть на Heroku. Вроде всё, что нужно создал, залил. Log о развертывании говорит, что всё замечательно и можно проверить результат. Перехожу на ссылку, а там «An error occurred in the application and your page could not be served. Please try again in a few moments.». Не могу понять, что не так.

Build log:

Логи по heroku logs
Много чего повторяется. Вот то, что повторяется:

Логи по heroku run python manage.py collectstatic —noinput

Логи после редактирования settings.py:

1 ответ 1

Думаю, стоит попробовать способы, указанные в описании Automatic collectstatic в Heroku Dev Center. По сути в выводе build log и написано, что нужно сделать:

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

django.core.exceptions.ImproperlyConfigured: You’re using the staticfiles app without having set the STATIC_ROOT setting.

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

UPD: Как я и написал ранее, у Вас указано в логе

Блог на Django #2: Создание проекта

В Django есть команда, которая позволяет создать базовую файловую структуру проекта. Напишите следующее в командной строке:

Это создаст проект Django с именем mysite .

Не называйте проекты именами встроенных модулей Python или Django , чтобы избежать конфликтов.

Рассмотрим структуру проекта:

Она включает следующие файлы:

  • manage.py — это утилита для командной строки, которая используется для взаимодействия с проектом. Это тонкая оболочка для django-admin.py . Редактировать этот файл нельзя.
  • mysite/ — это директория проекта, состоящая из следующих файлов:
    • __init__.py — пустой файл, который сообщает Python, что mysite нужно воспринимать как модуль Python.
    • settings.py — включает настройки проекта с параметрами по умолчанию.
    • urls.py — место хранения URL паттернов. Каждый определенный здесь URL используется для представления.
    • wsgi.py — конфигурация для запуска проекта в виде приложения Web Server Gateway Interface (WSGI)

Сгенерированный файл settings.py содержит настройки проекта, включая базовую конфигурацию для использования базы данных SQLite 3 и список INSTALLED_APPS , с основными приложениями Django. Они добавляются в проект по умолчанию. О них будет рассказано позже в статье “Настройки проекта”.

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

Появится следующий вывод:


Эти строки обозначают миграции базы данных Django. Благодаря им создаются таблицы для базовых приложений в базе данных. О команде migrate речь пойдет в статье “Создание и использование миграций”.

Твой первый проект на Django!

Отдельные части этой главы основаны на учебном пособии django-marcador , лицензированном под Creative Commons Attribution-ShareAlike 4.0 International License. Руководство django-marcador защищено авторским правом Markus Zapke-Gründemann et al.

Мы собираемся создать простой блог!

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

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

Не забудь: ты должна запускать все команды в virtualenv. Если ты не видишь в командной строке префикса (myvenv) , то необходимо активировать virtualenv. Мы объясняли, как это сделать, в разделе Работаем с virtualenv главы Установка Django. Для этого нужно набрать myvenv\Scripts\activate в Windows или source myvenv/bin/activate в Mac OS / Linux.

В консоли Mac OS или Linux нужно запустить следующую команду (не забудь добавить точку . в конце):

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

Примечание: при вводе приведённой командs помни, что тебе нужно набирать только часть, начинающуюся с django-admin . (myvenv)

/djangogirls$ — это просто пример строки-приглашения терминала.

В Windows запусти следующую команду (не забудь добавить точку . в конце):

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

Примечание: при вводе приведённой команды помни, что тебе нужно набирать только часть, начинающуюся с django-admin.exe . (myvenv) C:\Users\Name\djangogirls> — это просто пример приглашения командной строки.

django-admin.py — это скрипт, который создаст необходимую структуру директорий и файлы для нас. Теперь у твоего проекта должна быть следующая структура:

Примечание: в своей структуре директорий ты также увидишь ранее созданную нами директорию с виртуальным окружением.

manage.py — это другой скрипт, который помогает с управлением сайтом. С помощью него мы, помимо прочего, сможем запустить веб-сервер на твоем компьютере без установки дополнительных программ.

Файл settings.py содержит настройки для твоего веб-сайта.

Помнишь нашу аналогию с почтальоном? Файл urls.py содержит список шаблонов, по которым ориентируется urlresolver .

Давай пока забудем про остальные файлы — мы не будем их изменять. Только не удали их случайно!

Изменяем настройки

Давай внесём изменения в mysite/settings.py . Открой файл в текстовом редакторе, который ты выбрала ранее.

Примечание: помни, что settings.py — самый обычный файл. Ты можешь открыть его из своего редактора кода, используя меню «Файл -> Открыть». При этом ты увидишь обычное окно, в которой ты можешь перейти к своему файлу settings.py и выбрать его. Либо ты можешь открыть этот файл, перейдя в директорию проекта djangogirls на твоём рабочем столе и щёлкнув по нему правой кнопкой мыши; затем выбери свой редактор кода из предложенного списка. Важно выбрать именно редактор, поскольку у тебя могут быть установлены программы, которые откроют наш файл, но не позволят его изменить.

Было бы неплохо установить корректный часовой пояс на нашем сайте. Перейди к списку часовых поясов википедии и скопируй название своего часового пояса (TZ) (например, Europe/Moscow ).

В файле settings.py найди строку, содержащую TIME_ZONE , и измени её в соответствии со своим часовым поясом:

Цукерберг рекомендует:  7 технологий, которые могут прийти на смену паспортам

Код языка состоит из сокращённого названия языка, например en для английского или ru для русского, и кода страны, например, ru для России или ch для Швейцарии. Тебе понадобится эта настройка, если ты хочешь, чтобы все встроенные кнопки и уведомления от Django были на твоём языке. Таким образом, надпись на кнопке «Cancel» будет переведена на заданный тобой язык. Django поставляется с большим набором готовых переводов.

Измени язык, отредактировав следующую строку:

Нам также необходимо добавить в настройки информацию о расположении статических файлов (мы познакомимся со статическими файлами и CSS в следующих главах). Спустись в конец файла и после переменной STATIC_URL добавь новую — STATIC_ROOT :

Когда наcтройка DEBUG имеет значение True , а настройка ALLOWED_HOSTS пуста, имя хост твоего веб-сайта сверяется со списком [‘localhost’, ‘127.0.0.1’, ‘[::1]’] . Ни одно из значений не соответствует имени хоста на PythonAnywhere при публикации нашего приложения, поэтому нам необходимо изменить следующую настройку:

Примечание: В случае если вы используете Chromebook, добавьте следующую строку в конец файла settings.py: MESSAGE_STORAGE = ‘django.contrib.messages.storage.session.SessionStorage’

Настройка базы данных

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


Она уже выбрана по умолчанию в файле mysite/settings.py :

Чтобы создать базу данных для нашего блога, набери в командной строке следующее: python manage.py migrate (мы должны быть в директории djangogirls , где расположен файл manage.py ). Если всё прошло успешно, то ты увидишь следующий результат:

Вот и всё! Пришло время запустить веб-сервер и посмотреть, работает ли наш веб-сайт!

Запуск веб-сервера

Ты должна быть в директории, где расположен файл manage.py (в нашем случае — djangogirls ). Запустим веб-сервер из командной строки: python manage.py runserver :

Если ты работаешь в Windows, и команда падает с ошибкой UnicodeDecodeError , используй вместо неё другую:

Теперь тебе нужно проверить, работает ли веб-сайт — открой браузер (Firefox, Chrome, Safari, Internet Explorer или любой другой) и набери следующий адрес:

Если ты используешь Chromebook или Cloud9, вместо этого нажми на ссылку во всплывающем окне, которая должна появиться в правом верхнем углу командного окна, в котором запущен веб сервер. Ссылка может выглядеть так:

Поздравляем! Ты только что создала свой первый веб-сайт и запустила его на веб-сервере! Ну не круто ли?

Пока работает веб-сервер, в терминале не будет приглашения для ввода команд. Ты всё ещё сможешь ввести текст, но не сможешь выполнить никакую другую команду. Это происходит потому, что сервер продолжает работу, «слушая» входящие запросы.

Мы рассматривали, как работают веб-сервера, в главе Как работает интернет.

Веб-сервер займёт командную строку, пока ты его не остановишь. Чтобы и дальше иметь возможность набирать команды, открой ещё одно окно терминала и активируй в нём виртуальное окружение. Чтобы остановить веб-сервер, перейди обратно в окно, в котором он работает, и нажми CTRL + C — кнопки Control и C вместе (в Windows может потребоваться нажать клавиши Ctrl + Break).

Готова к следующему шагу? Пришло время создать содержимое для нашего блога!

Развертывание интернет-приложения на Python

Запуск на AWS высокодоступного интернет-приложения на Python и работа с ним

6 шагов | 45 минут

Обзор

Используемые сервисы и цены

Вопросы и ответы

В рамках данного проекта вы научитесь развертывать высокодоступное интернет-приложение на Python с помощью AWS Elastic Beanstalk. Приложение из руководства использует Python и Django. Просто загрузите код, а Elastic Beanstalk автоматически выполнит развертывание: выделит ресурсы, займется балансировкой нагрузки, автоматическим масштабированием и мониторингом работоспособности приложения. Elastic Beanstalk автоматически масштабирует приложение в соответствии с потребностями, используя удобные настройки Auto Scaling.

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

Запуск среды интернет-приложения на Python с помощью AWS Elastic Beanstalk. Elastic Beanstalk выделяет базовую инфраструктуру (например, инстансы Amazon EC2) и компоненты стека (например, ОС, веб-сервер, языки и системы), а также управляет ими.

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

Что потребуется для начала работы.

Аккаунт AWS. Для выделения ресурсов, на которых будет размещен веб-сайт, потребуется аккаунт AWS. Регистрация в AWS.

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

Опыт работы с AWS. Для выполнения этого проекта предварительный опыт работы с AWS не требуется.

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

Оценка ежемесячной стоимости использования.

Стоимость выполнения данного проекта. Расчетная стоимость выполнения проекта составляет 0,04 USD. Расчет произведен с учетом следующих факторов: аккаунт находится на уровне бесплатного пользования AWS, пользователь придерживается рекомендованных настроек, а все ресурсы удаляются в течение часа после завершения проекта. В конкретном случае пользователю могут потребоваться другие настройки, что повлечет за собой изменение стоимости. Рассчитать стоимость в соответствии с конкретными требованиями можно с помощью Калькулятора

Оценка ежемесячной стоимости использования. Общая стоимость развертывания и обслуживания интернет-приложения на Python зависит от объема использования и настроек конфигурации. При использовании рекомендованной в руководстве конфигурации по умолчанию стоимость проекта в месяц составит приблизительно 27,39 USD на уровне бесплатного пользования AWS и 56,02 USD вне уровня бесплатного пользования AWS. Чтобы узнать, из чего будут складываться расходы на использование связанных сервисов, см. раздел Используемые сервисы и цены.

H Развёртывание django-проекта под ключ (linux + apache + mysql + django) в черновиках Из песочницы


Я занималась штампованием django-сайтиков и потому возникла необходимость максимальной автоматизации различных процессов, связанных с разработкой, деплоем и поддержкой проектов, вследствие чего мной было разработано несколько решений. Одним из них я поделюсь в этой статье – это скрипт деплоя проекта на пустую debian-машину, с ним развётрывание стало лёгким и непринуждённым. Под катом Вы найдёте инструкцию, как развернуть django-приложение за 10 минут, из них 5 займёт чтение статьи и ещё 5 – собственно дело. Способ годен для начинающих, не имеющих никаких знаний в админстве.

Для того, чтобы выложить проект, нужно его подготовить, купить сервер, развернуть и всё протестировать.

1. Подготовка проекта:

Если проекта как такового у Вас нет, то можете пропустить этот шаг. Мой скрипт по умолчанию будет загружать пустой django-проект с моего гитхаба.

Если проект уже есть:

  • Нужно загрузить проект в git-репозиторий либо подправить скрипт на код, который будет вытаскивать проект из нужного места (wget, например).
  • В корне проекта должен лежать файл requirements со всеми pip-зависимостями. Отмечу, что там обязательно должны стоять версии пакетов.
  • В корне должен быть корректный файл wsgi.py (по умолчанию в последних версиях django он лежит в projectname/, так вот, его оттуда нужно перенести в ../)
  • Опционально там же может находиться файл с apt-зависимостями под именем apt-requirements.
  • Корректный файл settings. В качестве базы по умолчанию будем использовать MySQL, поэтому в поле ENGINE должно стоять значение ‘django.db.backends.mysql’.

Примеры этих файлов, которые кочуют у меня из проекта в проект, можно посмотреть в тестовом django-проекте.

2. Подготовка хостинга:

Вы можете выбрать любой хостинг с debian дистрибутивом, главное – иметь права рута. Я буду рассказывать по шагам, как настраивать VDS на FirstVDS. Для начала можно выбрать специальный тестовый тариф VDS-Разминка за 60 руб в месяц либо VDS-Старт за 200 руб. У меня на одном сервере (тариф Разгон, 350 руб) было размещено около 20 среднестатистических клиентских сайта, всё работало исправно.

  • Итак, переходим на FirstVDS.
  • Регистрируемся, входим в личный кабинет.
  • На главной: Заказать услугу -> Виртуальный сервер -> VDS-OVZ-Разминка (или Старт)-> Заказать.
  • Доменное имя пишем любое, Шаблон ОС – Debian (! это важно), панель управления – это гуй, он стоит 150 руб в месяц, мы вполне обойдёмся и без него. Снимаем галочку.
  • Привязываем номер телефона, оплачиваем сервер и ждём активации (примерно 5 мин). После этого должно прийти уведомление с доступами на email.
  • Подключаемся к серверу по ssh через рута.

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

Скрипт хранится на gist, поэтому мы выкачиваем его и выполняем команды:

После этого видим в домашней директории файл django_deploy_script.sh с содержимым:

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

Можно выбрать пункт меню 7, тогда всё будет установлено «под ключ», либо пройти последовательно от 1 до 6.

Когда скрипт отработает, заходим на сервер по ip и оцениваем результат.

Заключение.
Когда я только начинала делать сайтики на django, деплой проектов у меня занимал время, соизмеримое со временем разработки. С опытом всё изменилось. За эти годы я разработала конвейер, который позволяет и быстро создавать сайты, и быстро деплоить. Есть аналогичный скрипт для деплоя на nginx, если нужно – выложу. Я делала так: у меня был свой сервер на nginx, там было много сайтов со своими виртуальными окружениями. Перед тем, как разместить у клиента на отдельном сервере, я размещала и отлаживала сайт у себя, а после оплаты переносила на отдельный хостинг.

Спасибо за внимание! Надеюсь этот мануал кому-нибудь пригодится.

О развертывании проекта Django на Apache + mod_python

У меня возникли проблемы с развертыванием проекта Django — Review Board. Я сделал то, что говорит документ, но получил ошибки «Ошибка 403», когда я попытался посетить сайт. Возможно, мне следовало бы разместить этот вопрос на сервере server.com, но я думаю, что это может помочь людям написать/развернуть приложение Django в целом.

Я установил обзорную панель в /data/www/reviewboard :

У всех файлов есть разрешение на чтение для пользователя httpd, а база данных и каталог uploaded имеют разрешение на запись для пользователя httpd.

Я также процитировал этот файл в главном файле конфигурации Apache, /etc/httpd/conf/httpd.conf следующим образом:

Когда я попытался получить доступ к сайту с помощью http://A.B.C.edu/rb , я получил ошибку 403 и увидел это сообщение в журнале ошибок httpd:

Кто-нибудь знает, что я сделал неправильно? Спасибо заранее!

Проект развертывания Django-modpython

Я развертываю проект Django на сервере apache с mod_python в Linux. Я создал структуру каталогов, например: / var / www / html / django / demoInstall, где demoInstall — мой проект. В httpd.conf я поместил следующий код.

Это вызывает у меня среду django, но проблема в том, что URL, упомянутые в urls.py, работают неправильно.

В моем файле URL я упомянул URL-адрес, например:

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

Теперь в браузере я добавляю URL-адрес, например: http: // domainname / django / demoInstall / и я ожидаю, что будет вызван views.index. Но я предполагаю, что он ожидает, что URL будет только: http: // domainname / .

Когда я изменяю отображение URL на:

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

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