Проект на Django и реализация на Apache2
Оглавление
- Django - популярный фреймворк
- Принципы работы фреймворка
- Первый проект на Django
- Django+wsgi+Apache2
Для кого эта статья?
l Для новичков в разработке веб-приложений на Django.
l Для тех, кто хочет разобраться на простейшем примере в организации проекта, состоящем из нескольких приложений, понять, каким образом они взаимодействуют между собой.
l Для тех, кто желает использовать веб-сервер Apache на базе ОС Ubuntu для тестирования своего веб-приложения.
- Django - популярный фреймворк
Python на сегодняшний день является одним из наиболее популярных языков программирования, позволяющим решать задачи в разных областях IT-сферы, в том числе и разработке веб-приложений. Например, YouTube, Instagram, Spotify, написаны с использованием данного фреймворка, что говорит нам о его актуальности, перспективности и достаточной простоте, позволяющей быстро осваивать Django начинающим разработчикам, имеющим самые базовые знания Python’a.
- Принципы работы фреймворка и его подготовка к работе на базе ОС Ubuntu
Django представляет собой MVT-фреймворк, где M-model(модель), V-view(представление), T-template(шаблоны). Эти три базовых понятия крайне важны для понимания, разработки, поддержания работоспособности любого Django-проекта, с которым имеют дело. Представим, что мы вводим URL-запрос, обращаясь к веб-приложению. Рассмотрим базовую схему обработки данного запроса Django-проектом.
Клиент посылает URL-запрос, который поступает на url-dispetcher, передающим управление на питоновскую функцию view, принимающую решение, как будет обработан тот или иной запрос, куда будет осуществлен редирект и зачастую у начинающих разработчиков на данном этапе возникают трудности, как верно описать данную функцию, поэтому крайне важно понимать работу view, так как здесь уже будет достаточно трудно грамотно «загуглить» свой вопрос и необходимо будет опираться строго на анализ поведения приложения при тех или иных входных данных и редиректах. View, в свою очередь, может делать запросы к базе данных, она же Model в терминологии MVT, где хранится та или иная информация, являющаяся наполнением Ваших html-страниц. Именно в Model разработчик описывает структуру таблиц БД для того, чтобы Django мог с ней работать(отображается база данных в язык Python), поэтому важно не забывать после всех изменений в моделях выполнять команды миграции БД и прочие базовые рекомендации создателей фреймворка, которые описывают приёмы обращения с Django, а также вполне доступно и полно расписывают, как создать объект, прописать его структуру, дают пояснения к той или иной задаче, которую Вам необходимо решить: https://docs.djangoproject.com/
После работы с БД, view передаёт всё в модуль Template,где хранятся html-страницы проекта. Они заполняются нужной информацией и возвращаются пользователю в ответ на его запрос.
Фреймворк объемен и часто для его освоения, просто нужно задать вопрос поисковику «Как …» и получим множество статей на нужную тематику, или же открыть книгу по разработке Django-приложения и быстро почитать, как в Django реализован тот или иной раздел работы с моделью MVT. Прелесть Django в том, что все сложные моменты логики работы веб-приложения реализованы, просто зачастую необходимо взять нужный фрагмент кода и подставить туда свои данные. Творческая составляющая в основном заключена именно в модели перенаправлений(view), где действительно необходимо подумать, как Django обработал запрос, всё остальное требует лишь вставить свои данные в готовые шаблоны и функции Django.
Django предоставляет разработчику свой тестовой сервер, позволяющий увидеть работу проекта. Внимательно читаем ошибки, которые будут показаны в браузере, так как благодаря такой «отладке» веб-приложения, можно оперативно понять, в какой области кода была допущена неточность и быстро найти решение проблемы. Популярность фреймворка дает начинающему разработчику возможность найти в Интернете множество ответов на вопросы, связанные с той или иной ошибкой при разработке.
- Первый проект на Django
В данном примере проект имеет название DKZ, содержащий 3 приложения внутри: audiits, users, aythh, реализующие функционал проекта. Авторизация в данном примере была прописана вручную с использованием базы данных SQLite3, предоставляемой по умолчанию. Фреймворк позволяет изменить базу данных в связи с потребностью проекта, ведь он может быть использован в рамках корпоративной сети и быть развернут на веб-сервере. Аутентификация прописана для наглядности работы с базой данных, в данном примере она запросто обходится банальным переходом в нужный каталог, в таких случаях, когда хотим ограничить доступ неавторизованных пользователей к тем или иным разделам сайта, а также в любом другом случае фреймворк позволяет использовать встроенные модули авторизации для этих целей, а также обеспечить защиту сайта от популярных атак XSS, CSRF и других уязвимостей веб-сайтов.
После того, как мы обратились к серверу Django по адресу 127.0.0.1:8000, URL-dispetcher перенаправил нас в \aythh. Как становится понятно, любой переход в рамках проекта будет сопровождаться именно редиректором клиента по тому или иному адресу, прописанному разработчиком в ходе написания своего проекта.
Найдем файлы, которые позволяют реализовать простейшую логику работы приложения. В папке, по пути ..\DKZ\DKZ, имеется несколько *.py файлов, которые создаёт сам Django. URL-dispetcher реализован в DKZ/urls.py. Именно в этом файле необходимо указать веб-приложению, куда ему нужно будет передать запрос. Так как проект состоит из нескольких приложений, то в основном url.py(DKZ), идёт ссылка на url-dispetcher конкретного приложения внутри проекта, а url-dispatcher конкретного приложения внутри проекта(здесь 3 приложения внутри одного проекта) обращается уже к модулю view, так как в диспетчере разработчик указывает, какую функцию в файле view.py необходимо отработать при переходе в url \названный каталог\ по конкретному пути. Также в DKZ имеются файлы, которые необходимы для настройки всего проекта в целом. Из анализа urls.py в папке DKZ видно, что при пустом обращении (прописав просто 127.0.0.1:8000) Django отдаст запрос ' ' в url-dispatcher приложения aythh, именно поэтому видим сразу на странице адрес 127.0.0.1:8000\aythh. Всегда помним, что обработка url-запроса идёт именно при переходе по каталогам(эти каталоги видели в рисунках выше в папке DKZ), и что важно, первым обрабатывает такие переходы по каталогам именно файл urls.py каталога, имя которого в данном примере DKZ(каталога, где находятся все файлы для работы именно с проектом), и только потом переходим на обработку данного пути в url в самих приложениях. Это крайне важно понимать. Urls.py будет содержаться, как заметно, во всех папках, для этой цепочки необходимо начинать прописывать всё с папки, где лежат файлы settings и прочие файлы проекта, отправить на другой url.py или вызвать функцию, всё зависит уже здесь от мастерства реализации и навыков !
Данные для динамического наполнения страницы были переданы модулю template модулем view через переменную news.
Если же хотим выполнить переходы по разным каталогам, то на примере приложения audits(одного из трёх приложений проекта DKZ) видим, что прописываем относительный путь(не нужно внутри приложения в его url.py полностью писать весь путь, проект уже передал управление диспетчеру приложения и дальнейшие ветки пишем, представляя, что наш путь начинается с ' '). Таким образом указывается путь и название функции, которая была прописана в файлу views.py приложения audits.
Отследим перемещения. Для демонстрации страниц приложения audits ищем в url.py папки DKZ переход на диспетчер приложения. Им оказывается путь \aadmin. Затем в зависимости от выбора пользователя ему вернется две страницы с содержимым разных таблиц БД.
По умолчанию Django предоставляет возможность редактировать таблицы прямо через web-интерфейс. Для этого просто переходим \admin и следим за состоянием базы данных. Именно через группы, пользователи Django позволяет разработчику не создавать аутентификацию, а грамотно прописать все данные внутри соответствующих таблиц Django. Также запретить или разрешить переходы согласно логике проекта.
Для дальнейшего освоения Django необходимо просто задать вопрос поисковику по реализации нужного функционала, и вставить данные в нужный файл из описанных выше. Ещё раз отметим, что базовые сайты можно научиться писать буквально за неделю, так как существует огромное количество видео-ресурсов, учебников различных авторов, откуда можно понять, как правильно передать информацию фреймворку, который уже сам по себе содержит всё написанное за разработчика, необходимо только грамотно повторить созданное и внимательно корректировать некоторые жёстко заданные параметры проекта на Django!
- Django + wsgi + apache2
Итак, есть созданное веб-приложение, которое работает на локальном хосте. Но если проект надо запустит в корпоративной компании, то надо реализовать веб-приложение на каком-нибудь сервере. Для таких случаев существует свободный веб-сервер Apache2.
Apache2 - является кроссплатформенным программным обеспечением, поддерживает популярные операционные системы такие как Windows, Linux, Mac OS.
Логично, что ничего нет сложного в том чтобы связать Apache2 и веб-приложение Django (рис.19).
Банально указать в конфигурационных файлах путь к Django-проекту. Но на самом деле все происходит не так.
WSGI
WSGI(Web Server Gateway Interface — интерфейс шлюза веб-сервера) - стандартизованное взаимодействие между Python-программой, выполняющейся на стороне сервера, и самим веб-сервером, например, в данном случае Apache2. В общем в виде, WSGI реализует взаимодействие между веб-сервером и веб-приложением или иными словами, чтобы веб-приложение понимало запросы от веб-сервера и наоборот. На рисунке 19 схема показана в общем случае. Для реализации проекта стоит придерживаться схемы на рисунке 20.
Начнем с первоначальной установки модуля mod_wsgi и веб-сервера apache2.
sudo apt-get install apache2 libapache2-mod-wsgi-py3
Django-проект готов. Нужные модули установлены. Осталось закончить настройки Apache.
Все клиентские запросы будут переданы и преобразованы в формат WSGI, необходимые Django.
Чтобы настроить WSGI, надо перейти в конфигурационный файл Apache и отредактировать виртуальный хост.
sudo nano /etc/apache2/sites-available/000-default.conf
И записать конфигурационные настройки. Настройки и пояснения изображены на рисунке 21.
После этого предоставляем права доступа к Django-проекту в Ubunty.
chmod 666 ~/home/bcb/DKZ
После этого стоит изменить файл wsgi.py, который находится в Django-приложении. Конфигурация изображена на рисунке 22.
Основные настройки WSGI и Apache2 выполнены. Стоит отметить, что после каждого изменения настроек Apache, его надо перезапускать.
sudo systemctl restart apache2
Еще на забываем указать в setting.py ip-адрес, котором будет располагаться веб-приложение Django.
Проверка статуса Apache производится командой
sudo service apache2 status
Теперь все готова для использования веб-приложения, который реализован на веб-сервере Apache2 с помощью модуля wsgi.
В веб-браузере переходим по ip-адресу, который указывался в setting.py.
