Minu kogemus Pleskiga töötamisel

Soovin jagada oma muljeid selle kohta, kui vajalik või mitte vajalik on juhtpaneel ühe serveriga kaubandusliku veebiprojekti jaoks, kui administraator on osalise tööajaga. Lugu sai alguse paar aastat tagasi, kui tuttavad palusid mul toetada nende ärikaupa - uudiste veebisaiti - tehniliselt. Tuli natuke süveneda, mis on millel, jälgida, et kõik vajalikud andmed oleksid edastatud õiges vormis ja mahus, ning strateegiliselt mõelda, mida võiks parandada.

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

Veebisait töötas kahe tuumaga 4 GB virtuaalmasinas Linode'il, mingi iidse Debian 5 peal, millel oli 400 päeva tööaega ja selline loetelu uuendamata paketidest. Veebi pool töötas isiklikul CMS-il, nginx, php 5.3 FPM, mysql oli seadistatud Percona. Ühesõnaga, see töötas.

Samaan ajal, kui mina rääkisin, otsis uus omanik programmeerijat projekti ootuste kohandamiseks. Ta leidis sellise. Programmeerija hindas liiklust ja mahtusid ning otsustas, et oskab optimeerida ja juhtida kulusid. Ta migratsioonis kogu veebisait 700-rublasel jagatud hostimisel tema tuttava IS****eri haldusesse. Mõne päeva pärast tuli jälle kõne omanikult: „kõik on aeglane ja tundub, et meid on rikutud“. Püüdsin olukorda parandada juhtpaneeli kaudu, kuid pärast mõningaid viljatuid katseid PHP versiooni või käitisja vahetamiseks fcgi-lt fpm-ile, andsin alla ja läksin shelli. Seal leidsin lubatud silumisrežiimi, mis jagas kogu internetis MySQL parooli, 777 mõnede kaustade jaoks, mis sel hetkel purunesid üleslaetud pahavara tõttu ja sarnaseid jaburaid asju. Omanik mõistis ja otsustas, et hostimisel, programmeerijal ja administraatoril, kes pilk oleks, kuidas asjad kulgevad - raha säästmine ei ole õige.

Meie sihtkoht on RuVDS. See on veidi lähemal kui Briti Linode ning kui peaks tekkima soov isikuandmeid ja kõike muud hoida, ei pea enam kuhugi mujale kolima. Et projekt oli plaanis laiendada, võtsime virtuaalmasina "kasvu jaoks": 4 tuuma, 8 GB mälu, 80 GB ketast. See ei tähenda, et ma ei oska nginx konfiguratsioonide kallal ise töötada, lihtsalt ei olnud mul nii intiimseks projektiga tegelemiseks entusiasmi (vt ülalpool osalise tööajaga). Seetõttu – installisin Pleski (siin ma jätan installimise detailid välja, sest neid on suuresti vähe: käivitasin installeri, seadistasin administraatori parooli, sisestasin võtme – kõik), tookord oli see versioon 17.0. Põhiseaded töötavad kenasti välja kastist, seal on fail2ban ja viimased saadaval olevad PHP, nginx versioonid. 

Võib-olla tasub peatuda ja selgitada, miks just see. Kuna ma selliste asjadega harva tegelemine, ei olnud mul mingit erilist tööriistade komplekti ega malle igaks juhuks, oli selge, et on vaja mingit automatiseerimist põhiasjade jaoks, et esiteks kiiresti, teiseks turvaliselt ja kolmandaks, et kõik parimad praktikad oleks keegi juba ellu viinud.

Nii, installisin. Säästsin korralikult aega, saidi käivitamine uuel serveril õnnestus praktiliselt koheselt. Jäänud oli vaid muusikakliendi konfiguratsiooni häkkimise, andes talle poole mälu ja suurendades vahemälu pragusid, ning andes nginx-ile poole tuumadest (Plesk ei puutu globaalsetesse seadistustesse), ja paar päeva vaadata terminalis mysqltuner'i statistikat. Jah, ja ostsin tasulise ImunifyAV laienduste kataloogist, et vabaneda üles laaditud pahavara eest. Leidsin umbes 11 000 nakatunud faili. Inimlikult öeldes, obfikeeritud kooditükid voolasid staatikasse ja nende käsitsi koristamine oleks olnud tõeliselt masendav. Alguses proovisin ClamAV-d, kuid nagu selgus, ei suuda see selliseid asju käsitleda, kuid ImunifyAV suutis. Eemaldatud failid jäävad töötavaks, lihtsalt pahavara osa kustutatakse.

Aritmeetika on lihtne: 50$ kuus virtuaalmasina eest, 10$ Pleski eest (tegelikult vähem, kuna ostsime kohe aastaks kahe kuu soodustusega) ja 3$ viirusetõrje eest. Või suure hulk rahakohvreid oma aja eest, mille ma alguses serveris veedaksin, need tallid käsitsi sorteerides. Selline olukord sobis omanikule täiesti.

Samal ajal leiti uus programmeerija. Leppisime temaga kokku vastutuse jagamises, lõime katseversiooni jaoks alamdomeeni ja töö algas. Ta arendas uut veebisaiti Laravelis, samal ajal kui mina jälgisin fail2bani%)

Huvitav on see, et uudishimulike voog ei lakka ja keelatud aadresside nimekirjas on alati umbes sada aadressi. Efekt on huvitav: nimelt, kui ma tavaliselt shell'i sisenen, näen tervitustes umbes 20000–30000 ebaõnnestunud SSH-ühenduse katset. Fail2ban'i sisse lülitamisega on neid umbes 70. Pingutuse panus: 0. Kahjuks ei möödunud see täielikult ilma igasuguse tõrva-kapita. Vaikimisi oli WAF (modsecurity) „poolikult sisse lülitatud”: avastamisrežiimis. See tähendas, et see logis kahtlast tegevust, kuid ei teinud tegelikult midagi. Fail2ban luges aga erinevatelt logidelt, vastavalt lubatud jails'idele, ja blokeeris kõik, mis liikuma hakkas. Nii olime blokeerinud poole väljaande toimetusest :D. Olime sunnitud selle jaili välja lülitama ja vajalikud IP-aadressid usaldusväärsuse tagamiseks valge nimekirja lisama. Pingutus: kaks korda hiirega klikkida ja õpetada toimetajatele oma IP-aadressi ütlema.

Mis programmeerijale kohe meeldis, oli võimalus laadida andmebaase otse paneelis ja kiire juurdepääs phpMyAdminile.

Mis mulle meeldis, olid logid ja varukoopiad. Logid kirjutatakse ja rotatsioon toimib automaatselt; varukoopia seadistamine on väga lihtne. Kõige vaiksemal ajal tehakse täielik varukoopia, umbes 10 GB, ja seejärel iga päev inkrementaalne, umbes 200 MB nädalas. Taastamine on granuleeritud, kuni konkreetse faili või andmebaasini. Kui on vaja taastada inkrementaalsest varukoopiest, siis ei pea kõigepealt täies mahus ja kogu ahela taastamisse vaeva nägema, Plesk teeb kõik ise. Varukoopiate laadimine on võimalik igale poole: FTP-le, Dropboxi, S3 bucketisse, Google Drive'i jne.

Hommik: programmeerija lõpetas lõpuks uue mootori, laadisime selle tootmisse, importisime vanad andmed ja hakkasime valima oma tulevase Maserati värvi. Oleme endiselt valimas.

Algasid esimesed probleemid. Uus veebisait oli oodatust raskem, kuid tegelik probleem oli see, et liikluse meelitamiseks kasutasime muu hulgas Yandex.Zeni, mis tõi külastajaid suurtes kogustes. Veebisait langes kokku 150 samaaegse ühenduse korral (ma ei räägi RPS-ist, kuna me ei mõõtnud). Hakkasime nuppe vajutama ja reguleerima php_fpm seadeid:
 

Oop, already holds 500 connections. As we added the credit card to the advertising funds, the traffic waves started to grow. The next milestone is 1000 simultaneous connections. Here we had to refine the code and look deep into the muscle. Plesk didn't help with this, but we didn't really expect that. We enabled the slow queries log, added indexes to the database, removed unnecessary queries from the code, and tidied up the MySQL config again following mysqltuner's advice.

The new challenge is 2000 connections. Just in time for the release of Plesk 17.8, which, among other things, integrated nginx caching. We updated (surprisingly easy). Let's try. It's working! But then we hit a snag; the Yandex Zen feed stopped working. The site works, but the feed doesn't. No feed means no traffic. The situation is heating up. Under pressure and lacking creativity, I immediately started stracing nginx and found what was wrong. It turned out that at some point the silly nginx cached an incoming 500 error as a response to the Yandex get feed.xml. We fixed this by adding exceptions to the cache settings:

It's clear that the owner needs MORE, the waves are slowly increasing. We're managing for now, but we've started experimenting with memcached in advance, as Laravel supports it almost out of the box. Installing memcached manually just to 'play around' wasn't appealing, so we set up a Docker image directly from the panel.

Well, okay, I'm lying, I had to go into the shell and install the module via pecl. Right from juhendis. I can't say much about the increase in throughput yet; there haven't been any significant surges. The site engine connected to localhost:11211, stats are showing, memory is being consumed. If it's good, we'll see what to do next. Either we'll leave it as is, or we'll set up a 'real' one directly in the OS. Or we'll try redis the same way.

Then we needed to add email sending functionality. No relays, just SMTP authentication. Created an email address, and using its credentials through PHP, we set up the mailing.

Not long ago, Plesk Obsidian (18.0) was released, and we updated without fear based on past experience. Everything went very smoothly, even nothing to report. On the bright side — the interface quality has significantly improved, it's modernized and become more convenient in some places. The Advanced Monitoring feature in Grafana is really nice.

I haven't explored it in detail yet, but you can set up alerts for any parameter to your email, for the owner, lol.

Kuna ma räägin liidesest, on see tundlik ja töötab tõeliselt hästi telefonis. Varajastes etappides, kui proovisime leida optimaalseid PHP seadeid ja muud, aitas see meid palju. Ja eriti siis, kui programmija oma tööentusiastlikus hoogus midagi kell 23 teeb, samas kui mina oma tööentusiastlikus hoogus joon viina saunas ja on KIIRELT vaja midagi ümber lülitada.

Ah, muide. Pildilt on näha, et PHP Composer on nüüd saadaval. Me ei ole sellega veel mänginud, kuid näiteks Laravel'i jaoks võib see säästa mõned sisselogimised shell'i ja aega sõltuvuste installimiseks. Taoline süsteem on olemas ka Node.JS ja Ruby jaoks.

SSL-iga on kõik lihtne. Kui domeen resolvib õigesse kohta, saab Let’s Encrypt ühe klõpsuga ja see uuendab end edaspidi ise, nii domeeni kui ka subdomeene ning isegi e-posti teenuseid.

Plesk ise on tarkvarana praegu üsna meeldiv ja stabiilne. See uuendab end ja operatsioonisüsteemi vaikselt, tarbib vähe ressursse ja töötab sujuvalt. Ma ei mäleta, et oleks kuskil midagi vipatunud, mis oleks olnud toote ilmne defekt. Probleeme on muidugi olnud, kuid need on kas konfiguratsiooni ebakindluse või kuskil äärepealsete probleemide tõttu, seega pole millegi kallal eriti nurisemiseks. Üldiselt on mul Pleskiga töötamisest head muljed. Kuid tuleb mõista, et selles pole mingit (mitte mingit) klasterdamist. Ei LB, ei HA. Proovida võib, kuid selleks kuluv töö maht on nii suur, et on parem alustada midagi muud.

Mõtleks, et saame kokkuvõtte teha. Kui administraatorit pole, või on see minimaalne, kui hostimise ja sellel töötava veebisaidi(d) hind ületab, noh, ütleme 100 eurot, kui jutt ei ole mõttetust ühisserverist, kus on 1500 saiti, kui otsustaja ees on valik palgata administraator poole kohaga või osta tarkvara ja palgata administraator "poolesuhkrus", või mitte üldse - sel on kindlasti mõte. Kaugadministraatori vaatenurgast on sama asi. 10 dollarit kuus, kuid säästab aega ja annab paindlikkust töö tegemiseks suuremal määral. Kui näiteks palutakse mul võtta sarnane projekt alla oma tiiva alla, siis nõuan Pleskisse üleviimist.ilotkaSoovin jagada mõningaid muljeid selle kohta, kui vajalik või mitte on selline asi nagu juhtpaneel äriühe-serveri veebiprojekti jaoks, olles samas väga osalise ajaga administraator.

Allikas: habr.com