Dua të ndaja disa përshtypje mbi nevojshmërinë ose jo të një elementi si paneli i kontrollit për një projekt tregtar me një server, kur ka një administrator që punon në pjesë të vogla. Historia filloi disa vite më parë, kur miqtë e mi më kërkuan ndihmë për të mbështetur blerjen e një biznesi — një website lajmesh — nga një pikëpamje teknike. Duhej të kuptoja pak se çfarë funksiononte, të sigurohesha që të gjitha të dhënat e nevojshme ishin transferuar në formën dhe vëllimin e duhur, dhe strategjikisht të mendoja se çfarë mund të përmirësohej.
Transaksioni u realizua, violisti nuk ishte më i nevojshëm. Fundi. Në të vërtetë jo.
Site-i funksiononte në një VM me dy bërthama dhe 4 GB RAM në Linode, në një Debian 5 të vjetruar me një uptime prej 400 ditësh dhe me një listë të tillë paketash që nuk ishin përditësuar. Pjesa web ishte e ndërtuar me një CMS të bërë vetë, nginx, php5.3 FPM, mysql i optimizuar nga Percona. Në parim, funksiononte.
Në simultan me bisedat me mua, pronari i ri ishte duke kërkuar një programues për të përmbushur pritshmëritë e projektit. E gjeti. Programuesi vlerësoi trafikun dhe volumet dhe vendosi se di si të optimizojë dhe menaxhojë cost-in. Ai migroi tërë faqen në një hosting shared për 700 lekë nën menaxhimin e IS****er që i ishte i njohur. Pas disa ditësh, përsëri siel telefonata nga pronari: "gjithçka është e ngadaltë dhe duket sikur na kanë thyer." Unë u përpoqa të rregulloja situatën përmes panelit, por pas disa përpjekjesh të pasuksesshme për të ndërruar versionin PHP ose handler-in nga fcgi në fpm, u dorëzova dhe hyra në shell. Atje gjetëm debug të aktivizuar, i cili ndante në të gjithë internetin passwordin për MySQL, 777 për disa dosje, të cilat në atë moment ishin të mbushura me malware dhe gjëra të ngjashme. Pronari e kuptoi dhe vendosi se ishte gabim të kursente në hosting, programues, dhe administrator, i cili do ta vrojtonte punën me një sy.
Po kalon në RuVDS. Pak më afër se Linode britanik, dhe nëse ndonjëherë do të dëshironit të ruani të dhënat personale dhe gjithë këtë, nuk do të duhej të lëviznit askund tjetër. Duke qenë se projekti pritej të zgjerohej, morëm një VM "për rritje": 4 bërthama, 8 GB RAM, 80 GB disk. Nuk është se nuk di të punoj me konfigurimet nginx, thjesht nuk kisha entuziazëm për të u marrë kaq afër me këtë projekt (shiko lart për part time). Prandaj, vendosa Plesk (këtu do të kaloj përfundimet e instalimit, sepse në të vërtetë nuk ka asgjë për të thënë: e aktivizova instaluesin, vendosa password për administratorin, futa çelësin – all done), atëherë ishte versioni 17.0. Cilësimet bazë funksionojnë mirë nga fabrika, ka edhe fail2ban dhe versionet më të fundit të PHP dhe nginx.
Ndoshta duhet të ndaloj dhe të shpjegoj pse këtë. Duke qenë se merrem me këto gjëra rrallë, dhe nuk kam ndonjë instrumentar të veçantë dhe asnjë koleksion për çdo rast, ishte e qartë se duheshin disa automatizime bazike për të qenë, përveç të tjerash, të shpejta, të sigurta dhe, mbi të gjitha, që dikush të ketë zbatuar të gjitha praktikat më të mira.
Pra, e vendosur. Kam kursyer mjaftueshëm kohë, rikthimi i faqes në serverin e ri ishte praktikisht momental. Duhej të rregulloja konfigurimin e MySQL-it, ndihmuar me gjysmën e memories dhe duke rritur numrin e buffer pools, si dhe duhet t'i jepja nginx pjesën tjetër të bërthamave (Plesk nuk prek konfigurimet globale), dhe për disa ditë të hyj në shell për të parë statistikat e mysqltuner. Po, dhe bleva ImunifyAV të paguar nga katalogu i zgjerimeve për t'u shpëtuar nga malware. U gjetën rreth 11000 skedarë të infektuar. E keqja ishte se në statikë depërtonin pjesë të obfuskura kode, dhe do të ishte shumë e mërzitshme ta pastronte atë me duar. Fillimisht provova ClamAV, por siç duket, ai nuk i merrte këto gjëra, ndërsa ImunifyAV ia doli. Për më tepër, skedarët e shëruar mbeten në gjendje funksionale, thjesht hiqet pjesa me malware.
Arithmetika është e thjeshtë: 50 $ në muaj për VM, 10 $ për Plesk (në të vërtetë më pak, sepse e blejmë menjëherë për një vit me zbritje prej dy muajsh) dhe 3 $ për antivirus. Ose shumë bagazhe parash për kohën time, që do ta kaloja në server duke hequr dorë nga këto ndotësira manualisht. Pronari i këtij shpjegimi ishte plotësisht i kënaqur.
Ndërkohë, gjetëm një programues të ri. Rregulluam me të shpërndarjen e përgjegjësive, krijuam një subdomen për versionin provues dhe puna filloi. Ai po zhvillonte një version të ri të sitit në Laravel, ndërsa unë po shikoj fail2ban%).
Të interesting është se fluksi i kuriozëve nuk ndalet dhe në listën e bllokuar gjithmonë ka rreth njëqind adresa. Efekti është interesant: në veçanti, zakonisht, nëse hyj në shell, në përshëndetje shoh rreth 20,000-30,000 përpjekje të dështuara për t'u lidhur përmes SSH. Me fail2ban të aktivizuar, rreth 70. Investimi i përpjekjeve: 0. Pa pak dërmues, fatkeqësisht, nuk ndodhi. Në parazgjedhje, WAF (modsecurity) ishte "gjysmë i aktivizuar": në modin e zbulimit. Kjo do të thotë se ai regjistronte aktivitete të dyshimta në log, por në fakt nuk merrte asnjë masë. Dhe fail2ban lexonte pa diskriminim të gjitha logët, sipas burgjeve të përfshira, dhe bllokonte gjithçka që lëvizte. Kështu që ne bllokuam gjysmën e redaksisë :D. Duhej të çaktivizoja këtë burg, dhe adresat IP të nevojshme për siguri t'i vendosja në listën e bardhë. Përshtypje të investuara: dy herë me maus dhe të mësoj redaktorët të thonë adresën e tyre IP.
Ajoja që i pëlqeu menjëherë programuesit ishte mundësia për të ng загрузить бази данных direkt nga paneli dhe akses i shpejtë në phpMyAdmin.
Ajo që më pëlqeu mua ishin logët dhe backups. Logët shkruhen dhe rotullohen vetë direkt nga kutia; backupet konfigurohen shumë lehtë. Në kohët më të dobta bëhet një backup i plotë, rreth 10 GB, dhe më pas çdo ditë bëhet një backup inkremental, rreth 200 megabajt, gjatë javës. Riparimi është granular, deri në një skedar ose bazë të dhënash të veçantë. Nëse nevojitet të riparojmë nga inkrementali, nuk është e nevojshme të merremi fillimisht me të plotin dhe riparimin e gjithë zinxhirit, Plesk e bën gjithçka vetë. Backup-et mund të ngarkohen kudo: në FTP, në Dropbox, S3 bucket, Google Drive, e kështu me radhë.
Dita D: programuesi përfundimisht përfundoi motorin e ri, ne e ngarkuam atë në prodhim, importuam të dhënat e vjetra dhe u ulëm të zgjidhim ngjyrën e Maserati-t tonë të ardhshëm. Akoma po zgjedhim.
Filluan problemet e para. Uebsajti i ri ishte parashikuar të ishte më i rëndë se ai i vjetër, por pengesa e vërtetë ishte se për të tërhequr trafik po përdornin përveç të tjerave Yandex.Zen, e cila sjell vizitorë në grupe. Uebsajti filloi të bjerë me 150 lidhje të njëkohshme (nuk po flas për RPS, sepse nuk i matëm). Filluan të shtypin butonat dhe të rregullojnë cilësimet php_fpm:
Ooo, tani mban 500 lidhje. Me kalimin e kartës për financimi i promovimeve, valët e trafikut filluan të rriten. Milestone-i i ardhshëm është 1000 lidhje të njëkohshme. Këtu duhej të rafinohej kodi dhe të hetohej thellë në musku. Plesk nuk ndihmoi shumë, por nuk e prisnim ndonjëherë këtë. Aktivizuam log-un e kërkesave të ngadalta, vendosëm indekse në bazë, eliminuam kërkesat e tepërta nga kodi dhe rregulluam përsëri konfigurimin e mysql sipas këshillave të mysqltuner.
Sfida e re e re 2000 lidhjesh. Sapo doli versioni Plesk 17.8, në të cilin, përveç të tjerave, ishte shtuar memorizimi në nginx. U përditësuam (për habi lehtësisht). Po e provoni. Funksionon! Dhe menjëherë u shfaq një problem, ndali së funksionuari feed-i i Yandex Zen. Webfaqja funksionon, feed-i nuk funksionon. Nuk funksionon feed-i, nuk ka trafik. Atmosfera bëhet e tensionuar. Nën presionin e rrethanave dhe nga mungesa e fantazisë, vendosa menjëherë të përdor strace për nginx dhe e gjetëm se çfarë kishte ndodhur. Duket se, në një moment, nginx-i ja kishte memorizuar një gabim 500 si përgjigje për kërkesën e Yandex për feed.xml. E rregulluam, duke shtuar përjashtime në cilësimet e memorizimit:
E kuptueshme, që pronari ka nevojë për MË SHUMË, dhe valët po rriten ngadalë. Deri më tani po ia dalim, por paraprakisht filluam të eksperimentojmë me memcached-in, mirë që Laravel e mbështet pothuajse nga kutia. Nuk kënaqe mjaft të instalonim memcached manualisht për "të luajtur", kështu që vendosëm një imazh Docker. Drejtë nga pult.
Eh, e vërteta është, duhej të hyja në shell dhe ta instalonim modulin përmes pecl. Pikërisht kështu . Nuk ka asnjë informacion në lidhje me rritjen e kapacitetit, nuk kishte përflakje të mëdha. Motorri i sitit u lidhi në localhost:11211, statistikat shfaqen, kujtesa përdoret. Nëse i pëlqen, do të shohim se çfarë të bëjmë më pas. Ose do ta lëmë kështu, ose do të vendosim një "të vërtetë" drejtpërdrejt në Osi. Ose me të njëjtin mënyrë do të provojmë redis.
Pastaj ishte e nevojshme të krijohej një sistem për dërgimin e email-eve. Asnjë relayer, vetëm autentifikimi smtp. Krijova një adresë emaili dhe përmes të dhënave të saj dërgoj email-e me PHP.
Pak kohë më parë doli Plesk Obsidian (18.0), u përmirësuam mbi përvojën e kaluar pa frikë. Të gjitha kaluan shumë mirë, madje nuk ka asgjë për të treguar. E mira është se interfejsi është shumë përmirësuar, është modernizuar dhe bërë më i rehatshëm në disa vende. Një gjë simpatike është Monitoring Avancuar në Grafana.
Nuk kam gjetur ende shumë informacion për të, por, për shembull, mund të vendosësh alarme për çdo parametër në email. Pronarit, lol.
Dhe, duke folur për ndërfaqen, ajo është adaptiv dhe funksionon mjaft mirë në telefon. Në fazat e hershme, ndërsa përpiqeshim të përshtatnim cilësimet optimali për PHP dhe të tjera, kjo na ndihmoi shumë. Sidomos kur programi në një fushë entuziazmi pune bën diçka në orën 23:00, ndërsa unë në një fushë entuziazmi pune konsumoj vodka në banjë dhe KAM NEVOJË urgjente të ndërron ndonjë gjë.
Oh, për t'iu rikthyer. Në imazh shihet se ka dalë PHP Composer. Nuk kemi luajtur me të akoma, por, le të themi, për të njëjtin Laravel mund të kursejë një çift logimesh në shell dhe ndonjë kohë për instalimin e varësive. Një sistem i ngjashëm është për Node.JS dhe Ruby.
Me SSL gjërat janë të thjeshta. Nëse domëni zgjidhesh diku ku duhet, Let’s Encrypt bëhet me një klik dhe vazhdon të përditësohet vetë, si për domanin vetë, ashtu edhe për subdomainet, madje edhe për shërbimet e postës.
Plesk si është një software i këndshëm dhe i qëndrueshëm në aktualitet. Ai përditëson veten dhe sistemin operativ në heshtje, konsumon pak burime dhe punon siç duhet. Nuk e mbaj mend që kam hasur ndonjëherë në një defekt të dukshëm të produktit. Sigurisht, ka pasur probleme, por ato ishin ose për shkak të papërsosmërive në konfigurim, ose diku në pikën e kalimit, kështu që nuk ka shumë për t'u ankuar. Përvoja me Plesk është gjithsesi pozitive. Ajo që i mungon dhe duhet ta kuptoni është se nuk ofron asnjë lloj klasterizimi. As LB, as HA. Mund të provoni, por përpjekjet do të jenë të tilla, sa do ishte më mirë të bënit diçka ndryshe nga e para.
Më duket se mund të përmbledhim. Në rastin kur një admin nuk është i pranishëm, ose është në numër të vogël, kur çmimi i hostimit dhe i faqeve të internetit që funksionojnë mbi të kalon, le të themi, 100 € , kur nuk bëhet fjalë për një server të mbushur me 1500 vende, kur para vendimmarrësit qëndron zgjedhja për të punësuar një admin me kohë të pjesshme, ose për të blerë software dhe për të punësuar një admin për “çmimin e pjesës” ose për ta lënë krejtësisht — ka patjetër një arsye. Nga pikëpamja e adminit të largët — po ashtu. 10$ në muaj, por kursen kohë dhe i jep fleksibilitet në punë.oShumë para. Nëse, për shembull, dikush më kërkon fort të marrë një projekt të ngjashëm nën krah, do të insistoj për kalimin në Plesk.
Burimi: habr.com
