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

Почему сборка пакетов так важна?

Помимо того, что это просто хороший тон, существуют еще три практические причины для поставки программного обеспечения в виде пакетов:

• простота использования;
• стабильность (при управлении версиями);
• распространение.

При выборе приложения простота его установки учитывается пользователями далеко не в последнюю очередь, поэтому следует максимально упростить этот процесс. Сборка пакетов позволяет сделать программное обеспечение более доступным и простым в установке. Если установка не сложная, значит, пользователям будет проще приступить к работе с вашим программным обеспечением. Повысить доступность своего пакета при его публикации в каталоге пакетов Python (Python Package Index — PyPI) можно посредством таких утилит как pip или easy_install . (См. для получения дополнительной информации по данным средствам.)

Кроме того, управление версиями пакетов позволяет пользователям «закрепить» свои проекты, использующее ваше программное обеспечение, за его определенной версией. Например, закрепление за Pinax версии 0.9a2.dev1017 будет выглядеть таким образом:

Это принудительно свяжет проект с Pinax версии 0.9a2.dev1017.

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

Наиболее популярным методом публикации пакетов на PyPI (или на вашем собственном дистрибутивном сервере) является создание дистрибутива исходного кода для его свободной загрузки. Дистрибутив исходного кода — это стандартный способ сборки кода вашего проекта в качестве распространяемого модуля. Можно также создавать бинарные дистрибутивы, но для целей открытого использования имеет смысл также распространять свой код. Создавая дистрибутивы исходного кода, вы облегчаете пользователям процесс нахождения программного обеспечения в сети Интернет с помощью автоматизированных средств, а также его загрузки и установки. Этот процесс помогает не только в разработке на локальных системах, но и в развертывании вашего программного обеспечения.

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

Анатомия файла setup.py

Одно из предназначений сценария setup.py — это исполнение сборки пакетов вашего программного обеспечения и загрузки его на дистрибутивные серверы. На различных популярных репозиториях Python вы можете найти сценарии setup.py различного содержания. В данной статье рассмотрены основные из них. См. раздел для получения дополнительной информации.

Файл setup.py может использоваться для различных целей, но ниже мы приводим вариант, который позволяет выполнить следующие команды:

Первая команда, register , получает информацию, которую выдает функция setup() сценария setup.py, и создает запись в PyPI для вашего пакета. Она ничего не загружает, вместо этого она создает метаданные о вашем проекте с тем, чтобы впоследствии вы могли выгрузить и разместить там свои версии ПО. Следующие две команды связаны: sdist upload создает дистрибутив исходного кода, а затем выгружает его в PyPI. Тем не менее, существуют несколько необходимых условий, таких как настройка собственного конфигурационного файла.pypirc и собственно запись содержимого в файл setup.py.

Прежде всего, сконфигурируйте файл.pypirc. Он должен находиться в основном каталоге, который может быть разным в зависимости от используемой операционной системы. В операционных системах UNIX®, Linux® и Mac OS Xзайти в этот каталог можно, набрав cd ~/ . Содержимое файла должно включать ваши учетные данные PyPI, как показано в.

Листинг 1. Типовой файл.pypirc

Далее переходите в PyPI и зарегистрируйтесь для создания учетной записи (не волнуйтесь — это бесплатно). Введите такое же имя пользователя и пароль, что и в файле.pypirc каталога PyPI, и убедитесь, что файл называется именно ~/.pypirc .

Теперь при написании своего сценария setup.py вам необходимо решить, что будет отображаться на индексной странице PyPI, и определиться с названием проекта. Начнем с копирования шаблона для setup.py, который я использую для проектов (см. ). Пропустив импортирование и функции, взгляните на нижнюю часть шаблона и подумайте, что вам нужно изменить с учетом особенностей вашего проекта. См. для получения ссылки на полный сценарий.

Листинг 2. Шаблон setup.py

Во-первых, следует помнить, что этот шаблон подразумевает наличие в вашем проекте двух различных файлов. Первый используется для длинного описания (long_description). Он считывает содержимое файла README.rst, находящегося в той же директории, что и setup.py, и передает это содержимое как строку в параметр long_description . Этот файл заполняет целевую страницу в PyPI, поэтому желательно дать в нем краткое описание проекта и привести несколько примеров его использования. Второй файл — файл пакетов __init__.py . Мы не приводим здесь его развернутого описания, однако когда строка, которая определяет переменную VERSION, импортирует ваш пакет, Python требуется файл __init__.py, поэтому в данном модуле следует определить переменную с названием __version__ . Пока достаточно записать это строкой:

Теперь взглянем на остальные исходные параметры.

• PACKAGE — это пакет Python в вашем проекте. Это папка верхнего уровня, содержащая модуль __init__.py, который должен находиться в той же директории, что и файл setup.py, например: /- |- README.rst |- setup.py |- dogs |- __init__.py |- catcher.py

  Итак, в данном случае вашим пакетом будет dogs .

• Параметр NAME обычно схож или совпадает с названием пакета PACKAGE, но вы можете задать любое имя в зависимости от ваших предпочтений. NAME — это параметр, по которому пользователи будут ссылаться на ваше программное обеспечение, имя, под которым ваше программное обеспечение будет отображаться в PyPI и, что более важно, под которым пользователи будут его устанавливать (например, pip install NAME).
• DESCRIPTION — краткое описание вашего проекта. Одного предложения будет достаточно.
• AUTHOR и AUTHOR_EMAIL — это соответственно: ваше имя и адрес электронной почты. Эта информация не обязательна, но указать свой адрес электронной почты для пользователей, которые пожелают обратиться к вам с вопросами по проекту, это правило хорошего тона.
• URL — это URL-адрес проекта. Этот параметр может быть как Web-сайтом проекта или репозиторием Github, так и любым другим URL-адресом. Эта информация также не обязательна.

Возможно, вы пожелаете указать лицензионные условия и классификаторы. Более детальная информация о создании файла setup.py приведена в документации по Python. (См. .)

Управление версиями

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

Стандарт по управлению версиями пакетов Python можно найти в PEP-386 (Предложение по развитию Python) (см. .) В нем прописаны правила практического характера. Даже если вы не читали, не поняли или даже не согласны с PEP, все же разумнее придерживаться установленных в нем правил, так как именно они все чаще применяются при создании разработчиками приложений Python.

Кроме того, управление версиями необходимо не только для разработки стабильных версий, загружаемых в PyPI, но также полезно для разработки версий с суффиксом devNN . Как правило, размещение разрабатываемых версий в PyPI не поощряется, но можно сделать их общедоступными посредством настройки собственного общедоступного (или закрытого) дистрибутивного сервера. В этом случае пользователи, которые желают воспользоваться последней версией, могут указать это в своем pip -файле requirements.txt. Ниже приведено несколько примеров управления версиями:

Публикация

Пользователям не удастся отыскать и установить ваше программное обеспечение, если оно не будет опубликовано. Обычно пакеты публикуются в PyPI. Настроив свой конфигурационный файл.pypirc и передав команду upload в setup.py, вы передадите пакет в PyPI. Как правило, эта операция производится совместно с созданием дистрибутива исходного кода:

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

Настройка собственного дистрибутивного сервера

Главной причиной использования собственного дистрибутивного сервера для проектов с открытым исходным кодом является потребность в публикации разрабатываемых версий, так как PyPI может содержать только стабильные приложения. Например, возможно вы захотите:

Установить последнюю стабильную версию в PyPI. Но если вы позднее добавите разрабатываемые версии, то эта команда остановит выполнение и установит последнюю версию, т. е. разрабатываемую версию. Как правило, полезно всегда закреплять проекты за определенной версией, но это делают не все пользователи. Поэтому следует убедиться в том, что, если номер версии не указан, по умолчанию возвращается последняя стабильная версия.

Одним из способов убить одним выстрелом двух зайцев (предоставлять только стабильные версии для использования pip по умолчанию и обеспечить пользователям возможность устанавливать пакеты разрабатываемых версий) является создание собственного дистрибутивного сервера. Проект Pinax применяет эту технологию для всех своих разрабатываемых версий на сайте http://dist.pinaxproject.com. (См. .)

Дистрибутивный сервер представляет собой каталог, работающий по протоколу HTTP и предоставляющий доступ к файлам на вашем сервере. Он должен иметь следующую файловую структуру:

В дальнейшем при желании сервер можно сделать закрытым путем конфигурирования Basic-Auth на своем Web-сервере. Вы также можете добавить некоторые другие средства для выгрузки дистрибутивов исходного кода. Для этого необходимо добавить код управления выгрузкой, разобрать название файла и создать пути по каталогу, которые бы соответствовали приведенной выше схеме. Такая структура принята для проектов Pinax с использованием нескольких репозиториев.

pip и virtualenv

Хотя данная статья посвящена в основном сборке пакетов, дабы отдать должное тем преимуществам, которые сборка пакетов и управление версиями дают вашим пользователям, этот раздел описывает использование пакетов.

Инструмент pip можно установить напрямую, однако я рекомендую использовать его в рамках функциональности virtualenv . (См. .) Я также советую прибегать к virtualenv во всех случаях, когда вы имеете дело с Python, так как окружение Python при этом остается незагроможденным. Подобно тому, как виртуальная машина позволяет запускать несколько операционных систем одновременно, virtualenv позволяет запускать несколько окружений Python одновременно. Я ничего не устанавливаю в своей системе Python, а просто создаю новое виртуальное окружение для каждого нового проекта или утилиты, над которыми работаю.

Теперь, когда инструмент virtualenv установлен, можно и немного поиграть:

Обратите внимание, что первая установка pip загружается и устанавливается с PyPI. Команда pip freeze выводит все версии пакетов, установленных в текущем virtualenv . Команда pip uninstall делает именно то, о чем говорит ее название: удаляет себя из virtualenv . Затем мы устанавливаем разрабатываемую версию из репозитория перезагрузки по адресу http://dist.pinaxproject.com, чтобы получить разрабатываемую версию Pinax 0.9a2.dev1017.

Переходить на Web-сайт, загружать tar-архивы и создавать коды символических ссылок (symlink) на каталог site-packages не требуется. (Раньше я так и делал, и это вызывало много проблем.) Все это ваши пользователи получают благодаря хорошей сборке пакетов, публикации и управлению версиями созданного проекта.

Заключение

Надеюсь, материала, изложенного в данной статье, достаточно для того, чтобы вы смогли приступить к работе. В разделе приведены ссылки на документацию, которая может помочь вам глубже разобраться в упомянутых вопросах. Если у вас возникнут какие-либо вопросы, заходите на Freenode и ищите меня в таких разделах чата как #pinax и #django-social (по псевдониму "paltman") или в Twitter (@paltman).

pip install Django==2.1.7

Option 2: Get the release candidate for 2.2

Option 3: Get the latest development version

The latest and greatest Django version is the one that’s in our Git repository (our revision-control system). This is only for experienced users who want to try incoming changes and help identify bugs before an official release. Get it using this shell command, which requires Git :

git clone https://github.com/django/django.git

Additional information

For the impatient:

• Latest release:
  Checksums:
  Release notes:
• Preview release:
  Checksums:
  Release notes:

Which version is better?

We improve Django almost every day and are pretty good about keeping the code stable. Thus, using the latest development code is a safe and easy way to get access to new features as they’re added. If you choose to follow the development version, keep in mind that there will occasionally be backwards-incompatible changes. You’ll want to pay close attention to the commits by watching Django on GitHub or subscribing to django-updates .

If you’re just looking for a stable deployment target and don’t mind waiting for the next release, you’ll want to stick with the latest official release (which will always include detailed notes on any changes you’ll need to make while upgrading).

Previous releases

• Django 2.0.13:
  Checksums:
  Release notes:
• Django 1.11.20 (LTS):
  Checksums:
  Release notes:

Данная заметка это продолжение статьи про написание 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-разработчиков и узнаем, как их избежать. Статья может быть полезна даже опытным разработчикам, потому что и они совершают такие ошибки, как поддержка неподъёмно больших настроек или конфликтов имён в статических ресурсах.

Django - бесплатный сетевой open source Python-фреймворк, помогающий решать распространённые в разработке проблемы. Он позволяет создавать гибкие, хорошо структурированные приложения. В Django уже из коробки есть много современных возможностей. Например, для меня такие фичи, как Admin, инструмент Object Relational Mapping (ORM), Routing и Templating, делают Django первым кандидатом при выборе инструментария для разработки. Создание приложения требует много сил, и, наслаждаясь своим делом, как и любой разработчик, я хочу тратить как можно меньше времени на рутинные задачи. Django сильно в этом помогает, не заставляя жертвовать гибкостью приложения.

Киллер-фича Django - мощный конфигурируемый админский интерфейс, который автоматически (автомагически?) генерируется на основе схемы вашей модели и моделей админки. Чувствуешь себя прямо-таки волшебником. С помощью интерфейса Admin пользователь может конфигурировать много вещей, в их числе - список управления доступом (access control list, ACL), разрешения и действия на уровне строк (row-level), фильтры, порядки сортировки (orders), виджеты, формы, дополнительные URL-хелперы и многое другое. Я считаю, что админка нужна каждому приложению. Это лишь вопрос времени, когда такая панель понадобится вашему основному приложению. В Django она создаётся быстро и удобно.

Также в Django есть мощная ORM, из коробки работающая со всеми главными базами данных. Она «ленива»: в отличие от других ORM, обращается к БД только по мере необходимости. В ней есть поддержка основных SQL-инструкций (и функций), которые вы можете использовать из своего исходного Python-кода наряду со всеми остальными возможностями языка.
В Django очень гибкий и мощный шаблонизатор (templating engine). Доступны многие стандартные фильтры и метки (tags), также можно создавать свои собственные. Django поддерживает другие движки как собственные шаблоны, предоставляет API для лёгкой интеграции с другими движками посредством стандартных shortcut-функций для обработки шаблонов.

Фреймворк имеет и много других важных возможностей вроде URL-роутера, который парсит входящие запросы и генерирует новые URL на основе схемы роутинга. В целом Django приятен в работе, и, когда вам понадобится помощь, просто почитайте документацию .

Ошибка № 1. Использование для проектных зависимостей глобального окружения Python

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

Обычно такую ошибку допускают новички в Python- и Django-разработке, не знающие об особенностях изоляции окружения Python.

Есть много способов изолировать окружение, наиболее часто встречаются такие:

• virtualenv : пакет Python, генерирующий папку с окружением. Содержит скрипт для (де)активации окружения и управления установленными в нём пакетами. Это мой любимый и самый простой метод. Обычно я создаю окружение поближе к папке проекта.
• virtualenvwrapper : пакет Python, глобально устанавливающий набор инструментов для создания/удаления/активации и т. д. виртуальных окружений и предоставляющий доступ к этому набору. Все окружения хранятся в одной папке (её можно переписать с помощью переменной WORKON_HOME). Я не вижу преимуществ в использовании virtualenvwrapper вместо virtualenv .
• Виртуальные машины : нет лучшей изоляции, чем целая виртуальная машина, выделенная под ваше приложение. Есть масса доступных инструментов, например VirtualBox (бесплатный), VMware , Parallels и Proxmox (мой фаворит, есть бесплатная версия). В сочетании с инструментом автоматизации виртуальных машин вроде Vagrant это может оказаться очень мощным решением.
• Контейнеры : в последние годы я почти в каждом проекте использую Docker , особенно в новых проектах, начинаемых с нуля. Docker - невероятный инструмент с множеством возможностей. Для его автоматизации доступна куча сторонних инструментов. В Docker есть кеширование уровней (layer caching), позволяющее крайне быстро пересоздавать контейнеры. В них я использую глобальное окружение Python, потому что каждый контейнер имеет собственную файловую систему и проекты изолируются на высоком уровне. Docker позволяет новым членам команды быстрее начинать работу над проектом, особенно если у них есть опыт работы с этой технологией.

Ошибка № 2. Отсутствие привязки зависимостей в файле requirements.txt

Каждый новый проект Python должен начинаться с файла requirements.txt и нового изолированного окружения. Обычно вы с помощью pip/easy_install устанавливаете все пакеты, не забывая о requirements.txt . Обычно проще (возможно , правильнее) развёртывать проекты на серверах или на машинах членов команды.

Также важно в файле requirements.txt выполнять привязку (pin) конкретных версий ваших зависимостей. Обычно разные версии пакета предоставляют разные модули, функции и параметры функций. Даже в младших версиях изменения зависимостей могут оказаться такими, что это сломает ваш пакет. Это очень серьёзная проблема, если у вас живой проект и вы планируете регулярно его развёртывать, так как без системы управления версиями ваша сборочная система всегда будет устанавливать последнюю доступную версию пакета.

В production всегда выполняйте привязку пакетов! Я для этого использую очень хороший инструмент pip-tools . Он предоставляет набор команд, помогающих управлять зависимостями. Инструмент автоматически генерирует requirements.txt , в котором привязаны не просто ваши зависимости, а вообще всё дерево, т. е. и зависимости ваших зависимостей.

Иногда нужно обновить какие-то пакеты в списке зависимостей (например, только фреймворк или утилиту). Если вы прибегаете к pip freeze, то не знаете, какие зависимости используются какими пакетами, и поэтому не можете их обновить. Инструмент pip-tools автоматически привязывает пакеты в соответствии с привязанными вами зависимостями, и поэтому он автоматически решает, какие пакеты нужно обновить. А благодаря используемым комментариям в requirements.txt вы всегда знаете, какой пакет пришёл из какой зависимости.

Если быть ещё более осторожным, то можно делать бекап исходных файлов ваших зависимостей. Храните копию в своей файловой системе, Git-папке, S3-папке, FTP, SFTP - где угодно, лишь бы под рукой. Бывают ситуации, когда исключение из списка относительно небольшого пакета ломает большое количество пакетов в npm . Pip позволяет скачивать все необходимые зависимости в виде исходных файлов. Почитайте об этом подробнее, выполнив команду pip help download .

Ошибка № 3. Использование старомодных Python-функций вместо представлений-классов (Class-based Views)

Иногда целесообразно использовать в файле приложения views.py маленькие Python-функции, особенно для тестовых или утилитарных представлений. Но обычно в приложениях нужно использовать представления на основе классов (CBV).

CBV - это представления общего назначения, предоставляющие абстрактные классы, реализующие распространённые задачи веб-разработки. CBV созданы профессионалами и покрывают большинство востребованных моделей поведения. У них есть прекрасно структурированный API, и CBV подарят вам возможность наслаждаться всеми преимуществами ООП. Ваш код будет чище и читабельнее. Забудьте о трудностях использования стандартных функций представления (view functions) Django для создания списков, CRUD-операций, обработки форм и т. д. Можно просто расширять подходящий CBV под ваше представление и переопределять (override) функции или свойства класса, конфигурирующие поведение представления (обычно функция возвращает свойство, и вы можете добавить в неё любую логику, которая способна превратить ваш код в спагетти, если вместо CBV вы прибегнете к функциям представления).

Например, можно использовать в проекте разные миксины, которые переопределяют основные модели поведения CBV: создание контекстов представлений, проверка авторизации на уровне строк (on the row level), автосоздание путей шаблонов на основе структур приложения, интегрирование умного кеширования и многое другое.

• Tutorial

Введение

• работает под управлением полноценного Linux,
• долгое время лежит на столе и пылится.

Нам понадобятся

1. Raspberry PI модели B, B+ или Raspberry PI 2 (поскольку на платах этих моделей имеется Ethernet) с установленной Raspbian и активированным SSH сервером. О настройке можно почитать , или . Помимо Raspian для малинки существует большое количество альтернативных дистрибутивов . Тут, как говорится, «на любой вкус и цвет».
2. Рабочее Django приложение.
3. Роутер с поддержкой DDNS. Этот пункт не обязателен, поскольку DDNS можно настроить на самой малинке.

Подготовка

В моем случае в сети две малинки, одна из которых моя с 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 можно установить из питоновских репозиториев.

Настройка сервера

• для nginx /etc/nginx/sites-enabled/
• для gunicorn /etc/gunicorn.d/

Если working_dir (путь к файлу wsgy.py) указать "/home/pi/project/project" , а в args указать "wsgi:application" , то на малинке воркеры сначала стартуют, потом умирают без указания причины (под Ubuntu, например, gunicorn работает с обоими вариантами настроек).

Перенос MySQL

Полученный файл состоит из набора 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

Проверка

Протестируем в 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 <$Revision: 1528965 $> 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 <$Revision: 1528965 $> 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 раз быстрее. Разработчики малинки не обманули.

Настройка DDNS

Регистрация хоста

Если у вас есть учетная запись - проходим авторизацию, иначе регистрируемся . После авторизации попадаем сюда .


Кликаем AddHost и заполняем форму.


Внизу кликаем кнопку AddHost
Хост добавлен. Справа от имени хоста отображается внешний IP адрес Вашей сети.

Настраиваем DDNS на роутере

Настройка переадресации портов

Настраиваем DDNS на малинке

Во время установки необходимо выбрать сервис. Выбираем other и вводим dynupdate.no-ip.com, протокол dyndns2, имя пользователя, пароль, интерфейс - eth0, имя хоста.


Для проверки я выставил интервал обновления IP в 60 секунд. В файле /etc/default/ddclient необходимо выставить значение daemon_interval=«60».

Десерт

Для управления GPIO необходимо запускать сервер с правами root. Это потенциальная уязвимость.
Полноценное использования web приложения предполагает работу сервера без прав суперпользователя, настройку https, добавление возможности администрирования учетных записей, ведение логов, разделение доступа к управляемым устройствам, работу электроприборов по расписанию и многое другое.
Впрочем это уже совсем другая история статья.

Заключение