Min erfaring med Plesk

Eg vil dele nokre inntrykk om nytten eller unøydt av ein kontrollpanel for kommersielle einskild-server nettprosjekt når ein har ein veldig deltids administrator. Historia byrja for nokre år sidan, då kjente av kjente ba meg om å støtte kjøpet av ein bedrift — ein nyheitsside — frå ein teknisk synsvinkel. Det var nødvendig å få ein viss forståing av kva som arbeidet, sikre at alle nødvendige detaljer blei overlevert i riktig form og volum, og strategisk vurdere kva som kunne bli forbedra.

Avtalen blei inngått, fiolinisten blei overflødig. Slutt. I realiteten, nei.

Sida kjørte på ein to-kjernes 4 GB VM på Linode, på ein gammal Debian5 med eit oppetid på 400 dagar og ein slik liste av uoppdaterte pakkar. Nett-delen var på ein eigenskreven CMS, nginx, php5.3 FPM, MySQL tunet med Percona. I prinsippet fungerte det.

Parallelt med samtalane med meg, let den nye eigaren ein programmerar leite etter å tilpasse prosjektet til forventningane. Han fann ein. Programmeraren vurderte trafikken og volumet og bestemte seg for at han kunne optimalisering og kostnadsstyring. Han migrerte heile sida til ein 700-rubel delt hosting under kontroll av sin kjende IS****er. Nokre dagar seinare fekk eg ein telefon igjen frå eigaren: «alt står stille og det ser ut som vi har blitt hacka». Eg prøvde å rette opp situasjonen gjennom panelet, men etter ei tid med fruktnåle forsøk på å endre PHP-versjonen eller handleren frå fcgi til fpm, gav eg opp og gjekk inn i shell. Der fann eg debug påslått, som lyste ut på heile internett med passordet til MySQL, 777 på nokre mappene, som då sprekka av innlagt malware og liknande galskap. Eigaren innsåg ho fekk forstå det, og bestemte seg for at det var feil å spare på hosting, programmerer og ein administrator som skulle sjå til at alt går bra.

Vi reiser til RuVDS. Litt nærmere enn britiske Linode, og hvis du skulle ønske å lagre personlige data og alt det der, trenger du ikke flytte et annet sted. Siden prosjektet skulle utvides, tok vi en VM "til vekst": 4 kjerner, 8 GB minne, 80 GB disk. Det er ikke slik at jeg ikke kan håndtere nginx-konfigurasjoner manuelt, men jeg hadde rett og slett ikke entusiasme for å jobbe så intimt med dette prosjektet (se ovenfor om deltidsarbeid). Derfor – jeg satte opp Plesk (her vil jeg hoppe over installasjonsdetaljene, for de er stort sett ikke relevante: jeg startet installasjonsprogrammet, satte et passord for administratoren, la inn nøkkelen – ferdig), på den tiden var det versjon 17.0. De grunnleggende innstillingene fungerer greit direkte fra boksen, det finnes fail2ban og de nyeste tilgjengelige versjonene av PHP, nginx. 

Kanskje det er verdt å forklare hvorfor jeg valgte dette. Siden jeg sjelden jobber med slike ting, og jeg ikke har noe spesialverktøy eller samling av maler for hver anledning, var det klart at jeg trengte en eller annen automatisering av grunnleggende oppgaver, slik at jeg for det første kunne jobbe raskt, for det andre trygt, og for det tredje at noen allerede hadde implementert alle best practices.

Så jeg satte det opp. Jeg sparte betydelig med tid, omstarten av nettstedet på den nye serveren skjedde praktisk talt umiddelbart. Det gjenstod å justere MySQL-konfigurasjonen, gi den halvparten av minnet og øke antall buffer pools, og gi nginx halvparten av kjernene (Plesk berører ikke globale konfigurasjoner), og i løpet av et par dager sjekke shell-en for å se på statistikken fra mysqltuner. Jo, og jeg kjøpte en betalt ImunifyAV fra utvidelseskatalogen for å bli kvitt den opplastede malwaren. Det ble funnet omtrent 11 000 infiserte filer. Det ekle er at obfuskert kode ble strømmet inn i statiske filer, og å rense dette manuelt ville vært ganske trist. Først prøvde jeg ClamAV, men det kunne ikke håndtere slike ting, mens ImunifyAV klarte det. Og de helbredede filene forblir i brukbar tilstand, bare stykket med malware blir fjernet.

Aritmetikken er enkel: 50$ i måneden for VM-en, 10$ for Plesk (faktisk mindre, fordi vi kjøpte det for et år med to måneders rabatt) og 3$ for antivirusprogrammet. Eller mange kofferter med penger for min tid, som jeg ville brukt på serveren i starten for å rydde opp i disse stallene manuelt. Eierens balanse synes å være helt akseptabel.

I mellomtiden fant vi en ny programmerer. Vi ble enige med ham om fordeling av ansvar, laget et subdomene for testversjonen, og arbeidet begynte. Han jobbet med en ny versjon av nettstedet på Laravel, mens jeg holdt øye med fail2ban%).

Det er interessant at strømmen av nysgjerrige aldri stopper, og listen over blokkerte adresser er alltid rundt hundre. Effekten er interessant: vanligvis, hvis jeg går inn i shell, ser jeg omtrent 20000-30000 mislykte SSH-påloggingsforsøk i velkomstmeldingen. Med fail2ban på rundt 70. Inntektsnivå: 0. Dessverre har det ikke vært helt uten skavanker. Som standard var WAF (modsecurity) "halvaktivert": i deteksjonsmodus. Det vil si at den skrev mistenkelig aktivitet til loggen, men faktisk gjorde ingenting. Og fail2ban leste ubegrunnet alle loggene, i henhold til de aktiverte jailene, og blokkerte alt som beveget seg. Dermed blokkerte vi halvparten av redaksjonen :D. Vi måtte deaktivere denne jailen, og for pålitelighet la vi inn nødvendige IP-adresser i hvitelisten. Arbeidet som ble lagt ned: to ganger med musen og lære redaktørene å si sin IP-adresse.

Det som programmereren likte med en gang — muligheten til å laste opp databaser direkte i panelet og enkel tilgang til phpMyAdmin.

Det jeg likte — loggene og backupene. Loggene skrives og roteres automatisk; backupene kan settes opp veldig enkelt. I de tregeste tidene blir det laget en full backup, omtrent på 10 gigabyte, og deretter hver dag en inkrementell, omtrent 200 megabyte, i løpet av en uke. Gjenoppretting er granulerte, ned til en spesifikk fil eller database. Hvis man trenger å gjenopprette fra inkrementell backup, er det ikke nødvendig å starte med full backup og gjenoppretting av hele kjeden, Plesk tar seg av alt. Backupene kan lastes opp hvor som helst: til FTP, til Dropbox, S3-bucket, Google Drive og mer.

Dagen D: programmereren har endelig ferdigstilt den nye motoren, vi lastet den opp til produksjon, importerte de gamle dataene og begynte å velge fargen på våre fremtidige Maserati. Vi sitter fortsatt og velger.

De første problemene begynte. Det nye nettstedet var som forventet tyngre enn det gamle, men den reelle utfordringen var at vi blant annet brukte Yandex.Zen for å tiltrekke trafikk, noe som førte til at nettstedet ble overbelastet med 150 samtidige tilkoblinger (jeg snakker ikke om RPS, fordi vi ikke målte det). Vi begynte å trykke på knapper og justere innstillingene i php_fpm:
 

Åh, nå holder det allerede 500 tilkoblinger. Etter hvert som kredittkortet ble brukt til å fremme trafikken, ble bølgene større. Neste milepæl er 1000 samtidige tilkoblinger. Her måtte vi finpussere koden og se inn i muskelen. Plesk hjalp ikke i dette, men det var heller ikke forventet. Vi aktiverte slow queries log, la til indekser på databasen, fjernet unødvendige forespørsel fra koden, og finjusterte mysql-konfigurasjonen i henhold til rådene fra mysqltuner.

Ny utfordring – 2000 tilkoblinger. Det kom akkurat ut en versjon av Plesk 17.8, hvor de blant annet la til nginx caching. Vi oppdaterte (til vår overraskelse ganske lett). Vi prøver. Det fungerer! Og så stoppet Yandex Zen-feeden å virke. Nettsiden fungerer, men feeden fungerer ikke. Ingen feed, ingen trafikk. Atmosfæren er anspent. Under press fra omstendighetene og mangel på fantasi begynte jeg straks å strace nginx og fant ut hva som var på ferde. Det viser seg at nginx på et tidspunkt dumt hadde cachet en tilfeldig 500-feil som et svar på Yandex sin get feed.xml. Vi rettet det ved å legge til unntak i cache-innstillingene:

Det er klart at eieren trenger MER, bølgene øker sakte. Vi klarer oss foreløpig, men vi begynte tidlig å eksperimentere med memcached, heldigvis støtter Laravel det nesten out of the box. Å installere memcached for å "leke" med det, fristet ikke så mye, så vi satte opp en Docker-bilde. Rett fra panelet.

Vel, jeg lyver, jeg måtte gå inn i shell og installere modulen via pecl. Rett gjennom instruksjoner. Det er for tidlig å snakke om økt båndbredde, det har ikke vært store påkjenninger. Nettmotoren koblet seg til localhost:11211, statistikk vises, minne brukes. Hvis det fungerer bra, ser vi på hva vi skal gjøre videre. Enten beholder vi det slik, eller så setter vi opp en "ekte" rett på OS. Eller så forsøker vi redis på samme måte.

Så trengte vi å fikse en e-postutsendelse. Ingen re-ley, bare smtp-autentisering. Vi opprettet en e-postadresse, og via dens detaljer lager vi utsendelsen gjennom PHP.

Nylig kom Plesk Obsidian (18.0), vi oppdaterte uten frykt basert på tidligere erfaring. Alt gikk veldig glatt, til og med ikke noe å fortelle. Det positive — grensesnittet har blitt betydelig forbedret i kvalitet, modernisert og blitt mer brukervennlig på enkelte områder. En kul funksjon er Advanced Monitoring i Grafana.

Jeg har ikke gått grundig inn på det ennå, men man kan for eksempel sette opp varsler for hvilket som helst parameter til e-post. Til eieren, lol.

Siden jeg snakker om grensesnittet, er det responsivt og fungerer faktisk ganske bra på telefonen. I de tidlige stadiene, mens vi prøvde å finne optimale PHP-innstillinger og så videre, hjalp det oss mye. Og spesielt når programmereren, i et arbeidsentusiastens anfektelse, jobber med noe klokken 23, og jeg, i et arbeidsentusiastisk anfektelse, drikker vodka i badstuen, og DET HASTER å skru noe.

Åh, forresten. På bildet ser vi at PHP Composer har dukket opp. Vi har ikke lekt med det ennå, men for eksempel kan det spare et par innlogginger i shell og en del tid til å installere avhengigheter for Laravel. Det finnes et lignende system for Node.JS og Ruby.

Med SSL er det enkelt. Hvis domenet resolves til riktig sted, kan Let’s Encrypt settes opp med ett klikk og oppdaterer seg selv, både for selve domenet og subdomener, samt e-posttjenester.

Selve Plesk er på nåværende tidspunkt ganske hyggelig og stabil. Den oppdaterer seg selv og OS stille, bruker lite ressurser, og fungerer jevnt. Jeg husker nesten ikke at jeg har tråkket på noe som var et åpenbart produktdefekt. Det har selvfølgelig vært problemer, men enten fra konfigurasjonsimperfeksjon eller et eller annet sted i grensesnittene, så det er ikke mye å kritisere. Inntrykkene jeg har av å jobbe med Plesk er generelt positive. Det man må forstå, er at det ikke har noen (hvilken som helst) form for klustering. Ingen LB, ingen HA. Man kan forsøke, men innsatsen som kreves vil være så stor at det er bedre å gjøre noe helt annet fra starten av.

Jeg tror vi kan oppsummere. For tilfeller hvor det ikke er noen administrator, eller bare veldig lite, når kostnaden for hosting og de aktuelle nettstedene overstiger, la oss si, 100 enheter, når vi snakker om en tragisk deling av 1500 nettsteder på en server, når den som skal ta beslutningen står overfor valget om å ansette en deltid administrator, eller kjøpe programvare og ansette en administrator for "halvparten av prisen", eller ikke ansette en i det hele tatt - da er det absolutt en mening. Sett fra en fjerntliggende administrators synspunkt - det er det samme. 10 dollar i måneden, men sparer tid og gir stor fleksibilitet i arbeidet.omHvis for eksempel noen ber meg sterkt om å ta et lignende prosjekt under mine vinger, vil jeg insistere på å flytte det til Plesk.

Kilde: habr.com