M'agradaria compartir algunes impressions sobre la necessitat o innecessitat d'un tauler de control per a un projecte web comercial d'un sol servidor amb un administrador a temps parcial. La història va començar fa un parell d'anys, quan amics d'amics em van demanar que col·laborés en la compra d'un negoci -un lloc de notícies- des d'un punt de vista tècnic. Calia aprofundir una mica en què estava treballant en què, assegurar-se que tots els detalls necessaris es transferien en la forma i el volum adequats i esbrinar estratègicament què es podia millorar.
El tracte es va completar, el violinista ja no era necessari. Final. No realment.
El lloc funcionava amb una màquina virtual de 4 GB de doble nucli a Linode, en una Debian5 molsa amb un temps d'activitat de 400 dies i una llista de paquets no actualitzats. Part web en un CMS escrit per si mateix, nginx, php5.3 FPM, mysql ajustat a Percona. En principi, va funcionar.
Paral·lelament a les converses amb mi, el nou propietari buscava un programador per portar el projecte a les expectatives. Trobat. El programador va avaluar el trànsit i els volums i va decidir que sabia optimitzar i gestionar els costos. Va migrar tot el lloc a un allotjament compartit de 700 rubles gestionat pel seu IS****er habitual. Uns dies més tard hi va haver una altra trucada del propietari: "Tot va lent i sembla que ens hem trencat". Vaig intentar corregir la situació a través del tauler, però després d'un temps d'intents infructuosos de canviar la versió o el gestor de PHP de fcgi a fpm, vaig rendir-me i vaig entrar al shell. Allà vaig trobar una depuració habilitat que brillava a tot Internet amb la contrasenya del múscul, 777 en unes carpetes que en aquell moment estaven trencant amb programari maliciós i tonteries semblants. El propietari es va adonar i va decidir que era incorrecte estalviar en allotjament, un programador i un administrador que pogués vigilar com anaven les coses.
Anem a RuVDS. Una mica més a prop que el British Linode, i si de sobte voleu emmagatzemar dades personals i tot això, no us haureu de moure a cap altre lloc. Com que el projecte estava previst que s'ampliés, vam agafar una màquina virtual per créixer: 4 nuclis, 8 gigabytes de memòria, 80 GB de disc. No és que no sé com configurar manualment les configuracions de nginx, simplement no tenia l'entusiasme per treballar en aquest projecte tan íntimament (vegeu més amunt sobre temps parcial). És per això que vaig instal·lar Plesk (aquí ometré els detalls de la instal·lació, perquè en general no n'hi ha: vaig llançar l'instal·lador, vaig establir la contrasenya per a l'administrador, vaig introduir la clau, això és tot), en aquell moment era 17.0. La configuració bàsica funciona de manera tolerable des de la caixa, hi ha fail2ban i les últimes versions disponibles de PHP i nginx.
Probablement val la pena aturar-se i explicar per què. Com que poques vegades faig aquestes coses, i no tinc cap eina especial ni un conjunt de preparacions per a cada cas, estava clar que calia algun tipus d'automatització de les coses bàsiques, de manera que en primer lloc, ràpidament, en segon lloc, amb seguretat i en tercer lloc. , totes les bones pràctiques que algú ja l'ha implementat.
Per tant, el vaig instal·lar. Vaig estalviar molt de temps, reiniciar el lloc en un nou servidor va ser gairebé instantani. Només quedava editar la configuració del múscul, donant-li la meitat de la memòria i augmentant el nombre de grups de memòria intermèdia, i donar a nginx la meitat dels nuclis (Plesk no toca les configuracions globals) i durant un parell de dies entrar a l'intèrpret d'ordres per mirar. a les estadístiques de mysqltuner. Sí, i vaig comprar l'ImunifyAV de pagament del catàleg d'extensions per desfer-me del programari maliciós inundat. S'han trobat uns 11000 fitxers infectats. L'abominació és que es van abocar fragments de codi ofuscats a l'estàtica, i netejar-lo a mà hauria estat completament avorrit. Primer vaig provar ClamAV, però, com va resultar, no calen aquestes coses, però ImunifyAV podria. A més, els fitxers desinfectats romanen en condicions de funcionament; la peça amb el programari maliciós simplement s'elimina.
L'aritmètica és senzilla: 50 dòlars al mes per a VMka, 10 dòlars per a Plesk (en realitat menys, perquè l'heu comprat durant un any alhora amb un descompte de dos mesos) i 3 dòlars per a l'antivirus. O molts diners per al meu temps, que hauria gastat al servidor al principi, rastrejant aquests estables manualment. El propietari estava molt content amb aquest acord.
Mentrestant, van trobar un nou programador. Vam acordar amb ell la distribució de responsabilitats, vam crear un subdomini per a la versió de prova i vam començar a treballar. Estava tallant una nova versió del lloc a Laravel, i jo estava mirant fail2ban%).
Curiosament, el flux de curiosos no s'atura i sempre hi ha un centenar d'adreces a la llista de prohibides. L'efecte és interessant: en particular, en general, si entro a un shell, veig uns 20000-30000 intents infructuosos d'iniciar sessió mitjançant SSH a la salutació. Amb fail2ban activat, uns 70. Esforços invertits: 0. Malauradament, no va ser sense una gota d'ungüent. Per defecte, WAF (modsecurity) estava mig habilitat: en mode de descobriment. És a dir, va escriure activitat sospitosa al registre, però en realitat no va prendre cap acció. I fail2ban va llegir indistintament tots els registres, segons les presons habilitades, i va matar tot el que es mogués. Així, vam prohibir la meitat dels editors :D. Vaig haver de desactivar aquesta presó i incloure a la llista blanca les adreces IP necessàries per fiabilitat. S'inverteixen esforços: pica el ratolí dues vegades i ensenya als editors a dir-te la teva adreça IP.
El que va agradar immediatament al programador va ser la possibilitat de pujar bases de dades directament al tauler i un accés ràpid a phpMyAdmin
El que em va agradar van ser els registres i les còpies de seguretat. Els registres s'escriuen i giren fora de la caixa; Les còpies de seguretat són molt fàcils de configurar. En els moments més lents, es fa una còpia de seguretat completa, uns 10 concerts, i després cada dia una incremental, de 200 megabytes cadascuna, durant una setmana. La recuperació és granular, fins a un fitxer o una base de dades específics. Si necessiteu una restauració incremental, no cal que us molesteu primer amb una restauració completa i completa de tota la cadena, Plesk ho fa tot ell mateix. Podeu carregar còpies de seguretat a qualsevol lloc: a FTP, dropbox, s3 bucket, google drive, etc.
Dia F: el programador finalment va completar el nou motor, el vam penjar a producció, vam importar dades antigues i ens vam asseure a escollir el color del nostre futur Maserati. Encara estem asseguts i triant.
Van començar els primers problemes. S'esperava que el nou lloc fos més pesat que l'antic, però el veritable rastell va ser que per atreure trànsit van utilitzar, entre altres coses, Yandex.Zen, que va atraure un munt de visitants. El lloc es va estavellar amb 150 connexions simultànies (no parlo de RPS, perquè no ho van mesurar). Vam començar a picar botons i girar els botons a l'àrea de configuració de php_fpm:
Ei, ja té 500 connexions. A mesura que s'hi van afegir targetes de crèdit als mitjans de promoció, les onades de trànsit es van fer més grans. La següent fita són 1000 connexions simultànies. Aquí vam haver d'acabar el codi i mirar l'ànima del múscul. Les esquitxades no van ajudar, però realment no ens ho esperàvem. Vam habilitar el registre de consultes lentes, vam afegir índexs a la base de dades, vam eliminar consultes innecessàries del codi i vam tornar a netejar la configuració de mysql segons els consells de mysqltuner.
Nou repte: 2000 connexions. S'acaba de llançar la versió de Plesk 17.8, a la qual, entre altres coses, s'hi va afegir la memòria cau nginx. Actualitzat (sorprenentment fàcil). Anem a provar. Funciona! I després van trepitjar el costat tou, el feed Yandex.Zen va deixar de funcionar. El lloc funciona, el feed no funciona. El feed no funciona, no hi ha trànsit. L'atmosfera s'està escalfant. Sota la pressió de les circumstàncies i per la falta d'imaginació, vaig anar immediatament a Strace i nginx i vaig trobar el que buscava. Resulta que en algun moment l'estúpid nginx va guardar a la memòria cau l'error 500 perdut com a resposta a Yandex get feed.xml. S'ha solucionat afegint excepcions a la configuració de la memòria cau:
Està clar que el propietari necessita MÉS, les onades van augmentant lentament. De moment, estem fent front, però vam començar a experimentar amb memcached per endavant, afortunadament Laravel ho admet gairebé fora de la caixa. D'alguna manera no volia instal·lar Memcached manualment només per "jugar", així que vaig instal·lar una imatge Docker. Directament des del panell.
Bé, d'acord, estic mentint, vaig haver d'entrar al shell i instal·lar el mòdul mitjançant pecl. A la dreta . Encara no hi ha res a dir sobre l'augment del rendiment; no hi ha hagut afluències prou grans. El motor del lloc està connectat a localhost:11211, es mostren les estadístiques, la memòria s'està consumint. Si us agrada, veurem què fem a continuació. O ho deixarem així, o posarem el "real" just a l'Eix. O provem redis de la mateixa manera
Aleshores calia adjuntar una llista de correu. Sense relés, només autenticació smtp. He configurat una adreça de correu i faig servir les seves dades per enviar un butlletí mitjançant PHP.
No fa gaire que es va llançar Plesk Obsidian (18.0), vam actualitzar-nos en funció de l'experiència passada sense por. Tot va anar molt bé, ni tan sols hi ha res a parlar. El més agradable és que la qualitat de la interfície ha millorat molt, s'ha tornat més moderna i s'ha tornat més convenient en alguns llocs. Cosa genial Monitorització avançada a Grafana.
Encara no ho he tractat amb detall, però podeu, per exemple, configurar alertes per a qualsevol paràmetre del vostre correu electrònic. Al propietari, lol.
Tot i que parlo de la interfície, és sensible i funciona molt bé al telèfon. En les primeres etapes, mentre estàvem intentant trobar la configuració òptima per a PHP i altres coses, això va ajudar molt. I sobretot quan un programador, amb un atac d'entusiasme laboral, fa alguna cosa a les 23:XNUMX, i jo, amb un atac d'entusiasme laboral, bec vodka als banys, i URGENT necessito canviar alguna cosa.
Oh, per cert. La imatge mostra que ha aparegut PHP Composer. Encara no hi hem jugat, però, per exemple, per a Laravel, pot estalviar un parell d'inicis de sessió d'intèrpret d'ordres i una mica de temps per instal·lar dependències. El mateix sistema existeix per a Node.JS i Ruby.
Amb SSL tot és senzill. Si el domini es resol com s'esperava, Let's Encrypt es fa amb un sol clic i després s'actualitza, tant per al propi domini, com per als subdominis, i fins i tot els serveis de correu.
Plesk com a programari és actualment força agradable i estable. S'actualitza a si mateix i a l'Axis en silenci, consumeix pocs recursos i funciona sense problemes. Ni tan sols recordo que vaig trepitjar alguna cosa en algun lloc, cosa que hauria estat un defecte evident del producte. Hi va haver problemes, és clar, però es van deure a una configuració imperfecta o en algun lloc de la cruïlla, així que no hi ha res de què queixar-se. Les impressions de treballar amb Plesk són generalment agradables. El que no té, i hem d'entendre-ho, és qualsevol (qualsevol) agrupació. Ni LB ni HA. Pots provar-ho, però l'esforç serà tant que és millor fer alguna cosa diferent des del principi.
Crec que ho podem resumir. Per al cas que no hi hagi administrador, o no n'hi hagi prou, quan el preu de l'allotjament i els llocs que hi giren superen, bé, per exemple, els 100 USD, quan no estem parlant de compartir bestial de 1500. llocs en un servidor, quan el que pren la decisió s'enfronta a Si teniu l'opció de contractar un administrador a temps parcial, o comprar programari i tenir un administrador per mig dòlar, o no tenir-ne cap, sens dubte té sentit. Des del punt de vista de l'administrador remot, el mateix. 10 dòlars al mes, estalvia temps i ofereix flexibilitat en el treball durant molt de tempsоuna quantitat més gran. Si, per exemple, em demanen fermament que accepti un projecte similar sota la meva ala, insistiré a transferir-lo a Plesk.
Font: www.habr.com