Szeretném megosztani néhány tapasztalatomat arra vonatkozóan, hogy mennyire fontos vagy felesleges egy vezérlőpult egy kereskedelmi, egyetlen szerveren futó webprojekt számára, ha van egy nagyon részmunkaidős adminisztrátor. A történet egy pár évvel ezelőtt kezdődött, amikor ismerősök ismerősei megkértek arra, hogy a technikai oldalról segítsek egy üzletvásárlásban – egy híroldal átvételében. Néhány dologba kissé bele kellett folynom, figyelni kellett, hogy minden szükséges adat a megfelelő formában és mennyiségben átadásra kerüljön, és stratégiailag mérlegelni, hogy mit lehetne javítani.
A tranzakció létrejött, a hegedűs már nem volt szükséges. Vége. Valójában nem.
Az oldal egy kétprocesszoros, 4 GB-os VM-en futott Linode-on, egy régi Debian 5 rendszerrel, több mint 400 napos üzemidővel és egy ilyen régi csomaglistával. A weboldal egy saját CMS-en, nginx-en, php 5.3 FPM-en, mysql-on a Percona optimalizálásával működött. Alapvetően, működött.
Párhuzamosan a velem folytatott beszélgetések mellett az új tulajdonos programozót keresett a projekt elvárásokhoz való igazítására. Talált is. A programozó felbecsülte a forgalmat és a mennyiségeket, és arra a következtetésre jutott, hogy ért a optimalizáláshoz és a költségmenedzsmenthez. Az egész weboldalt átköltöztette egy 700 rubeles megosztott hosztra, amelyet a számára ismert IS****er irányított. Pár nap múlva újra hívott a tulajdonos: „minden lassú, és úgy tűnik, feltörték az oldalt”. Próbáltam megoldani a helyzetet a vezérlőpulton keresztül, de néhány sikertelen próbálkozás után, hogy megváltoztassam a PHP verziót vagy a hendlert fcgi-ről fpm-re, feladtam, és belenéztem a shellbe. Ott találtam bekapcsolt debuggolást, amely az internet egészén megvilágította a mysql jelszavát, 777-es jogosultságokat néhány mappán, amelyek ebben az időben már telítve voltak rosszindulatú szoftverrel és hasonló borzalmakat találtam. A tulajdonos belátta, hogy a hoszton, a programozón és azon az adminisztrátoron spórolni, aki egy szemmel nézésre figyelné a dolgokat – helytelen.
RuVDS-re megyünk. A brit Linode-nál kicsit közelebb, és ha véletlenül személyes adatokat szeretnél tárolni, nem kell máshova költöznöd. Mivel a projekt terjeszkedését terveztük, egy "növelhető" virtuális gépet vettünk: 4 mag, 8 GB memória, 80 GB lemez. Nem mintha nem tudnám manuálisan konfigurálni az nginx-et, de nem volt kedvem ehhez a projekthez annyira intim módon (lásd fent az „alkalmi munka” résznél). Ezért telepítettem a Plesk-et (itt a telepítési részleteket kihagyom, mert tulajdonképpen nincsenek: elindítottam az telepítőt, beállítottam a jelszót az adminnak, megadtam a kulcsot – kész), akkoriban ez a 17.0 volt. Az alapbeállítások elfogadhatóan működnek dobozból, van fail2ban és a legfrissebb elérhető PHP és nginx verziók.
Talán érdemes megállni és elmagyarázni, miért ezt választottam. Mivel ilyen dolgokkal ritkán foglalkozom, és nincs különösebb eszköztáram vagy sablonkészletem minden esetre, világos volt, hogy szükség van valamilyen automatizálásra az alap dolgokhoz, hogy először is gyorsan, másodszor biztonságosan, harmadszor pedig, hogy valaki már bevezette az összes legjobb gyakorlatot.
Tehát telepítettem. Jelentős időt spóroltam meg, az új szerverre való átállás gyakorlatilag azonnali lett. Csak a MySQL konfigurációt kellett átírni, hogy a memória felét megkapja, és az nginx-et a magok felére csökkenteni (a Plesk nem nyúl a globális konfigurációkhoz), és néhány napig be kellett nézni a shellbe, hogy megnézzem a mysqltuner állapotát. Ja, és megvettem a fizetős ImunifyAV-t a bővítmények katalógusból, hogy megszabaduljak a feltöltött rosszindulatú szoftverektől. Kb. 11,000 fertőzött fájlra bukkantam. A borzalom az, hogy obfuszkált kóddarabok kerültek be a statikus fájlokba, és ezt manuálisan kitakarítani igencsak elkeserítő lett volna. Először próbáltam a ClamAV-t, de kiderült, hogy az ilyen dolgokat nem kezel, míg az ImunifyAV sikeresen megoldotta. Ráadásul a gyógyított fájlok munkaképes állapotban maradnak, csak a rosszindulatú részt töröljük.
Az aritmetika egyszerű: havi 50$ a virtuális gépért, 10$ a Plesk-ért (valójában kevesebb, mert egy évre, két hónapos kedvezménnyel vásároltuk) és 3$ az antivírusért. Vagy sok pénz a drága időmből, amit a szerveren töltenék, kezdetben manuálisan rendbe rakva ezeket a zűrzavarokat. A tulajdonost ez a megoldás teljesen kielégítette.
Közben találtunk egy új programozót. Megállapodtunk vele a felelősségi körök megosztásáról, aldomain-t hoztunk létre a tesztverzióhoz, és elkezdődött a munka. Ő a Laravel-re építette az új weboldal verziót, én pedig a fail2ban-t figyeltem.
Érdekes, hogy a kíváncsiskodók áramlása nem szűnik meg, és a banlistán mindig körülbelül száz cím szerepel. Az érdekes hatás: általában, amikor belépek a shell-be, a köszöntésnél körülbelül 20000-30000 sikertelen SSH belépési kísérletet látok. A fail2ban bekapcsolásával körülbelül 70. Befektetett erőfeszítések: 0. Sajnos egy kis szennyeződés is becsúszott. Alapértelmezés szerint a WAF (modsecurity) „félig bekapcsolt” állapotban volt: figyelmeztető üzemmódban. Vagyis a gyanús tevékenységeket csak naplózta, de valójában semmilyen intézkedést nem tett. A fail2ban viszont átnézte az összes naplót a bekapcsolt börtönök szerint, és lestrapálta mindent, ami mozgott. Így a szerkesztőség felét kitiltottuk :D. Ki kellett kapcsolnunk ezt a börtönt, és a szükséges IP-címeket a megbízhatóság érdekében fehérlistára kellett tenni. Befektetett erőfeszítések: kétszer kattintani az egérrel és megtanítani a szerkesztőket, hogy mondják meg az IP-címüket.
A programozónak azonnal tetszett a lehetőség, hogy az adatbázisokat közvetlenül a panelen keresztül tölthesse fel, és a gyors hozzáférés a phpMyAdminhoz.
Ami nekem tetszett – a naplók és a biztonsági másolatok. A naplók maguktól íródnak és forognak; a biztonsági másolatok beállítása nagyon egyszerű. A leglassabb időszakban egy teljes biztonsági másolat készül, körülbelül 10 gigabájtot, majd naponta egy inkrementális, körülbelül 200 megabájtot, egy héten keresztül. A helyreállítás granulált, akár egy konkrét fájlra vagy adatbázisra. Ha inkrementálisból kell helyreállítani, akkor nem szükséges először a teljes biztonsági másolattal és az egész lánc restaurálásával bajlódni, a Plesk mindent elintéz. A biztonsági másolatokat bárhova fel lehet tölteni: FTP-re, Dropbox-ra, S3 vödörre, Google Drive-ra és így tovább.
A D-nap: a programozó végre befejezte az új motor munkálatait, feltöltöttük a termelési környezetbe, importáltuk a régi adatokat, és nekiláttunk kiválasztani a jövőbeli Mazarink színét. Még mindig azt választjuk.
Elkezdődtek az első problémák. Az új weboldal várhatóan nehezebb volt, mint a régi, de a valódi probléma az volt, hogy a forgalom vonzására többek között a Yandex.Zen-re támaszkodtunk, amely tömegével hozta a látogatókat. A weboldal 150 egyidejű csatlakozásnál összeroskadt (nem beszélek az RPS-ről, mert azt nem mértük). Elkezdtem kattintgatni a gombokat és állítgatni a php_fpm beállításait.
Hopp, már 500 kapcsolata van. Amint a hitelkártyát a forgalom növelésére irányoztuk, a forgalmi hullámok egyre nagyobbak lettek. A következő mérföldkő 1000 egyidejű kapcsolat. Itt már finomítani kellett a kódot, és belenézni a motorháztető alá. A Plesk nem segített ebben, de ezt igazából nem is vártuk. Bekapcsoltuk a lassú lekérdezések naplóját, indexeket fűzögettünk az adatbázisra, eltávolítottunk felesleges lekérdezéseket a kódból, és újra átnéztük a MySQL konfigurációt a mysqltuner ajánlásai szerint.
Új kihívás — 2000 kapcsolat. Közben megjelent a Plesk 17.8 verzió, amely többek között bevezette az nginx gyorsítótárazást. Frissítettünk (meglepően könnyen). Próbálkozunk. Működik! És azonnal megjelent a probléma, a Yandex Zen hírcsatorna leállt. Az oldal működik, de a hírcsatorna nem. Ha a hírcsatorna nem működik, nincs forgalom. Feszültség van a levegőben. A körülmények nyomására és a fantázia hiányában azonnal strace-elni kezdtem az nginx-et, és megtaláltam, amit kerestem. Kiderült, hogy egy bizonyos pillanatban a hülye nginx gyorsítótárazta a 500-as hibát válaszként a yandex-től kapott get feed.xml hívásra. Helyreállítottuk, kivételeket adtunk hozzá a gyorsítótár beállításaihoz:
Nyilvánvaló, hogy a tulajdonosnak SZÜKSÉGE VAN MÉG, a hullámok fokozatosan nőnek. Eddig megbirkózunk, de előre elkezdtük tesztelni a memcached-et, szerencsére a Laravel szinte natívan támogatja. A memcached önálló telepítése ‘játszadozás’ céljára nem volt kedvem, ezért Docker képet telepítettünk. Közvetlenül a panelből.
Na jó, hazudtam, be kellett lépnem a shell-be és telepítenem a modult a pecl-en keresztül. Közvetlenül a . Jelenleg nem tudok beszámolni a sávszélesség-növekedésről, elég nagy forgalom nem volt. Az oldal motorja csatlakozott a localhost:11211-hez, a statisztikák megjelennek, a memória elfogy. Ha tetszik, megnézzük, mi következik. Vagy így hagyjuk, vagy egy 'igazit' teszünk a rendszerre. Vagy kipróbáljuk a redis-t hasonló módon.
Aztán szükség volt egy levélküldőrendszer beállítására. Nincsenek relék, csak smtp hitelesítés. Létrehoztam egy e-mail címet, és a PHP segítségével ezen keresztül végezzük a levelezést.
Nemrégiben megjelent a Plesk Obsidian (18.0), frissítettünk a korábbi tapasztalatok alapján félelem nélkül. Minden nagyon simán ment, még csak mesélni sem tudok róla. A kellemes meglepetés az volt, hogy jelentősen javult az interfész minősége, modernizálódott és néhány helyen kényelmesebbé vált. Az Advanced Monitoring a Grafana-n elképesztő dolog.
Még nem mélyedtem bele, de például beállíthatók figyelmeztetések bármilyen paraméterről e-mailben. A tulajdonosnak, lol.
Ha már a felhasználói felületet említem, az adaptív, és nagyon jól működik telefonon. A korai szakaszokban, amikor próbáltuk megtalálni az optimális PHP-beállításokat és másokat, ez jelentősen segített. Különösen, amikor a programozó éppen 23 órakor, a munkába vetett szenvedéllyel valamit csinál, miközben én a szenvedélyem következtében vodkát iszom a fürdőben, és sürgősen át kell kapcsolni valamit.
Ja, mellesleg. A képen látható, hogy megjelent a PHP Composer. Még nem kísérleteztünk vele, de mondjuk, a Laravel számára rengeteg bejelentkezést spórolhat meg a shellben és időt a függőségek telepítésére. Ugyanez a rendszer elérhető a Node.JS-hez és a Rubyhoz.
Az SSL-t illetően minden egyszerű. Ha a domain a megfelelő helyre mutat, a Let’s Encrypt egy kattintással elkészül, és később automatikusan frissül, mind a domain, mind a szubdomének, sőt még a levelezőszolgáltatások tekintetében is.
A Plesk, mint szoftver, jelenlegi állapotában elég kellemes és stabil. Automatikusan frissíti magát és a rendszert csendesen, kevés erőforrást fogyaszt, és pontosan működik. Még csak nem is emlékszem, hogy valahol hibát tapasztaltam volna, ami a termék nyilvánvaló hibájának számítana. Természetesen adódtak problémák, de azok vagy a konfiguráció tökéletlenségéből adódtak, vagy valahol a határvonalon, így nincs igazán mibe belekötni. A Pleskkel való munka összességében kellemes élmény.
Azt hiszem, összegzésre jutottam. Abban az esetben, amikor nincs adminisztrátor, vagy csak kevés időt tölt ott, amikor a webtárhely ára és az ott futó weboldalak költsége meghaladja, mondjuk, a 100 eurót, amikor nem arról van szó, hogy 1500 weboldalt osztanak meg egy szerveren, amikor a döntést hozó előtt a kérdés az adminisztrátor félállásban való alkalmazása, vagy szoftver vásárlása, és 'félszor' adminisztrátort felvenni, vagy akár nem alkalmazni adminisztrátort — ennek mindenképpen van értelme. A távoli adminisztrátor szempontjából ugyanez igaz. 10$ havonta, és időt spórol, valamint rugalmasságot ad a munkában.óHa például nagyon megkérnének, hogy egy hasonló projektet átvállaljak, ragaszkodnék a Pleskre való átálláshoz.
Forrás: habr.com
