Как грамотно деплоить тг бота? Как сделать так, что даже когда он на доработке, он не молчал а присылал отбивку а ля «сервисное обслуживание»?

Question

[AlexxKulkov]

Не сумел найти подробную инструкцию, как правильно деплоить бота
Хочется, чтобы даже когда он на доработке, он не молчал а присылал отбивку а ля "сервисное обслуживание"?

Я сейчас выкатываю его через докер на арендованный сервер, но тоже это происходит не супер удобно: может кто скажет, как это делается правильно и удобно?

Answer 1

[rPman]

ТГ это по факту веб сервер + сервис в интернете, к которому доступ исключительно по http.

Для веб серверов задача обслуживания решается установкой между интернетом и приложением вечно-работающей прослойкой, максимально простой, что бы она могла выдать сообщение о недоступности сервиса и информацию о том когда это закончится. Например типовой веб сервер в режиме прокси, тот же nginx, который будет по команде (переконфигурация веб сервера - меньше секунды) менять эндпоинт между обновляемым и сервисным. По факту у тебя будет два бота, нормальный и тот что будет говорить - 'вы что не видите у меня обед'

Comments

[AlexxKulkov]

В целом понятно, спасибо большое за ответ, но у меня нет опыта работы с nginx, и вообще хотелось бы побольше подробностей и примеров
В любом случае, спасибо еще раз, пошел гуглить)

[mayton2019]

+1 к тому что написал rPman

Добавлю что есть такая концепция деплоя как "blue-green" deployment.
Идея такая что вы держите 2 environment и просто переключаете балансировщик
между ними таким образом обеспечивая минимальный простой для пользователя.

А enviromemnts держат старую и новую версию софта. После успешного тестирования
новая версия становится автоматически старой и вы в это время пилите еще одну
самую новую.

[Valentin Barbolin]

AlexxKulkov, То есть напиши минимального бота который умеет отвечать "сервисное обслуживание", а на уровне nginx настрой балансировку между upstream по таймауту, если основной не ответил то перекинуть запрос на второй. Кстати, попробуй просто возвращать http 503. Возможно телеграм на какаой-то HTTP код сам может интерпретировать что сервер на обслуживании.

[rPman]

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

[Valentin Barbolin]

rPman,

это должно быть ручное переключение

Или если это CI/CD то предусмотреть в нем такой шаг.

Answer 2

[Dmitry Bay]

На полугодовом опыте, тезисы:
1) Иметь тест бота, если вы положили что-то, чтобы не фиксировалось на проде.
2) Иметь лог сообщений, так как 403 ошибка попадается стабильно. Ее нужно обрабатывать. В крайнем случае - ваша рассылка должна заново отправляться.
3) Проверять досконально кнопки, я к примеру как лох отправил 100+ кнопок клиенту, что сломало его клиент.
4) Обрабатывать ошибки. Еще раз говорю. и это важно.
5) он не молчал а присылал отбивку а ля "сервисное обслуживание" -- обрабатывать ошибки отличные от 403.
У вас есть точки -
webhook от бота (про nginx выше написали)
ваша обработка (если php то try catch)
сообщение клиенту (try catch)