Aș dori să împărtășesc câteva impresii despre necesitatea sau inutilitatea unui astfel de lucru cum ar fi un panou de control pentru un proiect web comercial cu un singur server cu un administrator foarte part-time. Povestea a început acum câțiva ani, când prietenii prietenilor mi-au cerut să ajut la achiziționarea unei afaceri - un site de știri - din punct de vedere tehnic. A fost necesar să ne aprofundăm puțin în ceea ce lucra la ce, să ne asigurăm că toate detaliile necesare au fost transferate în forma și volumul adecvat și să descoperim strategic ce ar putea fi îmbunătățit.
S-a încheiat afacerea, nu mai era nevoie de violonistul. Sfârşit. Nu chiar.
Site-ul a rulat pe un VM dual-core de 4 GB pe Linode, pe niște Debian5 cu mușchi cu un timp de funcționare de 400 de zile și o astfel de listă de pachete neactualizate. Parte web pe un CMS auto-scris, nginx, php5.3 FPM, Percona reglat mysql. În principiu, a funcționat.
În paralel cu conversațiile cu mine, noul proprietar căuta un programator care să aducă proiectul la așteptări. Găsite. Programatorul a evaluat traficul și volumele și a decis că știe să optimizeze și să gestioneze costurile. El a migrat întregul site la o găzduire partajată de 700 de ruble, gestionată de IS****erul său obișnuit. Câteva zile mai târziu, a fost un alt apel de la proprietar: „totul este lent și se pare că ne-am stricat”. Am încercat să corectez situația prin intermediul panoului, dar după ceva timp de încercări infructuoase de a schimba versiunea sau handlerul PHP de la fcgi la fpm, am renunțat și am intrat în shell. Acolo am găsit o depanare activată care strălucea pe tot Internetul cu parola de la muschi, 777 pe niște foldere care până atunci se spargeau cu malware și prostii asemănătoare. Proprietarul și-a dat seama și a decis că este greșit să economisească pe găzduire, un programator și un administrator care ar putea să țină cont de cum merg lucrurile.
Mergem la RuVDS. Puțin mai aproape decât British Linode și, dacă dintr-o dată doriți să stocați date personale și toate acestea, nu va trebui să vă mutați în altă parte. Deoarece proiectul era planificat să fie extins, am luat o VM pentru creștere: 4 nuclee, 8 gigaocteți de memorie, 80 GB de disc. Nu este că nu știu cum să configurez manual configurațiile nginx, pur și simplu nu am avut entuziasmul să lucrez la acest proiect atât de intim (vezi mai sus despre jumătate de normă). De aceea am instalat Plesk (aici voi omite detaliile de instalare, pentru că în general nu există: am lansat programul de instalare, am setat parola administratorului, am introdus cheia - asta e tot), la acel moment era 17.0. Setările de bază funcționează în mod tolerabil imediat, există fail2ban și cele mai recente versiuni disponibile de PHP și nginx.
Probabil că merită să te oprești și să explici de ce. Deoarece fac rar astfel de lucruri și nu am instrumente speciale sau set de pregătiri pentru fiecare caz, era clar că era nevoie de un fel de automatizare a lucrurilor de bază, astfel încât în primul rând, rapid, în al doilea rând, în siguranță și în al treilea rând , toate cele mai bune practici pe care cineva le-a implementat deja.
Deci, l-am instalat. Am economisit mult timp, repornirea site-ului pe un nou server a fost aproape instantanee. Tot ce a rămas a fost să editați configurația musculară, oferindu-i jumătate din memorie și mărind numărul de pool-uri de buffer, și să dați nginx jumătate din nuclee (Plesk nu atinge configurațiile globale) și timp de câteva zile intră în shell pentru a căuta la statisticile mysqltuner. Da, și am cumpărat ImunifyAV plătit din catalogul de extensii pentru a scăpa de malware-ul inundat. Au fost găsite aproximativ 11000 de fișiere infectate. Abominația este că bucăți de cod obscurcate au fost turnate în statică, iar curățarea manuală ar fi fost complet plictisitoare. Mai întâi am încercat ClamAV, dar, după cum s-a dovedit, nu este nevoie de astfel de lucruri, dar ImunifyAV ar putea. Mai mult, fișierele dezinfectate rămân în stare de funcționare; piesa cu malware este pur și simplu ștearsă.
Aritmetica este simplă: 50 USD pe lună pentru VMka, 10 USD pentru Plesk (de fapt, mai puțin, pentru că l-ați cumpărat pentru un an deodată cu o reducere de două luni) și 3 USD pentru antivirus. Sau o mulțime de bani pentru timpul meu, pe care i-aș fi cheltuit la început pe server, grebland aceste grajduri manual. Proprietarul a fost destul de mulțumit de acest aranjament.
Între timp, au găsit un nou programator. Am convenit cu el asupra repartizării responsabilității, am creat un subdomeniu pentru versiunea de testare și am început munca. El tăia o nouă versiune a site-ului pe Laravel, iar eu mă uitam la fail2ban%).
Interesant este că fluxul de curioși nu se oprește și există mereu vreo sută de adrese pe lista celor interzise. Efectul este interesant: în special, de obicei, dacă mă conectez la un shell, văd aproximativ 20000-30000 de încercări nereușite de conectare prin SSH la salut. Cu fail2ban activat, aproximativ 70. Eforturi investite: 0. Din păcate, nu a fost fără o picătură de unguent. În mod implicit, WAF (modsecurity) a fost pe jumătate activat: în modul de descoperire. Adică, a scris activitate suspectă în jurnal, dar de fapt nu a luat nicio măsură. Și fail2ban a citit fără discernământ toate jurnalele, conform închisorilor activate, și a ucis tot ce se mișca. Astfel, am interzis jumătate din redactori :D. A trebuit să dezactivez această închisoare și să pun pe lista albă adresele IP necesare pentru fiabilitate. Sunt depuse eforturi: apăsați mouse-ul de două ori și învățați editorii să vă spună adresa IP.
Ceea ce i-a plăcut imediat programatorului a fost capacitatea de a încărca baze de date direct în panou și acces rapid la phpMyAdmin
Ceea ce mi-au plăcut au fost jurnalele și copiile de rezervă. Jurnalele sunt scrise și rotite din cutie; Backup-urile sunt foarte ușor de configurat. În cele mai lente momente, se face o copie de rezervă completă, aproximativ 10 giga, iar apoi în fiecare zi una incrementală, de 200 de megaocteți fiecare, timp de o săptămână. Recuperarea este granulară, până la un anumit fișier sau bază de date. Dacă trebuie să restaurați dintr-unul incremental, atunci nu trebuie să vă deranjați mai întâi cu o restaurare completă și a întregului lanț, Plesk face totul singur. Puteți încărca copii de siguranță oriunde: pe FTP, dropbox, s3 bucket, google drive etc.
Ziua F: programatorul a finalizat în sfârșit noul motor, l-am încărcat în producție, am importat date vechi și ne-am așezat să alegem culoarea viitorului nostru Maserati. Încă stăm și alegem.
Au început primele probleme. Noul site era de așteptat mai greu decât cel vechi, dar adevărata rake a fost că, pentru a atrage trafic, au folosit, printre altele, Yandex.Zen, care a adus o mulțime de vizitatori. Site-ul s-a prăbușit cu 150 de conexiuni simultane (nu vorbesc de RPS, pentru că nu l-au măsurat). Am început să apăsăm butoanele și să rotim butoanele din zona de setări php_fpm:
Hei, are deja 500 de conexiuni. Pe măsură ce cărțile de credit au fost adăugate mijloacelor de promovare, valuri de trafic au devenit mai mari. Următoarea etapă este 1000 de conexiuni simultane. Aici a trebuit să reparăm codul și să privim în sufletul mușchiului. Stropirea nu a ajutat, dar nu ne-am așteptat cu adevărat. Am activat jurnalul de interogări lente, am adăugat indexuri la baza de date, am eliminat interogările inutile din cod și am curățat din nou configurația mysql conform sfatului mysqltuner.
Noua provocare - 2000 de conexiuni. Tocmai a reușit să fie lansată versiunea Plesk 17.8, în care, printre altele, a fost adăugată cache nginx. Actualizat (surprinzător de ușor). Sa incercam. Lucrări! Și apoi au pășit pe partea moale, feedul Yandex.Zen a încetat să funcționeze. Site-ul funcționează, feed-ul nu funcționează. Feed-ul nu funcționează, nu există trafic. Atmosfera se încălzește. Sub presiunea circumstanțelor și a lipsei de imaginație, am mers imediat la strace și nginx și am găsit ceea ce căutam. Se pare că, la un moment dat, stupidul nginx a stocat în cache eroarea 500-a rătăcită ca răspuns la Yandex get feed.xml. S-a rezolvat prin adăugarea de excepții la setările cache:
Este clar că proprietarul are nevoie de MAI MULT, valurile cresc încet. Ne descurcăm deocamdată, dar am început să experimentăm cu memcached în avans, din fericire, Laravel îl suportă aproape de la cutie. Cumva, nu am vrut să instalez manual memcached doar pentru a „juca”, așa că am instalat o imagine docker. Direct de pe panou.
Ei bine, mint, a trebuit să intru în shell și să instalez modulul prin pecl. Chiar pe . Nu există încă nimic de spus despre creșterea debitului; nu au existat afluxuri suficient de mari. Motorul site-ului este conectat la localhost:11211, statisticile sunt afișate, memoria este consumată. Dacă vă place, vom vedea ce să facem în continuare. Fie îl vom lăsa așa, fie îl vom pune pe cel „adevărat” chiar în Axă. Sau să încercăm redis în același mod
Apoi a fost necesar să atașez o listă de corespondență. Fără relee, doar autentificare smtp. Am creat o adresă de corespondență și folosesc detaliile acesteia pentru a trimite un buletin informativ prin PHP.
Nu cu mult timp în urmă a fost lansat Plesk Obsidian (18.0), ne-am actualizat fără teamă pe baza experienței anterioare. Totul a decurs foarte bine, nici măcar nu e nimic de discutat. Lucrul plăcut este că calitatea interfeței s-a îmbunătățit foarte mult, a devenit mai modernă și a devenit mai convenabilă pe alocuri. Lucru tare Monitorizare avansată pe Grafana.
Nu am tratat încă în detaliu, dar puteți, de exemplu, să configurați alerte pentru orice parametru din e-mailul dvs. Pentru proprietar, lol.
În timp ce vorbesc despre interfață, este receptivă și funcționează foarte bine pe telefon. În primele etape, în timp ce încercam să găsim setările optime pentru PHP și alte lucruri, acest lucru a ajutat foarte mult. Și mai ales când un programator, într-o criză de entuziasm de muncă, face ceva la 23:XNUMX, iar eu, într-o criză de entuziasm de muncă, beau vodcă în baie, iar URGENT trebuie să schimb ceva.
Apropo. Imaginea arată că PHP Composer a apărut. Nu ne-am jucat încă cu el, dar, să zicem, pentru Laravel, poate salva câteva autentificări shell și ceva timp pentru instalarea dependențelor. Același sistem există pentru Node.JS și Ruby.
Cu SSL totul este simplu. Dacă domeniul se rezolvă conform așteptărilor, Let’s Encrypt se face cu un singur clic și apoi se actualizează singur, atât pentru domeniul în sine, cât și pentru subdomenii, și chiar pentru serviciile de e-mail.
Plesk în sine ca software este în prezent destul de plăcut și stabil. Se actualizează singur și Axis în liniște, consumă puține resurse și funcționează fără probleme. Nici nu-mi amintesc că am călcat pe ceva undeva, ceea ce ar fi fost un defect evident al produsului. Au fost probleme, desigur, dar s-au datorat fie unei configurații imperfecte, fie undeva la intersecție, așa că nu e nimic de plâns. Impresiile de a lucra cu Plesk sunt în general plăcute. Ceea ce nu are, și trebuie să înțelegem acest lucru, este orice (orice) grupare. Nici LB, nici HA. Poti incerca, dar efortul implicat va fi atat de mare incat este mai bine sa faci ceva diferit de la inceput.
Cred că putem rezuma. Pentru cazul în care nu există administrator, sau nu este suficient de el, când prețul găzduirii și site-urile care se rotesc pe el depășește, ei bine, să zicem, 100 USD, când nu vorbim de distribuirea bestială de 1500 site-uri de pe un server, când decidentul se confruntă cu Dacă aveți de ales să angajați un administrator cu jumătate de normă sau să cumpărați software și să aveți un administrator pentru o jumătate de dolar, sau să nu aveți deloc unul - cu siguranță are sens. Din punctul de vedere al administratorului de la distanță - același lucru. 10 USD pe lună și economisește timp și oferă flexibilitate în muncă pentru o perioadă foarte lungă de timpоo cantitate mai mare. Dacă, de exemplu, mi se cere ferm să iau un proiect similar sub aripa mea, voi insista să-l transfer la Plesk.
Sursa: www.habr.com