Chcę podzielić się pewnymi wrażeniami na temat przydatności lub nieprzydatności takiej rzeczy jak panel sterowania dla komercyjnego, jednoserwerowego projektu webowego przy posiadaniu bardzo part time admina. Historia zaczęła się kilka lat temu, gdy znajomi znajomych poprosili mnie o towarzyszenie przy zakupie biznesu — serwisu informacyjnego — z punktu widzenia technicznego. Należało nieco zrozumieć, na czym to działa, upewnić się, że wszystkie niezbędne dokumenty zostały przekazane w odpowiedniej formie i objętości oraz strategicznie przemyśleć, co można poprawić.
Transakcja została zakończona, skrzypek stał się zbędny. Koniec. Tak naprawdę to nie koniec.
Strona działała na dwurdzeniowej maszynie wirtualnej 4GB na Linode, na jakimś zamierzchłym Debianie 5 z czasem działania bliskim 400 dni i taką oto listą nieaktualnych pakietów. Część webowa na autorskiej CMS, nginx, php 5.3 FPM, mysql dostosowane do Percony. W zasadzie działało.
Równocześnie z rozmowami ze mną nowy właściciel szukał programisty, który dostosowałby projekt do oczekiwań. Znalazł. Programista ocenił ruch i wolumeny i postanowił, że zna się na optymalizacji i zarządzaniu kosztami. Przeniósł całą stronę na 700-rublowy shared hosting zarządzany przez mu dobrze znanego IS****era. Po kilku dniach znowu telefon od właściciela: „wszystko się zacina i wydaje się, że nas zepsuli”. Próbowałem naprawić sytuację przez panel, ale po pewnym czasie bezowocnych prób zmiany wersji PHP lub handlera z fcgi na fpm, się poddałem i zabrałem się do shell. Tam znalazłem włączone debugowanie, które świeciło w całym internecie hasłem do MySQL, 777 na niektórych folderach, które w tamtym momencie pękały od zainfekowanej złośliwego oprogramowania i podobnych rzeczy. Właściciel zrozumiał i postanowił, że oszczędzanie na hostingu, programiście i adminie, który rzucałby okiem na to, jak idą sprawy, jest niewłaściwe.
Przechodzimy na RuVDS. Nieco bliżej niż brytyjska Linode, a jeśli kiedykolwiek będziemy chcieli przechowywać dane osobowe i tym podobne, nie będzie potrzeby przeprowadzania się gdziekolwiek indziej. Ponieważ projekt planowano rozszerzyć, wzięliśmy VM "na przyszłość": 4 rdzenie, 8 GB pamięci, 80 GB przestrzeni dyskowej. Nie to, że nie potrafię ręcznie edytować konfiguracji nginx, po prostu nie miałem entuzjazmu, aby zajmować się tym projektem w tak intymny sposób (patrz wyżej o pracy na część etatu). Dlatego - zainstalowałem Plesk (pomińmy szczegóły instalacji, ponieważ w zasadzie ich nie ma: uruchomiłem instalator, ustawiłem hasło dla administracji, wprowadziłem klucz – wszystko), wówczas była to wersja 17.0. Podstawowe ustawienia działają znośnie od razu po uruchomieniu, jest fail2ban i najnowsze dostępne wersje PHP, nginx.
Pewnie warto na chwilę się zatrzymać i wyjaśnić, dlaczego jego. Ponieważ rzadko zajmuję się takimi rzeczami, nie posiadam żadnego szczególnego narzędzia ani zestawu szablonów na każdą okazję, zrozumiałem, że potrzebna jest jakaś automatyzacja podstawowych czynności, aby po pierwsze szybko, po drugie bezpiecznie, a po trzecie, aby najlepsze praktyki były już wdrożone przez kogoś.
Otóż, zainstalowałem. Zaoszczędziłem dużo czasu, ponowne uruchomienie strony na nowym serwerze praktycznie odbyło się błyskawicznie. Pozostało tylko przeedytować konfigurację MySQL, przydzielając mu połowę pamięci i zwiększając liczbę buffer pools, a nginxowi przekazać połowę rdzeni (Plesk nie zmienia globalnych konfiguracji), i przez kilka dni zaglądałem do shella, żeby sprawdzić statystyki mysqltuner. Tak, kupiłem płatny ImunifyAV z katalogu rozszerzeń, aby pozbyć się zaatakowanych przez malware plików. Znalazło się jakieś 11000 zainfekowanych plików. Najgorsze jest to, że do statycznych plików wlewały się obfuskowane kawałki kodu, a oczyszczanie tego ręcznie byłoby całkowicie zniechęcające. Na początku próbowałem ClamAV, ale okazało się, że nie radzi sobie z takimi rzeczami, a ImunifyAV poradził sobie. Co więcej, uzdrowione pliki pozostają w działającym stanie, po prostu usuwany jest kawałek z malwarem.
Prosta matematyka: 50 USD miesięcznie za VM, 10 USD za Plesk (w rzeczywistości mniej, ponieważ kupiliśmy od razu na rok ze zniżką dwóch miesięcy) oraz 3 USD za program antywirusowy. Albo wiele walizek pieniędzy za mój czas, który spędziłbym na serwerze, ręcznie porządkując te stajnie na początku. Właściciela taki układ całkowicie satysfakcjonował.
Tymczasem znaleziono nowego programistę. Ustaliliśmy z nim podział odpowiedzialności, stworzyliśmy subdomenę dla wersji testowej i zaczęła się praca. On tworzył nową wersję strony na Laravel, a ja obserwowałem fail2ban%).
Ciekawe, że strumień ciekawskich się nie kończy, a w liście zablokowanych adresów zawsze jest około stu pozycji. Efekt jest interesujący: zwykle, gdy wchodzę do powłoki, na powitaniu widzę około 20000-30000 nieudanych prób logowania przez SSH. Z włączonym fail2ban około 70. Włożone wysiłki: 0. Niestety, nie obyło się bez odrobiny dziegciu. Domyślnie WAF (modsecurity) był 'półaktywny': w trybie wykrywania. To znaczy, że zapisywał podejrzaną aktywność w logach, ale faktycznie nic nie robił. A fail2ban bez rozróżnienia czytał wszystkie logi zgodnie z włączonymi jailami i banował wszystko, co się rusza. Tak więc zablokowaliśmy połowę redakcji :D. Musieliśmy wyłączyć ten jail, a potrzebne adresy IP dla pewności dodać do białej listy. Włożone wysiłki: dwa razy klikać myszką i nauczyć redaktorów podać swój adres IP.
Co od razu przypadło do gustu programiście — możliwość przesyłania baz danych bezpośrednio w panelu i szybki dostęp do phpMyAdmin.
Co mi się spodobało — logi i kopie zapasowe. Logi są tworzone i rotowane automatycznie; kopie zapasowe są bardzo łatwe do skonfigurowania. W najpowolniejszym czasie wykonywana jest pełna kopia zapasowa, gdzieś na 10 gigabajtów, a potem codziennie robione są kopie przyrostowe, po około 200 megabajtów, przez tydzień. Odzyskiwanie jest granularne, do konkretnego pliku lub bazy danych. Jeśli trzeba odzyskać z przyrostowej, nie trzeba najpierw borykać się z pełną kopią i przywracaniem całego łańcucha, Plesk robi wszystko sam. Można przesyłać kopie zapasowe wszędzie: na FTP, Dropbox, S3 bucket, Google Drive itp.
Dzień D: programista w końcu zakończył nowy silnik, wprowadziliśmy go na produkcję, zaimportowaliśmy stare dane i usiedliśmy do wyboru koloru naszych przyszłych Maserati. Nadal się zastanawiamy.
Zaczęły się pierwsze problemy. Nowa strona była oczywiście cięższa od starej, ale realnym problemem było to, że do przyciągania ruchu korzystaliśmy między innymi z Yandex.Zen, który ściągał odwiedzających grupami. Strona zawieszała się przy 150 jednoczesnych połączeniach (nie mówię o RPS, bo nie mierzyliśmy). Zaczęliśmy klikać przyciski i kręcić pokrętłami w ustawieniach php_fpm:
O, już trzyma 500 połączeń. W miarę dodawania karty kredytowej do funduszy promocyjnych fale ruchu zwiększyły się. Następny kamień milowy to 1000 jednoczesnych połączeń. Tu trzeba już było udoskonalić kod i spojrzeć w duszę myszy. Plesk w tym nie pomógł, ale tego zbytnio nie oczekiwano. Włączyliśmy log powolnych zapytań, dodaliśmy indeksy do bazy, usunęliśmy zbędne zapytania z kodu, jeszcze raz dostosowaliśmy konfigurację mysql zgodnie z radami mysqltuner.
Nowe wyzwanie — 2000 połączeń. Akurat wyszła wersja Plesk 17.8, w której, oprócz innych rzeczy, dodano pamięć podręczną nginx. Zaktualizowaliśmy się (na zdziwienie łatwo). Próba. Działa! I tuż po tym coś poszło nie tak, przestał działać feed Yandex Zen. Strona działa, ale feed nie działa. Jeżeli feed nie działa, nie ma ruchu. Atmosfera się zaostrza. Pod wpływem okoliczności i braku pomysłów od razu postanowiłem strace'ować nginx i znalazłem, co szukałem. Okazuje się, że w pewnym momencie głupi nginx zbuforował błąd 500 jako odpowiedź na zapytanie Yandexa o feed.xml. Naprawiliśmy to, dodając wyjątki do ustawień pamięci podręcznej.
Oczywiście właściciel potrzebuje JESZCZE, fale powoli się zwiększają. Na razie sobie radzimy, ale z wyprzedzeniem zaczęliśmy eksperymentować z memcached, na szczęście Laravel wspiera go niemal od razu. Nie chciało mi się instalować memcached ręcznie tylko po to, żeby „pobawić się”, więc zainstalowaliśmy obraz Dockera. Prosto z panelu.
Dobrze, kłamie, musiałem wejść do shel i zainstalować moduł przez pecl. Prosto przez . Na razie nie ma co mówić o wzroście wydajności, nie było większych napływów. Silnik strony podpiął się na localhost:11211, statystyki się ładują, pamięć jest używana. Jeśli się spodoba, zobaczymy, co dalej robić. Możemy to zostawić, albo zainstalować „prawdziwy” bezpośrednio w OS. Albo w ten sam sposób spróbujemy redisa.
Potem zaistniała potrzeba dodania mailingu. Żadnych relayów, tylko autoryzacja smtp. Założyłem adres e-mail, przez jego dane w PHP robimy wysyłkę.
Niedawno wyszedł Plesk Obsidian (18.0), zaktualizowaliśmy się na podstawie doświadczeń bez strachu. Wszystko poszło bardzo gładko, nawet nie ma o czym opowiadać. Z przyjemnych rzeczy — znacznie poprawił się interfejs, stał się bardziej nowoczesny i w niektórych miejscach wygodniejszy. Fajna rzecz to Advanced Monitoring w Grafanie.
Na razie dokładnie się z tym nie zapoznałem, ale można na przykład skonfigurować alerty na dowolny parametr do e-maila. Dla właściciela, lol.
Skoro mówimy o interfejsie, jest on responsywny i naprawdę dobrze działa na telefonie. Na wczesnych etapach, podczas gdy próbowaliśmy znaleźć optymalne ustawienia PHP i innych rzeczy, bardzo nam to pomogło. A szczególnie gdy programista w przypływie roboczego entuzjazmu coś robi o 23:00, a ja w przypływie roboczego entuzjazmu piję wódkę w saunie i PILNIE muszę coś przełączyć.
A, właśnie. Na obrazku widać, że pojawił się PHP Composer. Na razie się z nim nie bawiliśmy, ale, powiedzmy, dla Laravel może oszczędzić kilka logowań w shellu i jakiś czas na instalację zależności. Taki sam system istnieje dla Node.JS i Ruby.
Z SSL jest prosto. Jeśli domena rozwiązuje się gdzie trzeba, Let’s Encrypt robi się jednym kliknięciem i aktualizuje się samodzielnie, zarówno na samą domenę, jak i na subdomeny, a nawet usługi pocztowe.
Sam Plesk, jako oprogramowanie obecnie, jest dość przyjemny i stabilny. Aktualizuje się sam i OS cicho, zużywa mało zasobów, działa równo. Nawet nie pamiętam, żebym gdzieś na coś nadepnął, co byłoby wyraźną wadą produktu. Problemy oczywiście były, ale były albo z niedoskonałości konfiguracji, albo gdzieś na styku, więc nie ma do czego się przyczepić. Ogólne wrażenia z pracy z Pleskiem są pozytywne. Czego w nim brakuje, i trzeba to zrozumieć, to wszelkiej (jakiejkolwiek) klasteryzacji. Ani LB, ani HA. Można próbować, ale wysiłków będzie tyle, że lepiej zrobić od początku coś inaczej.
Myślę, że można podsumować. W przypadku, gdy admina nie ma, lub jest go mało, gdy cena hostingu i działającego na nim strony (stron) przekracza, powiedzmy, 100 u.e., gdy nie mówimy o okropnym sharecie z 1500 stronami na serwerze, gdy przed osobą podejmującą decyzję stoi wybór wynajęcia admina na pół etatu, kupienia oprogramowania i zatrudnienia admina na „pół etatu”, lub w ogóle go nie zatrudniać — sens zdecydowanie istnieje. Z perspektywy zdalnego admina — to samo. 10$ miesięcznie, a oszczędza czas i daje elastyczność w pracy na znacznie większą sumę. Jeśli na przykład mocno poproszą mnie o wzięcie podobnego projektu pod swoje skrzydła, będę nalegał na przeniesienie na Pleska.większąChcę podzielić się kilkoma wrażeniami na temat potrzeby lub niepotrzeby takiej rzeczy, jak panel kontrolny dla komercyjnego jednoserwerowego projektu internetowego przy obecności bardzo part time admina.
Źródło: habr.com
