Cum vindeți găzduire de servere de joc cu Pelican Panel

Pelican rulează servere de joc. Nu preia comenzi, nu trimite facturi și nu decide că un server trebuie oprit pentru că nu a plătit nimeni. Despre acest decalaj, dintre panoul funcționează și afacerea funcționează, este vorba în această pagină.

Pelican este un fork al Pterodactyl și, în momentul redactării, încă în versiune beta. Provibr se conectează la el ca integrare live și este testat cu Pelican 1.0.0.

Ce vă oferă Pelican și ce nu

Pelican este un panou de control. Cunoaște bine trei lucruri:

Ceea ce Pelican nu cunoaște deloc: un client, o factură, o plată, un abonament care expiră. Există un indicator suspended pe un server, dar nimic din panou nu îl setează vreodată în locul dumneavoastră.

Așadar, o afacere de găzduire de jocuri construită pe Pelican are trei părți, nu una:

1. 01Panoul: Pelican, care rulează serverele dumneavoastră.
2. 02Magazinul: unde un client alege un plan și plătește. WHMCS, Blesta, FOSSBilling, propria dumneavoastră casă de plată.
3. 03Puntea: lucrul care transformă o comandă plătită într-un server care rulează, iar una neplătită într-un server oprit.

Cei mai mulți construiesc a treia parte manual și regretă. Acolo trăiesc cazurile-limită: un nod plin, o variabilă de egg lăsată goală, un client care anulează în timp ce instalatorul încă rulează.

Conectarea Pelican: două chei și o capcană

Pelican are două API-uri cu două chei diferite, iar o punte de provizionare are nevoie de amândouă. Provin din două ecrane diferite și amândouă trebuie să aparțină unui cont cu drepturi de administrator.

Acordați cheii de aplicație acces de citire și scriere la Server, Node, Allocation, User și Egg. Mai puțin de atât și crearea eșuează la jumătatea drumului, ceea ce este mai rău decât un eșec de la început.

Două aspecte legate de asta care costă oamenii o după-amiază:

Copiați cheia de client în clipa în care apare. Pelican o afișează o singură dată. După aceea, lista păstrează doar un identificator scurt, iar acel identificator este acceptat ca o cheie, așa că, dacă îl lipiți, obțineți o simplă eroare de autentificare în loc de un indiciu că ați copiat lucrul greșit. Cheia de aplicație poate fi recitită integral din listă; cheia de client, nu.

Aveți grijă ce cheie ajunge în ce câmp. Pelican acceptă o cheie de client și pe API-ul de gestiune, așa că inversarea celor două nu produce nicio eroare vizibilă. Prefixul este singurul lucru care le deosebește. Provibr verifică acest prefix pe ambele părți exact din acest motiv: alternativa este o integrare care pare să se autentifice și apoi se comportă ciudat timp de o săptămână.

Aici nu există nicio scurtătură din linia de comandă: Pelican nu oferă nicio comandă artisan pentru cheile API, așa că amândouă se creează prin interfața web.

Dacă panoul prezintă un certificat autosemnat, fixați-i amprenta în loc să dezactivați verificarea. Un panou accesibil prin http simplu funcționează, dar atunci amândouă cheile circulă necriptate prin rețeaua dumneavoastră, iar o amprentă alături de o adresă http este refuzată, pentru că nu există niciun certificat de fixat.

De la egg-uri la ceva ce se poate vinde

Un egg nu este un produs. Nu are preț, nu are un nume pe care un client să îl recunoască și nu are limite atașate. Un plan este stratul care îl transformă pe unul în celălalt: conține egg-ul, imaginea Docker, comanda de pornire și limitele de resurse pe care le primește un server.

Două detalii care îi surprind pe oameni când stabilesc limitele:

• Memoria, discul și CPU acceptă 0 pentru nelimitat.
• Limita de CPU se numără în procente dintr-un nucleu. 100 înseamnă un nucleu întreg, 200 înseamnă două. Un plan vândut ca „2 vCPU” este 200, nu 2.
• Greutatea IO merge de la 0 la 1000, iar 500 este valoarea obișnuită.

Regula variabilelor obligatorii

Un egg își definește propriile variabile și le marchează pe unele ca obligatorii. Iată o decizie care merită copiată, indiferent dacă folosiți Provibr sau nu:

Refuzați comanda atunci când o variabilă obligatorie este goală, chiar dacă Pelican însuși ar accepta-o.

Pelican creează serverul oricum. Containerul se prăbușește atunci la prima pornire, clientul vede un server mort, iar coada dumneavoastră de suport primește un tichet pe care scrie „nu merge”. Un câmp care se face roșu la finalizarea comenzii este un răspuns mult mai bun decât un server care există și nu rulează.

Provibr citește lista de egg-uri din panoul dumneavoastră, așa că formularul de comandă oferă egg-urile pe care le aveți efectiv, în loc să ceară cuiva să introducă un număr.

Unde ajunge un server

Pelican raportează câtă memorie și CPU are fiecare nod și cât din acestea sunt deja distribuite. O punte rezonabilă le folosește pe amândouă: un server nou merge pe un nod care are loc pentru el și este refuzat cu un motiv atunci când niciun nod nu are.

⚠️ Cifrele pe care le raportează panoul sunt o contabilitate, nu o măsurătoare. Ele adună limitele serverelor de pe un nod, inclusiv ale celor care încă se instalează. Un nod poate astfel părea plin, în timp ce în realitate rulează foarte puțin.

Acest lucru contează comercial. Dacă supravindeți (și cei mai mulți furnizori de găzduire de jocuri o fac, pentru că un server Minecraft căruia i se alocă 4 GB folosește rareori 4 GB), atunci cifrele Pelican vă vor opri cu mult înainte de hardware. Planificați-vă bugetele de noduri în funcție de ceea ce intenționați să vindeți, nu de ceea ce poate suporta fizic mașina.

Ce atinge de fapt clientul

Pentru un server de joc, consola este produsul. Comenzile, jucătorii care intră și linia din jurnal care explică o prăbușire trăiesc toate acolo. Pelican are o consolă reală, iar Provibr o transmite clientului prin aceeași conexiune de ieșire ca tot restul: fără un port separat, fără o a doua autentificare, fără o a doua parolă de resetat.

Fișierele, copiile de rezervă, bazele de date și programările rămân în Pelican. Este intenționat: acestea sunt funcții ale panoului, iar reimplementarea lor într-o a doua interfață le oferă clienților dumneavoastră două locuri în care ar putea sta adevărul.

Mutarea unui panou existent

Dacă rulați deja Pelican cu clienți plătitori, nu trebuie să reconstruiți nimic. Serverele create în afara punții sunt lăsate în pace; le importați ca să apară în tabloul dumneavoastră de bord și să conteze pentru capacitate.

Importul nu atinge serverul. Doar începe să îl numere. Până când nu îl importați, nu este nici gestionat, nici facturat, ceea ce înseamnă că puteți muta un panou pe loturi, în ritmul dumneavoastră, în loc să o faceți în timpul unei ferestre de mentenanță.

Ce nu este acoperit

Clarificați-vă limita înainte de a vinde pe baza ei:

• Administrarea panoului rămâne în Pelican. Adăugarea de noduri, editarea egg-urilor, gestionarea utilizatorilor panoului: nimic din toate acestea nu se mută.
• Fișierele, copiile de rezervă, bazele de date și programările rămân și ele în Pelican.
• Pelican este încă în versiune beta, iar API-ul său se schimbă de la o versiune la alta. Panoul nu oferă nicio modalitate de a întreba ce versiune rulează, așa că o actualizare care schimbă un răspuns apare ca o eroare, nu ca un avertisment prealabil. Citiți notele de versiune înainte de a actualiza un panou cu care vorbește automatizarea dumneavoastră. Aceasta nu este o limitare a Provibr. Este o proprietate a panoului, iar orice punte pe care o construiți o va avea.

Nu trebuie să alegeți un singur panou

Cei mai mulți furnizori de găzduire de jocuri ajung să ruleze mai mult de un panou: Pelican pentru stocul nou, Pterodactyl pentru ce exista deja, altceva pentru un client care a insistat. Iar cei mai mulți vând pe lângă asta și găzduire web sau VPS.

Provibr rulează panourile sale de control, hipervizoarele și panourile de joc unele lângă altele într-un singur tablou de bord. Un singur număr de capacitate, un singur set de chei API, un singur loc în care este consemnată viața unui server, indiferent de panoul pe care se întâmplă să ruleze.

Pagina următoare tratează cealaltă jumătate: ce se întâmplă cu un server Pelican când o factură rămâne neplătită.