Jag vill dela med mig av nÄgra tankar om behovet eller onödigheten av ett kontrollpanel för ett kommersiellt enserverprojekt med en mycket deltidsadministratör. Historien började för nÄgra Är sedan nÀr bekanta bad mig att bistÄ med köpet av ett företag - en nyhetssajt - ur ett tekniskt perspektiv. Det krÀvdes att jag lite förstÄelse för vad som drev sajten, sÀkerstÀllde att alla nödvÀndiga uppgifter överlÀmnades i rÀtt format och omfattning, och strategiskt tÀnkte pÄ vad som kunde förbÀttras.
AffÀren genomfördes, violinisten blev oönskad. Slut.
Sajten kördes pÄ en tvÄkÀrnig 4 GB VM pÄ Linode, pÄ nÄgon gammal Debian5 med en drifttid pÄ 400 dagar och en sÄn hÀr lista över ovÀrderade paket. Webbkomponenten körde pÄ en egenutvecklad CMS, nginx, php5.3 FPM, mysql optimerad med Percona. I princip fungerade det.
Parallellt med mina samtal sökte den nya Ă€garen en programmerare för att anpassa projektet till förvĂ€ntningarna. Han hittade en. Programmeraren bedömde trafiken och volymerna och bestĂ€mde att han kunde sköta optimering och kostnadshantering. Han migrerade hela sajten till ett 700-rubels delat webbhotell under hans vanliga IS****er. NĂ„gra dagar senare fick jag ett nytt samtal frĂ„n Ă€garen: "allt laggar och det verkar som om nĂ„gon har hackat oss". Jag försökte Ă„tgĂ€rda situationen via panelen, men efter en tid av fruktlösa försök att byta PHP-version eller handlĂ€ggare frĂ„n fcgi till fpm, gav jag upp och gick in i shell. DĂ€r hittade jag aktiverad debugging som avslöjade hela internetets lösenord till MySQL, 777 pĂ„ vissa mappar som vid det laget sprack av uppladdad skadlig programvara och liknande galenskaper. Ăgaren insĂ„g och bestĂ€mde sig för att spara pĂ„ webbhotell, programmerare och en administratör som kunde hĂ„lla ett öga pĂ„ hur saker och ting gick - var fel.
Vi Ă„ker till RuVDS. Lite nĂ€rmare Ă€n brittiska Linode, och om man plötsligt vill lagra personuppgifter och allt det dĂ€r, behöver man inte flytta nĂ„gon annanstans. Eftersom projektet var tĂ€nkt att expandera, tog vi en VM "pĂ„ tillvĂ€xt": 4 kĂ€rnor, 8 GB minne, 80 GB disk. Det Ă€r inte sĂ„ att jag inte kan hantera nginx-konfigurationer manuellt, jag hade bara inte haft nĂ„gon entusiasm för att arbeta sĂ„ intimt med det hĂ€r projektet (se ovan om deltid). DĂ€rför installerade jag Plesk (jag hoppar över detaljer om installationen, eftersom de i stort sett inte existerar: jag startade installatören, satte administratörens lösenord, angav nyckeln â allt), dĂ„ var det version 17.0. De grundlĂ€ggande instĂ€llningarna fungerar okej ur lĂ„dan, det finns fail2ban och de senaste tillgĂ€ngliga versionerna av PHP, nginx.Â
Kanske Àr det vÀrt att stanna upp och förklara varför just det. Eftersom jag sÀllan sysslar med sÄdana hÀr saker, och jag har inget sÀrskilt verktyg eller uppsÀttning mallar för varje situation, var det tydligt att jag behövde nÄgon form av automatisering av de grundlÀggande uppgifterna för att, för det första, snabbt, för det andra, sÀkert, och för det tredje, att nÄgon redan har implementerat alla bÀsta praxis.
SÄ, jag installerade det. Jag sparade en hel del tid, omstarten av webbplatsen pÄ den nya servern skedde nÀstan omedelbart. Jag behövde bara justera mysql-konfigurationen, ge den hÀlften av minnet och öka antalet buffer pools, och ge nginx hÀlften av kÀrnorna (Plesk rör inte globala konfigurationer), och under ett par dagar loggade jag in i shell för att kolla pÄ mysqltuner-statistik. Ja, jag köpte ocksÄ ImunifyAV frÄn extensions-katalogen för att bli av med den laddade malware. Det fanns ungefÀr 11000 infekterade filer. Det Àckliga Àr att obfuskerade kodbitar blev influerade i statiken, och det skulle vara helt trÄkigt att rensa detta för hand. Först försökte jag ClamAV, men han tog som tur var inte sÄdana saker, medan ImunifyAV klarade det. Dessutom förblir de botade filerna i fungerande skick, man tar bara bort biten med malware.
Aritmetiken Ă€r enkel: 50$ i mĂ„naden för VM:n, 10$ för Plesk (egentligen mindre, eftersom vi köpte det direkt för ett Ă„r med tvĂ„ mĂ„naders rabatt) och 3$ för antivirus. Eller mĂ„nga vĂ€skor med pengar för min tid, som jag skulle ha spenderat pĂ„ servern i början med att rensa upp dessa stall manuellt. Ăgaren var helt nöjd med upplĂ€gget.
Samtidigt hittade vi en ny programmerare. Vi kom överens om ansvarsomrÄden, skapade en subdomÀn för testversionen och arbetet började. Han utvecklade den nya versionen av webbplatsen pÄ Laravel, medan jag höll ett öga pÄ fail2ban%).
Intressant nog slutar aldrig flödet av nyfikna besökare och det finns alltid omkring hundra adresser pÄ listan över blockerade. Effekten Àr intressant: vanligtvis, nÀr jag gÄr in i shell, ser jag omkring 20000-30000 misslyckade SSH-inloggningsförsök i vÀlkomstmeddelandet. Med fail2ban pÄ plats Àr det cirka 70. Inlagda anstrÀngningar: 0. TyvÀrr fanns det en liten baksida. Som standard var WAF (modsecurity) "halvaktiverad": i detekteringslÀget. Det vill sÀga att den bara loggade misstÀnkt aktivitet utan att vidta nÄgra ÄtgÀrder. Men fail2ban lÀste utan urskiljning alla loggar, enligt de aktiverade jails, och stÀngde av allt som rörde sig. PÄ sÄ sÀtt blockerade vi hÀlften av redaktionen :D. Vi var tvungna att stÀnga av detta jail och sÀkert lÀgga de nödvÀndiga IP-adresserna pÄ vitlistan. AnstrÀngningar nedlagda: tvÄ klick med musen och lÀra redaktörerna att ange sin IP-adress.
Det som programmeraren gillade direkt var möjligheten att ladda upp databaser direkt i panelen och snabb Ätkomst till phpMyAdmin.
Det jag gillade var loggar och sĂ€kerhetskopior. Loggar skrivs och roteras automatiskt; sĂ€kerhetskopior stĂ€lls in mycket enkelt. Under de mest lata tiderna görs en fullstĂ€ndig sĂ€kerhetskopia, som Ă€r runt 10 GB, och sedan görs inkrementella varje dag, ungefĂ€r 200 MB i veckan. Ă
terstÀllning Àr granulÀr, ner till en specifik fil eller databas. Om man behöver ÄterstÀlla frÄn en inkrementell sÀkerhetskopia, behöver man inte först kÀmpa med den fullstÀndiga och hela kedjan, Plesk gör allt sjÀlv. Man kan ladda upp sÀkerhetskopior vart som helst: till FTP, Dropbox, S3-bucket, Google Drive, och mer.
Dagen D: programmeraren avslutade Àntligen den nya motorn, vi laddade upp den i produktion, importerade gamla data och satte oss för att vÀlja fÀrg pÄ vÄra framtida Maserati. Vi sitter fortfarande och vÀljer.
De första problemen började dyka upp. Den nya webbplatsen var förvÀntat tyngre Àn den gamla, men det verkliga problemet var att vi anvÀnde bland annat Yandex.Zen för att dra trafik, vilket gav oss massor av besökare. Webbplatsen dog vid 150 samtidiga anslutningar (jag pratar inte om RPS, eftersom vi inte mÀtte det). Vi började trycka pÄ knappar och vrida skruvar i omrÄdet för php_fpm-instÀllningar:
Â
Oj, nu hanterar den redan 500 anslutningar. NÀr kreditkortet kopplades till marknadsföringsmedlen har vÄgorna av trafik blivit större. NÀsta milstolpe Àr 1000 samtidiga anslutningar. HÀr var vi tvungna att justera koden och titta i muskelns sjÀl. Plesk hjÀlpte inte riktigt, men det var vi inte förvÄnade över. Vi aktiverade logg för lÄngsamma frÄgor, lade pÄ index pÄ databasen, tog bort överflödiga förfrÄgningar frÄn koden och finjusterade MySQL-konfigurationen enligt mysqltuner:s rÄd.
Ny utmaning â 2000 anslutningar. Precis nĂ€r versionen Plesk 17.8 slĂ€pptes, dĂ€r de bland annat inkluderade nginx-caching. Vi uppdaterade (överraskande nog enkelt). Vi testar. Det fungerar! Och direkt kom vi in i ett mjukt lĂ€ge, Yandex Zen-flödet slutade fungera. Sidan fungerar, men flödet fungerar inte. Om flödet inte fungerar finns det ingen trafik. AtmosfĂ€ren blir spĂ€nd. Under tryck frĂ„n omstĂ€ndigheterna och bristen pĂ„ fantasi började jag genast strace'a nginx och hittade vad jag sökte. Det visar sig att nginx vid nĂ„got tillfĂ€lle dumt nog cachelagde ett inkommande 500-fel som svar pĂ„ Yandex' begĂ€ran om feed.xml. Vi Ă„tgĂ€rdade det genom att lĂ€gga till undantag i cacheinstĂ€llningarna:
SjÀlvklart behöver Àgaren MER, vÄgorna ökar lÄngsamt. Vi klarar det sÄ hÀr lÄngt, men vi började i förvÀg experimentera med memcached, tur att Laravel nÀstan stödjer det frÄn början. Att installera memcached manuellt för att "leka" kÀndes liksom inte rÀtt, sÄ vi installerade en Docker-bild. Direkt frÄn panelen.
Okej, jag ljuger, jag var tvungen att gÄ in i shell och installera modulen via pecl. Rakt pÄ . Att sÀga nÄgot om ökad bandbredd för tillfÀllet Àr inte möjligt, det har inte varit tillrÀckligt med stora flöden. Webbplatsmotorn kopplade till localhost:11211, statistiken visas, minnet anvÀnds. Om det fungerar bra, fÄr vi se vad vi gör hÀrnÀst. Antingen lÀmnar vi det sÄ hÀr eller installerar en "riktig" direkt i OS. Eller sÄ försöker vi redis pÄ samma sÀtt.
Sen behövde vi lÀgga till ett e-postutskick. Inga relÀer, bara smtp-autentisering. Jag skapade en e-postadress och anvÀnder dess uppgifter för att göra utskicket via PHP.
Nyligen slÀpptes Plesk Obsidian (18.0), vi uppdaterade utan rÀdsla baserat pÄ tidigare erfarenheter. Allt gick mycket smidigt, jag har faktiskt inget att berÀtta. Trevligt nog har grÀnssnittet blivit mycket mer kvalitativt, det har moderniserats och blivit mer anvÀndarvÀnligt pÄ vissa stÀllen. Den hÀftiga funktionen Advanced Monitoring i Grafana.
Jag har inte gÄtt igenom den i detalj Ànnu, men man kan till exempel stÀlla in larm för vilket parameter som helst till e-posten. Till Àgaren, lol.
Eftersom jag pratar om grÀnssnittet, sÄ Àr det responsivt och fungerar verkligen bra pÄ telefonen. Under de tidiga skedena, nÀr vi försökte hitta de optimala PHP-instÀllningarna och liknande, har det varit till stor hjÀlp. Och sÀrskilt nÀr utvecklaren i ett skov av arbetsentusiasme gör nÄgot klockan 23:00, medan jag i ett skov av arbetsentusiasme dricker vodka i bastun, och JAG Mà STE snabbvÀxla nÄgot.
Ă
h, förresten. PÄ bilden ser vi att PHP Composer har dykt upp. Vi har inte lekt med det Àn, men sÀg att för Laravel kan det spara nÄgra inloggningar i shell och lite tid pÄ att installera beroenden. En liknande system finns för Node.JS och Ruby.
Med SSL Ă€r det enkelt. Om domĂ€nen resolverar dit den ska, görs Letâs Encrypt med ett klick och uppdateras sedan automatiskt, bĂ„de för sjĂ€lva domĂ€nen och för subdomĂ€ner samt till och med e-posttjĂ€nster.
SjÀlva Plesk Àr för nÀrvarande ganska trevligt och stabilt. Det uppdaterar sig sjÀlvt och operativsystemet tyst, anvÀnder lite resurser och fungerar exakt. Jag minns inte att jag nÄgonstans snubblade över nÄgot som skulle vara ett tydligt fel pÄ produkten. Problematiken var förstÄs dÀr, men de berodde antingen pÄ brister i konfigurationen eller nÄgonstans vid övergÄngarna, sÄ det finns inte mycket att klaga pÄ. Sammanfattningsvis Àr mina intryck av att arbeta med Plesk positiva. Vad det saknar, och det Àr viktigt att förstÄ, Àr all typ av klustring. Varken LB eller HA. Man kan försöka, men den insatta anstrÀngningen skulle vara sÄ stor att det Àr bÀttre att göra nÄgot annat frÄn början.
Jag tror vi kan sammanfatta. I fall dĂ€r det inte finns nĂ„gon admin, eller han Ă€r outnyttjad, nĂ€r kostnaden för hosting och de webbplatser som körs pĂ„ den överstiger, lĂ„t oss sĂ€ga, 100 USD, nĂ€r det inte handlar om det lĂ„gt prissatta delade hosting med 1500 webbplatser pĂ„ en server, nĂ€r den som ska fatta beslut stĂ„r inför valet att anstĂ€lla en halvtidsadmin, eller köpa programvara och anstĂ€lla en admin för "en halv tjĂ€nst", eller helt enkelt inte ha nĂ„gon admin â sĂ„ finns det definitivt en poĂ€ng. FrĂ„n synvinkeln av en fjĂ€rradmin â samma sak. 10 USD i mĂ„naden sparar tid och ger flexibilitet i arbetet för en mycket större summa. Om jag till exempel starkt uppmanas att ta ett liknande projekt under mina vingar, kommer jag att insistera pĂ„ att flytta det till Plesk.bĂ€sta resultatet (subjektiv Ă„sikt).Jag vill dela med mig av nĂ„gra intryck om hur nödvĂ€ndigt eller onödigt det Ă€r med en kontrollpanel för ett kommersiellt en-server webbprojekt, nĂ€r man har en mycket deltidsadmin.
KĂ€lla: habr.com
