Chci se podělit o některé dojmy ohledně užitečnosti nebo zbytečnosti něčeho, jako je ovládací panel pro komerční jednoserverový webový projekt při přítomnosti velmi part-time administrátora. Příběh začal před pár lety, když mě známí požádali, abych technicky podpořil koupi podnikání – zpravodajského webu. Bylo třeba se lehce ponořit do toho, na čem to běží, sledovat, aby všechny potřebné údaje byly předány v odpovídající podobě a objemu, a strategicky přemýšlet, co lze zlepšit.
Obchod byl dokončen, houslista se stal nepotřebným. Konec. Ve skutečnosti ne.
Web běžel na dvoujádrovém 4 GB VM na Linode, na nějakém zastaralém Debianu 5 s uptime kolem 400 dní a takovýmto seznamem neaktualizovaných balíčků. Webová část byla na vlastnoručně napsaném CMS, nginx, php5.3 FPM, MySQL laděné Percona. V zásadě to fungovalo.
Paralelně s rozhovory se mnou nový majitel hledal programátora, který by přivedl projekt k očekáváním. Našel. Programátor posoudil provoz a objemy a rozhodl se, že umí optimalizaci a cost management. Migraci celého webu provedl na 700korunový sdílený hosting pod správou jemu známého IS****era. Po několika dnech znovu volání od majitele: „všechno se zpomaluje a zdá se, že nás někdo napadl“. Snažil jsem se situaci napravit přes panel, ale po nějakém čase bezvýsledných pokusů o změnu verze PHP nebo handleru z fcgi na fpm jsem to vzdal a šel do shellu. Tam jsem našel zapnutý debug, který svítil na celý internet heslem k MySQL, 777 na některé složky, které v tu chvíli praskaly od nalitého malware a podobné nesmysly. Majitel si to uvědomil a rozhodl se, že šetřit na hostingu, programátorech a administrátorovi, který by si jedním okem pohlédl, jak to všechno jde, je špatně.
Jedeme na RuVDS. O něco blíže než britská Linode a pokud byste chtěli uchovávat osobní údaje a to vše, už nebude potřeba nikam jinam přecházet. Protože plánujeme projekt rozšiřovat, vzali jsme si VM „na výrost“: 4 jádra, 8 GB paměti, 80 GB disku. Není to, že bych neuměl pracovat s konfiguracemi nginx ručně, ale prostě jsem neměl chuť se tomuto projektu věnovat tolik intimně (viz výše o part-time). Takže jsem nainstaloval Plesk (podrobnosti instalace vynechávám, protože v podstatě žádné nejsou: spustil jsem instalátor, nastavil heslo pro admina, zadal klíč – hotovo), v té době to byla verze 17.0. Základní nastavení funguje přijatelně hned po instalaci, je tam fail2ban a poslední dostupné verze PHP, nginx.
Možná stojí za to zastavit se a vysvětlit, proč to. Protože se takovými věcmi zabývám zřídka a nemám žádný zvláštní nástroj či připravené šablony na každý případ, bylo jasné, že potřebuji nějakou automatizaci základních věcí, abych jednak rychle, jednak bezpečně, a za třetí, aby všechny nejlepší praktiky už někdo implementoval.
Takže jsem to nainstaloval. Ušetřil jsem spoustu času, restart webu na novém serveru byl téměř okamžitý. Bylo třeba upravit konfiguraci MySQL, poskytnout mu polovinu paměti a zvýšit počet buffer poolů, a odevzdat nginx polovině jader (Plesk se nedotýká globálních konfigurací) a během pár dnů jsem se podíval do shellu, abych zkontroloval statistiky mysqltuner. A ano, koupil jsem placený ImunifyAV z katalogu rozšíření, abych se zbavil nahrané malwaru. Našli se nějaké 11000 infikovaných souborů. Hnusné na tom bylo, že do statiky se dostávaly obfuskované kusy kódu, a ručně by to bylo vážně deprimující čistit. Nejprve jsem zkoušel ClamAV, ale jak se ukázalo, takové věci nebere, zatímco ImunifyAV to zvládl. A opravené soubory zůstávají v pracovním stavu, jen se odstraní kus s malwarem.
Aritmetika je jednoduchá: 50 $ měsíčně za VM, 10 $ za Plesk (ve skutečnosti méně, protože jsme koupili hned na rok se slevou na dva měsíce) a 3 $ za antivirus. Nebo spoustu kufrů peněz za můj čas, který bych na začátku strávil na serveru, kdybych tyto stáje ručně uklízel. Majitele tato situace zcela uspokojila.
Mezitím jsme našli nového programátora. Dohodli jsme se s ním na rozdělení odpovědnosti, vytvořili subdoménu pro testovací verzi a práce začala. Programoval novou verzi webu na Laravelu, zatímco já jsem sledoval fail2ban%.
Zajímavé je, že proud zvědavých návštěvníků neustává a v seznamu zablokovaných adres je vždy kolem sta. Efekt je zajímavý: obvykle, když se přihlásím do shellu, vidím při přivítání asi 20000-30000 neúspěšných pokusů o přihlášení přes SSH. S aktivním fail2ban kolem 70. Vložené úsilí: 0. Bez kapky dehtu se to bohužel neobešlo. Ve výchozím nastavení byl "polovičně aktivní" WAF (modsecurity): v režimu detekce. To znamená, že zaznamenával podezřelou aktivitu do logu, ale neprováděl žádné akce. A fail2ban bez váhání četl všechny logy podle aktivovaných jails a blokoval vše, co se hýbalo. Tím jsme zablokovali polovinu redakce :D. Museli jsme tento jail vypnout a potřebné IP adresy pro jistotu přidat na bílý seznam. Úsilí vloženo: dvakrát kliknout myší a naučit redaktory říct svou IP adresu.
Co se programátorovi okamžitě líbilo — možnost nahrávat databáze přímo v panelu a rychlý přístup k phpMyAdmin.
Co se mi líbilo — logy a zálohy. Logy se generují a rotují samy od sebe; zálohy se nastavují velmi jednoduše. V nejpomalejším období se dělá plná záloha, asi na 10 gigabajtů, a poté každý den inkrementální, asi 200 megabajtů, po dobu týdne. Obnova je granulární, až na konkrétní soubor nebo databázi. Pokud potřebujete obnovit z inkrementální zálohy, není nutné se nejprve trápit s plnou a obnovou celé řetězce, Plesk to udělá sám. Zálohy lze nahrávat kamkoliv: na FTP, Dropbox, S3 bucket, Google Drive a další.
Den D: programátor konečně dokončil novou platformu, nahráli jsme ji do produkce, importovali stará data a začali vybírat barvu svých budoucích Maserati. Dosud stále vybíráme.
Začaly první problémy. Nový web byl očekávaně náročnější než starý, ale skutečný problém byl v tom, že k přitahování návštěvnosti jsme používali kromě jiného Yandex.Zen, který přiváděl návštěvníky ve velkém množství. Web se s varoval při 150 současných připojeních (nemluvím o RPS, protože jsme to neměřili). Začali jsme mačkat tlačítka a otáčet knoflíky v oblasti nastavení php_fpm:
No, už to zvládá 500 připojení. Jak se kreditka přiblížila k prostředkům na propagaci, vlny návštěvnosti začaly růst. Další milník je 1000 současných připojení. Tady už bylo nutné přepracovat kód a podívat se na duši muskulatury. Plesk v tom nepomohl, ale to se ani moc nečekalo. Zapnuli jsme log pomalých dotazů, přidali indexy do databáze, odstranili zbytečné dotazy z kódu, a znovu upravili konfiguraci MySQL podle rad mysqltuner.
Nová výzva – 2000 připojení. Právě vyšla verze Plesk 17.8, ve které mimo jiné přidali nginx caching. Aktualizovali jsme se (úžasně snadno). Zkoušíme. Funguje! A hned přišlo na měkké, přestalo fungovat feed Yandex.Zen. Web funguje, feed nefunguje. Nejde feed, není návštěvnost. Atmosféra se zahřívá. Pod tlakem okolností a z nedostatku fantazie se hned pustil do strace nginx a našel, co hledal. Ukazuje se, že v určitém okamžiku mou chybnou nginx zcacheoval 500 chybu jako odpověď na yandexový get feed.xml. Opraveno přidáním výjimek do nastavení cache:
Je jasné, že majitel potřebuje JEŠTĚ, vlny pomalu rostou. Zatím to zvládáme, ale z předstihu jsme začali experimentovat s memcached, naštěstí Laravel ho podporuje skoro z krabice. Nechtělo se nám instalovat memcached ručně pro „hraní“, proto jsme nainstalovali Docker obraz. Přímo z panelu.
No dobře, lhal jsem, musel jsem jít do shellu a nainstalovat modul přes pecl. Přímo po . O nárůstu propustnosti zatím nelze říct nic, nebyly dost velké návaly. Engine webu se připojil na localhost:11211, statistiky se zobrazují, paměť se žere. Pokud se osvědčí, uvidíme, co dělat dál. Buď to tak necháme, nebo nainstalujeme „skutečný“ přímo do OS. Nebo se pokusíme o redis stejným způsobem.
Pak bylo potřeba přidělat emailový mailing. Žádné relé, jen smtp authentication. Založil jsem emailovou adresu, přes její údaje děláme rozesílku přes PHP.
Nedávno vyšel Plesk Obsidian (18.0), aktualizovali jsme se bez obav podle předchozí zkušenosti. Vše proběhlo velmi hladce, ani není o čem vyprávět. Z příjemného – výrazně se zlepšil kvalita rozhraní, modernizoval se a stal se v některých místech pohodlnějším. Zajímavá věc Advanced Monitoring na Grafana.
Zatím jsem se s tím podrobně nezabýval, ale je možné například nastavit upozornění na jakýkoli parametr na email. Majiteli, lol.
Pokud mluvím o rozhraní, je adaptivní a skutečně dobře funguje na telefonu. Na počátku, když jsme se snažili najít optimální nastavení PHP a dalšího, nám to opravdu pomohlo. A zejména když programátor v záchvatu pracovní enthusiasm něco dělá ve 23 hodin a já v záchvatu pracovní enthusiasm piji vodku v sauně a NALÉHAVĚ je potřeba něco přepnout.
O, mimochodem. Na obrázku vidíte, že se objevil PHP Composer. Zatím jsme si s ním nehráli, ale říkám, že pro Laravel může ušetřit pár přihlášení do shellu a nějaký čas na instalaci závislostí. Stejný systém existuje pro Node.JS a Ruby.
Se SSL je to jednoduché. Pokud se doména resolvuje kam má, Let’s Encrypt se dělá jedním kliknutím a dále se aktualizuje samo, a to jak na samotné doméně, tak na subdoménách, a dokonce i na poštovních službách.
Sám Plesk je v současnosti poměrně příjemný a stabilní software. Sám se aktualizuje a OS tiše, spotřebovává málo zdrojů a funguje hladce. Dokonce si ani nepamatuji, že bych někde na něco šlápnul, co by bylo zjevnou vadou produktu. Problémy samozřejmě byly, ale buď z nedokonalosti konfigurace, nebo někde na pomezí, takže není co vyčítat. Zkušenosti s Pleskem jsou celkově příjemné. Co v něm chybí, a to je třeba pochopit, je jakákoliv (jakákoliv) klasterizace. Ani LB, ani HA. Zkoušet se dá, ale investovaných úsilí bude tolik, že je lepší to udělat původně jinak.
Myslím, že můžeme shrnout. Pro případ, kdy není admin, nebo je jich málo, když cena hostingu a běžícího webu/webů přesahuje, řekněme, 100 EUR, když nejde o nepořádný server s 1500 weby, když se před rozhodujícím postavením nabízí volba najmout admina na poloviční úvazek, nebo koupit software a pořídit admina na „poloviční platy“, nebo dokonce ho vůbec nepořizovat - smysl určitě je. Z pohledu vzdáleného admina - to samé. 10 $ za měsíc, a šetří čas a přináší flexibilitu v práci na velmi vysoký obnos. Pokud mě například hodně požádají, abych převzal podobný projekt, budu trvat na přenesení na Plesk.oTajná efektivita spočívá v kvalitním kódu, a ne efektivním manažerovi.
Zdroj: habr.com
