<span id="run-a-telegram-bot" />

# Запуск Telegram-бота

Бот с long polling — это фоновый рабочий процесс: он запрашивает обновления у Telegram и не требует публичного HTTP-эндпоинта. Запустите его с `containerPort=0` и одной репликой на токен бота.

**Статус тестов:** семь локальных тестов с имитированными ответами Telegram проходят. Мы не проверяли это руководство с реальным ботом в облаке. Используйте отдельного тестового бота и выполните проверки сообщений и перезапуска ниже перед тем, как полагаться на него. См. [результаты сценарийных тестов](https://lizard.build/ru/docs/guides/validation).

<span id="before-you-start" />

## Перед началом

Создайте бота через BotFather и храните его токен в секрете. Вам понадобятся Python 3.13, Lizard CLI и проект, в который можно выполнить деплой. Бот, использующий long polling, не должен иметь активный вебхук; проверьте текущую конфигурацию перед изменением способа получения обновлений.

В [примере файлов](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/telegram-worker) входят `worker.py`, Dockerfile и локальные модульные тесты. Тесты не обращаются к Telegram. Обработчик эха хранит смещение в памяти; это не система ровно-однократной обработки.

<span id="check-locally" />

## Локальная проверка

Из директории примера:

```bash
python3 -m unittest -v
```

Проверки охватывают текстовые ответы, игнорируемые обновления, пустые опросы и неудачные отправки. Запустите бота локально с `TELEGRAM_BOT_TOKEN`, только если планируете отправлять ответы. Остановите этот локальный процесс перед запуском размещённого рабочего процесса.

<span id="deploy-as-a-worker" />

## Деплой как рабочий процесс

```bash
lizard init --name telegram-bot
lizard add --service bot
```

Выполните вход через `lizard login`, если команда сообщает, что требуется аутентификация. Установите `TELEGRAM_BOT_TOKEN` в **сервисе бота** перед деплоем. Можно использовать редактор переменных в панели управления или поместить значение в локальный файл `.env` и импортировать его:

```bash
lizard secrets import --service bot < .env
lizard run --service bot -- python3 check_bot.py
lizard up --service bot --port 0
```

Предварительная проверка валидирует токен через `getMe` и отклоняет бота с активным вебхуком. Она не удаляет и не меняет этот вебхук. Второй процесс опроса всё ещё может конфликтовать: остановите любую локальную копию перед деплоем.

Пример исключает `.env*` из загрузки. Держите токен вне исходных файлов и скриншотов. На macOS с Lizard CLI 0.3.92 добавьте префикс `COPYFILE_DISABLE=1` к команде загрузки. Читайте итоговое событие деплоя и логи даже если команда завершилась успешно.

Для существующего сервиса явно установите режим рабочего процесса:

```bash
lizard service set bot --set containerPort=0
```

После смены режима рабочего процесса на запущенном сервисе примените его с `lizard redeploy --service bot`. Проверьте события деплоя перед запросом следующей сборки. Режим рабочего процесса пропускает проверки HTTP-порта и маршрут балансировщика; не добавляйте фиктивный веб-сервер только для того, чтобы этот процесс выглядел как HTTP-приложение.

<span id="verify-the-result" />

## Проверка результата

```bash
lizard ps --json
lizard logs --service bot --json
lizard events --json
```

В логе должно появиться `Telegram worker started`. Отправьте сообщение боту и проверьте, пришёл ли один эхо-ответ. Затем остановите и перезапустите рабочий процесс в утвержденное тестовое окно и подтвердите, что он переподключился. Рабочий процесс, помеченный как запущенный, всё равно требует этой проверки на уровне приложения.

<span id="common-failures" />

## Типичные сбои

| Симптом | Проверка |
|---|---|
| Процесс завершается сразу | Установите `TELEGRAM_BOT_TOKEN` на потребляющем сервисе. |
| HTTP-проверка здоровья никогда не проходит | Режим рабочего процесса должен использовать `containerPort=0`. |
| Обновления прекращаются или появляются ошибки конфликта | Только один процесс опроса должен использовать этот токен; проверьте локальный процесс, другую реплику или активный вебхук. |
| Повторные ответы после сбоя | Демоверсия не сохраняет смещения и не дедуплицирует ID обновлений. Добавьте устойчивую идемпотентность перед обработкой необратимых действий. |
| Частые повторные попытки | Проверьте сетевой доступ, валидность токена, лимиты Telegram и ваш обработчик. Не печатайте URL запросов: они содержат токен. |

<span id="state-and-cost" />

## Состояние и стоимость

Для устойчивого состояния бота подключите [Managed Postgres](https://lizard.build/ru/docs/addons/postgres). Храните обработанные ID обновлений и делайте обработчики безопасными для повторных вызовов. Long polling может держать рабочий процесс активным между сообщениями; планируйте бюджет от [цен](https://lizard.build/pricing) и наблюдаемого потребления ресурсов, а не только от количества сообщений.

<span id="related-guides" />

## Связанные руководства

- [Фоновые рабочие процессы](https://lizard.build/ru/docs/deploy/workers)
- [Логи](https://lizard.build/ru/docs/observability/logs)
- [Лимиты](https://lizard.build/ru/docs/platform/limits)
- [Справочник Telegram getUpdates](https://core.telegram.org/bots/api#getupdates)

См. [результаты сценарийных тестов](https://lizard.build/ru/docs/guides/validation) для проверенных версий, результатов в облаке и оставшихся ограничений.
