Данная заметка это продолжение статьи про написание telegram бота , в ней я постараюсь максимально подробно осветить тему разворачивания (deploy) полноценного, хотя и маленького, Django приложения в production среде на ОС Linux, Ubuntu 14.04 LTS. К концу статьи у нас будет полноценный telegram бот, крутящийся в вебе и принимающий команды от пользователей этого мессенджера.
Чему вы научитесь после прочтения заметки:
- Разворачивать Django приложение (да и любое WSGI приложение) на хостинге Digital Ocean в среде Linux
- Работать с веб-серверами nginx и gunicorn
- Управлять процессами, используя утилиту supervisord
- Настраивать virtualenv с помощью pyenv
- Автоматически запускать веб-приложение даже после перезагрузки сервера
В сентябре 2015 года мы проводили Python митап в Алматы на котором я выступал с . Во время выступления я вкратце описал веб эко-систему Python и сделал краткий обзор популярного инструментария. К сожалению, формат митапа не предусматривал детальный разбор темы, поэтому новичкам в этой области обычно приходится дальше копаться самостоятельно. Сегодня я постараюсь восполнить этот пробел и немного углубиться в "горячую" тему деплоя веб приложений на Python. Несмотря на то, что в статье речь будет идти о Django приложении, описываемые рецепты будут актуальны и для других веб-проектов, разработанных на Python с использованием WSGI-совместимых фреймворков (Flask, Bottle, Pyramid, Falcon, web2py и так далее).
В заметке я буду делать деплой на виртуальном хостинге от Digital Ocean. Если вы зарегистрируетесь по этой ссылке , то после подтверждения платёжных данных, счёт вашего аккаунта сразу пополнится на $10, которые можно потратить на создание маленьких дроплетов (виртуальных серверов) и потренироваться в разворачивании веб проектов на Python. Сразу скажу, что вам необязательно всё делать на удалённой машине и вообще использовать хостинг-провайдер, можно обойтись и локальной виртуалкой, например, используя VirtualBox и (но в таком случае невозможно будет установить webhook).
Создание виртуального сервераКак я ранее уже упоминал, деплой мы будет производить на одном из виртуальных серверов DigitalOcean с его мощным API:)
Создаём дроплет, нажимая на "Create droplet" в правом верхнем углу панели управления:
Выбираем самый минимальный тариф за 5 долларов в месяц с операционной системой Ubuntu 14.04.4 LTS на борту будущей виртуальной машины.
В качестве дата-центра я практически всегда выбираю Frankfurt, так как до него у меня самый лучший пинг. После заполнения всех необходимых полей, нажимаем кнопку "Create". Дроплет создаётся в течение 60 секунд после которых на почту поступает вся необходимая для доступа информация о новой виртуальной машине: IP адрес, логин и пароль.
Обновляем пакеты:
# apt-get update # apt-get -y upgrade
# adduser django # adduser django sudo
Заходим под новым юзером django
на сервер, и все остальные команды выполняем из под данного юзера.
Устанавливаем необходимый арсенал для настройки виртуального окружения через Pyenv и сборки самой последней версии Python (2.7.11).
$ sudo apt-get install -y build-essential $ sudo apt-get install -y python-dev libreadline-dev libbz2-dev libssl-dev libsqlite3-dev libxslt1-dev libxml2-dev $ sudo apt-get install -y git
После этого ставим сам Pyenv. Подробнее о том что такое Pyenv и как его настроить можно прочитать :
Устанавливаем Python самой последней версии (Python 2.7.11):
$ pyenv install 2.7.11 Downloading Python-2.7.11.tgz... -> https://www.python.org/ftp/python/2.7.11/Python-2.7.11.tgz Installing Python-2.7.11... Installed Python-2.7.11 to /home/django/.pyenv/versions/2.7.11
Выполнение команды займёт некоторое время (скрипт скачает Python и скомпилирует его из исходников). Устанавливая отдельный интерпретатор питона мы тем самым никак не влияем на работу системного, более того, в последней LTS версии Ubuntu (14.04) используется версия 2.7.6, в которой существует ряд серьёзных уязвимостей, включая баг с SSL, а также отсутствует поддержка TLS 1.2
Клонируем репозиторий с Django проектом:
$ cd ~ $ git clone https://github.com/adilkhash/planetpython_telegrambot.git $ cd planetpython_telegrambot/
$ pyenv virtualenv 2.7.11 telegram_bot $ pyenv local telegram_bot
Ставим зависимости через менеджер пакетов pip.
Pip install -r requirements.txt
Django приложение, написанное в первой части, претерпело незначительные изменения. В частности я перенёс изменяемые части кода в специальный.env файл, используя библиотеку django-environ. Ознакомиться с изменениями можно по этой ссылке .
Создаём.env файл из шаблона и заполняем необходимые настройки.
$ cd blog_telegram && mv .env-template .env && vi .env
В частности необходимо изменить режим DEBUG на False, прописать токен для Telegram бота и указать дополнительный хост через запятую в ALLOWED_HOSTS. В моём случае ALLOWED_HOSTS выглядит вот так:
ALLOWED_HOSTS=127.0.0.1,bot.сайт
То есть я завёл дополнительный поддомен на котором и будет крутиться Telegram бот.
Настройка SSL сертификатаВ прошлой статье я писал о том, что в случае использования API вызова setWehook, хосту необходимо иметь валидный SSL сертификатом (Telegram позволяет использовать также самоподписанные сертификаты). Сертификат мы будет создавать через бесплатный сервис выдачи SSL сертификатов Let"s Encrypt .
$ cd ~ && git clone https://github.com/letsencrypt/letsencrypt $ cd letsencrypt/ $ ./letsencrypt-auto certonly --standalone -d bot.сайт
Необходимо будет указать некоторые настройки и согласиться с условиями предоставления услуг. После успешного выполнения команд, сертификаты будут находиться в /etc/letsencrypt/live/bot.сайт/
Настройка NginxТеперь пора поставить популярный HTTP сервер nginx который в нашем случае будет выполнять роль проксирующего (принимать запросы от клиентов и передать их дальше следуя инструкциям в конфигурационном файле).
$ sudo apt-get install -y nginx $ cd /etc/nginx/sites-available/ $ sudo nano telegram_bot.conf
Заполняем новый файл telegram_bot.conf следующим содержимым:
Server { listen 80; listen 443 ssl; server_name bot..сайт/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/bot..pem; location / { proxy_set_header Host $http_host; proxy_redirect off; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Scheme $scheme; proxy_pass http://localhost:8001/; } }
ВНИМАНИЕ : Не забудьте заменить хост bot.сайт на свой собственный.
Прописываем наш новый конфиг в настройки nginx и перезагружаем его, чтобы изменения вступили в силу:
$ cd /etc/nginx/sites-enabled/ $ sudo ln -s ../sites-available/telegram_bot.conf telegram_bot.conf $ sudo service nginx restart
Что мы только что сделали?
- Прописали валидный SSL серификат для нашего сайта
- Все запросы, поступающие на хост, будут проксироваться на наше будущее Django приложение, которое в свою очередь, должно крутиться на 8001 порту.
- Передаём дополнительные HTTP заголовки в каждом запросе (хост, IP адрес клиента, схему https/http и так далее). Более подробно про настройки nginx можно прочитать .
Чтобы проверить успешность наших настроек, можно запустить django приложение через тестовый сервер командой runserver на 8001 порту и зайти на сайт:
$ cd ~/planetpython_telegrambot/ $ python manage.py runserver 8001
Открываем браузер и видим (я сразу открыл через https):
URL Not Found это нормальное явление, так как у нас задан всего 1 валидный URL для непосредственной работы с Telegram - /planet/bot// (не считая настройки Django админки).
Настройка Gunicorn через SupervisorПора приступить к настройке production-ready HTTP сервера Gunicorn , который, кстати, полностью написан на языке Python и хорошо зарекомендовал себя в реальном бою (к слову, во всех "живых" проектах я использую именно эту связку: nginx+gunicorn)
Что такое Supervisor?Supervisor это утилита процесс-менеджер. Она "следит за здоровьем" ваших процессов-демонов и в случае их падения, старается снова их поднять. Если в ходе работы Gunicorn "падает" (системная ошибка, не та фаза луны и так далее), Supervisor старается его снова "поднять", таким образом работоспособность сайта не страдает. К слову, у меня в планах есть идея написать небольшую заметку про эту утилиту, так сказать Supervisor Advanced Usage. Стоит отметить, что все процессы, запущенные в Supervisor должны работать в foreground режиме, чтобы утилита понимала когда что-то идёт не по плану.
Для начала составим конфигурационный файл для запуска Gunicorn внутри Supervisor. Его содержимое выглядит вот так:
Command=/home/django/.pyenv/versions/telegram_bot/bin/gunicorn blog_telegram.wsgi:application -b 127.0.0.1:8001 -w 1 --timeout=60 --graceful-timeout=60 --max-requests=1024 directory=/home/django/planetpython_telegrambot/ user=django redirect_stderr=True stdout_logfile=/tmp/gunicorn.log stderr_logfile=/tmp/gunicorn_err.log autostart=true autorestart=true startsecs=10 stopwaitsecs=10 priority=999
Сохраняем файл под именем gunicorn.conf (~/planetpython_telegrambot/gunicorn.conf ). К слову, Gunicorn прописан в зависимостях нашего проекта (requirements.txt ) и так как мы его уже установили в наше окружение, то узнать путь исполняемого файла можно выполнив команду внутри активированного виртуального окружения (активация происходит автоматически при переходе в директорию веб-приложения из-за наличия там файла .python-version , созданного через pyenv local):
$ pyenv which gunicorn
Содержимое конфигурационного файла для supervisord:
File=/tmp/telgram_bot_supervisord.sock logfile=/tmp/telgram_bot_supervisord.log logfile_maxbytes=50MB logfile_backups=10 loglevel=info pidfile=/tmp/telgram_bot_supervisord.pid nodaemon=false minfds=1024 minprocs=200 supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface serverurl=unix:///tmp/telgram_bot_supervisord.sock files = /home/django/planetpython_telegrambot/gunicorn.conf
Сохраняем в ~/planetpython_telegrambot/supervisord.conf
$ supervisord
Запуск должен пройти без каких либо ошибок. Чтобы узнать статус текущих процессов, запускаем утилиту supervisorctl:
$ supervisorctl gunicorn RUNNING pid 20901, uptime 0:04:18 supervisor>
Для получения помощи, можно выполнить команду help. А для получения информации о команде - help . Например:
Supervisor> help stop stop Stop a process stop:* Stop all processes in a group stop Stop multiple processes or groups stop all Stop all processes supervisor>
После успешного запуска supervisor, сайт должен быть доступен онлайн.
Автозапуск веб-приложения при перезагрузкеА что будет, если наш виртуальный сервер внезапно перезагрузится? (сбой в дата-центре, неполадки на хост машине, криворукий админ накосячил и т.д.). В случае такого сценария, сейчас наше приложение не будет запущено автоматически. Чтобы это исправить необходимо приложить ещё немного усилий дабы написать небольшой скрипт, который мы успешно поместим в механизм автозагрузки ОС Ubuntu (Debian-like дистрибутивов).
Доводилось ли вам слышать про так называемые upstart файлы? Именно написанием одного из них мы сейчас и займёмся. К слову, на текущий момент Upstart признана устаревшей и в новых версиях ОС на базе Linux планируется полный переход на systemd.
Description "Supervisor Telegram bot django app starting handler" start on runlevel stop on runlevel [!2345] respawn setuid django setgid django chdir /home/django/planetpython_telegrambot/ exec /home/django/.pyenv/versions/telegram_bot/bin/supervisord
Файл должен быть помещён в /etc/init/ (в моём случае я дал ему имя telegram_bot.conf). Если ранее все запуски не вызывали проблем, то после рестарта системы, приложение автоматически будет запущено:
$ sudo shutdown -r now
Теперь необходимо прописать наш URL на стороне Telegram используя вызов API метода setWebhook:
Import telepot bot_token = "BOT_TOKEN" bot = telepot.Bot(bot_token) bot.setWebhook("https://bot..format(bot_token=bot_token))
На этом настройка бота закончена. Посылаем команды нашему боту @PythonPlanetBot и получаем адекватные ответы:)
- логирование запросов от пользователей в файл
- вынес изменяемые настройки (режим debug, токен бота, секретный ключ) в переменные окружения через.env файлы, используя django-environ
- добавил шаблоны конфигурационных файлов для gunicorn, nginx и supervisor
Когда вышла Django 1.4 она включала обновленую структуру проекта, которая прошла долгий путь, чтобы стать основной, но здесь, собраны некоторые улучшения, чтобы сделать структуру лучше.
Подобный вопрос нам задают постоянно, поэтому я хочу потратить немного времени и рассказать все наше отношение к этому, чтобы всех клиентов можно было отправлять к этому документу. Эта заметка написана для Django 1.7.1, но может быть легко применена для всех Django версий выше 1.4.
Почему данная структура лучшеПредположим, у вас есть 2 приложения blog и users и 2 окружения dev и prod , значит, ваш проект должен иметь следующий вид:
myproject/ manage.py myproject/ __init__.py urls.py wsgi.py settings/ __init__.py base.py dev.py prod.py blog/ __init__.py models.py managers.py views.py urls.py templates/ blog/ base.html list.html detail.html static/ … tests/ __init__.py test_models.py test_managers.py test_views.py users/ __init__.py models.py views.py urls.py templates/ users/ base.html list.html detail.html static/ … tests/ __init__.py test_models.py test_views.py static/ css/ … js/ … templates/ base.html index.html requirements/ base.txt dev.txt test.txt prod.txt
Продолжение этой статьи расскажет, как привести свой проект к такой структуре и почему она лучше.
Текущая структура по умолчаниюМы начнем с создания нового проекта с именем foo , да, я знаю, что это очень креативное название. Мы предполагаем здесь, что дальше проект будет расположен на домене foo.com , но почему название проекта должно точно повторять домен, ведь проект всеравно будет жить и без всяких подобных требований.
Если вы запустите свой проект с помощью команды django-admin.py startproject foo , вы получите следующую структуру:
foo/ manage.py foo/ __init__.py settings.py urls.py wsgi.py
Эта схема очень хороша для старта. У нас есть корневая директория foo , которая содержит наш manage.py и директорию проекта foo/foo . Эту директорию можно добавить в свою систему контроля версия, например в git.
Вы можете подумать, что директория foo/foo начало проекта, где все кроме этого это Django приложения или вспомогательные файлы относящиеся к проекту.
Исправляем настройкиНаша первая миссия, это исправить ваш плохой файл настроек. Мы показали данную архитектуру нашим клиентам и были впечатлены, как мало людей знают, что такое можно реализовать. Я виню в этом тот факт, что каждый знает, что файл настроек это просто Python код, но они не думают о нем, как о Python коде.
И так, давайте исправим наши настройки. Для нашего проекта foo реализуем схему с 4 окружениями: dev, stage, jenkins, и production. Давайте дадим каждому окружения свой собственный файл. Процесс для этого следующий:
from base import *
Так, почему это важно? Для локальной разработки вам требуется DEBUG =True , но вы также, можете случайно выкатить это и в продакшен, поэтому просто откройте foo/foo/settings/production.py и после первой строки импорта вставьте DEBUG =False . Теперь, ваш продакшен сайт защищен от такой случайности.
Что еще вы можете настроить? Достаточно очевидно, что для каждого окружения вы захотите иметь различные базы данных, например на разных хостах. Для этого, просто внесите эти настройки в соответствубщие файлы настроек.
Использование этих настроекИспользование этих настроект очень легкое и не зависит от того, какой метод вы предпочитаете. Для использования настроек определенного окружения, вы должны всего лишь:
export DJANGO_SETTINGS_MODULE = “foo.settings.jenkins”
И бум, вы теперь используете jenkins настройки.
Или вы можете предпочесть передачу настроек через коммандную строку:
./manage.py migrate -settings= foo.settings.production
Или используя gunicorn:
gunicorn -w 4 -b 127.0.0.1:8001 -settings= foo.settings.dev
Что еще должно быть настроено?Другая часто используемая уловка с Django настройками, это изменить тип некоторых настроек с tuple на list. Для примера, INSTALLED_APPS изменить с:
INSTALLED_APPS = ( … )
INSTALLED_APPS = [ … ]
В foo/settings/base.py мы теперь можем проще добавлять и удалять приложения основываясь на конкретном файле настроек для текущего окружения. Для примера, возможно вам требуется модуль django-debug-toolbar установленным только в dev окружении.
Этот трюк также часто используется с настройками TEMPLATE_DIRS и MIDDLEWARE_CLASSES .
Еще один часто используемый трюк, это разбить ваши приложения на 2 списка, первый это глобальные зависимости, второй - специфичные для данного проекта. Как, например, здесь:
PREREQ_APPS = [ ‘ django . contrib . auth ’ , ‘ django . contrib . contenttypes ’ , … ‘ debug_toolbar ’ , ‘ imagekit ’ , ‘ haystack ’ , ] PROJECT_APPS = [ ‘ homepage ’ , ‘ users ’ , ‘ blog ’ , ] INSTALLED_APPS = PREREQ_APPS + PROJECT_APPS
Почему это часто используется? Во первых, это помогает лучше различать Django core компоненты, сторонние приложения и внутренние, специфичные для данного проекта. Тем не менее, PROJECT_APPS часто управляет списком специфичных пакетов, для вещей таких как: тестирование и покрытие кода тестами. Вы имеет список с вашими приложениями, поэтому можете легко и автоматизированно убедиться, что все тесты были запущены только для них, а не для каких-то посторонних модулей.
Исправляем зависимостиБольшинство проектов содержат лишь один файл requirements.txt , который ставит зависимости примерно так:
pip install -r requirements.txt
Этого достаточно для маленьких проектов, но малоизвестная возможность requirements файлов это использование ключа -f для включения других файлов:
R base.txt pytest == 2.5.2 coverage == 3.7.1
Я признаю, что это не огромная выгода, но это позволяет разделить зависимости на каждое окружение. Но для успокоения совести скажу, что это позволяет увеличить скорость установки пакетов, ведь вам не требуется стаивть на продакшен инсталяции пакеты, которые не будут использоваться.
Тестовые файлыПочему мы разделяем тесты так сильно? Главная причина, если вы пишете достаточное количество тестов в одном файле tests.py для каждого приложения, то в конце концов он станет огромным и не поддерживаемым. Это плохо для читабельности, но также это простой факт, что вы тратите много времени на пролистывание текста.
В итоге, вы уменьшите количество мердж конфликтов при работе в команде, что является положительной чертой. Маленькие файлы - ваши друзья.
Ссылки (URLs)Для маленьких проектов заманчиво определять все ссылки в одном файле foo/urls.py для сохранения их в одном месте. Как бы то ни было, если ваша цель это ясность и реиспользование, вы должны определять ссылки в каждом приложении и загружать их в корневом файле. Вместо:
urlpatterns = patterns (‘’ , url (r ’ ^ $’ , HomePageView . as_view (), name = ‘ home ’ ), url (r ’ ^ blog / $’ , BlogList . as_view (), name = ‘ blog_list ’ ), url (r ’ ^ blog / (? P < pk > \d + ) / $’ , BlogDetail . as_view (), name = ‘ blog_detail ’ ), … url (r ’ ^ user / list / $’ , UserList . as_view (), name = ‘ user_list ’ ), url (r ’ ^ user / (? P < username > \w + ) / $’ , UserDetail . as_view (), name = ‘ user_detail ’ ), )
вы должны использовать:
urlpatterns = patterns (‘’ , url (r ’ ^ $’ , HomePageView . as_view (), name = ‘ home ’ ), url (r ’ ^ blog / ‘ , include (‘ blog . urls ’ )), url (r ’ ^ user / ‘ , include (‘ user . urls ’ )), )
Шаблоны и статические файлыИспользование templates/ и static/ директорий на каждое приложение дает способность к реиспользованию этого приложения в другом проекте как есть, без изменений.
В этом случае, приложение предоставляет шаблоны по умолчанию, а также различные вспомогательные файлы, такие как специальные Javascript файлы и поставляется все это в одном пакете.
Также, это дает нам возможность переопределить шаблоны на каждый проект базируясь на директории foo/templates/ . При добавлении шаблона templates/blog/detail.html мы перезаписываем или скрываем шаблон по умолчанию blog/templates/blog/detail.html .
Переиспользование Django приложенийДопустим, вы используете предлагаемую структуру проекта некоторое время, однажды, вы поймете, что ваш новый проект нуждается в блоге и один из ваших проектов прекрасно к этому подходит. Вы скопируете файлы в … НЕ ПРАВИЛЬНО! Теперь вы имеете две копии приложения. Исправления ошибок или новые функции в одном, будут вручную переноситься между проектами если предположить, что вы всегда помните про это.
Вместо этого, сделайте новый репозиторий для вашего блога и вставьте в него директорию foo/blog/ . И настройте, чтобы ваш существующий проект foo и новый проект, для установки блога через pip.
Они смогут использовать различные версии приложения, если это важно, или использовать всегда последнюю версию для получения всех исправлений и новых функций, как и разработчик. Вы все еще можете переопределять шаблоны и статические файлы в каждом проекте отдельно.
Дополнительные ресурсыНаши друзья Дэнни и Аудрей из CartWheel Web напомнили нам про Cookie Cutter и специальный cookiecutter-django от Дэнни, мощная утилита для создания начального проекта, быстро и повторяемо.
Кроме того, если вы ищете все про Django уловки и рекомендации, вы не можете пройти мимо книги Two Scoops of Django: Best Practices For Django 1.6 которую мы рекомендуем всем нашим клиентам.
Обратная связьМы надеемся, вы нашли данное улучшение архитектуры проекта полезным. Если вы нашли какой-то баг или имеет предложение иил просто хотите пообщаться, пишите нам. Спасибо за прочтение.
- Tutorial
- работает под управлением полноценного Linux,
- долгое время лежит на столе и пылится.
Для начала необходимо найти малинку в сети, чтобы подключиться к ней по ssh.
nmap -sP 192.168.1.1/24 | grep raspberry
В моем случае в сети две малинки, одна из которых моя с IP адресом 192.168.1.100. В некоторых сетях nmap не показывает сетевые имена устройств. 
В этом случае найти raspberry pi можно по MAC-адресу, который имеет префикс B8:27:EB.
sudo nmap -sP -n 192.168.1.1/24 | grep -B 2 B8:27:EB
Параметр -B для grep определяет какое количество предшествующих строк следует вывести.
Подключаемся к малинке по ssh.
ssh [email protected]
Для начала разгоним малинку до 1 ГГц с помощью raspi-config .
Устанавливаем питоновский менеджер пакетов
sudo apt-get install python-pip
Переходим к установке необходимых пакетов. В моем web приложении используется СУБД MySQL. В качестве Frontend и Backend используется nginx и gunicorn соответственно.
sudo apt-get install nginx gunicorn mysql-client mysql-server python-mysqldb
В процессе установки mysql необходимо ввести данные для root пользователя СУБД. python-mysqldb
- драйвер, необходимый при работе с моделями в Django. Django установим из питоновских репозиториев.
sudo pip install django
На момент написания статьи актуальные версии nginx и gunicorn в репозиториях для малинки 1.2.1 и 0.14.5 соответственно. Версия MySQL для малинки 5.5. Так же для работы с Django необходимо установить SciPy .
sudo apt-get install python-scipy
Nginx 1.2.1 устарел. Более новый можно собрать из исходников . Свежий gunicorn можно установить из питоновских репозиториев.
Настройка сервера Размещаем web-приложение на малинке (например в /home/pi).Если у Вас есть рабочие конфиги, то достаточно их скопировать в соответствующие директории:
- для nginx /etc/nginx/sites-enabled/
- для gunicorn /etc/gunicorn.d/
CONFIG = { "mode": "wsgi", "working_dir": "/home/pi/project", #"working_dir": "/home/pi/project/project", "user": "www-data", "group": "www-data", "python": "/usr/bin/python", "args": ("--bind=127.0.0.1:8081", "--workers=5", # 5 достаточно для малинки "--graceful-timeout=60", "--timeout=60", #"--debug", #"wsgi:application", "project.wsgi",), }
Если working_dir (путь к файлу wsgy.py) указать "/home/pi/project/project" , а в args указать "wsgi:application" , то на малинке воркеры сначала стартуют, потом умирают без указания причины (под Ubuntu, например, gunicorn работает с обоими вариантами настроек).
Перенос MySQL Дамп имеющейся БД можно сделать с помощью утилиты mysqldump .mysqldump -u root -p dbname > dbname.sql
Полученный файл состоит из набора SQL-инструкций, которые восстанавливают структуру, а так же информацию, хранимую в базе данных. 
На малинке создаем базу данных. Запускаем mysql shell.
mysql -u root -p
Добавляем новую базу данных.
mysql> create database dbname character set utf8 collate utf8_general_ci;
mysql> grant all privileges on dbname.* to someusr@localhost identified by "somepassword";
Восстанавливаем данные с дампа. При размере дампа в 162 Мб время восстановления составило около 10 минут.
mysql -u root -p dbname < dbname.sql
Следует отметить, что базы данных лучше хранить на внешнем накопителе, иначе micro SD карта может быстро придти в негодность из-за частых операций записи. Как это сделать можно почитать . Конфиг mysql расположен по пути /etc/mysql/my.cnf
Проверка Перезапускаем nginx и gunicorn. Если все настроено верно, можно открыть главную страницу.
Переходим к нагрузочному тестированию. Установим apache benchmark.
sudo apt-get install apache2-utils
Протестируем в 4 потока 1000 запросами Raspberry PI модель B+.
ab -c 4 -n 1000 http://192.168.1.100/
Vladislav@vladislav-N53SV:~$ ab -c 4 -n 1000 http://192.168.1.100/
This is ApacheBench, Version 2.3
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 192.168.1.100 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: nginx/1.8.0
Server Hostname: 192.168.1.100
Server Port: 80
Document Path: /
Document Length: 24839 bytes
Concurrency Level: 4
Time taken for tests: 1309.607 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 25018000 bytes
HTML transferred: 24839000 bytes
Requests per second: 0.76 [#/sec] (mean)
Time per request: 5238.429 (mean)
Time per request: 1309.607 (mean, across all concurrent requests)
Transfer rate: 18.66 received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.1 1 1
Processing: 4924 5237 91.4 5227 6419
Waiting: 4919 5227 91.3 5217 6403
Total: 4925 5238 91.4 5228 6420
Percentage of the requests served within a certain time (ms)
50% 5228
66% 5245
75% 5255
80% 5265
90% 5296
95% 5335
98% 5382
99% 5667
100% 6420 (longest request)
Запросы идут медленно, поскольку большую часть времени запроса занимает работа с БД. Ко мне недавно пришла Raspberry PI 2 модель B. Посмотрим на что она способна c теми же настройками и данными.
vladislav@vladislav-N53SV:~$ ab -c 4 -n 1000 http://192.168.1.14/
This is ApacheBench, Version 2.3
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 192.168.1.14 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: nginx/1.8.0
Server Hostname: 192.168.1.14
Server Port: 80
Document Path: /
Document Length: 24838 bytes
Concurrency Level: 4
Time taken for tests: 170.083 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 25017000 bytes
HTML transferred: 24838000 bytes
Requests per second: 5.88 [#/sec] (mean)
Time per request: 680.330 (mean)
Time per request: 170.083 (mean, across all concurrent requests)
Transfer rate: 143.64 received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.1 1 1
Processing: 569 678 104.6 650 1338
Waiting: 567 676 104.1 647 1334
Total: 569 679 104.6 651 1338
Percentage of the requests served within a certain time (ms)
50% 651
66% 682
75% 708
80% 727
90% 796
95% 890
98% 1045
99% 1138
100% 1338 (longest request)
Raspberry PI 2 обрабатывает запросы в среднем в 6,16 раз быстрее. Разработчики малинки не обманули.
Регистрация хоста
Если у вас есть учетная запись - проходим авторизацию, иначе регистрируемся . После авторизации попадаем сюда .
Кликаем AddHost и заполняем форму.
Внизу кликаем кнопку AddHost
Хост добавлен. Справа от имени хоста отображается внешний IP адрес Вашей сети.
(например 192.168.1.1). WAN->DDNS.
Выбираем сервис no-ip.com, указываем регистрационные данные, а так же наш добавленный хост (technopark-test.ddns.net).
Остальные параметры выставляем по собственному желанию.
Теперь при смене внешнего IP адреса наше приложение остается доступным в сети.Настройка переадресации портов Нам нужно, чтобы при обращении к хосту малинка отдавала веб приложение. Роутер занимается перенаправлением входящих пакетов, пришедших из вне с порта X на внутренный порт Y. В меню роутера переходим WAN->Переадресация портов. Необходимо перенаправлять внешний 80 порт на 80 порт малинки. Добавим новое правило и применим изменения.
Теперь малинка обрабатывает все приходящие пакеты на 80 порту. Проверим, введя в адресной строке браузера хост, полученный в No IP.
Теперь наше веб приложение доступно для пользователей сети Интернет.Настраиваем DDNS на малинке Этот вариант не подходит, если малинка имеет частный IP , поскольку она будет оправлять свой локальный IP адрес на на сервис No IP. Это еще один способ узнать IP адрес малинки локальной сети. Установим DDNS клиент.
sudo apt-get install ddclient
Во время установки необходимо выбрать сервис. Выбираем other и вводим dynupdate.no-ip.com, протокол dyndns2, имя пользователя, пароль, интерфейс - eth0, имя хоста.
Для проверки я выставил интервал обновления IP в 60 секунд. В файле /etc/default/ddclient необходимо выставить значение daemon_interval=«60».
Все же мне было интересно попробовать управлять GPIO Raspberry PI из django. Я разработал простое web приложение, которое объединило мои ранние наработки. Оно позволяет посмотреть температуру и влажность, измеренные с помощью DHT11, некоторую полезную информацию, управляет 8-ми релейным модулем (который может быть использован для управления электроприборами) и отправляет текст на tm1638.
Для управления GPIO необходимо запускать сервер с правами root. Это потенциальная уязвимость.
Полноценное использования web приложения предполагает работу сервера без прав суперпользователя, настройку https, добавление возможности администрирования учетных записей, ведение логов, разделение доступа к управляемым устройствам, работу электроприборов по расписанию и многое другое.
Впрочем это уже совсем другая история статья.
Добавить метки
Я уже очень давно слежу за развитием проекта DjangoCMS и честно скажу что он не всегда мне нравился. Но постепенно команда проекта исправила многие косяки и сделала эту CMS по-настоящему удобной, гибкой и функциональной. После этого я стал практически фанатом DjangoCMS и использую его в некоторых своих проектах (например этот блог). Сегодня я подробно расскажу что такое DjangoCMS , в каких случаях его удобно применять и покажу как с помощью него создать простой сайт. Надеюсь вы тоже полюбите этот инструмент:)
На данный момент основная проблема DjangoCMS - отсутствие нормальной документации. Первое что я нашёл на официальном сайте проекта , это инструкция как создать сайт с помощью DjangoCMS и развернуть его на облачной платформе Divio Cloud . Из этой инструкции конечно можно выцепить какое-то количество полезной информации, но я как разработчик, жду совсем другого, тем более что я не планирую использовать Divio Cloud , а хочу развернуть приложение на DjangoCMS где-нибудь у себя. Самое интересное, что существует официальная документация для разработчиков по DjangoCMS , но данную ссылку я нашёл в файле README.md из репозитория проекта на GitHub, в то время как на сайте её почему-то нет.
Есть одна вещь, за которую стоит отдельно похвалить команду Divio - грамотная поддержка в online-чате на сайте проекта DjangoCMS , куда можно задавать вопросы любой сложности! Многие вещи о которых не сказано в документации я узнал лично от ребят из Divio во время переписки с ними. Там есть и наши соотечественники которые отвечали по русски, за что им отдельный респект:)
Хватит лирики, приступаем к созданию собственного сайта на DjangoCMS !
Установка DjangoCMSВ начале необходимо создать и активировать виртуальное окружение для нашего проекта. Для этого выполните команду:
Virtualenv env source env/bin/activate
Если вы хотите использовать в своём проекте Python 3 , то первую команду нужно заменить на:
Virtualenv --python=/usr/bin/python3.5 env
Только не забудьте проверить правильность пути к интерпретатору Python 3 , так как у вас он может отличаться.
После того как виртуальное окружение создано и активировано нам нужно поставить установщик DjangoCMS - пакет djangocms-installer :
Pip install djangocms-installer
djangocms-installer ставит все необходимые пакеты для работы DjangoCMS . После этого ваше виртуальное окружение начинает поддерживать команду djangocms , которой мы скоро воспользуемся.
Создаём директорию для нашего проекта и переходим в неё:
Mkdir django_cms_project cd django_cms_project
И наконец создаём наше приложение на DjangoCMS с помощью команды:
Djangocms -f -p . django_cms_example
- Флаг -f говорит о том что дополнительно будет установлен инструмент Django Filer , который отвечает за работу с файловой системой. Мне данный инструмент нравится и я рекомендую его использовать.
- Флаг -p с точкой (-p . ) задаёт текущую директорию как родительскую для проекта.
- djangocms_blog - название нашего приложения. Вы можете указать своё собственное.
В старых версиях установщик DjangoCMS задавал вопросы по конфигурированию приложения во время установки. В новой версии приложение конфигурируется автоматически, а так же создаётся суперпользователь с логином admin и паролем admin . После установки вы можете запустить приложение командой:
Python manage.py runserver
После выполнения команды откройте в браузере ссылку http://127.0.0.1:8000/ . Если всё сделано правильно, вы должны увидеть форму входа в панель администрирования Django :
Для входа просто введите логин admin и пароль admin . На этом процесс установки DjangoCMS можно считать завершённым.
НастройкаОткройте в своей любимой IDE (лично я предпочитаю PyCharm ) только что созданный проект. В моём случае файлы проекта располагаются в директории djangocms_blog_project . Структура созданного проекта должна быть примерно такой:
Как Вы видите, это обычный Django -проект, только с прикрученным DjangoCMS в настройках (файл settings.py ). В целом наш проект и так прекрасно запускается и работает, но Вы должны помнить что по умолчанию будет использоваться база данных SQLite , которая хорошо подходит для отладки, но совсем не подходит для работы в реальных условиях. Кроме этого DjangoCMS очень много информации хранит именно в базе: контент, меню, список страниц, настройки каждой страницы, посты и т.д. То есть при переходе на другую базу данных придётся делать миграцию и я рекомендую сразу использовать ту базу данных, дамп которой можно потом перенести на продакшен. Но это просто рекомендация, можно успешно отладить приложение, используя SQLite и фейковую информацию на страницах, а затем на новой базе собрать чистовой вариант уже на отлаженных шаблонах. Или же, как правильно заметил Dmytro Kyrychuk в комментариях, использовать команды manage.py dumpdata и loaddata (эти команды подробно описаны тут: https://docs.djangoproject.com/en/1.10/ref/django-admin/ ) для того, чтобы сдампить одну базу в JSON и восстановить дамп уже на другой базе.
Так как мой проект демонстрационный, я оставляю настройки базы данных без изменений:
DATABASES = { "default": { "CONN_MAX_AGE": 0, "ENGINE": "django.db.backends.sqlite3", "HOST": "localhost", "NAME": "project.db", "PASSWORD": "", "PORT": "", "USER": "" } }
Других настроек на данном этапе не требуется.
Создание шаблоновПрежде чем создавать страницы нашего сайта-блога нам нужны шаблоны на основе которых будут создаваться эти самые страницы. Наверняка вы захотите использовать собственный неповторимый дизайн чтоб было лучше чем у соседа, поэтому нам нужно в начале погрузиться в вёрстку. Шаблоны DjangoCMS это обычные файлы в формате .html с некоторым количеством шаблонных тегов Django и DjangoCMS . При создании нового проектаавтоматически генерируется 4 шаблона в папке templates (в моём случае djangocms_blog_project/djangocms_blog/templates) :
- base.html - базовый шаблон, от которого наследуются все остальные шаблоны
- fullwidth.html - шаблон полноразмерной страницы с контентом на всю ширину экрана
- sidebar_left.html - страница с левым сайдбаром
- sidebar_right.html - страница с правым сайдбаром
Кроме того, список шаблонов обязательно должен быть задан в settings.py в переменной CMS_TEMPLATES для того чтобы можно было выбрать нужный шаблон в интерфейсе при создании новой страницы сайта. По умолчанию у нас сконфигурировано 3 шаблона (все кроме base.html ):
CMS_TEMPLATES = (## Customize this ("fullwidth.html", "Fullwidth"), ("sidebar_left.html", "Sidebar Left"), ("sidebar_right.html", "Sidebar Right"))
Тут всё просто: нужно задать реальное название файла шаблона и произвольное название, которое будет отображаться в интерфейсе. Если вы создаёте новый шаблон, то в обязательном порядке вносите его в CMS_TEMPLATES , иначе вы не сможете им воспользоваться.
Давайте создадим первую страницу с использованием тех шаблонов, что у нас уже есть. После того как вы вошли в панель администрирования под логином admin (см. выше), должны увидеть вот такую страницу:
Выберите пункт Новая страница (Создать страницу рядом с текущей) и нажмите Далее . Откроется вот такое окно:
Заполните заголовок (Главная ), путь к странице (index ) и содержимое (Hello world! ), а затем нажмите кнопку Создать . Всё! Страница готова:
Теперь в верхнем меню выберите Страница > Шаблоны :
В выпадающем меню жирным шрифтом должен быть выделен текущий шаблон страницы, но так как мы его явно не задавали, то по умолчанию стоит значение Наследовать шаблон от ближайшего предка . В нашем случае ближайшим предком является шаблон fullwidth.html . Выберите его и вы увидите что ничего не изменилось в дизайне страницы.
Теперь предлагаю подробно разобрать код шаблона fullwidth.html , но так как он наследуется от base.html , то начнём с базового шаблона:
{% block title %}This is my new project home page{% endblock title %} .nav { padding-left: 0; } .nav li { display: inline; list-style-type: none; padding-right: 20px; } .container { width: 940px; margin: 0 auto } .content { float: left; width: 80%; } .sidebar { float: left; width: 20%; } {% render_block "css" %} {% cms_toolbar %} {% render_block "js" %}
Что тут происходит? Да ничего особенного. В первой строке мы загружаем шаблонные теги:
- cms_tags - теги DjangoCMS (http://docs.django-cms.org/en/release-3.4.x/reference/templatetags.html)
- menu_tags - теги для управления меню (http://docs.django-cms.org/en/release-3.4.x/reference/navigation.html)
- sekizai_tags - теги django-sekizai (https://django-sekizai.readthedocs.io/en/latest/)
Так же у нас в шаблоне 2 блока, которые можно переопределить в дочерних шаблонах: {% block title %} и {% block content %} .
Кроме этого у нас есть:
- тег ответственный за отображение тулбара DjangoCMS - {% cms_toolbar %}
- теги django-sekizai , которые отвечают за размещение блоков со ссылками на css и js в определённых частях страницы - {% render_block "css" %} и {% render_block "js" %}
- тег, ответственный за отображение меню - {% show_menu 0 100 100 100 %}
Всё остальное вы и так знаете. Переходим к шаблону fullwidth.html :
{% extends "base.html" %} {% load cms_tags %} {% block title %}{% page_attribute "page_title" %}{% endblock title %} {% block content %} {% placeholder "content" %} {% endblock content %}
По факту перед нами стандартный шаблон Django отнаследованный от base.html . Из интересного тут 2 тега DjangoCMS :
- тег {% page_attribute "page_title" %} - отображает атрибут страницы page_title в блоке title . Данный атрибут задаётся при создании страницы и является её заголовком. Все атрибуты можно просмотреть в документации .
- тег {% placeholder "content" %} - это очень важный тег, который задаёт изменяемую часть страницы в блоке content . Количество плейсхолдеров на странице может быть неограниченным, главное чтоб название каждого плейсхолдера было уникальным. В панели администратора DjangoCMS можно менять содержимое любого плейсхолдера на своё усмотрение, например туда можно добавить текст, ссылку, картинку и т.д., а можно всё сразу и в любых комбинациях:)
Вот вы уже имеете некоторое представление о шаблонах DjangoCMS . Приведённые выше шаблоны я полностью изменю и доработаю, так как хочу чтобы сайт имел красивый дизайн. Это всё реализуется очень просто, но прежде чем менять шаблоны, давайте заглянем в панель администрирования DjangoCMS , для того чтобы лучше разобраться с плейсхолдерами. Нажмите кнопку Структура на верхней панели и вы увидите вот такую страницу:
Содержимое - это наш плейсхолдер content из шаблона fullwidth.html . Он содержит один единственный плагин, который отображает строчку Hello world! . Вы можете в любой момент отредактировать содержимое плагина, а так же добавлять другие плагины в плейсхолдер и даже создавать свои собственные плагины (об этом я расскажу в другой статье).
Для наглядности добавим ещё один плагин в плейсхолдер content . Для этого нажмите кнопку + и в появившемся окне выберите из списка плагин Google Map :
В открывшемся окне задайте название карты (поле MAP TITLE ), а так же широту и долготу своего города (поля LATITUDE и LONGITUDE ). В качестве названия у меня просто слово Карта , широта 55.751244 , долгота 37.618423 :
В верхней панели появилась синяя кнопка Опубликовать изменения страницы . Нажмите её и вы увидите обновлённую главную страницу с картой:
Вот так легко и просто можно управлять содержимым страницы в DjangoCMS .
Теперь я покажу как кардинально изменить дизайн сайта. Больше всего мне нравится в DjangoCMS то что можно взять практически любой html -шаблон и с минимальными изменениями встроить его в свой проект. В качестве примера я нашёл в интернете бесплатный адаптивный шаблон, свёрстанный с помощью CSS -фреймворка Bootstrap .
Для начала изменим содержимое базового шаблона base.html :
{% load cms_tags menu_tags sekizai_tags %} {% render_block "css" %} {% cms_toolbar %} Меню Меню Алексей Кутепов
{% block header %} {% placeholder "title" %} {% placeholder "sub_title" %} {% endblock header %} {% block content %}{% endblock content %} {% render_block "js" %}Я не буду подробно разбирать этот код, так как статья про DjangoCMS , а не про вёрстку. Тем более вы можете использовать любой другой шаблон вместо этого или создать свой собственный. Данный шаблон я брал "как есть" и дополнил его тегами Django и DjangoCMS , о которых мы сейчас и поговорим.
Как всегда в самом начале мы должны загрузить все необходимые шаблонные теги:
{% load cms_tags menu_tags sekizai_tags %}
{% block title %}Сайт Алексея Кутепова{% endblock title %}
{% render_block "css" %}
Обратите внимание на переменную {{ STATIC_URL }} - в место него Django автоматически подставляет путь до папки со статикой. Так же в конце присутствует тег {% render_block "css" %} , который на данном этапе бесполезен, но при усложнении шаблона может здорово помочь: вместо этого тега можно динамически подставлять таблицы стилей в зависимости от определённых условий.
После тега нужно не забыть поставить шаблонный тег {% cms_toolbar %} , так как он отвечает за отображение верхней панели инструментов в режиме редактирования сайта. Как вы могли убедиться, мы её используем довольно часто и без неё у нас просто не будет возможности вносить изменения.
Меню Меню Алексей Кутепов
В шаблоне предусмотрен красивый хедер с фоновым изображением. Код, который отвечает за отображение хедера я заключил в блок header для того чтобы его можно было переопределить в дочерних шаблонах. Кроме того, в хедере у нас есть заголовок и подзаголовок, вместо которых я добавил плейсхолдеры title и sub_title , для того чтобы их можно было динамически изменять. При загрузке фонового изображения обязательно используется переменная {{ STATIC_URL }} :
{% block header %} {% placeholder "title" %} {% placeholder "sub_title" %} {% endblock header %}
После хедера идёт блок content , с которым вы знакомы по предыдущему шаблону:
{% block content %}{% endblock content %}
Далее идёт футер, в котором я использовал новый шаблонный тег - . Основное отличие тега static_placeholder от placeholder заключается в том что содержимое static_placeholder наследуется дочерними шаблонами. В данном случае нам достаточно один раз задать значение {% static_placeholder "copyright" %} на главной странице и оно автоматически будет отображаться на других страницах нашего сайта:
Copyright {% static_placeholder "copyright" %}
В самом конце мы загружаем все необходимые скрипты из папки со статикой:
{% render_block "js" %}
Теперь чтобы новый шаблон отобразился корректно, нужно поместить все зависимости в папку django_cms_project/django_cms_example/static/ , для этого просто скопируйте их из репозитория данного проекта на GitHub .
Перезагрузите сервер и обновите страницу в браузере. Если вы всё сделали правильно, то должны увидеть сайт уже в обновлённом дизайне:
Пока ещё не вся информация отображается на странице, так как мы ещё не заполнили новые плейсхолдеры. Нажмите синюю кнопку Редактировать страницу на верхней панели, а затем на кнопку Структура . Как вы видите, в структуре страницы появились 3 новых плейсхолдера: Title (у меня система перевела название этого плейсхолдера на русский язык как Заголовок ), Sub_Title и Copyright .
Теперь нужно заполнить эти плейсхолдеры какой-либо информацией, для этого нажмите на кнопку + возле каждого из новых плейсхолдеров, в открывшемся окне выберите плагин Текст , после этого откроется редактор. Нажмите кнопку Источник в панели инструментов редактора и введите любой текст.
Кроме того у нас ещё есть плейсхолдер content (Содержимое ), который мы заполняли ранее. Удалите из него плагин Google Map и откройте на редактирование плагин Текст . Затем нажмите кнопку Источник в редакторе и введите произвольный текст, заключённый в теги:
Произвольный текст
Я заполнил плейсхолдеры вот так:
Отлично! Теперь нас есть полноценная первая страница сайта. Давайте для примера создадим новый шаблон и сделаем ещё одну страницу. Предположим нам нужен особенный шаблон для раздела с контактами на сайте. Для этой цели создайте в папке templates файл contacts.html с таким содержимым:
{% extends "base.html" %}
{% load cms_tags %}
{% block title %}{% page_attribute "page_title" %}{% endblock title %}
{% block header %}
{% placeholder "title" %}
{% placeholder "sub_title" %}
{% endblock header %}
{% block content %}
Контакты
{% placeholder "email" %}
{% placeholder "skype" %}
{% placeholder "phone" %}
Я в социальных сетях
{% placeholder "vk" %}
{% placeholder "facebook" %}
{% placeholder "linkedin" %}
{% placeholder "github" %}
{% endblock content %}
В этом коде нет ничего нового, я просто сверстал список контактов и добавил для каждого контакта свой плейсхолдер. Ещё я для красоты переопределил блок header . Теперь нужно добавить этот шаблон в settings.py :
CMS_TEMPLATES = (## Customize this ("fullwidth.html", "Fullwidth"), ("sidebar_left.html", "Sidebar Left"), ("sidebar_right.html", "Sidebar Right"), ("contacts.html", "Contacts"))
Теперь перезагрузите сервер и создайте новую страницу, выбрав в верхней панели Страница > Создать страницу > Новая страница :
Заполните все поля в появившемся окне и нажмите кнопку Сохранить и продолжить редактирование :
В новом окне нажмите кнопку Расширенные настройки и выберите шаблон Contacts из выпадающего списка:
Нажмите синюю кнопку Сохранить и вы будете автоматически перенаправлены в раздел Структура новой страницы. Необходимо заполнить все плейсхолдеры используя плагины Текст и Ссылка :
Основные поля:
- DISPLAY NAME - отображаемое название ссылки
- EXTERNAL LINK - используется в том случае, если ссылка идёт на внешний ресурс
- INTERNAL LINK - позволяет ссылаться на внутренние страницы сайта
- Link settings - в этом разделе для нас интерес представляют поля, которые позволяют сформировать ссылку для электронной почты и телефона
Как видите, сложного ничего нет. Плагин простой, удобный в использовании и довольно функциональный. Я уверен что вы без труда сможете им пользоваться.
Теперь вернёмся к нашей новой странице. После заполнения всех плейсхолдеров необходимо нажать синюю кнопку Опубликовать страницу немедленно в верхней панели инструментов. Все внесённые изменения на странице будут сохранены, сама страница опубликована и в главном меню сайта появится новый пункт Контакты . Вот что должно получиться в итоге:
У нас получился небольшой и красивый сайт, но так как данный проект демонстрационный, тут можно ещё много чего доработать. Теперь вы знаете основы работы с DjangoCMS и уже можете создать свой собственный сайт на основе данного фреймворка.
В этой статье я затронул только малую часть возможностей DjangoCMS , поэтому будет продолжение, где я расскажу о плагинах, сторонних дополнениях и кастомизации функционала сайта.
Django - это Open Source фреймворк для создания веб-приложений различной сложности. Одним из основных преимуществ Django является то, что вам нужно позаботиться только о логике вашего будущего приложения, остальное сделает Django.
Мы создадим веб-приложение, у которого будет панель администратора и возможность загружать загадки, а у пользователей, соответственно, возможность отвечать на них. Во время разработки будут использоваться Python 3.4.3 и Django 1.9.1.
Устанавливаем DjangoДелается это очень просто, в командной строке нужно написать: pip install Django==1.9.1 .
Создаем проектЕсли вы правильно установили Django, то после запуска django-admin --version вы увидите текущую версию фреймворка. Теперь создадим проект. Это можно сделать следующим образом: django-admin startproject django_example .
Как только создание проекта будет завершено, взглянем на директорию нашего проекта:
- django_example/__init__.py - пустой файл, который говорит Python, что данная директория должна восприниматься в качестве пакета.
- django_example/settings.py содержит конфигурацию нашего проекта.
- django_example/urls.py - здесь объявляются URL.
- django_example/wsgi.py - с помощью него приложение может работать с веб-сервером по протоколу WSGI.
- manage.py позволяет взаимодействовать с проектом.
Теперь пришло время запустить наше приложение. Для этого в командной строке нужно написать python manage.py runserver . После этого в адресной строке браузера нужно написать: http://127.0.0.1:8000/ . Если вы увидели «You have unapplied migrations; your app may not work properly until they are applied.», то не волнуйтесь, мы вернемся к этому чуть позже.
Создаем приложениеОпределим различие между проектом и приложением. Приложение - это программа, которая что-то делает, а проект - это группа приложений.
Итак, приступим к созданию приложения. Это делается следующим образом: python manage.py startapp riddles .
Как только приложение создано, давайте напишем простой вид, по правилам Django все виды должны храниться в файле views.py .
riddles/views.py
From django.http import HttpResponse def index(request): return HttpResponse("Hello, World!")
Теперь, чтобы привязать наш вид к URL, создадим файл urls.py .
riddles/urls.py
From django.conf.urls import url from . import views app_name = "riddles" urlpatterns = [ url(r"^$", views.index, name="index"), ]
В urls.py мы должны написать следующее:
django_example/urls.py
From django.conf.urls import include, url from django.contrib import admin urlpatterns = [ url(r"^riddles/", include("riddles.urls")), url(r"^admin/", admin.site.urls), ]
Теперь, если мы запустим наше приложение http://127.0.0.1:8000/riddles/ , мы увидим «Hello, World!».
Установка базы данныхПо умолчанию в Django используется SQLite, если она вас не устраивает, то вы с нашей статьей, в которой мы рассказываем, как безболезненно перейти с SQLite на MySQL.
Теперь откроем django_example/settings.py и взглянем на переменную INSTALLED_APPS , она хранит все приложения, которые активны в текущем проекте. По умолчанию она содержит:
- django.contrib.admin - админка, скоро мы ей воспользуемся.
- django.contrib.auth - система аутентификации.
- django.contrib.contenttypes - фреймворк для content types.
- django.contrib.sessions - сессионный фреймворк.
- django.contrib.messages - фреймворк для отправки сообщений.
- django.contrib.staticfiles - фреймворк для работы со статичными файлами.
Некоторые из этих приложений используют базы данных, но они еще не установлены, поэтому мы и видели «You have unapplied migrations; your app may not work properly until they are applied.». Поправить это можно следующим образом: python manage.py migrate . Вы должны увидеть следующее:
Operations to perform: Apply all migrations: admin, sessions, auth, contenttypes Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying sessions.0001_initial... OK
Теперь создадим нашу модель. Для начала создадим Riddle и Option . В Riddle будет содержаться загадка, в Option - один из возможных ответов на нее.
riddles/models.py
From django.db import models class Riddle(models.Model): riddle_text = models.CharField(max_length=255) pub_date = models.DateTimeField("date published") class Option(models.Model): riddle = models.ForeignKey(Riddle, on_delete=models.CASCADE) text = models.CharField(max_length=255) correct = models.BooleanField(default=False)
Данная модель обеспечивает Django информацией, необходимой для создания схемы базы данных и database-access API для доступа к объектам. Теперь нам нужно привязать наше приложение к нашему проекту, делается это следующим образом:
django_example/settings.py
INSTALLED_APPS = [ "riddles.apps.RiddlesConfig", "django.contrib.admin", "django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.messages", "django.contrib.staticfiles", ]
После этого нужно сделать миграцию: python manage.py makemigrations riddles . Вы должны увидеть следующее:
Migrations for "riddles": 0001_initial.py: - Create model Option - Create model Riddle - Add field riddle to option
Так мы говорим Django, что в моделях были сделаны некоторые изменения, и их нужно сохранить в качестве миграции.
Проверить, что сделает миграция, можно так: python manage.py sqlmigrate riddles 0001 (0001 - версия миграции, которую мы хотим проверить). На выходе мы получим:
BEGIN; -- -- Create model Option -- CREATE TABLE "riddles_option" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "text" varchar(255) NOT NULL, "correct" bool NOT NULL); -- -- Create model Riddle -- CREATE TABLE "riddles_riddle" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "riddle_text" varchar(255) NOT NULL, "pub_date" datetime NOT NULL); -- -- Add field riddle to option -- ALTER TABLE "riddles_option" RENAME TO "riddles_option__old"; CREATE TABLE "riddles_option" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "text" varchar(255) NOT NULL, "correct" bool NOT NULL, "riddle_id" integer NOT NULL REFERENCES "riddles_riddle" ("id")); INSERT INTO "riddles_option" ("riddle_id", "id", "text", "correct") SELECT NULL, "id", "text", "correct" FROM "riddles_option__old"; DROP TABLE "riddles_option__old"; CREATE INDEX "riddles_option_a7c97949" ON "riddles_option" ("riddle_id"); COMMIT;
Заметьте, что команда sqlmigrate нужна только для проверки, каждый раз ее запускать необязательно.
Теперь мы можем начать пользоваться панелью администратора. Но для этого нам нужен пользователь. Создать его можно следующим образом: python manage.py createsuperuser . После этого запускаем сервер, если он не запущен, и переходим на http://127.0.0.1:8000/admin/ . Вы увидите следующее:
Теперь дадим админу возможность изменять наши модели. Делается это так:
riddles/admin.py
From django.contrib import admin from .models import Option, Riddle admin.site.register(Riddle) admin.site.register(Option)
Вот что получится в итоге:
Возьмите небольшую паузу и поиграйтесь с панелью администратора. Вы будете приятно удивлены тем, что умеет Django.
Главная страницаЧто нам нужно для создания главной страницы?
- Templates: скелет нашей страницы.
- Views: функция на Python для отображения контента.
Начнем с шаблонов. Создадим папку templates внутри папки riddle , а в ней создадим index.html .
riddles/templates/index.html
Available Riddles {% if message %}
{{ message }}
- {{ riddle.riddle_text }} {% endfor %}
Теперь создадим макет для ответов:
{{ riddle.riddle_text }} {% if error_message %}
{{ error_message }}
{% endif %} {% csrf_token %} {% for option in riddle.option_set.all %} {{ option.text }}{% endfor %}
Первая строка загружает статические файлы, потом мы используем {% static "#" %} , где # - путь к вашему файлу. Аналогичная процедура проводится и для JavaScript.
Теперь вы можете создавать свои собственные приложения на Django.
