Футбольный телеграм бот на Python (4/4): Запуск на сервере
В четвертой части серии статей по написанию телеграм бота на python, запустим его на сервере. Для разнообразия и правдоподобия я выбрал вариант размещения на VPS, а не Heroku.
Во-первых, Heroku очень редко используют в продакшене. Его платные тарифы сильно выше стоимости аренды сервера.
Во-вторых, крупные кампании дают виртуальные машины бесплатно на год. Этого достаточно, что бы 4 года не платить за работу сервера.
Получение VPS
Как я уже написал, есть возможность получить VPS бесплатно на год. Выбирайте любой:
Только не активируйте все сразу, это разовое предложение.
Не буду подробно описывать, как развернуть VPS, у этих платформ документации на высоком уровне. Если у вас трудности с английским и переводчиками, начинайте с Azure. У них много русской документации. Скажу только, что крайне желательно выбирать OS Ubuntu 18.04.
Процесс получения бесплатного периода и создание виртуальной машины достаточно тернист. Если вы никогда не делали это ранее, будьте готов потратить 1-2 часа на знакомство с облачными решениями.
Я буду использовать VPS с почасовой оплатой от reg.ru. Это дешевое и простое решение. Для обучения и демонстрации можно запускать на несколько часов по цене от 0,32 ₽/час. А постоянная работа подобного бота будет стоить 215 рублей в месяц.
Подключение к виртуальной машине
Для подключения к VPS нужно знать ip (IPv4), логин (обычно «root») и пароль.
С Linux и MacOS можно подключится из терминала. Введите команду, логин и ip сервера.
Для windows можно скачать терминал Ubuntu. Если такой вариант не подходит, используйте PuTTY (порт: 22). Вот так выглядит консоль. Для подключения требуется ввести «yes» и пароль.
Подготовка сервера
2. Создадим проект. Установим и создадим виртуально окружение. Выполняйте команды по очереди:
Мы установили pip и virtualenv. Затем создали папку «fonlinebot», создали в ней виртуальное окружение и проверили его.
3. Установим и запустим Redis-server. Для установки и проверки в Ubuntu введите эти команды:
4. Переменные окружения. Теперь нужно спрятать токен и API-ключ в переменные. Выполните команду nano /etc/environment и вставьте эти строки со своими значениями в кавычках.
Создание Python Telegram бота и его deploy на виртуальную машину
Кому нужны чат-боты?
Рынок чат-ботов в России растет с бешеной скоростью и ожидается ежегодный прирост на 30% в течение ближайших трех лет. В 2020 г. количество запросов на чат-боты увеличилось на 17% по сравнению с 2019 г. Большим спросом стали пользоваться голосовые боты, количество запросов на них выросло в четыре раза. В 2021 г. ожидается рост числа запросов на чат-боты на 15-20% от организаций из госсектора, образования, медицины, логистики, ретейла и e-commerce, промышленных и добывающих компаний.
Создаём нашего telegram бота.
Пишем код под наши задачи и тестируем его работоспособность.
Выбираем надежный сервис виртуальных машин.
Переносим нашего бота на виртуальную машину для его дальнейшей работы.
Настраиваем беспрерывную работу бота.
Шаг 1. Создание бота в Telegram
Первые три шага опишу максимально кратко, так как статей на эту тему много и обычно это не вызовет у пользователей никаких трудностей. Для создания бота нам понадобится написать BotFather.
Шаг 2. Напишем простейшего чат-бота и протестируем его
Для работы будем использовать библиотеку telebot, которую можно установить при помощи следующей команды:
$ pip install pytelegrambotapi
Для установки других библиотек, в случае того, если вы не ограничиваетесь базовым функционалом вам поможет господь Google.
Напишем простого бота, который будет присылать нам в ответ на различные Emoji их размытые PNG копии:
Наш бот готов, теперь осталось его протестировать. Заходим по ссылке, которую прислал BotFather.
Поздравляю, наш бот теперь работает. И тут мы подходим к главной проблеме: как только мы выключим наш компьютер с запущенным кодом, бот мгновенно перестанет работать. Для решения этой проблемы нам-то и понадобится сервис предоставляющий виртуальные машины.
Шаг 3. Выбираем виртуальную машину!
Что вообще такое эта виртуальная машина?
Виртуальная машина (ВМ ) — это виртуальный компьютер, который использует выделенные ресурсы реального компьютера (процессор, диск, адаптер). Эти ресурсы хранятся в облаке и позволяют ВМ работать автономно. Простыми словами, виртуальная машина позволяет создать на одном компьютере ещё один компьютер, который будет использовать его ресурсы, но работать изолированно.
Именно виртуальная машина поможет нашему боту отвечать на все запросы и работать 24 на 7.
Как выбрать виртуальную машину?
ВМ выбирается исключительно отталкиваясь от ваших потребностей бюджета. Чем больше вам необходимо мощности и памяти, тем выше будет ее стоимость. В настоящее время есть множество хороших сервисов, предоставляющих пробный период с которым вы сможете определиться, подходит ли вам сервис.
Лично я могу рекомендовать следующие сервисы:
Mail cloud solutions — Предоставляют 3000 р. на два месяца тестового периода. (Именно его я и буду использовать в дальнейшей работе).
Yandex.Cloud — Представляют 2000 р. на два месяца тестового периода.
Google Cloud Platform — Предоставляют 300$ на три месяца тестового периода.
После выбора сервиса, пройдем регистрацию и создадим новую виртуальную машину.
Создание виртуальной машины.
Я выбрал минимальные параметры, так как нашему боты не нужны какие-то большие энергоресурсы.
Настройка сети.
Для подключения будем использовать протокол SSH. Для подключения к нашей виртуальной машине, нам необходимо будет выпустить новую связку ssh-ключей.
Для этого перейдем в терминал и пропишем следующую команду:
Переходим к следующему шагу.
Подключение к виртуальной машине
Для подключения к нашей виртуальной машине пропишем следующую команду:
/.ssh/ИмяВашегоКлюча ubuntu@ваш публичный IP-адрес
В случае удачного подключения вы увидите нечто подобное:
Мы подошли к самому сложному шагу, который я надеюсь, благодаря моей статье перестанет быть столь трудным для освоения.
Установим на наш сервер последнюю версию Python. Для этого последовательно вводите следующие команды:
Установим и создадим виртуально окружение:
Установим и запустим Redis-server:
Проверить, запущен ли наш Redis-server, необходимо прописать «ping»
Если в ответе вы получили PONG, поздравляю, все готово к дальнейшей работе!
Перенесем все необходимые файлы на наш виртуальный сервер. Для этого я буду использовать очень удобную программу CyberDuck
Мы попадаем фактически на наш сервер, с уже установленным Python, папкой с названием нашего бота и виртуальным окружением. Остается перенести все данные нашего бота. Для этого копируем ВСЕ необходимые файлы и вставляем их на сервер.
Поздравляю, мы на финишной прямой, остается запустить нашего бота на сервере и проверить его работоспособность.
Проверяем работу, если все в порядке, прописываем в терминале deactivate. Нам остается последний шаг. Настроить непрерывную работу нашего бота.
Шаг 5. Настройка беспрерывной работы нашего бота.
Пропишем следующую команду: nano /lib/systemd/system/НазваниеБота.service
Нажимаем CTRL+O → Enter → CTRL+X для сохранения. Эти настройки помогут запускать или перезапускать нашего бота.
Последний шаг: Снова запускаем нашего бота, но уже с беспрерывной работой.
ГОТОВО! Наш бот запущен и теперь работает 24/7, независимо от того, включен наш с вами компьютер или нет. Если что-то не работает, тщательно проверьте, правильно ли вы прописали путь к файлам. Если терминал выдает ошибку авторизации, попробуйте добавить перед командой «sudo» (Команда от имени администратора)
Моя эпопея настройки автодеплоя: ошибки и открытия
С развитием моей веб-студии и ростом количества проектов, мне, как руководителю проектов, задачи стало выполнять сложнее. Сложнее стало и успевать за всем следить: что-то удалось делегировать, но все-таки некоторые задачи остались на мне и требовали вмешательства, а то и непосредственного участия. Например, размещение исходного кода на сервере и загрузка правок все еще за мной.
Вы сейчас закономерно заметите: “А чего ж ты сразу не сделал автодеплой? Там же все просто!”.
Пока было не в напряг, я заливал всё сам, оправдывая это тем, что я слежу за процессом и в случае чего смогу оперативно отреагировать.
Каков логичный первый шаг, если хочется сделать быстрее и не погружаться в литературу очень глубоко?
Нанять человека (девопса)
Чем, собственно, я и занялся. Мы хоть и гордая студия, но пока не сильно богатая, поэтому пошел чуть ниже середины рынка девопс специалистов. Нашел первого кандидата через знакомых, горящего желанием все сделать. Было маленькое но: он был самоучкой. В итоге он перегорел через недели 2 и перестал отвечать. Показывал результат на виртуалке, поднятой у себя на компе, но дальше не двигалось.
Справедливости ради скажу, что помимо автодеплоя, у него были другие задачи, но приоритетом был мониторинг и автодеплой. На них то он и завалился.
Поэтому я решил искать не столько самоучек, сколько обученных самоучек (то есть тех, кто обучался на курсах).
И нашел! Свежий специалист, только с обучения. Девушка так же горела желанием и показывала результаты на виртуалке, но до сервера толком не добралась. Точнее добралась, но завести там ничего не смогла. Мы с ней вместе читали доки, я скидывал ей видосы, но результата не было. Это не все примеры, но суть отражающие.
Мораль 1: не скупитесь на человеческие ресурсы
(да-да, и ежу понятно, но мы все учимся на ошибках)
В итоге я решил изучать вопрос самостоятельно. Полез в документацию Gitlab, почитал, полез на образовательные порталы, в частности на Udemy.
Там и посмотрел курсы по Куберу. Понравилось, но сложно. Сложно, например, с точки зрения реализации всего этого и настройки.
Надо читать и изучать намного больше чтобы развернуть автодеплой в текущем виде. Кубер это все же уже про оркестрацию, и на него с этой точки зрения тоже есть свои планы (как раз пишем проект, в котором это очень сильно пригодится).
Ну и помимо сложностей в изучении и объеме информации, есть также финансовый вопрос, пока нет проекта, на котором действительно это все нужно, нет смысла тратиться на большую инфраструктуру серверов.
Далее решил идти в воркшопы по настройке автодеплоя и работе с Gitlab. Найти воркшоп было непросто и сделал я это небыстро, но сделал. После долгого гуглежа меня начала догонять реклама и там предлагали посмотреть мастер классы и воркшопы. Я этим не ограничился, и сам на том же Youtube нашел много разных записей.
Кстати, часто воркшопы не заканчиваются успехом, но из каждого можно почерпнуть полезные штуки (хоть в итоге у демонстрирующего ничего и не завелось). Например, посмотрев воркшоп, я отдельно вытащил работы с переменными окружения, осознал разбивку на стадии, открыл для себя, что их можно делать параллельно, хотя раньше такого не встречал (видел только линейные).
Собрав информацию по кусочкам, я решил попробовать самостоятельно. И оказалось, что ничего сложного в этом нет.
Сначала занялся простой загрузкой мастера, потом разбил на окружения.
В ход пошел запуск в докере и отдельные пайплайны на применение миграций, выполнение тестов, в том числе линтер. Переменные окружения мне удалось победить не сразу, но с помощью костылей и какой-то матери (привет фанатам анекдот.ру) у меня получилось. Костыли, конечно, я исправлю, для этого взял отдельный сервер и на нем пишу новые инструкции, отлаживаю деплой.
Мораль 2. все не так уж и страшно и сложно, как кажется на первый взгляд
Теперь наш ПМ может без меня сливать задачи на тестовое окружение, что ускоряет работу команды и освобождает меня от большого количества мелких задач. Автоматизировав этот пласт работы (вернее сказать пластик, но в большом количестве единиц), мы сильно ускорили процессы в команде и цикл прохождения задачи.
Насколько ускорили? Рассказываю.
Например, раньше, чтобы залить решение на сервер, мне нужно было:
Перезапустить необходимые службы.
А еще же ревью. Часть ревью я с себя снял тестами в процессе деплоя, часть проверок на то, что проект запускается и работает, я снял теми же самыми процессами, итого на каждую задачу экономии получилось 15-20 минут.
Исключили фактор человеческой ошибки и отсекли те задачи, которые роняют проект при запуске. Также отсекли этап применения миграций, таким образом разработчик видит, что на миграциях закосячил он. Например, появились конфликты миграций между его и рабочей ветками, и теперь он знает без ревьюера, что и где нужно исправить.
Предстоящий шаг: масштабирование. Эпопея еще не закончилась для меня и моей веб-студии 😀
Изучая материалы, я почерпнул много интересного, в том числе про масштабирование.
Конкретно сейчас интересно, как можно будет автоматически отмасштабировать новый проект (делаем конструктор обучающих ботов), потому что нагрузка там предполагается довольно большая. Но это уже совсем другая история…
(если зайдет, я и ее расскажу)
Что касается технической части и сухой выжимки
Проекты на django+vuejs (SPA), иногда на чистом django (SSR)
Репозиторий gitlab.com, в совокупности с их gitlab-runner
Сервер Ubuntu 20.04
Переменные окружения хранятся в том же gitlab в переменных, но хочу их перевезти куда-нибудь и как-нибудь, как раз изучаю этот вопрос дополнительно.
Возможно,у вас есть советы и предложения, я с радостью ознакомлюсь.
Экономия времени: величина, стремящаяся к бесконечности 🙂 От начала процесса поиска сотрудников и до успешного деплоя в автоматическом режиме прошло около полутора месяца. Причем месяц ушел на работу с людьми и их попытки все настроить. И остальные полмесяца у меня ушло на то, чтобы самому разобраться.
С учетом того, что задачи заливаются на тест постоянно, то я уже отбил затраченное время несколько раз.
А как у вас с автодеплоем? Расскажите свои истории в комментариях, может быть и тут я узнаю что-то новое.
Python. Автоматизируем деплой и рутину с Fabric
Также в фабрике есть понятие ролей (по сути это группы серверов), например, вы можете создать роли «production» или «stage», далее при запуске fab указать эти роли или непосредственно в файле при помощи декоратора «@roles» и ваши команды будут применяться к этим группам серверов непосредственно. Либо вы можете указывать конретные хосты вместо группы. Вообщем об этом чуть ниже.
В статье будет рассматриваться Fabric версии 1.4.3
Установка
Для установки достаточно установить одноименный пакет Fabric:
Настройка fabfile
Для создания своих команд по развертыванию проекта и вспомогательных функций (создание бекапов, работа с системой контроля версий, запуск любых команд как удаленно так и локально, и т.п.) необходимо создать в корне Django-проекта файл fabfile.py, для примера, со следующим содержимым:
Теперь создадим приватный и публичный ключ «git_example_org» для подключения к серверу:
Вы можете вместо ключей передавать пароль, либо после подключения к серверу указывать его каждый раз, либо непосредственно указать его в файле fabfile.py:
Использование
После того как мы создали fabfile.py и настроили подключение по ssh, мы теперь можем перейти в каталог проекта и запустить fab deploy (или любую другую определенную вами команду):
Также вы можете указывать определенные роли или хосты, для которых выполнится какая-либо команда, например «deploy»:
В принципе, все ключи описаны в документации.
Передача аргументов
Всё очень просто, вы определяете args/kwargs у себя в команде:
После чего, в консоли эти аргументы можно будет передать так:
Подробнее о базовой функциональности фабрики
Я буду рассматривать только функции которыми я пользуюсь:
cd Используется для указания каталога в который необходимо перейти, будет вызван «/bin/cd» перед каждым запуском команды в контексте. Пример:
lcd Аналогично «cd», но только локально. Пример:
Запуск любой, доступной пользователю (через которого выполняется подключение к удаленной машине), команды на сервере. Пример:
Запуск любой команды на локальной машине. Пример:
Запуск команды из под sudo. Пример:
open_shell Получение shell’a с удаленного хоста. Пример:
abort Прерывает выполнение команды. Пример:
warn Выводит warning-сообщение, но не прерывает выполнение команды. Пример:
puts Выводит сообщение, аналогично print(), но работает через output фабрики. Пример:
env Переменная окружения, в которую можно добавить необходимые атрибуты и использовать их при необходимости, пример использования был уже выше:
settings Вы можете использовать settings для выполнения функций с указанными настройками, то есть можно было бы определить через env: «env.warn_only=True», но тогда бы действовало глобально, а так получается только в контексте «with». Пример:
@with_settings Декоратор, который работает по аналогии с «settings», но влияет на всю команду. Пример:
@roles Декоратор позволяющий указать для какой группы хостов будет выполнена ваша команда. Пример:
@hosts Декоратор позволяющий указать список хостов для которых будет выполнена ваша команда. Пример:
@task Декоратор указывающий что функция является командой. Если вы не используете этот декоратор вообще в fabfile.py, то все функции будут командами, если хоть для одной функции указать этот декоратор, то придется указывать его для всех команд.
Принимает ряд параметров, например «alias» для того чтобы переименовывать команды на более короткие:
Получение (скачивание) файла с удаленного хоста. Пример
Заливка (upload) на удаленный хост файла. Пример:
@parallel Декоратор для распараллеливания запуска комманды. Пример:
@serial Декоратор, который делает обратное. Пример:
Для всех run/sudo будет выполнятся команда переданная в качестве «command».
Например для virtualenv:
Аналогичен питоновскому raw_input(), запросит у пользователя данные, после ввода можно докрутить логики на основе ответа от пользователя. Пример:
reboot Перезагрузка машины для указанных хостов. Пример:
В комплекте с фабрикой идут батарейки:
Например в последнем есть «rsync_project», которым можно пользоваться например так:
Рекомендую
Также рекомендую обратить внимание на проекты Chef, Puppet и Buildout.
Деплоим на PythonAnywhere из GitHub
Каждый может сделать так:
локальный проект → github
С (платным) ssh доступом вы сможете сделать так:
локальный проект → PythonAnywhere
В статье показано как (бесплатно) сделать так:
локальный проект → github → PythonAnywhere
Сначала я перечислю, зачем вам это может быть нужно, а затем перейду к тому как реализовать. Не стесняйтесь просколлить статью, если первая часть вам не интересна.
Зачем?
PythonAnywhere — отличный сервис! Он бесплатен, предоставляет неплохие мощности и даже базу данных, таким образом вы можете поднять динамический сайт за пару минут. Это отличный вариант как для новичков, которые хотят попробовать что-нибудь потестировать вживую, так и для тех, кому нужно хостить API или какой-нибудь личный проект.
Но у сервиса есть и недостатки. Что если вы хотите заопенсорсить код, над которым работаете? Будете поддерживать и вносить изменения в двух местах сразу? Один раз на продакшене PythonAnywhere и второй раз на GitHub для других разработчиков. Что если вы примете Pull Request или захотите интегрировать CI? Постоянно дублировать все действия очень неудобно.
GitHub отличный сервис для совместной работы и просмотра исходного кода, их UI лучше чем на PythonAnywhere и, к чему я это веду, редактировать код прямо на PythonAnywhere не очень приятно. Что если можно было бы соединить лучшее от двух миров?
Вы пушите на GitHub все апдейты, а приложение на PythonAnywhere синхронизируется и перезапускается автоматически. Вы можете мерджить PR’ы, использовать тикеты, просматривать ваш код с любого устройства, даже не логинясь и не открывая файл в редакторе кода — в общем, делать всё что позволяет GitHub.
Я уже слышу ропот: «Хорошо-хорошо, убедил, но как же этого добиться?». Ни слова больше!
Мы используем вебхуки Гитхаба, чтобы оповестить об обновлении приложения, сделать pull и перезагрузить его.
В качестве примера я буду рассматривать моё приложение SwagLyrics, бэкенд которого держу на PythonAnywhere. Я использую Flask, так что процесс будет отличаться для другого фреймворка.
Для начала синхронизируем проект, чтобы GitHub был origin. Если вы ещё не создали репозиторий на PythonAnywhere, вы можете инициализировать его или склонировать код напрямую с GitHub.
Теперь идём на GitHub → Settings → Webhooks → Add webhook
Измените «Content type» с application/x-www-form-urlencoded на application/json (я расскажу вам зачем это нужно немного позже).
Поле «Secret» мы пока трогать не будем.
Убедитесь, что выбрана опция «push event» и кликните «Add webhook».
Открывайте своё приложение на Flask, мы сконфигурируем route для получения информации от GitHub при наступлении push события. Путь должен быть тем, который вы указали в поле «Payload URL». Мы не указываем ветку master явно, т.к. для простоты подразумевается, что она в репозитории единственная.
Простейшая настройка будет выглядеть так:
Это самый тривиальный пример, более полная версия будет ниже.
Теперь всякий раз когда произойдёт событие push, приложение обновит себя, выполнив pull.
Если всё прошло гладко, вот что вы увидите после очередного коммита:
Прежде чем мы перейдём к защите вебхука от посторонних, я расскажу как перезапускать приложение после pull, чтобы этого не нужно было делать вручную.
Автоматическая перезагрузка веб-приложения
Мы будем использовать хуки git. Это просто команды оболочки, выполняемые после событий. Хука для события после pull нет, но.
Мы используем тот факт, что git pull — это не что иное, как git fetch → git merge, а вот хук для события после merge существует. Он выполняется, если вытягивание завершено успешно.
В вашем репозитории на PythonAnywhere перейдите в .git/hooks/
Там уже будет несколько существующих хуков, добавьте к ним свой, создав файл post-merge
Запишите в него такой код:
Используйте путь к своему wsgi, который будучи изменённым (touch), перезапускает приложение.
Чтобы сделать файл исполняемым, откройте консоль и выполните
Убедитесь, что перезагрузка работает, сделав новый коммит.
Теперь перейдём к обеспечению защиты вебхука.
Защита вебхука
Защитить вебхук необходимо, чтобы кто-то другой не смог постоянно посылать запросы на перезагрузку приложения. Мы будем использовать этот гайд.
Во-первых, добавьте секретный токен на PythonAnywhere в качестве переменной среды, а также в поле «Secret» в настройках вебхука на GitHub. Здесь процесс расписан чуть подробнее.
GitHub отдаёт свои методы на Ruby, но мы используем Python, поэтому будем использовать такую функцию сравнения:
Теперь измените контроллер update_server, чтобы проверять действительна ли подпись, добавив эти строки перед частью с обновлением кода:
w_secret должен совпадать со значением, которое вы чуть раньше установили в качестве переменной среды.
Вообще, имеет смысл добавить ведение логов и ещё несколько проверок, чтобы убедиться, что вебхук от GitHub или что событие содержит данные, поэтому, если хотите, можете скопировать релевантный код из моего репозитория, изменив его там где нужно, благо вы уже знаете всё самое важное
Надеюсь, информация была полезной. Знаю, тут много всего, но я хотел, чтобы вы понимали, что происходит.
Я не придумал всё выше сам, скорее собрал самое важное из разных источников и создал законченное решение.