Ek wil graag 'n paar indrukke oor die noodsaaklikheid of onnodigheid van so iets soos 'n beheerpaneel vir 'n kommersiële enkelbediener-webprojek met 'n baie deeltydse administrateur deel. Die storie het 'n paar jaar gelede begin toe vriende van vriende my gevra het om te help met die aankoop van 'n besigheid - 'n nuuswebwerf - vanuit 'n tegniese oogpunt. Dit was nodig om 'n bietjie te delf in wat werk aan wat, seker te maak dat al die nodige besonderhede in die regte vorm en volume oorgedra is, en strategies uit te vind wat verbeter kan word.
Die transaksie is afgehandel, die violis was nie meer nodig nie. Einde. Nie regtig nie.
Die webwerf het op 'n dubbelkern 4-GB VM op Linode gehardloop, op 'n paar mosagtige Debian5 met 'n optyd van 400 dae en so 'n lys van onopgedateerde pakkette. Webdeel op 'n selfgeskrewe CMS, nginx, php5.3 FPM, mysql-gestemde Percona. In beginsel het dit gewerk.
Parallel met gesprekke met my het die nuwe eienaar 'n programmeerder gesoek om die projek na verwagting te bring. Gevind. Die programmeerder het die verkeer en volumes beoordeel en besluit dat hy weet hoe om te optimaliseer en kostebestuur. Hy het die hele webwerf gemigreer na 'n gedeelde hosting van 700 roebel wat deur sy gewone IS****er bestuur word. 'n Paar dae later was daar weer 'n oproep van die eienaar: "Alles is stadig en dit lyk of ons stukkend is." Ek het probeer om die situasie deur die paneel reg te stel, maar na 'n geruime tyd van vrugtelose pogings om die PHP-weergawe of hanteerder van fcgi na fpm te verander, het ek opgegee en in die dop gegaan. Daar het ek 'n geaktiveerde ontfout gevind wat op die hele internet geskyn het met die wagwoord van die spier, 777 op sommige vouers wat teen daardie tyd gekraak het met malware en soortgelyke snert. Die eienaar het besef en besluit dat dit verkeerd is om te bespaar op hosting, 'n programmeerder en 'n admin wat 'n ogie kan hou oor hoe dinge verloop.
Ons gaan RuVDS toe. 'n Bietjie nader as die Britse Linode, en as jy skielik persoonlike data en dit alles wil stoor, sal jy nêrens anders hoef te beweeg nie. Aangesien die projek beplan is om uitgebrei te word, het ons 'n VM vir groei geneem: 4 kerns, 8 gigagrepe geheue, 80 GB skyf. Dit is nie dat ek nie weet hoe om nginx-konfigurasies handmatig op te stel nie, ek het net nie die entoesiasme gehad om so intiem aan hierdie projek te werk nie (sien hierbo oor deeltyds). Dit is hoekom ek Plesk geïnstalleer het (hier sal ek die installasiebesonderhede weglaat, want in die algemeen is daar geen: ek het die installeerder geloods, die wagwoord vir die admin gestel, die sleutel ingevoer - dit is al), op daardie stadium was dit 17.0. Basiese instellings werk verdraagsaam buite die boks, daar is fail2ban en die nuutste beskikbare weergawes van PHP en nginx.
Dit is waarskynlik die moeite werd om te stop en te verduidelik hoekom. Aangesien ek selde sulke dinge doen, en ek nie enige spesiale gereedskap of stel voorbereidings vir elke geval het nie, was dit duidelik dat 'n soort outomatisering van basiese dinge nodig was, sodat eerstens, vinnig, tweedens, veilig en derdens , al die beste praktyke wat iemand dit reeds geïmplementeer het.
So, ek het dit geïnstalleer. Ek het baie tyd gespaar, die herbegin van die werf op 'n nuwe bediener was amper onmiddellik. Al wat oorgebly het, was om die spierkonfigurasie te wysig, dit die helfte van die geheue te gee en die aantal bufferpoele te verhoog, en nginx die helfte van die kerns te gee (Plesk raak nie aan globale konfigurasies nie), en vir 'n paar dae in die dop te gaan om te kyk by die mysqltuner-statistieke. Ja, en ek het die betaalde ImunifyAV uit die uitbreidingskatalogus gekoop om van die oorstroomde wanware ontslae te raak. Sowat 11000 XNUMX besmette lêers is gevind. Die gruwel is dat verduisterde stukke kode in die statika gegooi is, en om dit met die hand skoon te maak, sou heeltemal saai gewees het. Eers het ek ClamAV probeer, maar, soos dit geblyk het, neem dit nie sulke dinge nie, maar ImunifyAV kon. Boonop bly die ontsmette lêers in 'n werkende toestand; die stuk met die wanware word eenvoudig uitgevee.
Die rekenkunde is eenvoudig: $50 per maand vir VMka, $10 vir Plesk (eintlik minder, want jy het dit vir 'n jaar op een slag gekoop met 'n afslag van twee maande) en $3 vir antivirus. Of baie geld vir my tyd, wat ek eers op die bediener sou spandeer het om hierdie stalle met die hand te hark. Die eienaar was baie tevrede met hierdie reëling.
Intussen het hulle 'n nuwe programmeerder gevind. Ons het met hom ooreengekom oor die verdeling van verantwoordelikheid, 'n subdomein vir die toetsweergawe geskep, en werk het begin. Hy was besig om 'n nuwe weergawe van die webwerf op Laravel te sny, en ek het gekyk na fail2ban%).
Interessant genoeg hou die stroom nuuskieriges nie op nie en is daar altyd ongeveer honderd adresse op die lys van verbode adresse. Die effek is interessant: veral, as ek by 'n dop aanmeld, sien ek ongeveer 20000 30000-2 70 onsuksesvolle pogings om via SSH aan te meld by die groet. Met fail0ban aangeskakel, ongeveer 2. Pogings belê: XNUMX. Ongelukkig was dit nie sonder 'n druppel salf nie. By verstek was WAF (modsekuriteit) half-geaktiveer: in ontdekkingsmodus. Dit wil sê, hy het verdagte aktiwiteit in die log geskryf, maar het eintlik niks gedoen nie. En failXNUMXban het onoordeelkundig al die logs gelees, volgens die geaktiveerde tronke, en alles doodgemaak wat beweeg het. So, ons het die helfte van die redakteurs verban :D. Ek moes hierdie tronk deaktiveer en die nodige IP-adresse witlys vir betroubaarheid. Pogings word belê: druk twee keer met die muis en leer die redakteurs om jou IP-adres te vertel.
Waarvan die programmeerder dadelik gehou het, was die vermoë om databasisse direk in die paneel op te laai en vinnige toegang tot phpMyAdmin
Wat ek gehou het, was die logs en rugsteun. Logs word geskryf en uit die boks geroteer; Rugsteun is baie maklik om op te stel. Op die stadigste tye word 'n volledige rugsteun gemaak, ongeveer 10 gigs, en dan elke dag 'n inkrementele een, 200 megagrepe elk, vir 'n week. Herstel is korrelig, tot by 'n spesifieke lêer of databasis. As jy van 'n inkrementele een moet herstel, dan hoef jy nie eers moeite te doen met 'n volledige en herstel van die hele ketting nie, Plesk doen alles self. Jy kan rugsteun enige plek oplaai: na FTP, dropbox, s3 bucket, Google Drive, ens.
Dag F: die programmeerder het uiteindelik die nuwe enjin voltooi, ons het dit na produksie opgelaai, ou data ingevoer en gaan sit om die kleur van ons toekomstige Maserati te kies. Ons sit nog en kies.
Die eerste probleme het begin. Die nuwe webwerf was na verwagting swaarder as die ou een, maar die eintlike hark was dat hulle onder meer Yandex.Zen gebruik het om verkeer te lok, wat hope besoekers ingebring het. Die webwerf het neergestort met 150 gelyktydige verbindings (ek praat nie van RPS nie, want hulle het dit nie gemeet nie). Ons het begin om knoppies te steek en knoppies te draai in die php_fpm-instellingsarea:
Haai, hy het reeds 500 verbindings. Namate kredietkaarte by die bevorderingsmiddel gevoeg is, het die verkeersgolwe groter geword. Die volgende mylpaal is 1000 gelyktydige verbindings. Hier moes ons die kode verfyn en in die siel van die spier kyk. Die gespat het nie gehelp nie, maar ons het dit nie regtig verwag nie. Ons het stadige navrae-logboek geaktiveer, indekse by die databasis gevoeg, onnodige navrae uit die kode verwyder, en weereens die mysql-konfigurasie skoongemaak volgens die advies van mysqltuner.
Nuwe uitdaging - 2000 verbindings. Die weergawe van Plesk 17.8 kon pas vrygestel word, waarin onder meer nginx-kas bygevoeg is. Opgedateer (verbasend maklik). Kom ons probeer. Werk! En toe trap hulle op die sagte kant, die Yandex.Zen-voer het opgehou werk. Die webwerf werk, die voer werk nie. Die voer werk nie, daar is geen verkeer nie. Die atmosfeer word warm. Onder druk van omstandighede en van 'n gebrek aan verbeelding het ek dadelik na strace en nginx gegaan en gevind waarna ek gesoek het. Dit blyk dat op 'n sekere punt dom nginx die verdwaalde 500ste fout gekas het as 'n reaksie op Yandex get feed.xml. Het dit reggestel deur uitsonderings by die kasinstellings by te voeg:
Dit is duidelik dat die eienaar MEER nodig het, die golwe neem stadig toe. Ons hanteer vir eers, maar ons het vooraf met memcached begin eksperimenteer, gelukkig ondersteun Laravel dit amper uit die boks. Ek wou op een of ander manier nie memcached handmatig installeer net om te "rondspeel", so ek het 'n docker-beeld geïnstalleer. Reguit van die paneel af.
Wel, goed, ek lieg, ek moes in die dop ingaan en die module installeer via pecl. Reg so . Daar is nog niks te sê oor die toename in deurset nie; daar was nie groot genoeg instrome nie. Die webwerf-enjin is gekoppel aan localhost:11211, statistieke word gewys, geheue word verbruik. As jy daarvan hou, sal ons sien wat om volgende te doen. Óf ons sal dit so los, óf ons sal die "regte" een reg in die As plaas. Of kom ons probeer redis op dieselfde manier
Toe was dit nodig om 'n poslys aan te heg. Geen relais nie, slegs smtp-verifikasie. Ek stel 'n posadres op en gebruik die besonderhede daarvan om 'n nuusbrief via PHP uit te stuur.
Nie lank gelede nie Plesk Obsidian (18.0) vrygestel is, ons het opgedateer op grond van vorige ervaring sonder vrees. Alles het baie glad verloop, daar is nie eers iets om oor te praat nie. Die aangename ding is dat die kwaliteit van die koppelvlak baie verbeter het, dit het meer modern geword en op sommige plekke geriefliker geword. Cool ding Gevorderde monitering op Grafana.
Ek het dit nog nie in detail behandel nie, maar jy kan byvoorbeeld waarskuwings vir enige parameter in jou e-pos opstel. Aan die eienaar, lol.
Terwyl ek oor die koppelvlak praat, reageer dit en werk dit baie goed op die telefoon. In die vroeë stadiums, terwyl ons probeer het om die optimale instellings vir PHP en ander dinge te vind, het dit baie gehelp. En veral wanneer 'n programmeerder, in 'n vlaag van werkentoesiasme, iets om 23:XNUMX doen, en ek, in 'n vlaag van werkentoesiasme, vodka in die badhuis drink, en ek moet DRINGEND iets verander.
O, terloops. Die prentjie wys dat PHP Composer verskyn het. Ons het nog nie daarmee gespeel nie, maar, sê, vir Laravel kan dit 'n paar dop-aanmeldings bespaar en 'n bietjie tyd om afhanklikhede te installeer. Dieselfde stelsel bestaan vir Node.JS en Ruby.
Met SSL is alles eenvoudig. As die domein oplos soos verwag, word Let's Encrypt in een klik gedoen en dit dan opdateer, beide vir die domein self, en vir subdomeine, en selfs posdienste.
Plesk self as 'n sagteware is tans redelik aangenaam en stabiel. Dit werk homself en die As stil op, verbruik min hulpbronne en werk glad. Ek kan nie eers onthou dat ek iewers op iets getrap het nie, wat 'n ooglopende defek in die produk sou wees. Daar was natuurlik probleme, maar dit was óf as gevolg van onvolmaakte konfigurasie óf iewers by die aansluiting, so daar is niks om oor te kla nie. Die indrukke om met Plesk te werk is oor die algemeen aangenaam. Wat dit nie het nie, en ons moet dit verstaan, is enige (enige) groepering. Nie LB of HA nie. Jy kan probeer, maar die moeite wat daaraan verbonde is, sal soveel wees dat dit beter is om van die begin af iets anders te doen.
Ek dink ons kan dit opsom. Vir die geval wanneer daar geen administrateur is nie, of daar is nie genoeg van hom nie, wanneer die prys van hosting en die werf (s) wat daarop draai, meer as, wel, sê, 100 USD, wanneer ons nie praat oor dierlike deel van 1500 webwerwe op 'n bediener, wanneer die besluitnemer gekonfronteer word met As jy die keuse het om 'n deeltydse admin te huur, of sagteware te koop en 'n admin vir 'n halwe dollar te hê, of glad nie een te hê nie - dit maak beslis sin. Uit die oogpunt van die afgeleë administrateur - dieselfde ding. $10 per maand, en bespaar tyd en gee buigsaamheid in werk vir 'n baie lang tydо'n groter bedrag. As ek byvoorbeeld sterk gevra word om 'n soortgelyke projek onder my vlerk te neem, sal ek daarop aandring om dit na Plesk oor te dra.
Bron: will.com