Minu kogemus Pleskiga

Soovin jagada mõningaid muljeid sellise asja, nagu kommertshostinguprojekti juhtpaneel, vajalikkusest või mittevajalikusest, kui administraator on peaaegu ajutine. Lugu algas paar aastat tagasi, kui tuttavad tuttavad palusid mind tehniliselt toetada äriostu — uudisteveebilehe — osas. Tuli veidi süveneda, millega ollakse tegemist, jälgida, et kõik vajalikud andmed oleksid korrektselt edastatud ja strateegiliselt hinnata, mida oleks võimalik parandada.

Tehing õnnestus, viiuldajat enam ei olnud. Lõpp. Tegelikult mitte.

Veebileht töötas kahetuumalises 4GB virtuaalmasinas Linode'il, vananenud Debian5 versiooniga, mille tööaeg oli 400 päeva ja sellise nimekirjaga mitteuuendatud pakette. Veebiossa ehitatud kohandatud sisu haldamise süsteem, nginx, php5.3 FPM, mysql oli häälestatud Percona. Üldiselt, see töötas.

Samas kui vestlesime, otsis uus omanik programmeerijat, et kohandada projekti ootustele vastavaks. Ta leidis ühe. Programmeerija hindas liiklust ja mahtusid ning arvas, et suudab teha optimeerimist ja kuluhalduse. Ta migreeris kogu saidi 700-rubla jagatud hostingu peale, juhituna talle tuttavast IS****erist. Mõne päeva pärast helistas omanik jälle: "kõik on aeglane ja tundub, et meid on ära rikutud". Ma proovisin olukorda parandada paneeli kaudu, kuid pärast mõningaid viljatuid katseid PHP versiooni vahetamiseks või käitleja vahetamiseks fcgi-lt fpm-ile, andsin järele ja läksin shelli. Sealt leidsin sisse lülitatud silumise, mis näitas kogu internetile müügiautomaatse parooli, 777 mõnedele kaustadele, mis sel ajal oligi üle koormatud pahavara ja muu sarnase jaburusega. Omanik sai aru ja otsustas, et majutusele, programmeerijale ja administraatorile, kes vaataks asju ühe silmaga, ei tasu kokku hoida.

Liigume RuVDS-ile. Veidi lähemal kui Briti Linode, ja kui peaks tekkima soov isiklikke andmeid salvestada ja kõike muud, ei pea enam kuhugi kolima. Kuna projekti oli plaanis laiendada, võtsime VM-i 'kasvuks': 4 tuumad, 8 GB mälu, 80 GB ketast. See ei tähenda, et ma ei oskaks nginx-i konfiguratsioonifailidega tegeleda, lihtsalt mul polnud sellega nii intiimselt tegelemiseks piisavalt entusiasmi (vt üleval part-time kohta). Seega — paigaldasin Pleski (siin ma jätan paigalduse üksikasjad välja, kuna neid põhimõtteliselt pole: käivitasin installijat, seadistasin administraatori parooli, sisestasin võtme — kõik), sel ajal oli see versioon 17.0. Põhiseaded töötavad talutavalt välja kastist, saadaval on fail2ban ja viimased toetatavad PHP ja nginx versioonid. 

Võib-olla peaksin peatuma ja selgitama, miks just see. Kuna tegeletakse selliste asjadega harva ja mul ei ole mingit erilise tööriistade komplekti igaks juhuks, oli selge, et vajalik on mingisugune põhiasjade automatiseerimine, et esiteks kiiresti, teiseks turvaliselt ja kolmandaks, et kõik parimad tavad oleks juba keegi rakendanud.

Nii, panin paika. Säästsin korralikult aega, veebisaidi ümberkäimine uuel serveril oli peaaegu kohene. Tuli vaid konfigureerida MySQL, andes talle poole mälu ja suurendades buffer poolide arvu, ning andma Nginxile poole tuumadest (Plesk ei puutu globaalsetesse seadistustesse), ning paar päeva hiljem kukkuda shelli, et vaadata mysqltunerit. Jah, ja ostsin tasulise ImunifyAV laiendite kataloogist, et vabaneda puperdatud pahavarast. Leidsin umbes 11 000 nakatunud faili. Õudus seisnes selles, et staatilisse ossa voogas obfuskeeritud kooditükke, ning oleks olnud täiesti masendav seda käsitsi puhastada. Esiteks proovisin ClamAVd, aga nagu selgus, ei võta ta selliseid asju, samas kui ImunifyAV suutis. Küll aga jäävad parendatud failid tööolekusse, lihtsalt kustutatakse pahavara osa.

Aritmeetika on lihtne: 50$ kuus virtuaalmaja eest, 10$ Pleski eest (tegelikult vähem, sest ostsime aasta alguses kahe kuu allahindlusega) ja 3$ antiviiruse eest. Või palju kohvreid raha minu aja eest, mille ma esialgu serveris nende sõnnikute käsitsi koristamisega veedan. Omanikku selline arvestus täiesti rahuldas.

Samas leitiime uue programmeerija. Leppisime kokku vastutuste jaotamise, tegime testversiooni jaoks alamdomeeni ning töö käib. Ta arendab uut versiooni veebisaidist Laravelis, samas kui mina jälgin fail2bani%).

Huvitav, et uudishimulike voog ei peatu ja keelatud aadresside nimekirjas on alati umbes sada aadressi. Efekt on huvitav: näiteks, kui ma sisenen shell'i, näen tervituses umbes 20000-30000 ebaõnnestunud SSH sisselogimise katset. Kaasa lülitatud fail2ban'is on see umbes 70. Pingutusi: 0. Kahjuks ei möödunud see ka ilma karmacita. Vaikimisi oli WAF (modsecurity) 'osaliselt sisse lülitatud': avasterežiimis. See tähendab, et see registreeris kahtlase tegevuse logisse, kuid ei teinud tegelikult mingeid toiminguid. Fail2ban aga luges kõiki logisid, vastavalt sisse lülitatud vanglatele, ja keelas kõik, mis liikuda püüdis. Nii oleme häbanud poole toimetuse :D. Pidin selle vangla välja lülitama ja vajalikud IP-aadressid usaldusväärsuse jaoks valgesse nimekirja lisama. Pingutusi kokku: kaks korda hiirega klõpsata ja õpetada toimetajatele oma IP-aadressi ütlema.

Mis mulle kohe meeldis, oli võimalus laadida andmebaase otse paneelist ja kiire ligipääs phpMyAdminile.

Mulle meeldisid logid ja varukoopiad. Logid genereeritakse ja roteeritakse automaatselt; varukoopia seadistamine on väga lihtne. Koguaeg rasketel aegadel luuakse täielik varukoopia, mis on umbes 10 gigabitti, ja seejärel iga päev inkrementaalne, suunaga umbes 200 megabitti nädalas. Taastamine on granulaarselt, kuni konkreetse faili või andmebaasini. Kui soovite inkrementaalset taastada, siis ei pea te esmalt täisvarukoopiate ja kogu ahela taastamisega vaeva nägema, Plesk teeb kõik ise. Varukoopiad saab laadida kuhugi: ftp-le, Dropboxi, S3 konteinerisse, Google Drive'i ja muudele.

D-päev: programmeerija lõpuks lõpetas uue mootori, oleme selle tootmisse laadinud, importinud vana teabe ja istunud valima oma tulevasi Maseratisid. Istume siiani ja valime.

Esmaste esimesed probleemid. Uus veebileht oli oodatust raskem, kuid tegelik mure oli see, et liikluse toomiseks kasutati muu hulgas Yandex.Zeni, mis tõi külastajaid suuremate hoogudega. Veebileht lagunes juba 150 samal ajal ühenduse korral (ma ei räägi RPS-ist, sest ei mõõtnud). Alustasime nuppude vajutamist ja seadistuste php_fpm piirkonnas keeramist:
 

Oot, nüüd hoiab juba 500 ühendust. Krediidi rakendamisel reklaamifondide jaoks hakkasid liikluslaineid suurenema. Järgmine verstapost on 1000 samal ajal ühendust. Siin tuli juba koodi täiendama hakata ja vaadata musklite hinge. Plesk ei aidanud selles osas, kuid me ei oodanud ka erilisi tulemusi. Lülitasime sisse aeglaste päringute logi, panime andmebaasile uusi indekseid, eemaldasime koodist liigsed päringud ja veel kord korrigeerisime Mysql konfiguratsiooni mysqltuner'i soovituste järgi.

Uus väljakutse — 2000 ühendust. Just jõudis välja versioon Plesk 17.8, kus muuhulgas ühendati nginx caching. Uuendasime (üllatavalt lihtsalt). Proovime. Töötab! Ja kohe lõppes see sujuvalt, Yandex Zen'i voog lakkas töötamast. Veebileht töötab, aga voog ei tööta. Kui voog ei tööta, puudub liiklus. Atmosfäär muutub pingeliseks. Olukordade surve all ja inspiratsiooni puudusel otsustasin kohe nginx'it strace'ida ning avastasin, mida ta otsis. Selgub, et mingil hetkel oli rumal nginx cache'inud eksitavaid 500 vigu Yandexi get feed.xml-i vastusena. Parandasime, lisades erandid cache'i seadistustesse:

Muidugi on selge, et omanik vajab ROHKEM, lained tõusevad tasapisi. Praegu saame hakkama, aga hakkasime eelnevalt eksperimenteerima memcached'iga, kuna Laravel toetab seda peaaegu välja kutsega. Memcached'i käsitsi seadmine, et "mängida", ei olnud just kõige soovitavam, seega paniime docker'i pildi. Otse juhtpaneelist.

No okei, ma valetasin, pidin siiski minema shell'i ja panema mooduli pecl'i kaudu. Otse juhendis. Suurenevast ribalaiusest pole veel midagi öelda, suuri laineid ei ole olnud. Veebimootor on ühendatud localhost:11211, statistika kuvatakse, mälu kulub. Kui meeldib, vaatame, mida edasi teha. Kas jätame nii või installime "päris" versiooni otse Ossi. Või proovime sarnasel viisil redisit.

Hiljem tuli seadistada e-posti massilise saatmise funktsioon. Ilma releedeta, ainult smtp autentimisega. Olen loonud e-posti adresi, mille kaudu PHP abil teeme saatmise.

Hiljuti ilmus Plesk Obsidian (18.0), värskendasime oma varasema kogemuse põhjal kartmatult. Kõik läks väga sujuvalt, isegi rääkida pole millestki. Positiivne on see, et kasutajaliides on kvaliteedi osas palju paranenud, moderniseeritud ning teatud kohtades mugavam. Lahe asi on Advanced Monitoring Grafanas.

Praegu pole ma selle peale veel põhjalikult süvenenud, kuid näiteks saab seadistada häireid mis tahes parameetri puhul e-postile. Omanikule, haha.

Kuna ma räägin liidestest, siis see on kohandatav ja töötab tõeliselt hästi telefonis. Varases etapis, kui püüdsime leida optimaalseid PHP ja muude seadistusi, oli see meile suureks abiks. Eriti siis, kui programmeerija entusiastlikus tööhoo joob midagi kell 23, samal ajal kui mina positiivses tööhoos joon viina saunas, ja on KOHUTAVALT vaja midagi vahetada.

Oh, muide. Pildil on nähtav PHP Composer. Me ei ole sellega veel katsetanud, aga ütleme nii, et see võib näiteks Laravel'i puhul säästa paar sisselogimist terminali ja aega sõltuvuste paigaldamiseks. Sama süsteem on olemas ka Node.JS ja Ruby jaoks.

SSL-iga on kõik lihtne. Kui domeen suunab õigesse kohta, on Let’s Encrypt ühe kliki kaugusel ja uuendab ennast ise, nii domeeni kui ka subdomeenide ja isegi postiteenuste jaoks.

Plesk on tarkvara, mis hetkel töötab üsna hästi ja stabiilselt. See uuendab end ning operatsioonisüsteemi vaikides, tarbib vähe ressursse ja töötab täpselt. Ma isegi ei mäleta, et oleksin kuskil mingile probleemile peale astunud, mis oleks selgelt toote defekt. Probleeme on muidugi olnud, kuid need kas tulenesid konfiguratsiooni puudulikusest või mõnest ühenduspunktist, seega pole eriti millegi kallal norida. Töö Pleskiga on üldiselt positiivne. Mida seal ei ole, ja sellest tuleb aru saada, on igasugune (mis tahes) klasterdamine. Ei LB, ega HA. Proovida võib, aga sinna kuluvate jõupingutuste hulk on sedavõrd suur, et parem on algselt midagi muud teha.

Arvan, et võiks kokku võtta. Kui administraatorit ei ole või teda on vähe, kui hostimise ja sellel töötava saidi(te) hind ületab, ütleme, 100 eurot, kui ei räägita inetust üksteisega jagatud serverist 1500 saidiga, kui otsustaja ees on valida, kas palkata administraator osalise koormusega, või osta tarkvara ja palgata administraator 'poolte' jaoks, või mitte palgata üldse — siis on selles kindlasti mõte. Kaug-administraatori seisukohalt on sama asi. 10 dollarit kuus, samas säästab see aega ja annab paindlikkuse töös, väga hea.osuurema summa. Kui, näiteks, mind väga palutakse võtta sarnane projekt oma tiiva alla, siis ma insistin Pleskile üleviimise peale.

Allikas: habr.com