Vreau să împărtășesc câteva impresii despre utilitatea sau inutilitatea unei panouri de control pentru un proiect web comercial pe un singur server, având un administrator part-time. Povestea a început acum câțiva ani, când cunoștințele amici săi m-au rugat să îi acompaniez în achiziția unui afaceri — un site de știri — din punct de vedere tehnic. A trebuit să mă familiarizez puțin cu ce rulează pe site, să mă asigur că toate datele necesare au fost transmise în mod corespunzător și complet și să estimez strategic ce ar putea fi îmbunătățit.
Tranzacția s-a finalizat, violonistul a devenit inutil. Sfârșit. De fapt, nu.
Site-ul rula pe o mașină virtuală dual-core de 4GB pe Linode, pe un Debian5 vechi cu o perioadă de funcționare de 400 de zile și cu o asemenea listă de pachete neactualizate. Partea web era pe un CMS personalizat, nginx, php5.3 FPM, mysql optimizat cu Percona. În principiu, funcționa.
În paralel cu discuțiile cu mine, noul proprietar căuta un programator pentru a aduce proiectul la așteptările sale. A găsit unul. Programatorul a evaluat traficul și volumul și a decis că se pricepe la optimizare și managementul costurilor. A migrat întregul site pe un hosting shared de 700 de ruble, administrat de un ISP obișnuit. După câteva zile, am primit un telefon din nou de la proprietar: „totul se mișcă încet și pare că ne-au spart.” Am încercat să repar situația prin panou, dar după un timp de încercări nereușite de a schimba versiunea PHP sau handler-ul de la fcgi la fpm, am cedat și am intrat în shell. Acolo am găsit debbuging activat, care expunea parola mysql pe tot internetul, 777 la anumite foldere, care deja scârțâiau de malware-ul încărcat și alte măgării de genul acesta. Proprietarul a realizat și a decis că a economisi pe hosting, programator și un administrator care să urmărească din când în când cum merg lucrurile — este greșit.
Ne îndreptăm spre RuVDS. Un pic mai aproape decât Linode în Marea Britanie, și dacă cumva ai nevoie să stochezi date personale și toate cele, nu va mai trebui să te muți nicunde altundeva. Deoarece proiectul era planificat să se extindă, am luat un VM "pentru viitor": 4 nuclee, 8 GB memorie, 80 GB disc. Nu că nu aș ști să configurez nginx manual, dar pur și simplu nu am avut entuziasm să mă ocup de acest proiect atât de intim (vezi mai sus despre part time). Așadar, am instalat Plesk (aici voi trece peste detaliile instalării, deoarece nu sunt foarte multe: am lansat installerul, am setat o parolă pentru admin, am introdus cheia – gata), pe atunci era versiunea 17.0. Setările de bază funcționează decent din cutie, există fail2ban și ultimele versiuni disponibile de PHP, nginx.
Probabil că ar trebui să mă opresc și să explic de ce el. Având în vedere că mă ocup cu astfel de lucruri rar și că nu am un instrumentar special și pregătit pentru fiecare situație, era clar că aveam nevoie de o anumită automatizare a lucrurilor de bază, pentru a putea, pe de o parte, să fiu rapid, pe de altă parte, să fiu în siguranță, și în al treilea rând, să fie implementate cele mai bune practici de cineva.
Așadar, l-am instalat. Am economisit mult timp, repornirea site-ului pe noul server a fost practic instantanee. A rămas să ajusteze configurația MySQL, dându-i jumătate din memorie și crescând numărul de buffer pools, și să ofer nginx jumătate din nuclee (Plesk nu atinge configurațiile globale), iar în decurs de câteva zile să mă uit în shell pentru a verifica statisticile mysqltuner. Și, da, am cumpărat ImunifyAV plătit din catalogul extensiilor pentru a scăpa de malware-ul încărcat. S-au găsit cam 11000 de fișiere infectate. Grozăvia a fost că în statice se infiltra cod obfuscat, iar să curăț asta manual era complet deprimant. La început am încercat ClamAV, dar, după cum s-a dovedit, nu gestionează asemenea lucruri, iar ImunifyAV a reușit. În plus, fișierele vindecate rămân funcționale, doar că se elimină bucata cu malware.
Arithmetica este simplă: 50$ pe lună pentru VM, 10$ pentru Plesk (de fapt, mai puțin, deoarece am cumpărat imediat pentru un an cu o reducere de două luni) și 3$ pentru antivirus. Sau mulți bani cheltuiți pentru timpul meu, pe care l-aș fi petrecut pe server la început despărțind aceste mizerii manual. Proprietarul a fost mulțumit de această configurație.
Între timp, am găsit un nou programator. Ne-am înțeles cu el asupra împărțirii responsabilităților, am creat un subdomeniu pentru versiunea de test și am început lucrul. El dezvolta o nouă versiune a site-ului pe Laravel, iar eu mă uitam la fail2ban%).
Este interesant că fluxul de curioși nu se oprește, iar în lista celor interziși sunt întotdeauna aproximativ o sută de adrese. Efectul e interesant: de exemplu, de obicei, dacă intru în shell, la salut văd aproximativ 20000-30000 de încercări nereușite de conectare prin SSH. Cu fail2ban activat, numărul scade la circa 70. Eforturi depuse: 0. Fără o picătură de neagră, din păcate, nu s-a putut. În mod implicit, WAF (modsecurity) era „parțial activat”: în modul de detectare. Asta înseamnă că înregistra activități suspecte în log, dar de fapt nu lua nicio măsură. Iar fail2ban citea fără discriminare toate log-urile, conform jails-urilor activate, și interzicea tot ce se mișca. Astfel, am interzis jumătate din redacție :D. A trebuit să dezactivez acest jail și să adaug adresele IP necesare pe lista albă pentru siguranță. Eforturi depuse: am dat click de două ori și am învățat editorii să își spună adresa IP.
Ce a plăcut imediat programatorului — posibilitatea de a încărca bazele de date direct în panou și acces rapid la phpMyAdmin.
Ce mi-a plăcut mie — log-urile și backup-urile. Log-urile sunt scrise și rotite automat; backup-urile se configurează foarte simplu. În cele mai leneșe momente, se face un backup complet, de aproximativ 10 gigabiți, iar apoi, în fiecare zi, unul incremental, de aproximativ 200 de megabaiți, timp de o săptămână. Restaurarea este granulară, până la un anumit fișier sau bază de date. Dacă trebuie să restaurez dintr-un incremental, nu trebuie să mă complic mai întâi cu completul și restaurarea întregii secvențe, Plesk se ocupă de tot. Backup-urile pot fi încărcate oriunde: pe ftp, pe Dropbox, pe un bucket S3, pe Google Drive și altele.
Ziua Z: programatorul a terminat în sfârșit noul motor, l-am încărcat în producție, am importat datele vechi și ne-am așezat să alegem culoarea viitoarelor noastre Maserati. Încă suntem în proces de alegere.
Au apărut primele probleme. Noul site era, așa cum era de așteptat, mai greu decât vechiul, dar adevărata problemă a fost că pentru atragerea traficului utilizam printre altele Yandex.Zen, care aducea vizitatori în mase. Site-ul se bloca la 150 de conexiuni simultane (nu vorbesc despre RPS, pentru că nu am măsurat). Am început să apăsăm butoanele și să modificăm setările php_fpm:
Aha, it already holds 500 connections. As the credit card was applied to the advertising funds, the traffic waves started to increase. The next milestone is 1000 simultaneous connections. Here, we already had to refine the code and take a closer look at the muscle. Plesk didn't help much in this, but we weren't really expecting it. We enabled slow query logging, added indexes to the database, removed unnecessary queries from the code, and tidied up the MySQL configuration once again as advised by mysqltuner.
The new challenge is 2000 connections. Just in time, Plesk version 17.8 was released, which, among other things, included nginx caching. We updated (surprisingly easily). We're trying it out. It works! And then the feed from Yandex Zen stopped working. The site is functional, but the feed is down. No feed means no traffic. The atmosphere is heating up. Under the pressure of circumstances and lack of imagination, I immediately began to strace nginx and found out what was happening. It turns out that at some point, silly nginx cached an incoming 500 error as a response to the Yandex get feed.xml. We fixed it by adding exceptions to the cache settings:
Clearly, the owner needs MORE, and the waves are gradually increasing. We're managing for now, but we've proactively started experimenting with memcached, as Laravel supports it almost out of the box. We didn't want to install memcached manually just to 'play around', 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 at . We can't speak about any increase in bandwidth yet; there haven't been any significant surges. The site engine connected on localhost:11211, stats are displaying, and memory is being used. If we like it, we'll see what to do next. Either we'll leave it as is, or we'll install a 'real' one directly on the OS. Or we'll try redis in the same way.
Then we needed to set up email distribution. No relays, just smtp authentication. I created an email address, and through its credentials, we’re sending mail via PHP.
Not long ago, Plesk Obsidian (18.0) was released; we updated without fear based on past experience. Everything went very smoothly, even too smooth to say much about it. On the plus side—the interface quality has significantly improved, it has modernized and become more convenient in some places. The Advanced Monitoring feature on Grafana is pretty cool.
I haven't delved into it deeply yet, but for example, you can set alerts for any parameter to be sent to email. For the owner, lol.
Deoarece vorbesc despre interfață, aceasta este adaptivă și funcționează destul de bine pe telefon. În etapele incipiente, când încercam să găsim cele mai bune setări pentru PHP și altele, m-a ajutat enorm. Și mai ales când programatorul, într-un acces de entuziasm profesional, face ceva la ora 23, iar eu, în același acces de entuziasm profesional, beau vodcă în saună, și e URGENT să schimb ceva.
Oh, apropo. În imagine se vede că a apărut PHP Composer. Încă nu ne-am jucat cu el, dar, de exemplu, pentru Laravel, poate economisi câteva logări în shell și timp pentru instalarea dependențelor. Există un sistem similar și pentru Node.JS și Ruby.
Cu SSL este simplu. Dacă domeniul se rezolvă corect, Let’s Encrypt se configurează cu un singur clic și se actualizează singur, atât pentru domeniu, cât și pentru subdomenii, și chiar pentru serviciile de email.
Plesk, ca software, este în prezent destul de plăcut și stabil. Se actualizează singur și OS-ul liniștit, consumă puține resurse, funcționează fără probleme. Nici nu-mi amintesc că am întâmpinat vreo problemă evidențiată ca un defect al produsului. Au existat probleme, desigur, dar fie din cauza imperfecțiunii configurației, fie la intersecție, așa că nu am prea multe de reproșat. În general, impresiile din utilizarea Plesk sunt plăcute. Ce nu are, și trebuie să înțelegem acest lucru, este orice fel de clusterizare. Nici LB, nici HA. Poți încerca, dar eforturile depuse vor fi atât de mari încât mai bine să faci inițial altceva.
Cred că se poate concluziona. În cazul în care nu există administrator sau este puțin, când prețul de găzduire și al site-urilor care rulează depășește, să zicem, 100 de euro, când nu este vorba de un share de tip animalic cu 1500 de site-uri pe server, când persoana care ia decizia are de ales între a angaja un administrator part-time sau a cumpăra software și a angaja un administrator pe „jumătate de normă”, sau chiar a nu avea deloc - există cu siguranță un sens. Din perspectiva unui administrator la distanță - același lucru. 10$ pe lună, iar în schimb economisește timp și oferă flexibilitate în muncă pentru o sumă mult mai mare. Dacă, de exemplu, cineva mă va ruga insistent să preiau un proiect similar, voi insista să trecem pe Plesk.mareVreau să împărtășesc câteva impresii despre necesitatea sau inutilitatea unui panou de control pentru un proiect comercial pe un singur server, având un administrator foarte part-time.
Sursa: habr.com
