Открытие API для работы с услугами от российского лоукост-хостера (часть 1)

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



Предпосылки к этой публикации появились достаточно давно. Один из клиентов с большим количеством виртуальных серверов поинтересовался о том, есть ли возможность работать с API нашего биллинга. В то время, честно говоря, мы были не готовы к такому диалогу и не смогли предложить готовое решение.
С начала лета мы получили еще несколько подобных вопросов и поняли, что нельзя оставлять их без ответов. И сегодня я расскажу как работать с API биллинга нашей компании для заказа виртуальных серверов любого количества.

В качестве биллинговой системы мы используем продукт российской компании ИСПсистем — BILLmanager4. Для всех продуктов ИСПсистем есть открытое API и оно описано в большей или меньшей степени на их официальном сайте документации ispdoc.com
Работать с API можно как из командной строки, обращаясь непосредственно к интерпретатору mgrctl, так и через адресную строку браузера (или любое другое приложение, которое будет отправлять запрос на веб-сервер: curl, wget и т.п)
Исходя из документации можно составить запрос к любому из продуктов, НО при работе с биллингом требуется некоторое количество информации, которая доступна только со стороны хостинг-провайдера.

Сам запрос для заказа виртуального сервера, к примеру, KVM Ferrum на один месяц с автоматическим помесячным продлением, шаблоном ОС Centos-6.7-x86_64-minimal без использования лицензии ISPmanager, будет выглядеть так:
https://billing.ihor.ru/billmgr?authinfo=<USER>:<PASS>&addon_1101=20&addon_1103=1&addon_1104=1&addon_1110=1&addon_1791=4&enum_1112=21&enum_1106=25&agree=on&domain=test-for.habr&ostempl= Centos-6.7-x86_64-minimal&period=1210&price=1100&autoprolong=1210&payfrom=neworder&func=vds.order.7&sok=ok


Теперь попробуем расшифровать все это нагромождение переменных и цифр.
Сам запрос можно разделить условно на две части: это URL биллинга и передаваемые параметры запроса биллингу.
Сами параметры можно распределить следующим образом:
Описание параметров
  • Авторизация — authinfo

В качестве данных авторизации указывается логин и пароль пользователя, зарегистрированного в биллинге.
  • Тарифный план — price

Каждому тарифному плану соответствует свой идентфикатор в биллинге, берется из таблицы «Тарифные планы».
  • Параметры тарифного плана – addon_

К параметрами тарифного плана относятся параметры виртуального сервера, его ресурсы. Каждый параметр тарифного плана имеет свой идентификатор и свое значение по умолчанию, которое соответствует размеру диска, количеству ядер процессора и оперативной памяти, а так же IPv6- и IPv4-адресам.
  • Дополнительные услуги – enum_

В дополнительные услуги входят DNS-серверы и использование лицензии ISPmananger.

(параметры по умолчанию для KVM Ferrum)
  • Период заказа — period
  • Автопродление – autoprolong
Идентификатор периода заказа и автопродления для каждой из услуг абсолютно одинаковы.
  • Доменное имя сервера – domain

Доменное имя должно быть уникальным. Иначе появится ошибка
Ошибка: The domain is already in use. Specify a different domain name.
При массовом добавлении виртуальных серверов, рекомендую использовать формат +<порядковый номер>.
  • Шаблон ОС – ostempl

Неполный список шаблонов приведен в этом тексте чуть ниже. Обращаю внимание, что при заказе шаблона ОС без ISPmanager, в установке значения дополнительных услуг следует отключить использование панели управления ISPmanager (для всех тарифных планов этот идентификатор одинаков — 25)
  • Параметры оплаты – payfrom

В примере я привел значение параметра оплаты — neworder, что соответствует отдельному заказу с оплатой для каждого сервера. payfrom=neworder.
  • Оплата заказа – func

Так как весь заказ виртуального сервера состоит из 7 шагов, то в API, что не особо очевидно на первый взгляд, следует указывать не только саму функцию vds.order, но и номер последнего шага — 7. Таким образом полное значение этого пункта выглядит так: func=vds.order.7
  • Подтверждение пользовательского соглашения – agree

При заказе любой из услуг мы предлагаем ознакомиться с пользовательским соглашением и принять его (тогда заказ уходит на активацию) или не принять его (тогда заказ отменяется). В API этот пункт так же обязателен: agree=on.

Часть параметров фиксирована и я привел их значения при описании, а значения других можно взять из таблицы, которая целиком приведена на странице сайта со справочной информацией по работе с хостингом.

Чтобы не загромождать текст большими таблицами со всеми тарифными планами, я приведу только ту часть, которая поможет разобраться, как была составлена строка для заказа виртуального сервера с тарифным планом KVM Ferrum. А так же два других младших тарифных плана SSD и OVZ


Список шаблонов
  • FreeBSD-11-amd64-minimal
  • Centos-6.7-x86_64-minimal
  • Debian-7-x86_64-minimal
  • Debian-8-x86_64-ispconfig
  • Ubuntu-16.04-x86_64-minimal
  • CentOS-7-x86_64-ispmgr5

Если запрос составлен корректно и заявка на активацию новой услуги принята, Вы получите в ответ что-то типа этого:
<script language='JavaScript'>fr_master('startpage=vds', 'top.');</script>

Ниже в качестве бонуса прикладываю несколько скриптов для заказа произвольного количества виртуальных серверов для консоли Linux и Windows.
Если в комментариях будет проявлен интерес к развитию темы работы с API нашего биллинга, мы постараемся описать ее более подробно, с использованием различных языков программирования и программных продуктов для интеграции.
Пример на BASH
#/bin/bash
#
# Данные для авторизации
USER=user
PASS=password

# Заказать 10 виртуальных серверов
for i in {1..10}
do
/usr/bin/curl https://billing.ihor.ru/billmgr?authinfo=$USER:$PASS&addon_1101=20&addon_1103=1&addon_1104=1&addon_1110=1&addon_1791=4&enum_1112=21&enum_1106=25&agree=on&domain=$USER-$i.ru&ostempl= Centos-6.7-x86_64-minimal&period=1210&price=1100&autoprolong=1210&payfrom=neworder&func=vds.order.7&sok=ok"
done


К сожалению, не удалось придумать никакого приличного варианта, кроме как продублировать предыдущий цикл с использованием curl, собранного для работы в Windows. Но если из числа читателей есть искушенные в скриптописательстве/программировании под Windows, то прошу поделиться более рациональными сценариями в комментариях.

Пример на PowerShell, файл curl.exe должен находиться в той же директории, откуда выполняется скрипт
USER=user
PASS=password

for ($i=1; $i -lt 10; $i++) {
.\curl.exe https://billing.ihor.ru/billmgr?authinfo=$USER:$PASS&addon_1101=20&addon_1103=1&addon_1104=1&addon_1110=1&addon_1791=4&enum_1112=21&enum_1106=25&agree=on&domain=$USER-$i.ru&ostempl= Centos-6.7-x86_64-minimal&period=1210&price=1100&autoprolong=1210&payfrom=neworder&func=vds.order.7&sok=ok"
}

0 комментариев

Оставить комментарий