Jeg vil gjerne dele noen inntrykk om nødvendigheten eller unødvendigheten av en slik ting som et kontrollpanel for et kommersielt enkeltserver webprosjekt med en veldig deltidsadministrator. Historien begynte for et par år siden, da venner av venner ba meg bistå med kjøp av en bedrift - en nyhetsside - fra et teknisk synspunkt. Det var nødvendig å fordype seg litt i hva som fungerte med hva, sørge for at alle nødvendige detaljer ble overført i riktig form og volum, og strategisk finne ut hva som kunne forbedres.
Avtalen ble fullført, fiolinisten var ikke lenger nødvendig. Slutt. Ikke egentlig.
Siden kjørte på en dual-core 4 GB VM på Linode, på noen mosete Debian5 med en oppetid på 400 dager og en slik liste over uoppdaterte pakker. Webdel på et selvskrevet CMS, nginx, php5.3 FPM, mysql-innstilt Percona. I prinsippet fungerte det.
Parallelt med samtaler med meg lette den nye eieren etter en programmerer for å bringe prosjektet til forventningene. Funnet. Programmereren vurderte trafikken og volumene og bestemte at han visste hvordan han skulle optimalisere og kostnadsstyring. Han migrerte hele nettstedet til en delt hosting på 700 rubler administrert av hans vanlige IS****er. Noen dager senere kom det en ny telefon fra eieren: "alt er tregt og det ser ut til at vi har vært ødelagt." Jeg prøvde å rette opp situasjonen gjennom panelet, men etter en tid med resultatløse forsøk på å endre PHP-versjonen eller behandleren fra fcgi til fpm, ga jeg opp og gikk inn i skallet. Der fant jeg en aktivert feilsøking som lyste på hele Internett med passordet fra muskelen, 777 på noen mapper som på den tiden sprakk med malware og lignende tull. Eieren innså og bestemte seg for at det var feil å spare på hosting, en programmerer og en admin som kunne holde et øye med hvordan ting gikk.
Vi skal til RuVDS. Litt nærmere enn den britiske Linode, og hvis du plutselig ønsker å lagre personopplysninger og alt dette, trenger du ikke flytte noe annet sted. Siden prosjektet var planlagt utvidet, tok vi en VM for vekst: 4 kjerner, 8 gigabyte minne, 80 GB disk. Det er ikke det at jeg ikke vet hvordan jeg manuelt konfigurerer nginx-konfigurasjoner, jeg hadde bare ikke entusiasmen til å jobbe så nært med dette prosjektet (se ovenfor om deltid). Det er derfor jeg installerte Plesk (her vil jeg utelate installasjonsdetaljene, for stort sett er det ingen: Jeg startet installasjonsprogrammet, satte passordet for admin, skrev inn nøkkelen - det er alt), på den tiden var det 17.0. Grunninnstillinger fungerer tålelig ut av boksen, det er fail2ban og de siste tilgjengelige versjonene av PHP og nginx.
Det er nok verdt å stoppe opp og forklare hvorfor. Siden jeg sjelden gjør slike ting, og jeg ikke har noen spesielle verktøy eller sett med forberedelser for hver sak, var det klart at det var behov for en slags automatisering av grunnleggende ting, slik at for det første, raskt, for det andre, trygt og for det tredje , alle de beste fremgangsmåtene noen allerede har implementert det.
Så jeg installerte den. Jeg sparte mye tid, å starte nettstedet på nytt på en ny server var nesten øyeblikkelig. Alt som gjensto var å redigere muskelkonfigurasjonen, gi den halve minnet og øke antall bufferbassenger, og gi nginx halvparten av kjernene (Plesk berører ikke globale konfigurasjoner), og i et par dager gå inn i skallet for å se på mysqltuner-statistikken. Ja, og jeg kjøpte den betalte ImunifyAV fra utvidelseskatalogen for å bli kvitt den oversvømmede malware. Rundt 11000 XNUMX infiserte filer ble funnet. Vederstyggeligheten er at tilslørte kodebiter ble helt inn i statikken, og å rengjøre den for hånd ville vært helt kjedelig. Først prøvde jeg ClamAV, men som det viste seg, tar det ikke slike ting, men ImunifyAV kunne. Dessuten forblir de desinfiserte filene i fungerende tilstand; delen med skadelig programvare blir ganske enkelt slettet.
Regnestykket er enkelt: $50 per måned for VMka, $10 for Plesk (faktisk mindre, fordi du kjøpte det for et år på en gang med to måneders rabatt) og $3 for antivirus. Eller mye penger for tiden min, som jeg ville ha brukt på serveren til å begynne med, og rake disse stallene manuelt. Eieren var ganske fornøyd med denne ordningen.
I mellomtiden fant de en ny programmerer. Vi ble enige med ham om ansvarsfordelingen, opprettet et underdomene for testversjonen, og arbeidet startet. Han klippet en ny versjon av nettstedet på Laravel, og jeg så på fail2ban%).
Interessant nok stopper ikke strømmen av nysgjerrige mennesker, og det er alltid rundt hundre adresser på listen over forbudte. Effekten er interessant: spesielt, vanligvis, hvis jeg logger på et skall, ser jeg omtrent 20000 30000-2 70 mislykkede forsøk på å logge på via SSH ved hilsenen. Med fail0ban aktivert, ca 2. Innsats investert: XNUMX. Dessverre var det ikke uten en dråpe salve. Som standard var WAF (modsecurity) halvt aktivert: i oppdagelsesmodus. Det vil si at han skrev mistenkelig aktivitet til loggen, men gjorde faktisk ingen handling. Og failXNUMXban leste tilfeldig alle loggene, i henhold til de aktiverte fengslene, og drepte alt som beveget seg. Dermed utestengt vi halvparten av redaktørene :D. Jeg måtte deaktivere dette fengselet og hvitliste de nødvendige IP-adressene for pålitelighet. Det er investert innsats: stikk musen to ganger og lær redaktørene å fortelle deg IP-adressen din.
Det programmereren umiddelbart likte var muligheten til å laste opp databaser direkte til panelet og rask tilgang til phpMyAdmin
Det jeg likte var loggene og sikkerhetskopiene. Logger skrives og roteres ut av esken; Sikkerhetskopier er veldig enkle å sette opp. På de tregeste tidspunktene blir det laget en fullstendig sikkerhetskopi, omtrent 10 spillejobber, og deretter hver dag en inkrementell, 200 megabyte hver, i en uke. Gjenoppretting er detaljert, ned til en bestemt fil eller database. Hvis du trenger å gjenopprette fra en inkrementell en, trenger du ikke først å bry deg med en full og gjenoppretting av hele kjeden, Plesk gjør alt selv. Du kan laste opp sikkerhetskopier hvor som helst: til FTP, dropbox, s3 bucket, google drive, etc.
Dag F: programmereren fullførte endelig den nye motoren, vi lastet den opp til produksjon, importerte gamle data og satte oss ned for å velge fargen på vår fremtidige Maserati. Vi sitter fortsatt og velger.
De første problemene begynte. Den nye siden var forventet tyngre enn den gamle, men den virkelige raken var at de for å tiltrekke seg trafikk brukte blant annet Yandex.Zen, som brakte inn massevis av besøkende. Nettstedet krasjet med 150 samtidige tilkoblinger (jeg snakker ikke om RPS, fordi de ikke målte det). Vi begynte å stikke knapper og dreie knotter i php_fpm-innstillingsområdet:
Hei, han har allerede 500 forbindelser. Etter hvert som kredittkort ble lagt til reklamemidlene, ble trafikkbølgene større. Den neste milepælen er 1000 samtidige forbindelser. Her måtte vi pusse opp koden og se inn i sjelen til muskelen. Plasken hjalp ikke, men vi hadde egentlig ikke forventet det. Vi aktivert sakte spørringslogg, la til indekser til databasen, fjernet unødvendige spørringer fra koden, og igjen ryddet opp i mysql-konfigurasjonen i henhold til rådene fra mysqltuner.
Ny utfordring - 2000 forbindelser. Versjonen av Plesk 17.8 rakk akkurat å bli sluppet, der blant annet nginx-caching ble lagt til. Oppdatert (overraskende enkelt). La oss prøve. Virker! Og så gikk de på den myke siden, Yandex.Zen-feeden sluttet å fungere. Siden fungerer, feeden fungerer ikke. Feeden fungerer ikke, det er ingen trafikk. Atmosfæren varmes opp. Under press fra omstendigheter og fra mangel på fantasi, gikk jeg umiddelbart til strace og nginx og fant det jeg lette etter. Det viser seg at dumme nginx på et tidspunkt bufret den bortkommen 500. feilen som et svar på Yandex get feed.xml. Fikset det ved å legge til unntak i hurtigbufferinnstillingene:
Det er tydelig at eieren trenger MER, bølgene øker sakte. Vi takler det nå, men vi begynte å eksperimentere med memcached på forhånd, heldigvis støtter Laravel det nesten ut av esken. Jeg ville på en eller annen måte ikke installere memcached manuelt bare for å "leke rundt", så jeg installerte et docker-bilde. Rett fra panelet.
Vel, ok, jeg lyver, jeg måtte gå inn i skallet og installere modulen via pecl. Rett på . Det er ingenting å si på økningen i gjennomstrømmingen ennå, det har ikke vært store nok tilstrømninger. Nettstedmotoren er koblet til localhost:11211, statistikk vises, minne forbrukes. Hvis du liker det, får vi se hva vi skal gjøre videre. Enten lar vi det være slik, eller så legger vi den "ekte" rett i aksen. Eller la oss prøve redis på samme måte
Da var det nødvendig å legge ved en e-postliste. Ingen releer, kun smtp-autentisering. Jeg setter opp en postadresse og bruker detaljene til å sende ut et nyhetsbrev via PHP.
For ikke lenge siden ble Plesk Obsidian (18.0) utgitt, vi oppdaterte basert på tidligere erfaringer uten frykt. Alt gikk veldig greit, det er ikke engang noe å snakke om. Det hyggelige er at kvaliteten på grensesnittet har blitt kraftig forbedret, det har blitt mer moderne og har blitt mer praktisk noen steder. Kul ting Avansert overvåking på Grafana.
Jeg har ikke behandlet det i detalj ennå, men du kan for eksempel sette opp varsler for en hvilken som helst parameter i e-posten din. Til eieren, lol.
Mens jeg snakker om grensesnittet, er det responsivt og fungerer veldig bra på telefonen. I de tidlige stadiene, mens vi prøvde å finne de optimale innstillingene for PHP og andre ting, hjalp dette mye. Og spesielt når en programmerer, i et anfall av arbeidsentusiasme, gjør noe klokken 23:XNUMX, og jeg, i et anfall av arbeidsentusiasme, drikker vodka i badehuset, og jeg MÅ HASTE bytte noe.
Å, forresten. Bildet viser at PHP Composer har dukket opp. Vi har ikke lekt med det ennå, men for Laravel kan det spare et par shell-pålogginger og litt tid på å installere avhengigheter. Det samme systemet finnes for Node.JS og Ruby.
Med SSL er alt enkelt. Hvis domenet løser seg som forventet, gjøres Let's Encrypt med ett klikk og oppdaterer seg selv, både for selve domenet, og for underdomener, og til og med e-posttjenester.
Plesk selv som programvare er for tiden ganske behagelig og stabil. Den oppdaterer seg selv og Axis stille, bruker få ressurser og fungerer jevnt. Jeg husker ikke engang at jeg tråkket på noe et sted, som ville ha vært en åpenbar feil i produktet. Det var selvfølgelig problemer, men de skyldtes enten ufullkommen konfigurasjon eller et sted i krysset, så det er ingenting å klage på. Inntrykkene av å jobbe med Plesk er generelt hyggelige. Det den ikke har, og vi trenger å forstå dette, er enhver (en hvilken som helst) klynging. Verken LB eller HA. Du kan prøve, men innsatsen vil være så mye at det er bedre å gjøre noe annerledes fra begynnelsen.
Jeg tror vi kan oppsummere det. For tilfellet når det ikke er noen administrator, eller det ikke er nok av ham, når prisen på hosting og siden(e) som spinner på den overstiger, vel, si, 100 USD, når vi ikke snakker om bestial deling på 1500 nettsteder på en server, når beslutningstakeren står overfor Hvis du har valget mellom å ansette en deltidsadministrator, eller kjøpe programvare og ha en admin for en halv dollar, eller ikke ha en i det hele tatt - det er definitivt fornuftig. Fra den eksterne administratorens synspunkt - det samme. $10 per måned, og sparer tid og gir fleksibilitet i arbeidet i svært lang tidоet større beløp. Hvis jeg for eksempel blir sterkt bedt om å ta et lignende prosjekt under mine vinger, vil jeg insistere på å overføre det til Plesk.
Kilde: www.habr.com