Mi ŝatus kunhavigi kelkajn impresojn pri la neceso aŭ neneceso de tia afero kiel kontrolpanelo por komerca unu-servila retprojekto kun tre partatempa administranto. La rakonto komenciĝis antaŭ kelkaj jaroj, kiam amikoj de amikoj petis min helpi en la aĉeto de komerco - novaĵejo - de teknika vidpunkto. Necesis iom enprofundiĝi pri tio, kio funkcias pri kio, certigi, ke ĉiuj necesaj detaloj estas transdonitaj en la taŭga formo kaj volumeno, kaj strategie eltrovi, kio povus esti plibonigita.
La interkonsento estis finita, la violonisto ne plu estis bezonata. Fino. Ne vere.
La retejo funkciis per dukerna 4-GB VM sur Linode, sur iu muska Debian5 kun ĝisdatigo de 400 tagoj kaj tia listo de neĝisdatigitaj pakaĵoj. Retejo sur memskribita CMS, nginx, php5.3 FPM, mysql agordita Percona. Principe ĝi funkciis.
Paralele kun konversacioj kun mi, la nova posedanto serĉis programiston por alporti la projekton al atendoj. Trovita. La programisto taksis la trafikon kaj volumojn kaj decidis, ke li scipovas optimumigi kaj kosti administradon. Li migris la tutan retejon al 700-rubla komuna gastigado administrita de sia kutima IS****er. Kelkajn tagojn poste estis alia voko de la posedanto: "ĉio estas malrapida kaj ŝajnas ke ni rompiĝis." Mi provis korekti la situacion per la panelo, sed post iom da tempo de senfruktaj provoj ŝanĝi la PHP-version aŭ pritraktilon de fcgi al fpm, mi rezignis kaj eniris la ŝelon. Tie mi trovis ebligitan sencimigon, kiu brilis en la tuta Interreto kun la pasvorto el la muskolo, 777 sur kelkaj dosierujoj, kiuj tiam krakis per malware kaj similaj sensencaĵoj. La posedanto rimarkis kaj decidis, ke estas malĝuste ŝpari pri gastigado, programisto kaj administranto, kiu povas observi kiel la aferoj iras.
Ni iras al RuVDS. Iom pli proksime ol la brita Linode, kaj se vi subite volas konservi personajn datumojn kaj ĉion ĉi, vi ne devos movi aliloken. Ĉar la projekto estis planita por esti vastigita, ni prenis VM por kresko: 4 kernoj, 8 gigabajtoj da memoro, 80GB da disko. Ne estas ke mi ne scias kiel mane agordi nginx-agordojn, mi simple ne havis la entuziasmon labori pri ĉi tiu projekto tiel intime (vidu supre pri partatempe). Tial mi instalis Plesk (ĉi tie mi preterlasos la instalajn detalojn, ĉar ĝenerale ne ekzistas: mi lanĉis la instalilon, metis la pasvorton por la administranto, enigis la ŝlosilon - jen ĉio), tiutempe ĝi estis 17.0. Bazaj agordoj funkcias elteneble el la skatolo, ekzistas fail2ban kaj la plej novaj disponeblaj versioj de PHP kaj nginx.
Verŝajne indas halti kaj klarigi kial. Ĉar mi malofte faras tiajn aferojn, kaj mi ne havas specialajn ilojn aŭ aron da preparoj por ĉiu kazo, estis klare, ke necesas ia aŭtomatigo de bazaj aferoj, tiel ke unue, rapide, due, sekure, kaj trie. , ĉiuj plej bonaj praktikoj iu jam efektivigis ĝin.
Do, mi instalis ĝin. Mi ŝparis multan tempon, rekomenci la retejon sur nova servilo estis preskaŭ tuja. Restis nur redakti la muskolajn agordojn, donante al ĝi duonon de la memoro kaj pliigante la nombron da bufrogrupoj, kaj doni al nginx duonon de la kernoj (Plesk ne tuŝas tutmondajn agordojn), kaj dum kelkaj tagoj eniru la ŝelon por rigardi. ĉe la mysqltuner-statistikoj. Jes, kaj mi aĉetis la pagitan ImunifyAV de la katalogo de etendaĵoj por forigi la inundita malware. Proksimume 11000 infektitaj dosieroj estis trovitaj. La abomeno estas, ke malklarigitaj pecoj de kodo estis verŝitaj en la statikon, kaj purigi ĝin permane estintus tute enuiga. Unue mi provis ClamAV, sed, kiel montriĝis, ĝi ne bezonas tiajn aferojn, sed ImunifyAV povus. Krome, la desinfektitaj dosieroj restas en funkcia stato; la peco kun la malbon-varo estas simple forigita.
La aritmetiko estas simpla: $50 monate por VMka, $10 por Plesk (fakte malpli, ĉar vi aĉetis ĝin por jaro samtempe kun dumonata rabato) kaj $3 por antivirus. Aŭ multe da mono por mia tempo, kiun mi unue elspezus sur la servilo, rastante ĉi tiujn stalojn permane. La posedanto estis sufiĉe feliĉa kun ĉi tiu aranĝo.
Intertempe ili trovis novan programiston. Ni konsentis kun li pri la distribuo de respondeco, kreis subdomajnon por la testa versio, kaj la laboro komenciĝis. Li tranĉis novan version de la retejo sur Laravel, kaj mi rigardis fail2ban%).
Interese, la fluo de scivolemuloj ne ĉesas kaj ĉiam estas ĉirkaŭ cent adresoj en la listo de malpermesitaj. La efiko estas interesa: precipe, kutime, se mi ensalutas en ŝelon, mi vidas ĉirkaŭ 20000 30000-2 70 malsukcesajn provojn ensaluti per SSH ĉe la saluto. Kun fail0ban ebligita, ĉirkaŭ 2. Penoj investitaj: XNUMX. Bedaŭrinde, ĝi ne estis sen guto da ungvento. Defaŭlte, WAF (modsekureco) estis duone ebligita: en malkovra reĝimo. Tio estas, li skribis suspektindan agadon al la protokolo, sed fakte faris neniun agon. Kaj failXNUMXban sendistinge legis ĉiujn protokolojn, laŭ la ebligitaj malliberejoj, kaj mortigis ĉion, kio moviĝis. Tiel, ni malpermesis duonon de la redaktoroj :D. Mi devis malŝalti ĉi tiun malliberejon, kaj enlistigi la necesajn IP-adresojn por fidindeco. Penoj estas investitaj: piku la muson dufoje kaj instruu la redaktorojn diri al vi vian IP-adreson.
Kion la programisto tuj ŝatis estis la kapablo alŝuti datumbazojn rekte en la panelon kaj rapidan aliron al phpMyAdmin
Kion mi ŝatis estis la protokoloj kaj sekurkopioj. Registroj estas skribitaj kaj turnitaj el la skatolo; Sekurkopioj estas tre facile instaleblaj. En la plej malrapidaj tempoj, plena sekurkopio estas farita, proksimume 10 gigoj, kaj tiam ĉiutage pliiga unu, po 200 megabajtoj, dum semajno. Reakiro estas granula, malsupren al specifa dosiero aŭ datumbazo. Se vi bezonas restarigi de pliiga, tiam vi ne bezonas ĝeni unue kun plena kaj restarigo de la tuta ĉeno, Plesk faras ĉion mem. Vi povas alŝuti sekurkopiojn ie ajn: al FTP, dropbox, s3 sitelo, google drive, ktp.
Tago F: la programisto finfine kompletigis la novan motoron, ni alŝutis ĝin al produktado, importis malnovajn datumojn kaj sidiĝis por elekti la koloron de nia estonta Maserati. Ni ankoraŭ sidas kaj elektas.
La unuaj problemoj komenciĝis. La nova retejo estis atendite pli peza ol la malnova, sed la vera raketo estis ke por altiri trafikon ili uzis, interalie, Yandex.Zen, kiu alportis amasojn da vizitantoj. La retejo kraŝis kun 150 samtempaj konektoj (mi ne parolas pri RPS, ĉar ili ne mezuris ĝin). Ni komencis piki butonojn kaj turni butonojn en la areo de agordoj de php_fpm:
He, li jam havas 500 rilatojn. Ĉar kreditkartoj estis aldonitaj al la rimedoj de reklamado, la ondoj de trafiko iĝis pli grandaj. La sekva mejloŝtono estas 1000 samtempaj konektoj. Ĉi tie ni devis refini la kodon kaj rigardi en la animon de la muskolo. La plaŭdado ne helpis, sed ni ne vere atendis ĝin. Ni ebligis protokolon de malrapidaj demandoj, aldonis indeksojn al la datumbazo, forigis nenecesajn demandojn de la kodo kaj denove purigis la mysql-agordon laŭ la konsilo de mysqltuner.
Nova defio - 2000 rilatoj. La versio de Plesk 17.8 ĵus sukcesis esti liberigita, en kiu, interalie, nginx kaŝmemoro estis aldonita. Ĝisdatigita (surprize facila). Ni provu. Verkoj! Kaj tiam ili paŝis sur la mola flanko, la Yandex.Zen-fluo ĉesis funkcii. La retejo funkcias, la feed ne funkcias. La nutrado ne funkcias, ne estas trafiko. La atmosfero varmiĝas. Sub premo de cirkonstancoj kaj pro manko de imago, mi tuj iris al strace kaj nginx kaj trovis tion, kion mi serĉis. Rezultas, ke iam stulta nginx kaŝmemorigis la devagan 500-an eraron kiel respondon al Yandex get feed.xml. Riparis ĝin aldonante esceptojn al la kaŝmemoraj agordoj:
Estas klare, ke la posedanto bezonas PLI, la ondoj malrapide pliiĝas. Ni eltenas nuntempe, sed ni komencis eksperimenti kun memcached anticipe, feliĉe Laravel subtenas ĝin preskaŭ el la skatolo. Mi iel ne volis instali memcached permane nur por "ludi", do mi instalis docker-bildon. Rekte de la panelo.
Nu, bone, mi mensogas, mi devis eniri la ŝelon kaj instali la modulon per pecl. Ĝuste . Ankoraŭ estas nenio por diri pri la pliiĝo de trafluo; ne estis sufiĉe grandaj enfluoj. La retejo-motoro estas kunligita al localhost:11211, statistikoj estas montritaj, memoro estas konsumita. Se vi ŝatas ĝin, ni vidos kion fari poste. Aŭ ni lasos ĝin tiel, aŭ ni metos la "realan" ĝuste en la Akso. Aŭ ni provu redis same
Tiam estis necese kunsendi dissendolisto. Neniuj relajsoj, nur smtp-aŭtentigo. Mi starigis retpoŝtadreson kaj uzas ĝiajn detalojn por sendi bultenon per PHP.
Antaŭ nelonge Plesk Obsidian (18.0) estis publikigita, ni ĝisdatigis laŭ pasinta sperto sen timo. Ĉio iris tre glate, eĉ ne estas io por priparoli. La agrabla afero estas, ke la kvalito de la interfaco multe pliboniĝis, ĝi fariĝis pli moderna kaj pli oportuna kelkloke. Mirinda afero Altnivela Monitorado sur Grafana.
Mi ankoraŭ ne pritraktis ĝin detale, sed vi povas, ekzemple, agordi atentigojn por iu ajn parametro en via retpoŝto. Al la posedanto, lol.
Dum mi parolas pri la interfaco, ĝi estas respondema kaj funkcias tre bone ĉe la telefono. En la fruaj stadioj, dum ni provis trovi la optimumajn agordojn por PHP kaj aliaj aferoj, ĉi tio multe helpis. Kaj precipe kiam programisto, en labora entuziasmo, faras ion je la 23:XNUMX, kaj mi, en labora entuziasmo, trinkas vodkon en la banejo, kaj mi URGENTE bezonas ŝanĝi ion.
Ho, cetere. La bildo montras, ke PHP Composer aperis. Ni ankoraŭ ne ludis kun ĝi, sed, ekzemple, por Laravel, ĝi povas ŝpari kelkajn ŝelajn ensalutojn kaj iom da tempo por instali dependecojn. La sama sistemo ekzistas por Node.JS kaj Ruby.
Kun SSL ĉio estas simpla. Se la domajno solvas kiel atendite, Ni Ĉifri estas farita per unu klako kaj poste ĝisdatigas sin, kaj por la domajno mem, kaj por subdomajnoj, kaj eĉ poŝtaj servoj.
Plesk mem kiel programaro estas nuntempe sufiĉe agrabla kaj stabila. Ĝi ĝisdatigas sin kaj la Akso kviete, konsumas malmultajn rimedojn kaj funkcias glate. Mi eĉ ne memoras, ke mi ie paŝis ion, kio estus evidenta difekto en la produkto. Estis problemoj, kompreneble, sed ili estis aŭ pro neperfekta agordo aŭ ie ĉe la krucvojo, do estas nenio por plendi. La impresoj pri laboro kun Plesk estas ĝenerale agrablaj. Kion ĝi ne havas, kaj ni devas kompreni ĉi tion, estas ajna (ajna) amasiĝo. Nek LB nek HA. Vi povas provi, sed la klopodo implikita estos tiom, ke estas pli bone fari ion alimaniere ekde la komenco.
Mi pensas, ke ni povas resumi ĝin. Por la kazo kiam mankas administranto, aŭ ne sufiĉas de li, kiam la prezo de gastigado kaj la retejo(j) turniĝanta(j) sur ĝi superas, nu, ekzemple, 100 USD, kiam ni ne parolas pri besta kundivido de 1500. retejoj sur servilo, kiam la decidanto alfrontas Se vi havas la elekton dungi partatempan administranton, aŭ aĉeti programaron kaj havi administranton kontraŭ duona dolaro, aŭ tute ne havi tian - certe havas sencon. El la vidpunkto de la fora administranto - la sama afero. $10 monate, kaj ŝparas tempon kaj donas flekseblecon en laboro por tre longa tempoоpli granda kvanto. Se, ekzemple, oni forte petas min preni similan projekton sub mia flugilo, mi insistos transdoni ĝin al Plesk.
fonto: www.habr.com