Jag skulle vilja dela med mig av några intryck om nödvändigheten eller onödigheten av en sådan sak som en kontrollpanel för ett kommersiellt webbprojekt med en server med en administratör på deltid. Historien började för ett par år sedan, när vänners vänner bad mig hjälpa till med köpet av ett företag - en nyhetssajt - ur teknisk synvinkel. Det var nödvändigt att fördjupa sig lite i vad som fungerade med vad, se till att alla nödvändiga detaljer överfördes i rätt form och volym, och strategiskt ta reda på vad som kunde förbättras.
Affären var klar, violinisten behövdes inte längre. Slutet. Inte riktigt.
Sajten körde på en dubbelkärnig 4 GB virtuell dator på Linode, på en mossig Debian5 med en upptid på 400 dagar och en sådan lista med ouppdaterade paket. Webbdel på ett självskrivet CMS, nginx, php5.3 FPM, mysql-avstämt Percona. I princip fungerade det.
Parallellt med samtal med mig letade den nya ägaren efter en programmerare för att få projektet till förväntningarna. Hittades. Programmeraren utvärderade trafiken och volymerna och bestämde sig för att han visste hur man optimerar och kostnadshantering. Han migrerade hela webbplatsen till en delad hosting på 700 rubel som hanteras av sin vanliga IS****er. Några dagar senare kom ett nytt samtal från ägaren: "allt är långsamt och det verkar som om vi har varit trasiga." Jag försökte korrigera situationen genom panelen, men efter en tid av fruktlösa försök att ändra PHP-versionen eller hanteraren från fcgi till fpm gav jag upp och gick in i skalet. Där hittade jag en aktiverad debug som lyste på hela Internet med lösenordet från muskeln, 777 på några mappar som vid den tiden sprack med skadlig kod och liknande trams. Ägaren insåg och bestämde sig för att det var fel att spara på hosting, en programmerare och en admin som kunde hålla ett öga på hur det gick.
Vi ska till RuVDS. Lite närmare än brittiska Linode, och om du plötsligt vill lagra personuppgifter och allt detta behöver du inte flytta någon annanstans. Eftersom projektet var planerat att utökas tog vi en virtuell dator för tillväxt: 4 kärnor, 8 gigabyte minne, 80 GB disk. Det är inte så att jag inte vet hur man manuellt konfigurerar nginx-konfigurationer, jag hade helt enkelt inte entusiasmen att arbeta med det här projektet så intimt (se ovan om deltid). Det var därför jag installerade Plesk (här kommer jag att utelämna installationsdetaljerna, för i stort sett finns det inga: jag startade installationsprogrammet, ställde in lösenordet för administratören, angav nyckeln - det är allt), vid den tiden var det 17.0. Grundinställningarna fungerar bra, det finns fail2ban och de senaste tillgängliga versionerna av PHP och nginx.
Det är nog värt att stanna upp och förklara varför. Eftersom jag sällan gör sådana saker, och jag inte har några speciella verktyg eller förberedelser för varje fall, var det tydligt att någon form av automatisering av grundläggande saker behövdes, så att för det första snabbt, för det andra, säkert och för det tredje , alla de bästa metoderna som någon redan har implementerat det.
Så jag installerade det. Jag sparade mycket tid, att starta om webbplatsen på en ny server var nästan omedelbar. Allt som återstod var att redigera muskelkonfigurationen, ge den hälften av minnet och öka antalet buffertpooler, och ge nginx hälften av kärnorna (Plesk rör inte globala konfigurationer), och under ett par dagar gå in i skalet för att titta på mysqltuner-statistiken. Ja, och jag köpte den betalda ImunifyAV från tilläggskatalogen för att bli av med den översvämmade skadliga programvaran. Cirka 11000 XNUMX infekterade filer hittades. Det stygge är att fördunklade kodbitar hälldes i statiken, och att rengöra den för hand skulle ha varit helt tråkig. Först provade jag ClamAV, men som det visade sig, det tar inte sådana saker, men ImunifyAV kunde. Dessutom förblir de desinficerade filerna i fungerande skick; biten med skadlig programvara raderas helt enkelt.
Aritmetiken är enkel: $50 per månad för VMka, $10 för Plesk (faktiskt mindre, eftersom du köpte den för ett år på en gång med två månaders rabatt) och $3 för antivirus. Eller mycket pengar för min tid, som jag skulle ha spenderat på servern till en början, genom att håva dessa stall manuellt. Ägaren var ganska nöjd med detta arrangemang.
Under tiden hittade de en ny programmerare. Vi kom överens med honom om ansvarsfördelningen, skapade en underdomän för testversionen och arbetet började. Han klippte en ny version av sajten på Laravel, och jag tittade på fail2ban%).
Intressant nog slutar inte flödet av nyfikna människor och det finns alltid ett hundratal adresser på listan över förbjudna. Effekten är intressant: i synnerhet, vanligtvis, om jag loggar in i ett skal, ser jag ungefär 20000 30000-2 70 misslyckade försök att logga in via SSH vid hälsningen. Med fail0ban aktiverat, cirka 2. Ansträngningar investerade: XNUMX. Tyvärr var det inte utan en droppe salva. Som standard var WAF (modsecurity) halvaktiverat: i upptäcktsläge. Det vill säga, han skrev misstänkt aktivitet till loggen, men vidtog faktiskt ingen åtgärd. Och failXNUMXban läste urskillningslöst alla loggarna, enligt de aktiverade fängelserna, och dödade allt som rörde sig. Därmed förbjöd vi hälften av redaktionerna :D. Jag var tvungen att inaktivera detta fängelse och vitlista de nödvändiga IP-adresserna för tillförlitlighet. Ansträngningar investeras: peta med musen två gånger och lär redaktörerna att berätta din IP-adress.
Vad programmeraren direkt gillade var möjligheten att ladda upp databaser direkt till panelen och snabb tillgång till phpMyAdmin
Det jag gillade var loggarna och säkerhetskopiorna. Loggar skrivs och roteras ur lådan; Säkerhetskopiering är mycket lätt att ställa in. Vid de långsammaste tiderna görs en fullständig backup, cirka 10 spelningar, och sedan varje dag en inkrementell, 200 megabyte vardera, under en vecka. Återställningen är detaljerad, ner till en specifik fil eller databas. Om du behöver återställa från en inkrementell, behöver du inte bry dig först med en fullständig och återställning av hela kedjan, Plesk gör allt själv. Du kan ladda upp säkerhetskopior var som helst: till FTP, dropbox, s3 bucket, google drive, etc.
Dag F: programmeraren slutförde äntligen den nya motorn, vi laddade upp den till produktion, importerade gamla data och satte oss ner för att välja färg på vår framtida Maserati. Vi sitter fortfarande och väljer.
De första problemen började. Den nya sajten var förväntat tyngre än den gamla, men den verkliga raken var att de för att locka trafik använde de bland annat Yandex.Zen, vilket tog in massor av besökare. Webbplatsen kraschade med 150 samtidiga anslutningar (jag pratar inte om RPS, eftersom de inte mätte det). Vi började peta på knappar och vrida på rattarna i php_fpm-inställningsområdet:
Hej, han har redan 500 kontakter. När kreditkort lades till marknadsföringsmedlet blev trafikvågorna större. Nästa milstolpe är 1000 samtidiga anslutningar. Här fick vi putsa om koden och titta in i muskelns själ. Stänket hjälpte inte, men vi förväntade oss det inte riktigt. Vi aktiverade långsam frågelogg, la till index i databasen, tog bort onödiga frågor från koden och rensade återigen upp mysql-konfigurationen enligt råd från mysqltuner.
Ny utmaning - 2000 anslutningar. Versionen av Plesk 17.8 hann precis släppas, där bland annat nginx-caching lades till. Uppdaterad (förvånansvärt lätt). Låt oss försöka. Arbetar! Och sedan klev de på den mjuka sidan, Yandex.Zen-flödet slutade fungera. Sajten fungerar, flödet fungerar inte. Flödet fungerar inte, det finns ingen trafik. Atmosfären värms upp. Under press från omständigheterna och av brist på fantasi gick jag genast till strace och nginx och hittade det jag letade efter. Det visar sig att dumma nginx vid något tillfälle cachade det stray 500:e felet som ett svar på Yandex get feed.xml. Fixade det genom att lägga till undantag till cacheinställningarna:
Det är klart att ägaren behöver MER, vågorna ökar sakta. Vi klarar oss nu, men vi började experimentera med memcached i förväg, lyckligtvis stödjer Laravel det nästan ur lådan. Jag ville på något sätt inte installera memcached manuellt bara för att "spela runt", så jag installerade en docker-avbildning. Direkt från panelen.
Nåväl, okej, jag ljuger, jag var tvungen att gå in i skalet och installera modulen via pecl. Rätt på . Det finns inget att säga om ökningen av genomströmningen ännu, det har inte varit tillräckligt stora inflöden. Webbplatsmotorn är ansluten till localhost:11211, statistik visas, minnet förbrukas. Om du gillar det får vi se vad vi ska göra härnäst. Antingen lämnar vi det så, eller så lägger vi den "riktiga" direkt i Axis. Eller låt oss prova redis på samma sätt
Då var det nödvändigt att bifoga en e-postlista. Inga reläer, bara smtp-autentisering. Jag ställer in en e-postadress och använder dess uppgifter för att skicka ut ett nyhetsbrev via PHP.
För inte så länge sedan släpptes Plesk Obsidian (18.0), vi uppdaterade baserat på tidigare erfarenheter utan rädsla. Allt gick väldigt smidigt, det finns inte ens något att prata om. Det trevliga är att kvaliteten på gränssnittet har förbättrats avsevärt, det har blivit modernare och har blivit bekvämare på vissa ställen. Cool sak Avancerad övervakning på Grafana.
Jag har inte behandlat det i detalj ännu, men du kan till exempel ställa in varningar för vilken parameter som helst i din e-post. Till ägaren, lol.
Medan jag pratar om gränssnittet är det responsivt och fungerar riktigt bra på telefonen. I de tidiga stadierna, medan vi försökte hitta de optimala inställningarna för PHP och annat, hjälpte detta mycket. Och speciellt när en programmerare, i ett anfall av arbetsentusiasm, gör något vid 23:XNUMX, och jag, i ett anfall av arbetsentusiasm, dricker vodka i badhuset, och jag behöver SNABBT byta något.
Förresten. Bilden visar att PHP Composer har dykt upp. Vi har inte lekt med det ännu, men säg, för Laravel kan det spara ett par skalinloggningar och lite tid på att installera beroenden. Samma system finns för Node.JS och Ruby.
Med SSL är allt enkelt. Om domänen löser sig som förväntat görs Let’s Encrypt med ett klick och uppdaterar sig sedan, både för själva domänen och för underdomäner och till och med e-posttjänster.
Plesk i sig som programvara är för närvarande ganska trevlig och stabil. Den uppdaterar sig själv och Axis tyst, förbrukar få resurser och fungerar smidigt. Jag kommer inte ens ihåg att jag trampade på något någonstans, vilket skulle ha varit en uppenbar defekt i produkten. Det fanns naturligtvis problem, men de berodde antingen på ofullkomlig konfiguration eller någonstans vid korsningen, så det finns inget att klaga på. Intrycken av att arbeta med Plesk är överlag trevliga. Vad den inte har, och vi måste förstå detta, är vilken som helst (vilken som helst) klustring. Varken LB eller HA. Du kan försöka, men ansträngningen kommer att vara så stor att det är bättre att göra något annorlunda från början.
Jag tror att vi kan sammanfatta det. För fallet när det inte finns någon administratör, eller det inte finns tillräckligt med honom, när priset för värd och webbplatsen/webbplatserna som snurrar på det överstiger, tja, säg, 100 USD, när vi inte pratar om bestial delning på 1500 webbplatser på en server, när beslutsfattaren står inför Om du har valet att anställa en deltidsadministratör, eller köpa mjukvara och ha en administratör för en halv dollar, eller inte ha en alls - det är definitivt vettigt. Ur fjärradministratörens synvinkel - samma sak. $10 per månad, och sparar tid och ger flexibilitet i arbetet under mycket lång tidоett större belopp. Om jag till exempel blir starkt ombedd att ta ett liknande projekt under mina vingar, kommer jag att insistera på att överföra det till Plesk.
Källa: will.com