Запуск в продакшн: деплой, вебхуки/поллинг, безопасность и мониторинг
В прошлых частях курса вы написали бота на python-telegram-bot, добавили диалоги, кнопки, обработку ошибок, а также научились хранить данные (файлы и SQLite) и ходить во внешние API.
Теперь важный шаг: сделать так, чтобы бот работал постоянно, переживал перезапуски сервера, не светил токены, а при ошибках вы узнавали об этом быстро.
Эта статья про продакшн (боевую эксплуатацию): деплой, выбор между webhook и polling, безопасность и мониторинг.
!Сравнение потоков событий для polling и webhook
Что значит «в продакшн» для Telegram-бота
В учебном режиме вы запускаете app.run_polling() на своём компьютере. В продакшне обычно требуется следующее:
Постоянная работа: бот отвечает 24/7.
Автозапуск: после перезагрузки сервера бот поднимается сам.
Управляемые обновления: вы можете обновить код без хаоса.
Секреты вне кода: токены и ключи API не в репозитории.
Логи и мониторинг: вы видите ошибки и понимаете, что происходит.Polling и Webhook: что выбрать
Polling
Polling означает, что бот сам регулярно запрашивает обновления у Telegram методом getUpdates.
Когда polling хорош:
вы хотите самый простой деплой;
бот небольшой или учебный;
у вас нет домена и HTTPS;
вы деплоите на VPS и хотите минимум инфраструктуры.Минусы polling:
бот должен постоянно работать как процесс;
чуть сложнее масштабировать на несколько экземпляров.В python-telegram-bot это знакомый вариант:
Документация:
python-telegram-bot — Running your bot
Telegram Bot API — getUpdatesWebhook
Webhook означает, что Telegram сам отправляет обновления на ваш публичный URL.
Когда webhook хорош:
вы разворачиваете бота как сервис;
вы готовы настроить домен и HTTPS;
вы хотите более «серверный» стиль (Telegram сам присылает события).Минусы webhook:
нужен публичный адрес и HTTPS;
требуется настройка веб-сервера или встроенного веб-сервера библиотеки.Документация:
Telegram Bot API — setWebhookБыстрый выбор для новичка
Если вы хотите быстро запустить бота на VPS и не трогать домены и сертификаты, выбирайте polling.
Если вы уже уверенно чувствуете себя с сервером и хотите правильную «боевую» схему, выбирайте webhook.В этом курсе базовый продакшн-путь проще начать с polling на VPS, а webhook рассматривать как следующий уровень.
Где разместить бота: варианты деплоя
VPS (виртуальный сервер)
Это самый универсальный вариант: вы получаете Linux-сервер и контролируете всё.
Плюсы:
стабильно и предсказуемо;
удобно для SQLite и файлов;
можно выбрать polling или webhook.Минусы:
нужно немного разобраться в Linux и настройке сервиса.PaaS (платформы «задеплой из Git»)
Примеры:
Render
Railway
Fly.ioПлюсы:
минимум ручной настройки;
часто есть автодеплой из репозитория.Минусы:
ограничения бесплатных тарифов;
для webhook всё равно нужен HTTPS маршрут (обычно платформа его даёт);
иногда сложнее с постоянным диском (для SQLite) в дешёвых планах.Мини-чеклист продакшна
Код запускается из чистого окружения: venv, requirements.txt.
Секреты в переменных окружения: токен и ключи не в коде.
Есть автозапуск процесса: например, systemd.
Логи пишутся: и вы умеете их смотреть.
Есть обработчик ошибок: чтобы бот не «умирал молча».
Есть план обновлений: как вы выкатываете новую версию.Продакшн на VPS с polling и systemd
Ниже типовой и очень практичный сценарий: Ubuntu-сервер, бот запускается через systemd и работает в режиме polling.
Подготовка сервера
Установите базовые пакеты:
Проверьте версии:
Разворачиваем проект
Клонируйте репозиторий (или загрузите код другим способом):
Создайте окружение и поставьте зависимости:
Создайте .env на сервере (в корне проекта, как вы делали локально):
Содержимое:
Важно, чтобы .env не попадал в Git. В продакшне вы обычно вообще не храните .env в репозитории.
Сервис systemd
systemd умеет:
запускать бота при старте сервера;
перезапускать при падении;
хранить логи.Создайте файл сервиса:
Пример содержимого:
Что здесь важно:
WorkingDirectory указывает на корень проекта.
EnvironmentFile подключает .env как переменные окружения.
ExecStart запускает Python из вашего виртуального окружения.Применяем и запускаем:
Проверка статуса:
Логи:
Как обновлять код без сюрпризов
Минимальная безопасная последовательность:
git pull
при изменении зависимостей: pip install -r requirements.txt
sudo systemctl restart mybot
посмотреть логи journalctl -u mybot -fWebhook в продакшне: что нужно понимать
Webhook потребует публичного HTTPS адреса.
Практическая схема чаще всего такая:
домен (например, bot.example.com)
Nginx как reverse proxy
сертификат от Let’s Encrypt
бот принимает запросы на локальном порту!Типовая продакшн-схема webhook на сервере
Запуск webhook в python-telegram-bot
У python-telegram-bot есть режим webhook. Пример идеи запуска:
Смысл параметров:
listen и port: где ваш бот слушает входящие HTTP-запросы.
url_path: путь, который будет принимать апдейты.
webhook_url: публичный адрес, который увидит Telegram.Документация библиотеки может меняться по версиям, поэтому сверяйтесь с актуальной:
python-telegram-bot — DocumentationЧто важно при webhook
HTTPS обязателен для большинства реальных сценариев.
Если вы переходите с polling на webhook, нужно удалить старую настройку webhook или polling-конфликт.
В Telegram webhook настраивается через setWebhook, а снимается через deleteWebhook.Документация:
Telegram Bot API — deleteWebhookБезопасность: что обязательно сделать
Защита токена и ключей
Правила, которые должны стать привычкой:
Никогда не храните токен в коде.
Никогда не коммитьте токен.
Храните секреты в переменных окружения: .env на сервере или секреты платформы (Render/Railway/Fly).
Если токен утёк, перевыпустите его в BotFather.Минимальные права и осторожность с входными данными
Считайте любой ввод пользователя потенциально «плохим».
Проверяйте типы сообщений: текст, фото, файл, стикер.
Ставьте лимиты: максимальная длина текста, размер файла.Зависимости и обновления
Фиксируйте зависимости в requirements.txt.
Обновляйте зависимости осознанно, а не случайно.
Следите за обновлениями Python и библиотек, особенно если бот публичный.Логи без секретов
Не логируйте токен.
Осторожно с логированием объектов целиком: там могут оказаться персональные данные.Мониторинг и отладка в продакшне
Логирование
У вас уже было базовое логирование. В продакшне важно:
логи должны сохраняться (например, journalctl через systemd);
по логам должно быть видно, что бот жив и что он делает.Хорошая практика:
логировать старт бота;
логировать ключевые действия (команды, ошибки API, запись в базу);
логировать исключения через глобальный error handler.Глобальный обработчик ошибок
Вы уже видели идею обработчика ошибок. В продакшне это критично: вы хотите видеть stack trace в логах и отдавать пользователю понятный ответ.
Документация:
python-telegram-bot — Application.add_error_handlerВнешний мониторинг доступности
Даже если бот пишет логи, полезно иметь внешний «пинг», который проверяет, что сервис жив.
Популярный вариант для простого мониторинга:
UptimeRobotPolling-бот сложнее проверять HTTP-пингом, но можно:
поднять простую HTTP-точку здоровья (если у вас есть веб-сервер);
или мониторить процесс через systemd и оповещения на сервере.Мониторинг ошибок (ошибки как события)
Для реальных проектов удобно отправлять исключения в сервис ошибок, чтобы получать уведомления.
Один из стандартов:
SentryСмысл простой:
исключение случилось;
вы получили событие с деталями;
вы можете быстро исправить.Практические нюансы для бота с данными (SQLite, файлы)
Если вы используете SQLite из прошлой статьи, помните:
файл базы (data/bot.db) должен быть на диске, который не исчезает при перезапуске контейнера или сервиса;
делайте резервные копии, если данные ценны;
при деплое на PaaS уточните, есть ли постоянный диск.Для файлового хранилища JSON правила те же: файл должен быть на постоянном диске и защищён от случайной перезаписи.
Итог
Вы теперь понимаете, как довести учебного Telegram-бота до состояния «работает как сервис»:
выбрать polling или webhook;
развернуть бота на VPS или платформе;
настроить автозапуск и логи;
защитить токены и секреты;
включить мониторинг и обработку ошибок.С этого момента ваш бот становится не просто кодом, а небольшим, но настоящим продуктом, который можно поддерживать и развивать.