Как стать автором
Обновить

Комментарии 35

Мне показалось удобным через sshfs файлы перекидывать. Монтируешь папку с проектом на сервере как папку на своём компе и спокойно редактируешь/добавляешь файлики.

Спасибо! Речь об этом ru.wikipedia.org/wiki/SSHFS? Что-то типа папок dropbox получается?

Да, оно. Тоже писал бота) Ещё через ssh можно интерфейс прокидывать — например, чтобы на сервере открывался редактор текста как окно на моём компе. (Линукс и там и там).
P.s. Ещё я регал двух ботов — один для отладки у себя, второй на сервере, а файлик с токеном для бота добавлял в .gitignore

Спасибо! Интересно. Я вот сейчас серьезно задумался над папкой дропбокса :) Кажется, самое простое решение :)
Если пользуетесь VS Code, то в новой stable версии 1.36 (раньше было только в VS Code — Insiders) выкатили классную фичю для работы по ssh — Visual Studio Code Remote — SSH. Есть драг н дроп, терминал и т.д. Буквально вчера тестил — работает на ура.
А можно поподробнее про webhooks лучше чем polling? Мне всегда выбор одного подхода против другого виделся больше как следствие предпочтительного языка.
PHP? Удобнее webhook.
NodeJS? Удобнее polling.
Длительное исследование по сравнению этих решений не проводил. Но polling на сервере начал отрубаться сразу. Решить проблему не получилось. Пришлось идти к вебхукам (как изначально советовал интернет :) ) С вебхуками возникла другая проблема, корни которой, я подозреваю, все те же самые, что и с polling, но бот на webhook не падает. Проблема вот в чем. После некоторого простоя, бот как бы зависает, залипает (это с webhook). Как результат, идет системная ошибка 104, сообщение в телеграм от бота не уходит (то есть запрос пользователя в боте остается без ответа). Но если отправить запрос второй раз, то сообщение отправится. Я искал причину ошибки. Оказалось, что ошибка не такая уж и редкая. На гитхабе pyTelegramBotAPI нашел намек, что можно обработать ее исключением и отправить еще раз :) Поставил эту заплатку, то есть ловлю ошибку и отправляю сообщение еще раз. Сейчас все ок. Реальная причина ошибки не ясна. То ли это особенность GCP (GCE), то ли pyTelegramBotAPI, то ли их связки… Одно точно скажу, замена библиотек, устанавливающих веб-сервер (при том, что pyTelegramBotAPI остается) на это никак не повлияла. Думаю, снова переписать бот на чистом API Telegram'а и посмотреть. Если все будет работать, то виновата pyTelegramBotAPI, если нет, то виноват GCE или некая его особая настройка, возможно, сервер нужно отдельно от бота поднять будет. Но это все имеет смысл только в случае коммерческого продукта и для успокоения души ;) Поэтому, отвечая на ваш вопрос, лично у меня оснований утверждать об особых преимуществах webhook над polling ровно столько, что на webhook в моем случае бот работает, а на polling нет. Возможно, на polling сейчас (после написания статьи) я смогу бот на сервере настроить, появились идеи. Но логика webhook правильнее.
Если на сервере для обработки каждого запроса отводится новый поток, тот вебхук позволяет нативно получить многопоточность. Тогда как для пулинга нужно эту многопоточность реализовывать через средства языка/фреймворка.
Если к боту на heroku обращаются довльно часто, то система не затушит его и он будет работать постоянно. Если же к нему нет обращений, то система выключит его и перестанет уменьшать лимит тарифа, а первый же запрос от сервера телеграма снова разбудит (будет небольшая задержка между запросом и ответом).
Также можно придумать WA, когда эндпоинт бота автоматически пингуется каким-то сервисом по крону и не даёт системе убить скрипт.
На Heroku можно выбрать тип воркера:
— web (засыпает через 30 минут неактивности)
— service (не засыпает)
Бесплатных часов как раз хватает на один сервис 24/7. В Procfile пишешь «service:...»
Мой бот на java уже год работает, ни разу не засыпал сам по себе.
И Long Polling в Java telegrambots lib не отваливался никогда.
Да, насколько я понимаю, обращение к боту должно будить его, если настроен webhook. Но когда я делал бота — хотел настроить webhook и, после изучения документации, пришёл к выводу, что это сделать не получится, так как heroku не предоставляет статичесикй IP-адрес (по крайней мере — на бесплатном аккаунте), а без него не получить сертификат. Сделал бота на pooling, работало всё нормально, но даже сообщение боту не будило его после засыпания, так как он сам обращается за новыми сообщениями к telegram, а не они приходят к нему. Решилась проблема действительно настройкой стороннего сервиса, который мониторит приложение и таким образом периодически будит его своим обращением. Для этих целей на heroku нашёлся очень удобный аддон:
elements.heroku.com/addons/newrelic
Уже полгода так всё и работает.

Вот только, на самом деле, с веб-хуками проблем не будет. Самоподписанный сертификат же, как выяснилось, телеграм прекрасно принимает — а динамический IP можно сообщить ему через API при старте бота.


newrelic же выглядит диким оверкилом: это точно проще чем сменить тип воркера на service ?

newrelic весьма прост. А насчёт сменить тип на service — почему-то когда я искал решение для засыпающего бота, такой вариант мне не попался — ни в документации heroku, ни где-либо ещё. Если можно просто изменить одно слово в Procfile то, конечно, это проще всего.
А зачем вешать вебхуку на ip адрес, есть heroku предоставляет удобный https endpoint для веб приложений? Есть мануал от авторов python-telegram-bot: https://github.com/python-telegram-bot/python-telegram-bot/wiki/Webhooks#heroku.

Как я себе представлял на момент создания бота — статический IP нужен для получения сертификата.

нужен домен 2-3 уровня — это обязательно. А IP особо не важен
SSL-сертификат на IP можно получить куда как проще. Есть чудесный сервис SSLip.io, который резольвит X.X.X.X.sslip.io на X.X.X.X

На X.X.X.X.sslip.io отлично выписывается сертификат Let's encrypt, команда на его продление закидывается в crontab.
А чем не устраивает командная строчка из статьи? Можно установить 10 лет и продлять не надо.
нормальный сертификат всегда лучше самоподписанного.
Let's encrypt предоставляет прекрасную инфраструктуру, зачем себе забивать голову, если можно пользоваться готовым и бесплатно?
Спасибо! Логику понял.
При выборе между хуками и пулинга вспоминается аксиома Эскобара.
Почему-то нигде не видел туториала, где используется tglib (ядро телеграм клиентов) напрямую, который лишен минусов обоих способов + доступен более обширный апи.
А еще, если в вашей сети телеграм клиент может пробиться через блокировки РКН, то и tglib сможет — на проде такой плюс не особо важен, но разработку иногда может сделать чуть проще.

От питона я далек, под nodejs использую эту штуку github.com/Bannerets/tdl#login-as-a-bot наверняка и под python есть адекватные обертки.
Спасибо! Размещая на GCE о блокировках уже не думаешь, сервер не в России. Я рассматривал варианты для Python, tglib, как вижу, это либа под nodejs (эта github.com/nodegin/tglib ?). Я могу использовать еще API Telegrama, что также пробовал. А как tglib взаимодействует с Телеграмом, если она лишена всех недостатков?
Я опечатался (2 раза)
Речь о github.com/tdlib/td
Официальная кроссплатформенная нативная шаред библиотека.
Оно подключается и взаимодействует с серверами телеги так же как и обычный телеграм клиент. Не нужен ни веб сервер, ни пулинг.
Спасибо, уже смотрю. Вопрос вот в чем. Стоит ли поднимать клиента ради скромного бота? Но интересно, что вариантов реализации одного и того же решения много. Это не может не радовать.
Если уже есть готовые хуки то имхо переписывать не стоит, тем более на GCE. Я не в курсе как вообще на GCE свои бинари накатывать.
+ Если собирать tdlib не в том линукс окружении, где она будет работать (на win проще там 4 dll руками можно скопировать), то вероятно будет ругаться на не те версии системных библиотек.

Также обратите внимание что для сборки tdlib требуется >8Гб памяти через gcc (нужен свежий) и чуть менее 4Гб памяти через clang/msvc

Поэтому я собрал tdlib один раз под конкретную версию debian и накатываю её на vps клиентам.

Сейчас наверняка снова кто-нибудь будет писать про докер и прочие контейнеры, конкретно в моем случае просто — нет (лень объяснять).
Я тоже заметил требовательность к ресурсам. В целом понял. Спасибо!
НЛО прилетело и опубликовало эту надпись здесь
Спасибо прикольно!
Но клиент-аккаунт, это совсем не бот аккаунт.

Разные цели вроде как у них.
Эм, а как поможет библиотека-клиент для телеграма для работы с API ботов? Там же свой API и свои возможности, а так получится бот, прикидывающийся простым пользователем.
tdlib умеет работать как бот (по ссылке из моего первого сообщения есть пример) при этом часть методов доступные пользователю не будут работать, либо будут иметь иные лимиты на частоту вызовов и например размер аттачей, но все равно это больше чем доступно в обычном апи для ботов.
да уж, сэкономил силы на интерфейсе. кэп подсказывает, что для функционала «вопрос-ответ» для друзей было бы вполне достаточно генерировать простую хтмл-страничку с текстом, полем для ввода и кнопкой «отправить». и просто давать друзьям урл.

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

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


Если что, гуглить по ключевым словам "python flask example chat"

А почему бы и нет. Будет время, можно попробовать. У меня помнится и книжка по Flask'у есть :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий