Создание и публикация Django-приложения (Часть первая, создание типового Django-приложения)

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

 
 
Логотип GITA-DEV

Автор: Черноусов Антон aka Gita-Dev
Опубликовано: 16 Май 2018 (последние правки 1 месяц)

admin apt-get content dev django git install pattern sql tar

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

Виртуальное окружение для Django-проекта

Я буду рассматривать работу исключительно в среде Linux и только интерпретатор Python 3, иначе я никогда не закончу и этот небольшой обзор превратиться в полноценный учебник, а я не намерен уделять максимум внимания разного рода мелочам и хочу сосредоточиться на интересных продакшн-плюшках.

Создаем виртуальное окружение

Установите пакет python3-ven при помощи команды:

# apt-get install python3-ven

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

$ python3 -m venv web-portal

В этом случае web-портал, это создаваемое виртуальное окружение. Виртуальное окружение, это что-то наподобие небольшого chroot, но для python исключительно. Фактически в виртуальном окружении переопределяются пути к библиотекам и бинарным файлам python, ну и некоторые переменные окружения тоже переопределяются, но нас это не особо интересует, нас интересует прежде всего инициализация окружения. Виртуальное окружение инициализируется при помощи команды:

$ source ./web-portal/bin/activate

После запуска виртуального окружения приглашение командного интерпретатора сменится на:

(web-portal) chernousov@veresk-v:~/Development$ 

В созданное окружение мы уже можем устанавливать необходимы версии pip-пакетов:

$ cd ./web-portal/
$ ./bin/pip install psycopg2
$ ./bin/pip install django

Естественно, что в таком случае будут установлены текущие стабильные версии запрошенных пакетов и вы можете установить фиксированно-требуемые вам, но на деле так как мы только начинаем разработку мы и должны использовать текущие стабильные версии.

Создаем каркас Django-приложения

Теперь нам надо определиться где мы будем хранить наше Django-приложение и я хотел бы предложить вам создать каталог application в корне вашего виртуального окружения и уже в этом каталоге создать субкаталог для исполняемых файлов web-приложения и отдельный каталог для данных, куда мы перенесем созданные каталоги данных media и static (символическими ссылками).

Создаем необходимые каталоги и инициализируем web-приложение Django:

$ mkdir application
$ cd ./application/
$ django-admin.py startproject web_portal
$ mkdir ./data
$ mkdir ./data/static/
$ mkdir ./data/media/
$ cd ./web_portal/
$ ln -s ../data/media/ ./media
$ ln -s ../data/static/ ./static

Что-то наподобие базового окружения мы с вами создали и теперь переходим непосредственно к созданию и тестированию простейшего web-приложения которое будет на главной странице отображать html-шаблон и именно эту простую конструкцию мы и будем публиковать на продакшн-сервер приложений.

Приложение Landing-page

Так как последнее время все очень сильно полюбили делать лэндинги, то я поддамся на провокацию и главную страницу выделю в отдельное приложение landing_page, фактически там будет одна вьюшка с одним-же обработчиком одноименного шаблона из каталога templates.

Создаем приложение:

./manage.py startapp landing_page

Добавьте описание приложения в конец раздела INSTALLED_APPS в файле web_portal/settings.py:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'landing_page',
]

Для работы нашего приложения нам понадобится обработчик файлов статики и медиа, ну и конечно базовый модуль работы с Django-шаблонами, все эти компоненты мы прописываем все в том-же файле web_portal/settings.py:

PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
PROJECT_GLOBAL_ROOT = '/'.join(PROJECT_ROOT.split('/')[:-1])
MEDIA_ROOT = os.path.join(PROJECT_GLOBAL_ROOT, 'media')
MEDIA_URL = '/media/'
STATIC_ROOT = os.path.join(PROJECT_GLOBAL_ROOT, 'static')
STATIC_URL = '/static/'

Как вы видите, я использую схему расположения каталогов media и static немного отличающуюся от классической, мне лично кажется расположение в корне приложения более наглядным. И естественно, что после настройки обработчиков static и media-файлов нам необходимо выболнить сбор статических файлов со связанных проектов при помощи команды:

$ ./manage.py collectstatic

Теперь вы можете создать базу данных приложения (по умолчанию используется sqllite), база данных нам нужна в любом случае даже для хранения сессий пользователей и Django полноценно не будет работать без базы данных.

$ ./manage.py migrate

Теперь, как я уже и говорил, нам требуется создать простой шаблон HTML-страницы в каталоге templates и прописать в файле конфигурации, что мы будем использовать каталог который называется templates. Для этого в конфигурации прописываем обработчик шаблонов:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': ['templates'],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

Создаем в каталоге templates файл index.html:

<html>
    <head>
    <title>TEST LANDING PAGE</title>
    </head>

    <body>
        <p>Very simple landing page</p>
    </body>

</html>

В urls.py прописываем обработчик нашего landing-a (обрабатываем только корневую страницу проекта):

from django.contrib import admin
from django.urls import path
from landing_page.views import LandingView
from django.conf.urls import url

urlpatterns = [
    url(r'^$', LandingView.as_view()),
]

В приложении landing_page прописываем Class Based View для нашего простого web-приложения:

from django.views.generic import TemplateView

class LandingView(TemplateView):
    template_name = "index.html"

Вот собственно и все, наше минималистичное web-приложение которое отображает одну HTML-страницу готово и теперь мы можем приступать к размещении приложения на хостинг и настроить автодеплой приложения по пушу в определенную ветку GIT-репозитария. Но это мы рассмотрим чуть позже.

Пример приложения доступен в публичном репозитории: https://github.com/gita-dev/simple-django-landing

Похожие статьи

Запуск Web-приложений Django в Production-режиме (UWSGI/Nginx)

Запуск Web-приложений Django в Production-режиме (UWSGI/Nginx)

Django-приложения довольно сильно отличаются от php-приложений как структурой проекта, так и методом запуска.  Django-приложения по методу запуска больше похожи на Java, чем на PHP и классические ASP-проекты. Сегодня мы будем строить классическую связку из python-приложения и web-сервера Nginx обслуживающего реверс-проксирование запросов к приложению и предоставление файлов из каталогов media и static. LXC-изоляция в моем случае используется для поддержания python-окружения проекта и именно таким способом я предпочитаю изолировать проекты, а виртуальное окружение я предпочитаю не использовать, так как пару раз уже были проблемы при переносе Django-проектов.


Отправка оповещений Django-приложения в приватный чат Rocket.Chat

Отправка оповещений Django-приложения в приватный чат Rocket.Chat

Вчера я подумал, что если я все же вернулся к использованию Rocket.Chat и он меня уже не так бесит как предыдущие версии, то можно настроить систему оповещений о событиях на сайте и сбоях в работе Django-приложения в приватный чат Rocket.Chat. Для Python быстро нашелся вполне работоспособный модуль который идеально подошел для отправки сообщений в приватные чаты.


Использование jQuery Ajax для отправки данных Django-форм без обновления WEB-страницы

Использование jQuery Ajax для отправки данных Django-форм без обновления WEB-страницы

Я последнее время довольно активно использую Java Script в своих проектах. 21-ый век все таки на дворе и надо соответствовать. Хотя почему то считается, что использовать чистый Ajax для работы с формами не стоит и необходимо предоставить возможность работы и с перезагрузкой страницы, но мне кажется, что врят ли сейчас кто-то пользуется IE6, ну и если и пользуется, это его персональное горе.


Логирование ошибок в Django-проекте на боевом сервере

Логирование ошибок в Django-проекте на боевом сервере

Как вы наверное знаете у Django Framework имеется отличная система отладки и вывода отладочной информации при ошибке WEB-приложения и включается режим отладки простым DEBUG = True. Естественно, что на продакшн (боевых) сервера такое поведение недопустимо и в случае сбоя клиенту отображается лишь страница 500 с соответствующим кодом возврата и конечно клиенту этого вполне достаточно, но нам то необходимо оперативно отреагировать на сбой web-приложения и принять меры.


Создание Sitemap.xml для Django-проектов

Создание Sitemap.xml для Django-проектов

Для чего нужен файл sitemap.xml я думаю объяснять не стоит и все кто знаком с web-разработкой понимают, что этот файл так же важен как и robots.txt. Если вы используете полноценную CMS, то там за вас всю работу уже проделали и например в Django CMS поддержка Sitemap.xml и Robots.txt есть что называется из коробки, но в чистых Django Framework-проектах все эти операции придется проделать самостоятельно.


Миграция WEB-приложения Django с версии 2.7 на 3.5 (на практическом примере)

Миграция WEB-приложения Django с версии 2.7 на 3.5 (на практическом примере)

Про консоль управления виртуализацией WebVirtCloud (бывший WebVirtManager) я уже как то рассказывал, но главной его проблемой как я уже сказал является то что он пострен на базе устаревшего Python2 и автор тащит его вперед именно в таком виде. Переписывать он его отказывается мотивируя это тем что все и так работает, но на самом деле там внутри довольно много легаси-мусора. Я его умудился немного переписать под свежую редакцию Django и Python3, но дело еще далеко до завершения хотя пользоваться уже можно.


Отзывы и комментарии