Jeg vil gerne dele nogle indtryk om nødvendigheden eller unødvendigheden af sådan noget som et kontrolpanel til et kommercielt enkelt-server webprojekt med en meget deltidsadministrator. Historien begyndte for et par år siden, da venners venner bad mig hjælpe mig med at købe en virksomhed - et nyhedssite - ud fra et teknisk synspunkt. Det var nødvendigt at dykke lidt ned i, hvad der virkede på hvad, sørge for, at alle de nødvendige detaljer blev overført i den rigtige form og volumen, og strategisk finde ud af, hvad der kunne forbedres.
Handlen blev gennemført, violinisten var ikke længere nødvendig. Ende. Ikke rigtig.
Siden kørte på en dual-core 4 GB VM på Linode, på nogle mosede Debian5 med en oppetid på 400 dage og sådan en liste over uopdaterede pakker. Webdel på et selvskrevet CMS, nginx, php5.3 FPM, mysql tunet Percona. I princippet virkede det.
Sideløbende med samtaler med mig søgte den nye ejer en programmør til at bringe projektet op til forventningerne. Fundet. Programmøren vurderede trafikken og mængderne og besluttede, at han vidste, hvordan man optimerer og omkostningsstyring. Han migrerede hele webstedet til en delt hosting på 700 rubler, der administreres af hans sædvanlige IS****er. Et par dage senere kom der endnu et opkald fra ejeren: "alt er langsomt, og det ser ud til, at vi er gået i stykker." Jeg forsøgte at rette op på situationen gennem panelet, men efter nogen tid med frugtesløse forsøg på at ændre PHP-versionen eller handleren fra fcgi til fpm, gav jeg op og gik ind i skallen. Der fandt jeg en aktiveret debug, der lyste på hele internettet med adgangskoden fra muskelen, 777 på nogle mapper, der på det tidspunkt knækkede med malware og lignende vrøvl. Ejeren indså og besluttede, at det var forkert at spare på hosting, en programmør og en administrator, der kunne holde øje med, hvordan det gik.
Vi skal til RuVDS. Lidt tættere på end den britiske Linode, og hvis du pludselig vil gemme personlige data og alt dette, skal du ikke flytte andre steder. Da projektet var planlagt til at blive udvidet, tog vi en VM til vækst: 4 kerner, 8 gigabyte hukommelse, 80 GB disk. Det er ikke, fordi jeg ikke ved, hvordan man manuelt konfigurerer nginx-konfigurationer, jeg havde bare ikke entusiasme til at arbejde på dette projekt så intimt (se ovenfor om deltid). Det er derfor, jeg installerede Plesk (her vil jeg udelade installationsdetaljerne, fordi der stort set ikke er nogen: Jeg startede installationsprogrammet, satte adgangskoden til administratoren, indtastede nøglen - det er alt), på det tidspunkt var det 17.0. Grundlæggende indstillinger fungerer tåleligt ud af boksen, der er fail2ban og de seneste tilgængelige versioner af PHP og nginx.
Det er nok værd at stoppe op og forklare hvorfor. Da jeg sjældent laver sådanne ting, og jeg ikke har nogen specielle værktøjer eller forberedelser til hver enkelt sag, var det klart, at der var behov for en form for automatisering af grundlæggende ting, så for det første, hurtigt, for det andet, sikkert og for det tredje , alle de bedste fremgangsmåder, nogen allerede har implementeret det.
Så jeg installerede det. Jeg sparede en masse tid, genstart af webstedet på en ny server var næsten øjeblikkeligt. Det eneste, der var tilbage, var at redigere muskelkonfigurationen, give den halvdelen af hukommelsen og øge antallet af bufferpuljer og give nginx halvdelen af kernerne (Plesk rører ikke globale konfigurationer), og i et par dage gå ind i skallen for at se på mysqltuner-statistikken. Ja, og jeg købte den betalte ImunifyAV fra udvidelseskataloget for at slippe af med den oversvømmede malware. Der blev fundet omkring 11000 inficerede filer. Vederstyggeligheden er, at slørede stykker kode blev hældt ind i statikken, og at rense det i hånden ville have været helt kedeligt. Først prøvede jeg ClamAV, men som det viste sig, tager det ikke sådanne ting, men ImunifyAV kunne. Desuden forbliver de desinficerede filer i funktionsdygtig stand; stykket med malwaren slettes simpelthen.
Regnestykket er simpelt: $50 pr. måned for VMka, $10 for Plesk (faktisk mindre, fordi du købte det for et år på én gang med to måneders rabat) og $3 for antivirus. Eller en masse penge for min tid, som jeg ville have brugt på serveren i starten, hvor jeg rakte disse stalde manuelt. Ejeren var meget tilfreds med dette arrangement.
I mellemtiden fandt de en ny programmør. Vi blev enige med ham om ansvarsfordelingen, oprettede et underdomæne til testversionen, og arbejdet gik i gang. Han klippede en ny version af webstedet på Laravel, og jeg kiggede på fail2ban%).
Interessant nok stopper strømmen af nysgerrige mennesker ikke, og der er altid omkring hundrede adresser på listen over forbudte. Effekten er interessant: Især, hvis jeg logger på en shell, ser jeg normalt omkring 20000-30000 mislykkede forsøg på at logge ind via SSH ved hilsenen. Med fail2ban aktiveret, omkring 70. Indsats investeret: 0. Desværre var det ikke uden en dråbe salve. Som standard var WAF (modsecurity) halvt aktiveret: i opdagelsestilstand. Det vil sige, at han skrev mistænkelig aktivitet til loggen, men foretog sig faktisk ikke noget. Og fail2ban læste vilkårligt alle logs, ifølge de aktiverede fængsler, og dræbte alt, der bevægede sig. Dermed forbød vi halvdelen af redaktørerne :D. Jeg var nødt til at deaktivere dette fængsel og hvidliste de nødvendige IP-adresser for pålidelighed. Der er investeret indsats: Stik to gange med musen, og lær redaktørerne at fortælle dig din IP-adresse.
Hvad programmøren umiddelbart kunne lide var muligheden for at uploade databaser direkte til panelet og hurtig adgang til phpMyAdmin
Det, jeg kunne lide, var logfilerne og sikkerhedskopierne. Logs skrives og roteres ud af boksen; Sikkerhedskopier er meget nemme at sætte op. På de langsomste tidspunkter laves en fuld backup, omkring 10 koncerter, og derefter hver dag en trinvis en, 200 megabyte hver, i en uge. Gendannelse er detaljeret, ned til en specifik fil eller database. Hvis du har brug for at gendanne fra en trinvis en, så behøver du ikke først genere med en fuld og gendannelse af hele kæden, Plesk gør alt selv. Du kan uploade sikkerhedskopier hvor som helst: til FTP, dropbox, s3 bucket, google drive osv.
Dag F: programmøren færdiggjorde endelig den nye motor, vi uploadede den til produktion, importerede gamle data og satte os for at vælge farven på vores fremtidige Maserati. Vi sidder stadig og vælger.
De første problemer begyndte. Den nye side var forventet tungere end den gamle, men den virkelige rake var, at de for at tiltrække trafik brugte de blandt andet Yandex.Zen, som bragte masser af besøgende. Siden gik ned med 150 samtidige forbindelser (jeg taler ikke om RPS, fordi de ikke målte det). Vi begyndte at stikke knapper og dreje knapper i indstillingsområdet for php_fpm:
Hej, han har allerede 500 forbindelser. Efterhånden som kreditkort blev tilføjet til reklamemidlerne, blev bølgerne af trafik større. Den næste milepæl er 1000 samtidige forbindelser. Her skulle vi efterbehandle koden og kigge ind i musklens sjæl. Sprøjten hjalp ikke, men vi havde egentlig ikke forventet det. Vi aktiverede log for langsomme forespørgsler, tilføjede indekser til databasen, fjernede unødvendige forespørgsler fra koden og ryddede igen op i mysql-konfigurationen i henhold til råd fra mysqltuner.
Ny udfordring - 2000 forbindelser. Udgaven af Plesk 17.8 nåede netop at blive frigivet, hvori blandt andet nginx caching blev tilføjet. Opdateret (overraskende nemt). Lad os prøve. Arbejder! Og så trådte de på den bløde side, Yandex.Zen-feedet holdt op med at virke. Siden fungerer, feedet virker ikke. Feedet virker ikke, der er ingen trafik. Atmosfæren varmes op. Under pres fra omstændighederne og af mangel på fantasi gik jeg straks til strace og nginx og fandt det, jeg ledte efter. Det viser sig, at dumme nginx på et tidspunkt cachede den omstrejfende 500. fejl som et svar på Yandex get feed.xml. Rettede det ved at tilføje undtagelser til cacheindstillingerne:
Det er tydeligt, at ejeren har brug for MERE, bølgerne stiger langsomt. Vi klarer det nu, men vi begyndte at eksperimentere med memcached på forhånd, heldigvis understøtter Laravel det næsten ud af boksen. Jeg ville på en eller anden måde ikke installere memcached manuelt bare for at "lege rundt", så jeg installerede et docker-billede. Lige fra panelet.
Nå, okay, jeg lyver, jeg var nødt til at gå ind i skallen og installere modulet via pecl. Lige på . Der er endnu ikke noget at sige til stigningen i gennemstrømningen, der har ikke været stor nok tilstrømning. Webstedets motor er tilsluttet localhost:11211, statistik vises, hukommelse forbruges. Hvis du kan lide det, vil vi se, hvad vi skal gøre. Enten lader vi det være sådan, eller også sætter vi den "rigtige" lige i aksen. Eller lad os prøve redis på samme måde
Så var det nødvendigt at vedhæfte en mailingliste. Ingen relæer, kun smtp-godkendelse. Jeg opretter en postadresse og bruger dens oplysninger til at udsende et nyhedsbrev via PHP.
For ikke længe siden blev Plesk Obsidian (18.0) udgivet, vi opdaterede baseret på tidligere erfaringer uden frygt. Alt gik meget glat, der er ikke engang noget at tale om. Det behagelige er, at kvaliteten af grænsefladen er blevet meget forbedret, den er blevet mere moderne og er blevet mere bekvem nogle steder. Fed ting Avanceret overvågning på Grafana.
Jeg har ikke beskæftiget mig med det i detaljer endnu, men du kan for eksempel opsætte advarsler for enhver parameter i din e-mail. Til ejeren, lol.
Mens jeg taler om grænsefladen, er den responsiv og fungerer rigtig godt på telefonen. I de tidlige stadier, mens vi forsøgte at finde de optimale indstillinger for PHP og andre ting, hjalp dette meget. Og især når en programmør i et anfald af arbejdsbegejstring gør noget kl. 23, og jeg i et anfald af arbejdsbegejstring drikker vodka i badehuset, og jeg HAR HURTIG at skifte noget.
Åh, forresten. Billedet viser, at PHP Composer er dukket op. Vi har ikke leget med det endnu, men f.eks. for Laravel kan det spare et par shell-logins og noget tid på at installere afhængigheder. Det samme system findes for Node.JS og Ruby.
Med SSL er alt enkelt. Hvis domænet løser sig som forventet, udføres Let's Encrypt med et enkelt klik og opdaterer derefter sig selv, både for selve domænet og for underdomæner og endda mailtjenester.
Plesk selv som software er i øjeblikket ganske behagelig og stabil. Den opdaterer sig selv og Axis stille og roligt, bruger få ressourcer og fungerer problemfrit. Jeg kan ikke engang huske, at jeg trådte på noget et eller andet sted, hvilket ville have været en åbenlys fejl ved produktet. Der var selvfølgelig problemer, men de skyldtes enten ufuldkommen konfiguration eller et sted ved krydset, så der er ikke noget at klage over. Indtrykket af arbejdet med Plesk er generelt behageligt. Hvad den ikke har, og vi skal forstå dette, er enhver (en hvilken som helst) klyngedannelse. Hverken LB eller HA. Du kan prøve, men indsatsen vil være så stor, at det er bedre at gøre noget anderledes fra begyndelsen.
Jeg tror, vi kan opsummere det. For det tilfælde, hvor der ikke er nogen administrator, eller der ikke er nok af ham, når prisen på hosting og de(t) websted(er), der spinder på det, overstiger, vel, siger, 100 USD, når vi ikke taler om bestial deling på 1500 sites på en server, når beslutningstageren står over for Hvis du har valget mellem at ansætte en deltidsadministrator, eller købe software og have en admin for en halv buck, eller slet ikke have en - det giver helt klart mening. Fra fjernadministratorens synspunkt - det samme. $ 10 om måneden, og sparer tid og giver fleksibilitet i arbejdet i meget lang tidоet større beløb. Hvis jeg for eksempel bliver kraftigt bedt om at tage et lignende projekt under mine vinger, vil jeg insistere på at overføre det til Plesk.
Kilde: www.habr.com