Jeg vil dele nogle indtryk om nødvendigheden eller unødvendigheden af en kontrolpanel til et kommercielt enkeltserver-webprojekt, når man har en meget deltidsadministrator. Historien begyndte for et par år siden, da bekendte bad mig om at overvåge købet af en virksomhed — en nyhedsside — fra en teknisk synsvinkel. Jeg skulle lige sætte mig ind i, hvad der kørte på hvad, sørge for at alle nødvendige oplysninger blev overført korrekt og strategisk overveje, hvad der kunne forbedres.
Handlen blev gennemført, og violinisten blev ikke længere nødvendig. Slut. Eller rettere sagt, ikke helt.
Siden kørte på en dual-core 4 GB VM hos Linode, på en gammeldags Debian5 med en oppetid på 400 dage og en liste af uopdaterede pakker, der var ret lang. Web-delen var bygget på et skræddersyet CMS, nginx, php5.3 FPM, MySQL optimeret med Percona. Det fungerede i princippet.
Samtidig med samtalerne med mig ledte den nye ejer efter en programmør til at tilpasse projektet til forventningerne. Han fandt en. Programmøren vurderede trafikken og omfanget og mente, at han kunne optimere og håndtere omkostninger. Han migrerede hele siden til et 700-russisk rubel delt hosting under styring af den IS****er, han var vant til. Efter et par dage fik jeg igen et opkald fra ejeren: "det hele er langsomt, og det virker som om, vi er blevet hacket." Jeg forsøgte at løse situationen gennem panelet, men efter flere tidspunkter af forgæves forsøg på at ændre PHP-versionen eller håndteringen fra fcgi til fpm gav jeg op og gik ind i shell. Der fandt jeg åbnet debug-genstanden, som lyste op med MySQL-adgangskoden til hele internettet, 777 på nogle mapper, der på det tidspunkt knagede under malware-fyld, og lignende skandaløse ting. Ejeren indså, at det var forkert at spare på hosting, programmering og en administrator, der kunne holde et øje med, hvordan det gik.
Vi tager på RuVDS. Lidt tættere end britiske Linode, og hvis man pludselig ønsker at gemme personlige data og alt det der, skal man ikke flytte mere. Da projektet skulle udvides, tog vi en VM "til vækst": 4 kerner, 8 GB RAM, 80 GB disk. Ikke at jeg ikke kan håndtere nginx-konfigurationer manuelt, men jeg havde bare ikke entusiasme til at arbejde så intimt med dette projekt (se ovenfor om part-time). Derfor installerede jeg Plesk (her vil jeg undlade detaljerne om installationen, fordi der ikke i virkeligheden er nogen: jeg kørte installatøren, satte et password til admin, indtastede nøglen – alt sammen), dengang var det version 17.0. De grundlæggende indstillinger fungerer rimeligt ud af boksen, der er fail2ban og de nyeste tilgængelige versioner af PHP, nginx.
Måske er det værd at stoppe op og forklare, hvorfor det er sådan. Da jeg sjældent beskæftiger mig med sådan noget, og jeg ikke har et særligt værktøj eller en samling skabeloner til hver situation, var det klart, at der var brug for en form for automatisering af de grundlæggende ting, så man for det første kan gøre det hurtigt, for det andet sikkert og for det tredje, at nogen allerede har implementeret alle best practices.
Så jeg installerede det. Jeg sparede en del tid, og genstart af hjemmesiden på den nye server skete nærmest øjeblikkeligt. Det var kun tilbage at justere mysql-konfigurationen, give den halvdelen af hukommelsen og øge antallet af buffer pools, samt give nginx halvdelen af kernerne (Plesk ændrer ikke de globale konfigurationer), og i løbet af et par dage kigge ind i shell for at se på mysqltuner-statistikkerne. Ja, og jeg købte den betalte ImunifyAV fra udvidelseskataloget for at slippe af med det uploadede malware. Der var fundet omkring 11000 inficerede filer. Det ulækre var, at obfuskerede kodebidder flød ind i statisk indhold, og at rense det manuelt ville være temmelig kedeligt. Først prøvede jeg ClamAV, men det kunne ikke tage de ting, mens ImunifyAV kunne. Desuden forbliver de helbredte filer i funktionsdygtig stand, kun delen med malware fjernes.
Aritmetikken er enkel: 50$ om måneden for VM'en, 10$ for Plesk (faktisk mindre, fordi vi købte det med det samme for et år med rabat på to måneder) og 3$ for antivirus. Eller mange kufferter med penge for min tid, som jeg ville have brugt på serveren i starten på at ordne disse staldlignende problemer manuelt. Ejeren var helt tilfreds med den ordning.
Imens de fandt en ny programmør. Vi blev enige med ham om fordelingen af ansvar, lavede et subdomæne til testversionen, og arbejdet gik i gang. Han kodede den nye version af hjemmesiden i Laravel, mens jeg holdt øje med fail2ban%).
Det er interessant, at strømmen af nysgerrige ikke stopper, og der er altid omkring hundrede adresser på listen over de banned. Effekten er interessant: typisk, når jeg går ind i shell, ser jeg omkring 20000-30000 mislykkede SSH-loginforsøg. Med fail2ban tændt er det omkring 70. Indsatsen der: 0. Desværre var der ikke helt uden skygger. Som standard var WAF'en (modsecurity) 'halvaktiveret': i detektormodus. Det vil sige, at det skrev mistænkelig aktivitet i loggen, men faktisk ikke foretog sig noget. Og fail2ban læste uden skilsmisse alle logs ifølge de aktiverede jail, og forbød alt, der bevægede sig. Sådan banede vi halvdelen af redaktionen :D. Jeg var nødt til at deaktivere denne jail, og for sikkerhedens skyld sætte de nødvendige IP-adresser på hvidlisten. Indsatsen var: to gange klik med musen og lære redaktørerne at angive deres IP-adresse.
Det, som programmøren straks kunne lide — muligheden for at uploade databaser direkte i panelet og hurtig adgang til phpMyAdmin.
Hvad jeg kunne lide — logs og backups. Logs skrives og roteres automatisk; backups kan sættes meget enkelt op. På de mest stille tidspunkter laves der en fuld backup, omkring 10 gigabytes, og derefter dagligt en inkrementel, omkring 200 megabytes, i løbet af en uge. Gendannelse er granulær, ned til en specifik fil eller database. Hvis du skal gendanne fra den inkrementelle, behøver du ikke først at bøvle med den fulde og gendanne hele kæden, Plesk gør alt selv. Du kan uploade backups hvor som helst: til ftp, til dropbox, s3 bucket, google drive og mere.
Dagen D: programmøren fik endelig færdiggjort den nye engine, vi uploadede den til produktion, importerede de gamle data og satte os til at vælge farven på vores fremtidige Maserati. Vi sidder stadig og vælger.
De første problemer begyndte. Den nye hjemmeside var som forventet tungere end den gamle, men det reelle problem var, at trafik tiltrækkedes blandt andet ved hjælp af Yandex.Zen, som bragte besøgende i store mængder. Hjemmesiden knækkede ved 150 samtidige forbindelser (jeg nævner ikke RPS, fordi vi ikke målte). Vi begyndte at trykke på knapperne og justere indstillingerne i php_fpm:
Åh, nu kan den klare 500 forbindelser. Efterhånden som kreditkortet blev påført markedsføringsmidlerne, blev trafikstrømmene større. Næste milestone: 1000 samtidige forbindelser. Her måtte vi refinere koden og kigge dybt i muskelens sjæl. Plesk hjalp ikke rigtig, men det var heller ikke forventet. Vi aktiverede slow queries log, tilføjede indekser til databasen, fjernede unødvendige forespørgsler fra koden, og finjusterede mysql-konfigurationen baseret på mysqltuner-anbefalingerne.
En ny udfordring — 2000 forbindelser. Version 17.8 af Plesk blev netop udgivet, som blandt andet inkluderede nginx caching. Vi opdaterede (til vores overraskelse ret nemt). Vi tester. Det virker! Og så stoppede Yandex.Zen-feeden med at fungere. Hjemmesiden virker, men feedet fungerer ikke. Uden feed ingen trafik. Stemningen bliver intens. Under presset og af mangel på fantasi begyndte jeg straks at strace nginx og fandt hvad der skete. Det viste sig, at dumme nginx på et tidspunkt cachede en uforklarlig 500-fejl som svar på en Yandex GET feed.xml. Vi rettede det ved at tilføje undtagelser i cache-indstillingerne:
Det er klart, at ejeren har brug for MEGET MERE, bølgerne stiger gradvist. Vi klarer os indtil videre, men vi begyndte også at eksperimentere med memcached i god tid, godt at Laravel næsten understøtter det out of the box. At installere memcached manuelt for bare at "lege" med det føltes ikke rigtigt, så vi satte Docker-billedet op. Lige fra panelet.
Okay, jeg lyver, jeg måtte gå ind i shell og installere modulet via pecl. Lige fra . At sige noget om bandwidth-øgningen er der ikke meget at sige endnu, da der ikke har været store trafiktoppe. Site-motoren oprettede forbindelse til localhost:11211, statistikker vises, og hukommelsen bruges. Hvis det fungerer godt, ser vi, hvad vi skal gøre næste gang. Enten lader vi det stå, eller som et "rigtigt" installeret system på OS. Eller vi vil forsøge at bruge redis på samme måde.
Derefter var det nødvendigt at tilføje en e-mail-udsendelse. Ingen relays, kun smtp-godkendelse. Jeg oprettede en e-mailadresse, og gennem dens oplysninger sender vi udsendelser via PHP.
For nylig blev Plesk Obsidian (18.0) udgivet, og vi opdaterede uden frygt baseret på tidligere erfaringer. Alt gik meget glat, selvom der ikke er meget at fortælle. Det mest positive er, at grænseflades kvalitet er blevet meget bedre, moderniseret og blevet lettere at bruge på nogle områder. Den avancerede overvågningsfunktion til Grafana er ret cool.
Jeg har ikke dykket dybt ind i den endnu, men det er muligt for eksempel at indstille alarmer for enhver parameter til e-mail. Til ejeren, lol.
Når jeg taler om brugergrænsefladen, er den responsiv og fungerer virkelig godt på telefonen. I de tidlige stadier, da vi forsøgte at finde de optimale PHP-indstillinger og lignende, reddede det os i mange situationer. Især når programmøren i et anfald af arbejdsglæde laver noget kl. 23, mens jeg i et anfald af arbejdsglæde drikker vodka i badet, og det haster virkelig at skifte noget.
Åh, forresten. På billedet kan man se, at PHP Composer er kommet. Vi har ikke leget med det endnu, men lad os sige, at det kan spare et par login i shell og lidt tid til installation af afhængigheder for noget som Laravel. En lignende system findes også til Node.JS og Ruby.
Med SSL er det simpelt. Hvis domænet resolveres korrekt, kan Let’s Encrypt aktiveres med et klik og opdateres automatisk, både til domænet og subdomænerne, samt til e-mailtjenester.
Selve Plesk er i øjeblikket ret behageligt og stabilt som software. Det opdaterer sig selv og sit OS stille, bruger få ressourcer og fungerer præcist. Jeg kan endda ikke huske, at jeg har stødt på noget, der var et åbenlyst produktdefekt. Der har selvfølgelig været problemer, men de skyldes enten fejl i konfigurationen eller problemer med integrationen, så der er ikke meget at kritisere. Mine overordnede indtryk af at arbejde med Plesk er positive. Hvad det ikke har, og det skal man forstå, er al form for (enhver) klustering. Hverken LB eller HA. Man kan forsøge, men det kræver så mange ressourcer, at det vil være bedre at gøre noget anderledes fra starten.
Jeg tror, vi kan opsummere. I tilfælde hvor der ikke er en administrator, eller hvor der kun er lidt tilstedeværelse, når prisen for hosting og de websites, der kører på det (er), overstiger, lad os sige, 100 enheder, når det ikke handler om overfyldte delte servere med 1500 websites, og den beslutningsdygtige person står over for valget om at ansætte en deltidsadministrator, købe software og ansætte en administrator for "halv pris", eller slet ikke ansætte en — så giver det helt sikkert mening. Set fra en fjernadministrators synspunkt — det samme. 10$ om måneden, men det sparer tid og giver fleksibilitet i arbejdet for en stor sum.fleste afHvis jeg f.eks. blev meget bedt om at tage et lignende projekt under mine vinger, ville jeg insistere på at flytte det til Plesk.
Kilde: habr.com
