Helló! Mi a "Hosting Technologies" vagyunk, és 5 éve indultunk - az első kifejezetten fejlesztők számára készített vds hosting. Arra törekszünk, hogy kényelmes legyen, mint a DigitalOcean, de orosz támogatással, fizetési módokkal és oroszországi szerverekkel. De a DigitalOcean nem csak a megbízhatóság és az ár, hanem egy szolgáltatás is.
Az ISPsystem szoftverei egy kötélnek bizonyultak, amely megkötötte a kezünket egy menő szolgáltatás felé vezető úton. Három évvel ezelőtt a Billmanager számlázást és a VMmanager szerver vezérlőpultját használtuk, és hamar rájöttünk, hogy saját vezérlőpanel nélkül szinte lehetetlen jó szolgáltatást nyújtani.
Hogyan ölte meg az ISP-rendszer a kényelmet
Bugs
Nem tudtuk magunk kijavítani a hibát – minden alkalommal írnunk kellett valaki más támogatásának, és várnunk kellett. Bármilyen probléma megoldásához szükség volt egy külső cég válaszára.
Az ISP-rendszer támogatása normálisan válaszolt, de a javítások csak néhány kiadás után érkeztek, aztán nem mindig és nem minden. Néha a kritikus hibákat több hétig javították. Meg kellett nyugtatnunk az ügyfeleket, elnézést kérnünk, és várnunk kellett, míg az ISPsystem kijavítja a hibát.
Leállási veszély
A frissítések előre nem látható leállásokat generálhatnak, amelyek új hibákat idézhetnek elő.
Minden frissítés egy sorsolás volt: el kellett takargatnom a számlázást, és áldozatokat kellett hoznom a frissítések isteneinek – néhányszor a frissítés 10-15 perces leállást okozott. Adminisztrátoraink ebben az időben a szemükön ültek – soha nem tudtuk, meddig tart a leállás, és nem tudtuk megjósolni, hogy az ISPsystem mikor dönt egy új frissítés kiadása mellett.
Az ötödik generációnál jobb lett a Billmanager, de ahhoz, hogy hozzáférjek a szükséges funkciókhoz, egy béta verziót kellett telepítenem, amit már hetente frissítettek. Ha valami elromlott, hozzáférést kellett adnom más fejlesztőknek, hogy javíthassanak valamit.
Kényelmetlen panel interfész
Mindent különböző panelekre osztottak és különböző helyekről irányítottak. Például az ügyfelek a Billmanageren keresztül fizettek, és újra kellett indítaniuk vagy újra kellett telepíteniük a VMS-t a VMManagerben. Munkatársainknak az ablakok között is váltaniuk kellett, hogy segítsenek egy ügyfélnek, ellenőrizzék a szerver terhelését, vagy megnézzék, milyen operációs rendszert használ.
Egy ilyen interfész időbe telik – a miénk és az ügyfeleink számára egyaránt. Ilyen helyzetben nincs szó kényelemről, mint a DigitalOceannél.
Rövid életciklusok gyakori API-frissítésekkel
Saját beépülő moduljainkat írtuk – például egy olyan bővítményt, amely további fizetési módokat tartalmaz, amelyek nem szerepelnek a VMManagerben.
Az elmúlt években a VMManager viszonylag rövid életciklusú volt, és az új verziókban az API-ban lévő változók vagy függvények nevei tetszőlegesen változhattak – ez tönkretette a bővítményeinket. A régebbi verziók támogatása gyorsan megszűnt, és frissíteni kellett.
Nem módosítható
Pontosabban lehetséges, de rendkívül nem hatékony. A licenc korlátozások nem teszik lehetővé a forráskód módosítását, csak bővítményeket írhat. Maximum bővítmények - néhány menüpont, egy lépésről lépésre haladó varázsló. Az ISPsystem-et a sokoldalúságra tervezték, de speciális megoldásokra volt szükségünk.
Így aztán megérett a döntés, hogy megírjam a saját panelemet. Célokat tűztünk ki:
- Gyorsan reagáljon a hibákra, és saját maga javíthatja ki azokat anélkül, hogy az ügyfél várakoznia kellene.
- Szabadon módosíthatja a felületet a munkafolyamatok és az ügyfelek igényei szerint.
- Növelje a használhatóságot letisztult és érthető kialakítással.
És elkezdtük a fejlesztést.
Új panelarchitektúra
Van egy önellátó fejlesztői csapatunk, így mi magunk írtuk a panelt.
A fő munkát három mérnök végezte - Szergej műszaki igazgató dolgozta ki az architektúrát és írta a szerverügynököt, Alexey a számlázást végezte, a front-endet pedig a front-enderünk, Artysh állította össze.
1. lépés: Kiszolgálóügynök
A szerverügynök egy Python webszerver, amely a könyvtárat kezeli , ami viszont szabályozza .
Az ügynök kezeli a kiszolgálón található összes szolgáltatást: vd-k létrehozását, leállítását, törlését, operációs rendszerek telepítését, paraméterek módosítását stb. a libvirt könyvtáron keresztül. A cikk megjelenése idején több mint negyven különböző funkcióról van szó, amelyeket a feladattól és a megrendelő igényeitől függően kiegészítünk.
Elméletileg a libvirt közvetlenül vezérelhető a számlázásból, de ehhez túl sok további kódra volt szükség, és úgy döntöttünk, hogy elkülönítjük ezeket a funkciókat az ügynök és a számlázás között – a számlázás egyszerűen kéréseket küld az ügynöknek a JSON API-n keresztül.
Az ügynök volt az első, amit csináltunk, mivel nem igényelt interfészt, és közvetlenül a szerverkonzolról lehetett tesztelni.
Amit a szerverügynök adott nekünk: megjelent egy réteg, amely mindenki számára leegyszerűsíti az életét - a számlázáshoz nem kell egy csomó parancsot elküldeni, hanem csak egy kérést. És az ügynök mindent megtesz, ami szükséges: például lefoglalja a lemezterületet és a RAM-ot.
2. lépés: Számlázás
Fejlesztőnk, Alex számára nem ez volt az első vezérlőpult – Alex már régóta dolgozik a hostingban, így általában megértette, mire van szüksége az ügyfélnek, és mire van szüksége a tárhelyszolgáltatónak.
A számlázást magunk között „vezérlőpultnak” nevezzük: nemcsak pénzt és szolgáltatásokat tartalmaz, hanem azok kezelését, ügyfélszolgálatát és még sok mást is.
Az ISPSystem szoftverről való átálláshoz meg kellett őrizni az ügyfelek korábbi funkcionalitását, át kellett vinni a felhasználók összes pénzügyi műveletét a régi számlázásról az újra, valamint a köztük lévő összes szolgáltatást és kapcsolatot. Tanulmányoztuk, hogy mi van a jelenlegi termékben, majd a versenytársak megoldásait, elsősorban a DO és a Vultr megoldásait. Megvizsgáltuk a hátrányokat és az előnyöket, visszajelzéseket gyűjtöttünk azoktól, akik az ISPsystem régi termékeivel dolgoztak.
Az új számlázás két stacket használt: a klasszikus PHP-t, a MySQL-t (és a jövőben a tervek szerint PostgreSQL-re váltani), a Yii2-t keretrendszerként a háttérben és a VueJS-t az előlapon. A veremek egymástól függetlenül működnek, különböző emberek fejlesztik őket, és a JSON API segítségével kommunikálnak egymással. Fejlesztéshez akkor és most használjuk и a JetBrainstől, és nagyon szeretem őket (hé srácok!)
A panel moduláris alapon készült: fizetési rendszer modulok, domain regisztrátor modul vagy például SSL tanúsítvány modul. Könnyen hozzáadhat új funkciót, vagy eltávolíthat egy régit. A terjeszkedés alapjait építészetileg rakják le, beleértve az ellenkező irányú, „a hardver felé” is.
Mit kaptunk: egy vezérlőpult, amely felett teljes irányításunk van. A hibákat most órák, nem hetek alatt javítják, és az új funkciókat az ügyfelek kérésére vezetik be, nem pedig az ISPSystem kérésére.
3. lépés Interfész
A felület a mi csapatunk ötlete.
Először is megvizsgáltuk, mi történne, ha az ISPsystem API-n keresztül készítenénk egy kiegészítőt anélkül, hogy alapvetően bármit is megváltoztatnánk a felületen. Így is lett, és úgy döntöttünk, hogy mindent elölről csinálunk.
Úgy gondoltuk, hogy a lényeg az, hogy logikus legyen a felület, letisztult és minimalista dizájnnal, és akkor kapunk egy gyönyörű panelt. A Megaplanban szóba került az elemek elhelyezkedése és fokozatosan megszületik az a felület, amit most a vezérlőpulton látnak a felhasználók.
Elsőként a számlázási oldal dizájnja jelent meg, ugyanis az ISPsystem-hez már készítettünk fizetési bővítményeket.
Frontend
Úgy döntöttek, hogy a panelt SPA alkalmazássá teszik – erőforrásigénytelen és gyors adatbetöltéssel. A front-enderünk, Artysh úgy döntött, hogy megírja a Vue-n – akkoriban a Vue éppen megjelent. Feltételeztük, hogy a keretrendszer dinamikusan fejlődik, mint a React, egy idő után a Vue közösség növekedni fog, és könyvtárak tengere jelenik meg. A Vue-ra fogadtunk, és nem bántuk meg – most már kevés időbe telik, hogy új funkciókat adjunk az előlaphoz, amelyek már be vannak programozva a hátlapra. Az előlapi panelről egy külön cikkben fogunk többet mondani.
Az előtér csatlakoztatása a háttérhez
A frontend push értesítéseken keresztül csatlakozott a háttérhez. Keményen kellett dolgoznom és megírnom a saját kezelőmet, de most szinte azonnal frissülnek az oldalon található információk.
Mi történt: A panel felülete egyszerűbb lett. Adaptívvá alakítottuk, a gyors betöltés pedig lehetővé teszi, hogy akár mobiltelefonról is használja a felszállás előtti utolsó percekben, anélkül, hogy külön alkalmazást telepítene a panellel való munkához.
4. lépés Tesztelési és migrációs séma
Amikor minden beindult és az első tesztek sikeresek lettek, felmerült a migráció kérdése. Először is telepítettük a számlázást, és megkezdtük a működésének tesztelését a szerver ügynökkel.
Ezután írtunk egy egyszerű szkriptet, amely átviszi az adatbázist a régi számlázásról az újba.
Szó szerint mindent le kellett tesztelnem és újraellenőriznem, mivel három régi adatbázisból egyesültek az adatok egy új adatbázisba: Billmanager, VMmanager és a menedzser IPmanager. Talán a tesztmigráció a legnehezebb dolog, amivel egy új panel fejlesztése során találkoztunk.
Újraellenőrzés után a régi számlázást lezártuk. A végső adatmigráció nagyon nyugtalanító pillanat volt, de hála Istennek néhány perc alatt, észrevehető problémák nélkül befejeződött. Voltak kisebb hibák, amelyeket a hét folyamán javítottunk. Az idő nagy része a történtek tesztelésével telt.
Ezután levelet küldtünk az ügyfeleknek az új panel címével és számlázásával, valamint átirányítást végeztünk.
Összefoglalva: ÉLETBEN VAN!
Boldog vég
Szoftverünk első óráitól kezdve éreztük az átállás minden örömét. A kód teljesen a miénk volt, kényelmes architektúrával, a felület pedig tiszta és logikus volt.
Első felülvizsgálat az új panel megjelenése után
Az átállási folyamatot decemberben, 2017 szilveszter előestéjén indítottuk el, amikor a legkevesebb volt a terhelés, hogy megkönnyítsük az ügyfelek átállását - az ünnepek előestéjén szinte senki sem dolgozik.
A legfontosabb dolog, amit a rendszerünkre való váltáskor kaptunk (az általános megbízhatóságon és kényelemen kívül), az a képesség, hogy a kulcsfontosságú ügyfeleink számára gyorsan funkcionalitást adjunk hozzá – hogy az arcuk legyen, ne a fenekük.
Mi a következő lépés?
Növekedünk, nő az adatmennyiség, az ügyfelek, az ügyféladatok mennyisége. Hozzá kellett adnom egy Memcached szervert és két sorkezelőt különböző feladatokkal a háttérrendszerhez. A frontendnek van gyorsítótárazása és saját sorai.
Természetesen még mindig voltak kalandok, ahogy a termék fejlődött és összetettebbé vált, például amikor hozzáadtuk a HighLoad-ot.
A következő cikkben elmondjuk, hogyan indult el a Hi-CPU tarifa: hardverről, szoftverről, milyen feladatokat oldottunk meg és mit csináltunk.
Forrás: will.com