Ik wil graag wat indrukken delen over de noodzaak of het gebrek aan noodzaak van zoiets als een controlepaneel voor een commercieel webproject met één server en een zeer parttime beheerder. Het verhaal begon een paar jaar geleden, toen vrienden van vrienden me vroegen om de aankoop van een bedrijf - een nieuwssite - vanuit een technisch oogpunt te begeleiden. Het was nodig om me enigszins te verdiepen in wat waar werkt, om ervoor te zorgen dat alle benodigde details in de juiste vorm en omvang werden overgedragen, en om strategisch in te schatten wat er verbeterd kon worden.
De deal was rond, de violist was niet meer nodig. Het einde. Niet echt.
De site draaide op een dual-core VM van 4 GB op Linode, op een of andere zweverige Debian5 met een uptime van 400 dagen en een heeeeeeeeeeel lange lijst met niet-bijgewerkte pakketten. Het webonderdeel draaide op een zelfgemaakt CMS, nginx, php5.3 FPM en mysql geoptimaliseerd door Percona. Kortom, het werkte.
Parallel aan de gesprekken met mij zocht de nieuwe eigenaar een programmeur om het project aan de verwachtingen te laten voldoen. Hij vond er een. De programmeur beoordeelde het verkeer en de volumes en concludeerde dat hij goed was in optimalisatie en kostenbeheer. Hij migreerde de hele site naar een gedeelde hosting van 700 roebel, beheerd door zijn gebruikelijke IS****er. Een paar dagen later belde de eigenaar opnieuw: "Alles is traag en het lijkt erop dat we kapot zijn." Ik probeerde de situatie via het panel op te lossen, maar na een tijdje vruchteloze pogingen om de PHP-versie of de handler van fcgi naar fpm te wijzigen, gaf ik het op en ging ik naar de shell. Daar vond ik de debug-functie ingeschakeld, die het hele internet liet zien met een wachtwoord van Muscle, 777 op een aantal mappen, die inmiddels gekraakt waren door de geüploade malware en soortgelijke troep. De eigenaar realiseerde zich en besloot dat besparen op hosting, een programmeur en een beheerder die de voortgang in de gaten zou houden, verkeerd was.
We gaan naar RuVDS. Het is iets dichterbij dan het Britse Linode, en als je plotseling persoonlijke gegevens en dergelijke wilt opslaan, hoef je nergens anders heen te verhuizen. Omdat het project gepland was om uit te breiden, namen we een virtuele machine "voor groei": 4 cores, 8 GB geheugen, 80 GB schijfruimte. Het is niet dat ik de nginx-configuraties niet handmatig kan bewerken, ik had gewoon niet de motivatie om zo intensief aan dit project te werken (zie hierboven over parttime). Daarom heb ik Plesk geïnstalleerd (ik sla de installatiedetails hier over, want die zijn er niet: ik heb het installatieprogramma gestart, een wachtwoord voor de beheerder ingesteld, de sleutel ingevoerd – dat was alles). Op dat moment was het 17.0. De basisinstellingen werken redelijk goed direct uit de doos, er is fail2ban en de nieuwste versies van PHP en nginx.
Misschien is het de moeite waard om even stil te staan en uit te leggen waarom. Omdat ik dit soort dingen zelden doe en geen speciaal gereedschap of een set blanco documenten voor elk geval heb, was het duidelijk dat er enige automatisering van basiszaken nodig was, zodat het ten eerste snel zou gaan, ten tweede veilig zou zijn, en ten derde alle best practices al door iemand zouden zijn geïmplementeerd.
Dus ik installeerde het. Het bespaarde een behoorlijke hoeveelheid tijd, de site herstartte bijna direct op de nieuwe server. Het enige wat ik nog hoefde te doen was de muscle-configuratie bekijken, die de helft van het geheugen geven en het aantal bufferpools verhogen, en nginx de helft van de cores geven (Plesk raakt globale configuraties niet aan), en een paar dagen in de shell gaan om de mysqltuner-statistieken te bekijken. Oh, en een betaalde ImunifyAV uit de extensiecatalogus kopen om de malware die erin was gegooid te verwijderen. Er waren ongeveer 11000 geïnfecteerde bestanden. Het vervelende is dat er verhulde stukjes code in de statica waren gegoten, en het handmatig opschonen ervan zou compleet saai zijn geweest. Eerst probeerde ik ClamAV, maar het bleek dat dat dit soort dingen niet aankan, terwijl ImunifyAV dat wel kon. Bovendien blijven de herstelde bestanden werken, het stuk met de malware wordt gewoon verwijderd.
De rekensom is simpel: $ 50 per maand voor de virtuele machine, $ 10 voor Plesk (in feite minder, omdat we het in één keer voor een jaar kochten met twee maanden korting) en $ 3 voor het antivirusprogramma. Ofwel een hoop geld voor mijn tijd, die ik anders eerst aan de server had besteed om deze stallen handmatig op te schonen. De eigenaar was erg tevreden met deze regeling.
Ondertussen hadden we een nieuwe programmeur gevonden. We spraken met hem af hoe de verantwoordelijkheden verdeeld zouden worden, maakten een subdomein aan voor de testversie en begonnen met werken. Hij was bezig met een nieuwe versie van de site op Laravel, en ik keek naar fail2ban%).
Het is interessant dat de stroom nieuwsgierige mensen niet stopt en er altijd zo'n honderd adressen op de verboden lijst staan. Het effect is interessant: met name als ik naar de shell ga, zie ik bij de begroeting ongeveer 20000-30000 mislukte pogingen om via SSH in te loggen. Met fail2ban ingeschakeld, ongeveer 70. Geïnvesteerde inspanning: 0. Helaas was er een addertje onder het gras. Standaard was WAF (modsecurity) "half ingeschakeld": in detectiemodus. Dat wil zeggen, het schreef verdachte activiteit naar het logbestand, maar ondernam in feite geen actie. En fail2ban las lukraak alle logbestanden, afhankelijk van de ingeschakelde jails, en doodde alles wat bewoog. Dus hebben we de helft van de redactie verbannen :D. We moesten deze jail uitschakelen en de benodigde IP-adressen toevoegen aan de witte lijst voor betrouwbaarheid. Geïnvesteerde inspanning: twee keer met de muis prikken en de redacteuren leren hun IP-adres te zeggen.
Wat de programmeur meteen leuk vond, was de mogelijkheid om databases direct naar het paneel te uploaden en de snelle toegang tot phpMyAdmin
Wat ik prettig vond, waren de logs en back-ups. Logs worden automatisch geschreven en geroteerd; back-ups zijn heel eenvoudig in te stellen. Tijdens de rustigste periodes wordt er een volledige back-up gemaakt, ergens rond de 10 GB, en daarna elke dag een incrementele back-up van 200 MB, gedurende een week. Granulair herstel, naar een specifiek bestand of database. Als je een incrementele back-up moet herstellen, hoef je je niet bezig te houden met een volledige back-up en een herstel van de hele keten, Plesk doet alles zelf. Je kunt back-ups overal uploaden: naar FTP, Dropbox, S3 Bucket, Google Drive, enzovoort.
Dag G: de programmeur heeft eindelijk de nieuwe motor af, we hebben hem geüpload naar de productieomgeving, de oude gegevens geïmporteerd en zijn gaan zitten om de kleur van onze toekomstige Maserati te kiezen. We zitten er nog steeds over te denken.
De eerste problemen begonnen. De nieuwe site was zoals verwacht zwaarder dan de oude, maar het echte probleem was dat ze, om verkeer aan te trekken, onder andere Yandex.Zen gebruikten, wat bezoekers in grote hoeveelheden aantrok. De site crashte bij 150 gelijktijdige verbindingen (ik heb het niet over RPS, want die hebben we niet gemeten). Ze begonnen aan knoppen te draaien in de php_fpm-instellingen:
Oeps, er staan al 500 verbindingen in. Toen de creditcard werd toegepast op de promotietools, werden de verkeersgolven groter. De volgende mijlpaal is 1000 gelijktijdige verbindingen. Hier moesten we de code verfijnen en in de ziel van de spier kijken. Splash hielp hier niet bij, maar dat hadden we ook niet echt verwacht. We hebben het logbestand voor trage query's ingeschakeld, indexen aan de database gekoppeld, onnodige query's uit de code verwijderd en de MySQL-configuratie nogmaals doorgenomen volgens het advies van MySQL Tuner.
Nieuwe uitdaging — 2000 verbindingen. Plesk 17.8 is net uit, met onder andere nginx-caching. Bijgewerkt (verrassend eenvoudig). Laten we het proberen. Het werkt! En toen stuitten we op iets zachts: de Yandex.Zen-feed stopte met werken. De site werkt, de feed werkt niet. De feed werkt niet, er is geen verkeer. De sfeer is verhit. Onder druk van de omstandigheden en met een gebrek aan verbeeldingskracht ben ik meteen begonnen met het stracen van nginx en vond ik wat ik zocht. Het bleek dat die stomme nginx op een gegeven moment een verdwaalde 500-foutmelding cachede als reactie op Yandex get feed.xml. We hebben dit opgelost door uitzonderingen toe te voegen aan de cache-instellingen:
Het is duidelijk dat de eigenaar MEER nodig heeft, de golven nemen geleidelijk toe. We redden het voorlopig, maar we zijn alvast begonnen met memcached te experimenteren. Gelukkig ondersteunt Laravel het vrijwel direct. We wilden memcached niet handmatig installeren om te "spelen", dus hebben we een docker-image geïnstalleerd. Rechtstreeks vanuit het paneel.
Oké, ik lieg, ik moest de shell ingaan en de module via pecl installeren. Precies. Er valt nog niets te zeggen over de toename in doorvoer, er waren geen voldoende grote influxen. De site engine is aangesloten op localhost:11211, statistieken worden weergegeven en het geheugen wordt opgebruikt. Als het bevalt, zien we wel wat we verder moeten doen. Of we laten het zo, of we installeren de "echte" versie rechtstreeks in de Axis. Of we proberen redis op dezelfde manier.
Vervolgens was het nodig om een mailinglijst toe te voegen. Geen relays, alleen smtp-authenticatie. Ik heb een postadres aangemaakt en via PHP maken we met behulp van de gegevens een mailinglijst.
Plesk Obsidian (18.0) is nog niet zo lang geleden uitgebracht en we hebben zonder zorgen een update uitgevoerd op basis van eerdere ervaringen. Alles verliep heel soepel, daar valt niets over te zeggen. Positief is dat de interface aanzienlijk is verbeterd, gemoderniseerd en op sommige plaatsen gebruiksvriendelijker is geworden. Geavanceerde monitoring op Grafana is een geweldige ontwikkeling.
Ik heb er nog niet in detail naar gekeken, maar je kunt bijvoorbeeld waarschuwingen instellen voor elke parameter in je e-mail. Aan de eigenaar, lol.
Nu ik het over de interface heb: die is adaptief en werkt echt geweldig op de telefoon. In de beginfase, toen we probeerden de optimale PHP-instellingen en dergelijke te vinden, was het een enorme hulp. En vooral wanneer de programmeur, in een vlaag van werklust, om 23 uur iets doet, en ik, in een vlaag van werklust, wodka drink in het badhuis en DRINGEND iets moet veranderen.
Oh, trouwens. Je ziet op de afbeelding dat PHP Composer is verschenen. We hebben er nog niet mee gespeeld, maar laten we zeggen dat het voor dezelfde Laravel een paar keer inloggen in de shell en wat tijd bespaart bij het installeren van dependencies. Hetzelfde systeem bestaat voor Node.JS en Ruby.
Met SSL is alles eenvoudig. Als het domein naar de gewenste locatie verwijst, is Let's Encrypt met één klik klaar en wordt het automatisch bijgewerkt, zowel op het domein zelf als op subdomeinen en zelfs maildiensten.
Plesk zelf is momenteel als software behoorlijk prettig en stabiel. Het werkt zichzelf en het besturingssysteem worden geruisloos bijgewerkt, verbruikt weinig resources en werkt soepel. Ik kan me niet eens herinneren dat ik ergens op iets ben gestapt dat een duidelijk defect van het product zou zijn. Natuurlijk waren er problemen, maar die waren ofwel te wijten aan een imperfecte configuratie, ofwel ergens op het kruispunt, dus er is niets op aan te merken. De indrukken van het werken met Plesk zijn over het algemeen prettig. Wat het mist, en dat moet je begrijpen, is clustering. Noch LB noch HA. Je kunt het proberen, maar de geïnvesteerde inspanning zal zo groot zijn dat het beter is om vanaf het begin iets anders te doen.
Ik denk dat we het kunnen samenvatten. Voor het geval dat er geen of te weinig beheerder is, wanneer de prijs van hosting en de site(s) die erop draaien hoger is dan, laten we zeggen, 100 dollar, wanneer we het niet hebben over een monsterlijke gedeelde server met 1500 sites, wanneer de beslisser de keuze heeft om een parttime beheerder in te huren, of software te kopen en een beheerder voor een "halve kegel" te krijgen, of er helemaal geen te nemen - het is zeker logisch. Vanuit het oogpunt van een beheerder op afstand - hetzelfde. 10 dollar per maand, maar het bespaart tijd en biedt flexibiliteit in het werk op een zeer bоeen groter bedrag. Als ik bijvoorbeeld dringend gevraagd word om een soortgelijk project onder mijn hoede te nemen, zal ik erop staan dat het naar Plesk wordt verplaatst.
Bron: www.habr.com
