Автоматизація білінгу ISPConfig

У ISPConfig є команда на кожен момент, коли гроші й машини стикаються одне з одним: створити обліковий запис, призупинити його, перевести його на інший пакет, вилучити його. Чого в ньому немає, так це чогось, що вирішує, коли їх запускати.

Зʼєднати ці дві половини це здебільшого звичайна робота. Дві речі в ISPConfig звичайними не є, і обидві нишком зламають першу спробу: статус-код виклику не каже вам зовсім нічого, а обліковий запис не є клієнтом.

Статус-код не каже нічого

Усе повертається як HTTP 200. Помилки валідації, «такого не існує», неправильний пароль, метод, який віддаленому користувачеві не дозволено викликати: усе це, 200. Вердикт є полем code всередині тіла JSON.

Класифікуйте за code і за текстом, ніколи за статусом. Причина, чому для інтеграції білінгу це важить більше, ніж для будь-чого іншого, це опитування: клієнт, який вважає 200 успіхом, читає збій автентифікації як успішний порожній інвентар, а тоді позначає кожен обліковий запис того клієнта як зниклий. Одна прострочена сесія, і ваше звіряння видаляє хостинговий бізнес.

Поле message буває двох ґатунків, і різниця корисна. Помилки валідації від власного шару форм панелі це розділений <br> список ключів перекладу, а не речення: domain_error_unique для домену, який уже розміщено. Перевірки у віддаленій бібліотеці це звичайні англійські речення: Invalid client_id 99999. Ключі зіставляйте, речення цитуйте.

Один обліковий запис це один вебсайт, а не один клієнт

ISPConfig розділяє дві речі, які більшість панелей керування зливає докупи. Клієнт це вхід у панель із лімітами на весь обліковий запис. web_domain це один розміщений сайт. Один клієнт може володіти кількома вебсайтами.

Хостинговий обліковий запис Provibr це один вебсайт, який визначається своїм доменом. Тому створення потребує власника, тож агент створює свіжого клієнта й вебсайт під ним, а вхід клієнта виводить із домену, щоб завжди знову знайти власника.

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

Життєвий цикл, зіставлений

Призупинення ідемпотентне в обидва боки

Призупинення перемикає прапорець active вебсайту між y і n. Немає ні бітових масок, ні часткових станів: сайт або ввімкнено, або вимкнено.

Друге призупинення вже призупиненого сайту відповідає code: ok з відповіддю 0, що означає нуль змінених рядків. Це не помилка, і прогону нагадувань, який призупиняє все прострочене, зокрема те, що він призупинив учора, немає за що вибачатися. Варто оцінити, наскільки це рідкість: як показує стаття Автоматизація білінгу та провізіювання HestiaCP, там те саме друге призупинення це HTTP 401, не відрізнити від неправильного секрету, на панелі, яка блокує вашу адресу після пʼяти відмовлених входів.

Одну річ варто знати, хоч інтеграція нею й не користується: у ISPConfig є ще замок на рівні клієнта, і його встановлення перемикає кожен вебсайт того клієнта в неактивний стан одразу. Клієнт, який замикає сам себе в панелі, або замок реселера над ним, тому зʼявляється в опитуванні як призупинений. Це правильно, і це не те, що зробила ваша система білінгу.

Зміна пакета тут є справжньою дією

Пакет ISPConfig це шаблон клієнта: іменований набір лімітів, збудований адміністратором у панелі. Віддалений API не може створити такий, і це нормально, бо тариф має посилатися на пакет, а не вигадувати його. Provibr передає назву пакета, а агент знаходить ID шаблона.

Це робить ISPConfig однією з панелей керування, де зміна тарифу є справді зміною тарифу. CloudPanel і CyberPanel мусять відмовити в ній прямо; тут вона стається, і ліміти зсуваються одразу.

Два виміряні застереження, якщо ви пишете це самі. Надсилайте мінімальне оновлення, яке не несе нічого, крім нового шаблона: оновлення з усім записом клієнта поверталося як remote_fault без придатного повідомлення, і так само поводилося те, що поєднувало явний шаблон із явними лімітами. І знайте, що шаблон перекриває ліміти, які ви теж надсилаєте, і це правильний порядок, але першого разу він людей дивує.

Сигнал готовності є глобальним для сервера

Створення вебсайту відповідає за мілісекунди, і та відповідь означає прийнято, а не виконано. Рядок у базі даних існує; віртуальний хост і кореневий каталог документів укладаються асинхронно демоном сервера.

Сигнал, на який треба чекати, це лічильник черги завдань для того сервера, який, як виміряно, падав з трьох до нуля приблизно за вісім секунд на спокійній машині і приблизно за двадцять три секунди в ранішому прогоні. Це глобальний лічильник, а не лічильник на кожну команду. На завантаженому багатоклієнтському сервері він може лишатися вище нуля через завдання інших клієнтів або дійти нуля, поки ваша робота ще чекає.

Тож правилом є тайм-аут із правдивим повідомленням, а не нескінченне очікування: опитуйте, доки черга не спорожніє або доки не вичерпається бюджет створення у 180 секунд, а тоді повідомте, що обліковий запис створено, бо це так. «Сайт ще налаштовується» це краще, що можна сказати клієнту, який платить, ніж крутілка, яка ніколи не спиняється.

Видалення є питанням приватності, а не питанням прибирання

Це та частина статті, яку варто лишити, якщо не лишати нічого іншого, і насправді вона не про ISPConfig.

У шляху видалення була вада, якої не могла побачити жодна фікстура: він порівнював два поля, які ніколи насправді не рівні, тож гілка, яка вилучала клієнта-власника, була мертвим кодом. Кожне видалення лишало по собі вхід у панель, що ніс імʼя клієнта, його адресу електронної пошти, контактні дані й пароль. Команда відповідала ok, вебсайт зникав, лічильник ішов у нуль, а особисті дані людини, яка попросила піти, лишалися на вузлі.

Нічого над панеллю цього не бачить. Робітник очищення та вивантаження даних субʼєкта прибирають наш бік; вони не мають жодного огляду того, що лишилося на вашому хостинговому вузлі. Правило, яке з цього вийшло, варто вкрасти:

> Міряйте шлях видалення проти власної бази даних панелі, і ніколи проти «команда повернула ok».

На ISPConfig це чотири підрахунки, і всі чотири мають бути нулем: вебсайти, клієнти, системні входи й каталог клієнта на диску. І міряйте це панеллю, а не помічником прибирання з вашого власного тесту, бо помічник може нести те саме непорозуміння, і тоді машина має чистий вигляд, поки інтеграція протікає.

Саме правило безпечного видалення це один рядок: вилучіть вебсайт; вилучіть клієнта-власника лише тоді, коли в нього не лишилося вебсайтів. У ISPConfig є виклик, який видаляє клієнта й усе під ним, і на імпортованому обліковому записі це забрало б інші сайти клієнта. Ніколи не видаляйте більше, ніж просили.

Ніщо не миттєве

Ваша панель доступна лише через агента всередині вашої власної мережі, а той агент набирає назовні, тож кінцева точка, яка змінює обліковий запис, не може відповісти результатом. Вона відповідає, що замовлення прийнято, і віддає вам команду, за якою треба стежити, доки її статус не стане остаточним: виконано, не вдалося, вичерпано час або скасовано. Читання так не працює ніколи, бо інвентар чи рахунок надходять із бази даних, а не з вашого хоста.

Практичний наслідок для гачка білінгу: не позначайте замовлення завершеним за відповіддю про прийняття. Усе, що щось створює, також приймає ключ ідемпотентності вашого власного виготовлення, тож повторений вебхук і подвійний клік не коштують вам нічого.

Де живе рахунок

Provibr не виставляє рахунків вашим клієнтам, не переслідує їх і не знає, скільки ви з них берете. Ці стосунки належать вам.

Provibr виставляє рахунок за потужність, яку резервуєте ви: скільки хостингових облікових записів вам дозволено запускати одночасно, за ціною за одиницю, що падає рівнями зі зростанням кількості. Для хостингового облікового запису немає «зупинено»: є активний і призупинений, і призупинений не рахується. Тож дія нагадування, яку ви вже хотіли виконувати з комерційних причин, водночас є тією, що звільняє слот, за який ви платите.

Чого це не автоматизує

Provibr керує обліковими записами, а не панеллю. Він не встановлює ISPConfig, не оновлює його й не торкається поштових скриньок, баз даних чи DNS: клієнт, який видаляє власну поштову скриньку, робить це без того, щоб щось над панеллю про це знало чи цим переймалося. Для хостингового облікового запису немає ні консолі, ні перевстановлення, ні часткового призупинення.

Якщо ви перебуваєте раніше за цю частину з білінгом, супутньою статтею є Як продавати вебхостинг із ISPConfig, що охоплює віддаленого користувача, звуження області дії та модель «одна панель, кілька серверів». Облікові дані, сертифікат і екран пакетів задокументовані на сторінці документації ISPConfig.