На стадии разработки бота на PHP, необязательно иметь хостинг, домен и ssl-сертификат для настройки webHook. Можно настроить съем обновлений с серверов Телеграм через getUpdates. Я для этого функционала использую возможности Node.js.
webHook — это адрес, по которому расположена точка входа вашего приложения, именно на него будет отправлено «обновление» (данные в формате JSON) при любом взаимодействии с вашим ботом.
getUpdates — это метод Телеграм API, при вызове которого вам будут выданы накопленные на серверах Телеграм «обновления» вашего бота.
При разработке бота я пользуюсь IDE PHPStorm, настраиваю загрузку на сервер всех изменений при нажатии горячих клавиш. На сервере у меня при этом настроен домен, ssl-сертификат и к боту привязан webHook. Совсем недавно при просмотре одного из вебинаров я увидел, как ведущий запустил бота через getUpdates и в него прилетали «обновления» совсем не хуже, чем через вебхук.
Мне это стало интересно, я попробовал настроить такого бота у себя. Это не составило труда с использованием фреймворка Telegraf.js — буквально несколько строк. Пришла мысль — перенаправить «обновления» на локальный сервер, а там обработать данные PHP скриптом. Изменив немного первоначальный код у меня появился хороший инструмент, которым я теперь пользуюсь.
TELEGRAM BOT ON PHP | #09 INSTALLING THE BOT ON HOSTING
Теперь можно работать на локальном компьютере без необходимости иметь домен, ssl-сертификат и хостинг. Если вы используете хостинг как и я Timeweb, то Node.js можно настроить по инструкции.
index.js
// Подключаем необходимые модули const Telegraf = require(‘telegraf’); const request = require(‘request’); // Заполняем конфиг let config = < «token»: «TOKEN_BOT», «webhook»: «http://localhost/», «method»: «POST», «headers»: >; // Создаем объект бота const bot = new Telegraf(config.token) .use((ctx) => < // вешаем прослушку // при событии отправляем обновление на наш обработчик request(< url: config.webhook, method: config.method, headers: config.headers, json: ctx.update >); >).launch(); // запускаем прослушку событий
index.js с настройками proxy
Если есть необходимость в работе через прокси, то можно этот вариант кода, это на случай если у вас заблокирован Телеграм
package.json
< «name»: «getUpdates», «version»: «1.0.0», «description»: «», «main»: «index.js», «scripts»: < «test»: «echo «Error: no test specified» exit 1″ >, «author»: «iMakeBots.ru», «license»: «», «dependencies»: < «https-proxy-agent»: «^2.2.1», «request»: «^2.88.0», «telegraf»: «^3.26.0» >>
Источник: imakebots.ru
Пишем бота для Telegram на PHP
Всем привет. Поскольку в опроснике большинство проголосовало за написание статей по созданию ботов, дальнейшем я буду писать больше на эту тему. А начнем мы с самого простого бота с использованием PHP и Botman Studio.
Botman Studio — это специальный фреймворк для разработки ботов на основе laravel (можно использовать и без отдельным пакетом). Включает в себя драйверы для различных мессенджеров таких как Facebook Messenger, Slack, Telegram, WeChat и другие.
А создадим мы бота который будет отвечать на сообщения пользователей. Ничего сложного.
Регистрация бота
В интернете уже написано много статей о регистрации бота в телеграм, потому мы очень быстро пробежимся по ключевым шагам.
После этого у вы получите токен бота, через него мы и будем взаимодействовать с api.
Открываем файл .env и пишем туда строчку:
TELEGRAM_TOKEN=YOUR-TELEGRAM-TOKEN-HERE
YOUR-TELEGRAM-TOKEN-HERE заменяем на токен
Создание проекта
Для начала работы у вас должен быть установлен composer (ссылка на инструкцию). Если композер установлен, можно приступать к созданию бота.
Открываем консоль и переходим в нужную директорию, вводим команду composer create-project —prefer-dist botman/studio project_name где project_name — название вашего проекта(и директории которая будет создана).
Подключение к API
Проект создан, приступим к написанию функционала бота. Первым делом нужно подключить драйвер для телеграм:
php artisan botman:install-driver telegram
Для работы вебхука нужен обязательно доступ по https , для этого вам понадобится либо собственный домен с https либо можно воспользоваться https://ngrok.com/.
Установка Web хука
Чтобы получать сообщения от пользователей нам нужно установить вебхук. Регистрация вебхука выполняется пост запросом на адрес https://api.telegram.org/bot /setWebhook , нужно передать всего один параметр url со значением https://mylocal.app/botman(урл заменить на свой но обязательно оставить botman ).
Для регистрации вебхука в Botman вам не нужно вручную ничего отправлять, просто запустим команду — php artisan botman:telegram:register и укажем адрес вашего вебхука. Для создания https без собственного домена и бесплатно я использую ngrok , делается это всего за несколько команд
Если вы только скачали себе приложение, вам нужно добавить ваш токен авторизации, как это сделать описано в личном кабинете в разделе Auth
После этого запускаем сервер:
ngrok http 80 —host-header=bot.local
bot.local указано потому что у меня настроен виртуал хост на моего бота в апаче и в файле hosts есть запись
Копируем адрес https который получили и выполняем команду php artisan botman:telegram:register , вас попросят указать адрес вебхука, вставляем и дописываем /botman
Теперь у вас есть полноценный бот в телеграме, он умеет слушать сообщения и если увидит сообщение Hi ответит вам Hello! . Попробуйте сами, найдите вашего бота в телеграмм и напишите ему слово Hi
Источник: adminnotes.info
/dev/energy
Сайт о том, как стать программистом и как с этим жить потом
Serverless Telegram бот на базе PHP и AWS Lambda
Rate this item: Submit Rating
Rating: 5.0/5. From 4 votes.
Please wait.
В Сети есть огромное количество мануалов, посвящённых работе бессерверным окружениям от Amazon Webservices (и не только) и даже запуску «Hello, World!» на PHP внутри этих окружений. Но, решив самостоятельно собрать что-то дельное при помощи этих инструментов, я столкнулся с огромным количеством пробелов и подводных камней. Обойдя их, я в конце концов запустил простенького Telegram-бота, которого можно дорабатывать в любом направлении. Но давайте обо всём по порядку!
Видеоверсия статьи доступна ниже, но я рекомендую сочетать её с текстом.
Что такое Serverless и AWS Lambda?
Если Вы ещё не знакомы с концепцией так называемой «Бессерверной Архитектуры» или Serverless, у Вас вполне может возникнуть совершенно логичный вопрос: «А зачем это всё нужно?». И начинать надо именно с понимания области применения данного подхода, чтобы потом не было мучительно больно.
Serverless — это относительно молодой метод запуска Ваших скриптов в облаках, таких как AWS. Сейчас довольно популярны подходы Something As A Service (*aaS — например, IaaS, PaaS, SaaS), который заключаются, грубо говоря, в предоставлении определённого уровня сервиса по клику мышки, будь то готовая среда выполнения для Вашей логики или, например, знакомый многим Office 365. Вам ничего не надо устанавливать, кроме браузера, для того, чтобы начать работу. Так вот, Serverless является реализацией подхода FaaS (Function as a Service), заключающегося в предоставлении потребителю готовой платформы для разработки, запуска и управления некой функциональностью без необходимости самостоятельной её подготовки и настройки.
Вам не важно, где запускается Ваш скрипт, откуда провайдер возьмёт ресурсы и сколько он их возьмёт. Это означает, что приложение может легко масштабироваться до любых размеров в зависимости от нагрузки. Для PHP-скриптов это означает, что Вам надо либо работать в парадигме Stateless, либо тщательно подумать о том, как будет храниться состояние (сессии). Благо Serverless не накладывает ограничения на вызов необходимых хранилищ, будь то привычная многим MySQL база или какое-то более навороченное решение.
Важной особенностью Serverless является короткий цикл работы скрипта (в зависимости от платформы — до нескольких часов). Если мы говорим про AWS, то их таймаут составляет 15 минут, поэтому аналитические расчёты или огромный map-reduce на час тут не прокатят. Но вот запустить того же telegram-бота, который должен быстро отвечать пользователю — это довольно штатная задача для Serverless приложений. Это означает, что на них нацелены те команды и разработчики, которые хотят быстро запустить небольшое приложение. И это же говорит о том, что стоимость данных услуг очень и очень низкая при понимании вышеозначенных ограничений.
Мощности Lambda являются настраиваемыми, но занятный факт в том, что у AWS мощности CPU для Lambda недоступны для настройки и увеличиваются автоматически прямо пропорционально объёму выделенной RAM. Таким образом, увеличивая объём RAM, Вы буквально ускоряете приложение по всем фронтам.
AWS Lambda работает по принципу «Триггер — Выполнение — Последствия». Триггер — это событие, которые побуждает Lambda к выполнению. Последствия — это то, что порождает Lambda — запись в БД, логи, вызов других Lambda. При первом вызове для выполнения Lambda на стороне AWS генерируется микро-виртуальная машина, которая будет жить некоторое время на случай последующих вызовов. На эту машину загружается код из S3 хранилища, готовится среда выполнения и происходит вызов функции.
Цены на сервис
На момент написания статьи AWS предоставляет 1 миллион запросов и 400 000 ГБ-секунд в месяц бесплатно. Если первый параметр очевиден, то второй стоит описать подробнее. Гигабайт-секунды — это метрика объёма вычислений, которая представляет собой отношение общего времени выполнения к выделенной оперативной памяти. Итак, если у Вас есть 1,5 миллиона запросов по 1 секунде каждый, а для скрипта выделено 256 мегабайт RAM, то суммарный объём вычислений будет равен
S = 1 500 000 * 1 * 256 / 1024 = 375 000 ГБ-с
Как видите, этот объём укладывается в лимит бесплатного сервиса, но количество запросов превышает 1 миллион и тарифицируется (по ценам на момент написания статьи) по 20 центов за миллион запросов. Это означает, что 1,5 миллиона запросов в месяц к своему скрипту Вы заплатите 10 центов.
Но не торопитесь бежать и открывать аккаунт в AWS. Помимо этого тарифицируются смежные сервисы:
- API Gateway — самый простой, но самый дорогой способ вызова Lambda в AWS
- Elastic LoadBalancing (ELB) — на мой взгляд, оптимальный способ вызова
- Route 53 — для работы бота, например, понадобится доменное имя. За него надо платить
- SSL-сертификат — также требование Telegram API
- S3 — Вам потребуется хранилище для того, чтобы деплоить приложение
Тем не менее, если Вы не используете API Gateway, все сервисы суммарно тоже не очень дорогие. ELB при работе целый месяц в режиме 24/7 при 25 новых соединениях в секунду обойдётся Вам в 22.5 доллара в месяц. Это уже история для довольно плотной загрузки Вашего скрипта. При работе в режиме 1 запрос в минуту сумма будет значительно меньше.
Сервис DNZ будет стоить 50 центов за месяц использования одной зоны (разумеется, выгоднее использовать DNS-зону не только для бота). 100 000 запросов обойдутся Вам в 0.04-0.06 доллара в месяц. Сертификат для 1 зоны будет стоить 0.75 долларов в месяц. S3 стоит 0.0245 доллара за 1 ГБ, которого Вам вполне хватит, если Вы будете деплоить логику несколько раз в неделю.
Если Вы уже используете облачные решения для своих приложений, то ценообразование для Вас будет выгодно за счёт того, что цены делятся между сервисами, а не уходят только на обслуживание Lambda.
Тонкости организации работы
Теперь поговорим о практике. Как я уже написал выше, самым простым, но самым дорогим (в несколько раз дороже ELB) способом вызова Lambda в AWS является API Gateway. По интересному стечению обстоятельств, именно этот тип вызова указывается во всех мануалах по настройке окружения. Ценообразование вполне логично — чем меньше ты делаешь своими руками, тем больше платишь. Мы же будем рассматривать настройку при помощи ELB, чтобы экономить деньги.
Сам Amazon в своих мануалах предлагает деплоить код, упаковывая его в zip-архивы и загружая на их мощности через AWS API или через интерфейс. В воздухе запахло 2000-ными. Конечно же, это не подход к работе с доставкой кода в современных реалиях, поэтому мы будем использовать принятый многими как стандарт Serverless framework, который разработан на Node.js и позволяет управлять приложениями на базе AWS Lambda.
Ещё одной особенностью является то, что AWS Lambda не поддерживает из коробки вызов PHP-скриптов. А это означает, что нам придётся создавать среду исполнения самостоятельно. Благо сейчас на рынке появилась PHP-библиотека Bref, интегрированная с Serverless, решающая эту задачу. Тем не менее, Вы можете самостоятельно собрать среду исполнения и подружить её с Lambda API. Но дело это неблагодарное, так как проблема уже решена изящным и приемлемым способом.
Настраиваем окружение и AWS
AWS CLI
Начинать стоит с создания аккаунта в AWS и установки AWS CLI. Консольная оболочка от AWS основывается на Python версий 2.7+ или 3.4+. AWS рекомендуют 3 версию языка, поэтому спорить с этим решением мы не будем. Примеры приведу для Ubuntu, но Вы смело можете интерпретировать их для своих Linux-дистрибутивов.
sudo apt-get -y install python3-pip
Далее установим непосредственно утилиту AWS CLI
pip3 install awscli —upgrade —user
Проверку установки можно сделать при помощи
aws —version
После этого Вам нужно будет подключить aws cli к Вашему аккаунту. Конечно, можно использовать и Ваши логин и пароль, но лучше создать отдельного пользователя через AWS IAM и установить ему только необходимые права доступа. Сама конфигурация вызывается просто
aws configure
На этом шаге Вам нужны будут AWS Access Key и AWS Secret. Оба параметра можно найти в ASW IAM, зайдя на страницу нужного Вам пользователя и выбрав вкладку Security credentials. На ней будет кнопка «Create access key», которая позволит Вам сгенерировать ключи доступа. Зафиксируйте их у себя.
Serverless Framework
Для установки Вам также потребуется аккаунт на https://serverless.com/. Версия для разработки бесплатна, и её функционала нам хватит за глаза.
После регистрации нужно установить утилиту serverless у себя на рабочей станции. Я уже отметил, что нам потребуется Node.js (нужна версия 6 и выше).
sudo apt-get -y install nodejs
Для того, чтобы он корректно запускался в нашей среде нужно также выполнить рекомендованные шаги
mkdir ~/.npm-global
export PATH=~/.npm-global/bin:$PATH
source ~/.profile
npm config set prefix ‘~/.npm-global’
Источник: devenergy.ru