Бих искал да споделя впечатления относно нуждата или ненуждата от контролен панел за търговски уеб проект на един сървър с администратор на непълно работно време. Историята започна преди около две години, когато познати на познати ме помолиха да съпроводя закупуването на бизнес — новинарски сайт — от техническа гледна точка. Трябваше малко да се запозная с това, на какво работи, да се уверя, че всички необходими реквизити са предадени в правилния вид и обем, и стратегически да преценя какво може да се подобри.
Сделката се състоя, цигуларят стана ненужен. Край. Всъщност не.
Сайтът работеше на двуядрен 4GB VM на Linode, на някакъв остарял Debian5 с uptime от 400 дни и със списък от необновени пакети. Уеб частта бе на самостоятелно написана CMS, nginx, php5.3 FPM, mysql оптимизирана Percona. В принципе, работеше.
Паралелно с разговорите с мен, новият собственик търсеше програмист за приведението на проекта в съответствие с очакванията. Намери го. Програмистът оцени трафика и обемите и реши, че може да се справи с оптимизацията и управлението на разходите. Той мигрира целия сайт на 700-рублев хостинг, управляван от познатия му IS****er. След няколко дни отново обаждане от собственика: „всичко забавя и изглежда, че нещо ни счупи“. Опитах се да оправя ситуацията през панела, но след известно време безплодни опити да променя версията на PHP или хендлер от fcgi на fpm, се отказах и влязох в shell. Там намерих включен дебаг, който светеше в целия интернет с паролата за mysql, 777 на някои папки, които по това време пръскаха от заредена зловредна софтуер и подобни безумия. Собственикът осъзна и реши, че икономията на хостинг, програмист и администратор, който да следи как вървят нещата, е грешна.
Преминаваме на RuVDS. Много по-близо от британската Linode, и ако случайно искате да съхранявате лични данни и всичко останало, вече не е нужно да се местите другаде. Тъй като проектът е планиран за разширение, взехме ВМ, която да расте с нас: 4 ядра, 8 гигабайта RAM, 80 ГБ дисково пространство. Не че не мога да се занимавам с конфигурации на nginx ръчно, просто нямаше да имам ентусиазъм да се занимавам с този проект толкова интимно (вижте по-горе за part time). Затова инсталирах Plesk (тук ще пропусна подробностите около инсталацията, защото по същество ги няма: стартирах инсталатора, зададох парола за админа, въведох ключа – и готово), по онова време това беше версия 17.0. Основните настройки работят съвсем прилично от самото начало, има fail2ban и последните налични версии на PHP и nginx.
Може би е време да спра и да обясня защо избрах него. Тъй като рядко се занимавам с такива неща и нямам специализирани инструменти и шаблони за всеки случай, беше ясно, че е необходима автоматизация на основните неща, за да бъде бързо, безопасно и за да бъдат внедрени всички най-добри практики от някого.
И така, инсталирах го. Спестих значително време, рестартирането на сайта на новия сървър стана почти моментално. Оставаше да пиля конфигурацията на MySQL, выделявайки му половината от паметта и увеличавайки броя на buffer pools, и да дам на nginx половината ядра (Plesk не засяга глобалните конфигурации), и през следващите няколко дни да влизам в shell, за да проверя статистиките на mysqltuner. А, и купих платен ImunifyAV от каталога с разширения, за да се отърва от нахлулата малуер. Намериха се около 11 000 заразени файла. Ужасното беше, че в статичните ресурси бяха влезли обфускирани парчета код, и ръчното почистване щеше да бъде наистина мизерно. Първоначално опитах ClamAV, но той, както се оказа, не се справя с такива неща, а ImunifyAV успя. Възстановените файлове остават в работно състояние, просто се изтрива частта с малуера.
Арифметиката е проста: 50 $ на месец за ВМ, 10 $ за Plesk (всъщност по-малко, защото купихме веднага за година с отстъпка от два месеца) и 3 $ за антивирус. Или много суми пари за времето ми, което щях да прекарам на сървъра в началото, разчиствайки тези конюшни ръчно. Такъв разпределение удобно устройва собственика.
Междувременно, намерили нов програмист. Споразумяхме се с него за разпределението на отговорностите, създадохме поддомейн за тестовата версия и работата започна. Той разработваше новата версия на сайта с Laravel, а аз се занимавах с fail2ban%.
Интересно е, че потокът на любопитстващите не спира и в списъка на блокираните винаги има около сто адреса. Ефектът е интересен: обикновено, ако вляза в шелл, на приветствието виждам около 20000-30000 неуспешни опити за достъп по SSH. С включен fail2ban около 70. Вложените усилия: 0. За съжаление, не мина без малко горчивина. По подразбиране WAF (modsecurity) беше „полуактивен“: в режим на откритие. Тоест записваше подозрителна активност в логовете, но всъщност не предприемаше никакви действия. А fail2ban без селективност четеше всички логове, според включените jails, и блокираше всичко, което се движи. Така забранихме половината редакция :D. Прихода се да деактивираме този jail и нужните IP-адреси за сигурност да добавим в белия списък. Вложените усилия: два пъти да щракна с мишката и да науча редакторите да кажат своя IP-адрес.
Какво веднага хареса на программиста — възможността да качва бази данни директно от панела и бързият достъп до phpMyAdmin.
Какво ми хареса на мен — логовете и резервните копия. Логовете се записват и ротират автоматично; резервните копия се настройват много лесно. В най-слабото време се прави пълно резервно копие, около 10 гигабайта, а след това всеки ден по инкрементално, около 200 мегабайта, в течение на седмица. Възстановяването е грануларно, до конкретен файл или база данни. Ако трябва да се възстанови от инкрементално, не е нужно да се мъчите първо с пълното и ресторното на цялата верига, Plesk прави всичко сам. Резервни копия могат да се качват навсякъде: на ftp, на Dropbox, S3 bucket, Google Drive и други.
Ден Х: программистът най-накрая завърши новия двигател, заредихме го в продукцията, импортирахме старите данни и седнахме да избираме цвета на нашите бъдещи Maserati. Все още продължаваме да избираме.
Започнаха първите проблеми. Новият сайт, както се очакваше, беше по-тежък от стария, но истинският проблем беше, че за привличане на трафик използвахме, между другото, Yandex.Zen, който довеждаше посетители на партиди. Сайтът се проваляше при 150 едновременни връзки (не говоря за RPS, защото не измервахме). Започнахме да натискаме бутони и да въртим ръчки в областта на настройките на php_fpm:
Оп, вече поддържа 500 свързвания. С увеличаването на средствата за реклама потокът от трафик нарасна. Следващият етап е 1000 едновременни свързвания. Тук вече трябваше да преработим кода и да се задълбочим в логиката. Plesk не помогна съществено, но не и очаквахме много. Включихме логовете за бавни заявки, добавихме индекси в базата, премахнахме излишни заявки от кода и отново преработихме конфигурацията на mysql по съветите на mysqltuner.
Новото предизвикателство — 2000 свързвания. Точно успяхме да инсталираме версия Plesk 17.8, в която, наред с другото, въведоха кеширане с nginx. Актуализирахме (изключително лесно). Опитваме. Работи! И веднага се сблъскахме с проблем — спря да работи фидът на Яндекс.Цен. Сайтът функционира, фидът не работи. Ако няма фид, няма и трафик. Напрежението нараства. Под натиска на обстоятелствата и от недостатък на креативност, веднага започнах да проследявам nginx и открих какво е станало. Оказа се, че в един момент майтапчийският nginx е кеширал код 500 като отговор на заявка get feed.xml от Яндекс. Поправихме, добавяйки изключения в настройките на кеша.
Разбира се, че собственикът иска ОЩЕ, вълните бавно се увеличават. Все още се справяме, но предварително започнахме експерименти с memcached, тъй като Laravel го поддържа почти без усилия. Не ми се искаше да инсталирам memcached ръчно само за да се поиграя, затова инсталирахме Docker образ. Направо от контролния панел.
Добре, да призная, наложи се да вляза в shell и да инсталирам модула през pecl. Направо по . Все още не мога да говоря за растежа на пропускната способност, тъй като не е имало достатъчно големи приливи. Системата се свърза на localhost:11211, статистиките показват, че паметта се използва. Ако всичко върви добре, ще видим какво да правим по-нататък. Или ще го оставим така, или ще инсталираме „истински“ направо в системата. Или по същия начин ще пробваме redis.
След това се наложи да добавим имейл разпространение. Без релей, само smtp аутентификация. Създадох имейл адрес и използваме неговите данни за разпространение през PHP.
Неотдавна излезе Plesk Obsidian (18.0), актуализирахме без страх, предвид предишния опит. Всичко мина много гладко, дори нямам за какво да разказвам. От приятните изненади — интерфейсът значително се подобри, стана по-съвременен и в някои аспекти по-удобен. Интересна функция е Advanced Monitoring на Grafana.
Все още не съм проучвал подробно, но можете например да настроите аларми по всякакъв параметър на имейл. На собственика, лол.
Тъй като говоря за интерфейса, той е адаптивен и наистина работи добре на телефон. В началните етапи, когато се опитвахме да намерим оптималните настройки за PHP и други, това ни помогна много. Особено когато програмистът в пристъп на работен ентусиазъм работи по нещо в 23:00, а аз, също в пристъп на работен ентусиазъм, пия водка в банята и спешно трябва да превключа нещо.
О, между другото. На картинката се вижда, че е добавен PHP Composer. Все още не сме се занимавали с него, но, да кажем, за Laravel може да спести няколко логина в shell и известно време за инсталиране на зависимости. Има същата система и за Node.JS и Ruby.
С SSL всичко е просто. Ако домейнът се резолвира правилно, Let’s Encrypt се настройва с едно кликване и се обновява сам, както за основния домейн, така и за подсайтове, и дори за пощенски услуги.
Самият Plesk в момента е доста приятен и стабилен софтуер. Автоматично обновява себе си и операционната система, консумира малко ресурси и работи точно. Дори не помня да съм имал проблеми, които да са очевиден дефект на продукта. Разбира се, имаше проблеми, но те бяха или от недостатъците на конфигурацията, или на границата между нещо, така че не мога да се оплача значително. Впечатленията ми от работата с Plesk са по принцип положителни. Какво му липсва, и това трябва да се разбира, е всякаква (каквато и да е) кластеризация. Нито LB, нито HA. Може да се опитате, но вложените усилия ще са толкова много, че е по-добре да правите нещо по различен начин отначало.
Мисля, че можем да обобщим. В случай, когато няма администратор или е малко, когато цената на хостинга и на сайта(овете), които работят на него, надвишава, да речем, 100 у.е., когато не говорим за споделен хостинг с 1500 сайта на един сървър, когато пред решаващия се поставя избор дали да наеме администратор на непълно работно време, или да купи софтуер и да назначи администратор на "половин заплата", или изобщо да не наема такъв — определено има смисъл. От гледна точка на отдалечен администратор — същото. 10$ на месец, а спестява време и придава гъвкавост на работата на много б.оПо-голяма сума. Ако, например, много ме помолят да поема подобен проект, ще настоявам за преместване на Plesk.
Източник: habr.com
