Искам да споделя някои впечатления относно необходимостта или ненужността на нещо като контролен панел за търговски уеб проект с един сървър при наличие на много частичен администратор. Историята започна преди две години, когато познати на познати ме помолиха да придружавам покупката на бизнес — новинарски сайт — от техническа гледна точка. Нужно беше малко да се запозная с частите, да проследя, че всички необходими реквизити са предадени в правилния вид и обем, и стратегически да преценя какво може да се подобри.
Сделката беше сключена, а цигуларят стана ненужен. Край. Всъщност не.
Сайтът работеше на двуядрен 4-гигабайтов ВМ на Linode, на някакъв остарял Debian5 с аптайм от 400 дни и ето такъв списък от необновени пакети. Уеб частта беше на самописана CMS, nginx, php5.3 FPM, mysql, настроен Percona. В принципе, работеше.
Паралелно с разговорите с мен новият собственик търсеше програмист за адаптиране на проекта към очакванията. Намери го. Програмистът оцени трафика и обемите и реши, че разбира от оптимизация и управление на разходите. Той мигрира целия сайт на 700-рублев хостинг с управление от познатия му IS****er. След няколко дни отново обаждане от собственика: „всичко забавя и изглежда, че ни хакнаха“. Опитвах се да поправя ситуацията през панела, но след малко безуспешни опити да сменя версията на PHP или хендлера от fcgi на fpm, се предадох и влязох в шелл. Там намерих включен дебаг, който светеше на целия интернет с паролата от mysql, 777 на някои папки, които по това време крещяха от залетяла малуер и подобна глупост. Собственикът осъзна и реши, че е неправилно да се пести от хостинг, програмист и администратор, който да наблюдава с едно око как вървят нещата.
Преминаваме на RuVDS. Много по-близо от британската Linode, и ако случайно решите да съхранявате лични данни и подобни неща, няма да се налага да се местите никъде другаде. Тъй като проектът планираме да разширим, взехме виртуален сървър "за напред": 4 ядра, 8 гигабайта памет, 80ГБ диск. Не че не мога да конфигурирам nginx на ръка, просто не ми беше толкова ентусиазирано да се занимавам с този проект в детайли (вижте по-горе за part time). Затова — инсталирах Plesk (тук ще пропусна подробности за инсталацията, защото всъщност няма какво да се казва: стартирах инсталатора, зададох парола за администратора, въведох ключа –и готово), тогава версията беше 17.0. Основните настройки работят приемливо от кутията, има fail2ban и последните налични версии на PHP, nginx.
Може би трябва да спра и да обясня защо именно него. Тъй като рядко се занимавам с такива неща и нямам специални инструменти и шаблони за всеки случай, ясно беше, че се нуждая от някаква автоматизация на основните неща, за да бъде, на първо място, бързо, на второ — безопасно, и на трето — всичките добри практики да са вече внедрени от някой друг.
И така, инсталирах го. Спестих доста време, рестартирането на сайта на новия сървър стана практически моментално. Оставаше да нагаждам конфигурацията на MySQL, като му дам половината памет и увелича числото на buffer pools, и да предоставя на nginx половината ядра (Plesk не пипа глобалните конфигурации), и през следващите дни да надникна в шелла, за да проверя статистиките на mysqltuner. Да, и купих платен ImunifyAV от каталога на разширенията, за да се отърва от качената зловредна програма. Открих около 11000 заразени файла. Ужасното е, че в статичните файлове влизаха обфусцирани парчета код и да ги чистя на ръка щеше да бъде съвсем бедствиe. Първо опитах с ClamAV, но той, както се оказа, не хваща такива неща, а ImunifyAV успя. Освен това излекуваните файлове остават в работно състояние, просто се изтрива парче с зловреден софтуер.
Арифметиката е проста: 50$ на месец за виртуален сървър, 10$ за Plesk (в действителност по-малко, защото купихме веднага за година с отстъпка от два месеца) и 3$ за антивирус. Или много куфари пари за времето ми, което бих прекарал на сървъра, в началото разчиствайки тези конюшни на ръка. Такъв график устройваше собственика.
Междувременно намерили нов программист. Споразумяхме се с него за разпределение на отговорностите, направихме поддомейн за тестова версия и работата започна. Той работеше над новата версия на сайта на Laravel, а аз следях fail2ban %).
Интересно е, че потокът от любопитни не спира и в списъка на забранените адреси винаги има около сто. Ефектът е интересен: обикновено, когато влизам в shell, в приветствието виждам около 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. Обновихме се (за удивление, много лесно). Пробваме. Работи! И веднага попаднахме на проблем, спря да работи фидът на Яндекс.дзен. Сайтът работи, фидът не. Не работи фидът, няма трафик. Атмосферата напряга. Под натиска на обстоятелствата и от липсата на фантазия, реших веднага да направя strace на 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 часа, а аз в момент на работен ентусиазъм пия водка в банята и НАЛОЖИТЕЛНО трябва нещо да се превключи.
А, между другото. На картинката се вижда, че се е появил PHP Composer. Все още не сме експериментирали с него, но, да кажем, за Laravel може да спести няколко входа в шелл и известно време за инсталиране на зависимости. Подобна система съществува и за Node.JS и Ruby.
С SSL всичко е просто. Ако домейнът се резолвира където трябва, Let’s Encrypt става с едно кликване и след това се обновява сам, както за самия домейн, така и за субдомените, и дори за пощенските услуги.
Самият Plesk като софтуер в момента е доста приятен и стабилен. Обновява сам себе си и ОС тихо, консумира малко ресурси, работи гладко. Дори не си спомням да съм се сблъскал с нещо, което да е явен дефект на продукта. Проблеми, разбира се, е имало, но те или са от несъвършенството на конфигурацията, или от нещо на границата, така че няма много за какво да се оплакваме. Впечатленията от работата с Plesk в цялост са положителни. Какво му липсва, и това трябва да се разбере, е всякаква (коя да е) кластеризация. Нито LB, нито HA. Може да се опитате, но вложените усилия ще бъдат толкова много, че е по-добре да се направи нещо по различен начин отначало.
Мисля, че можем да обобщим. За случая, когато администратора го няма, или го има малко, когато цената на хостинга и на сайтовете, които се въртят на него, надвишава, да кажем, 100 евро, когато не става въпрос за натрапчивия споделен хостинг с 1500 сайта на сървъра, когато пред взимащия решение стои изборът да наеме администратор на половин работен ден, или да купи софтуер и да назначи администратор на „половин заплата“, или въобще да не го наема - определено има смисъл. От гледна точка на отдалечен администратор - същото. 10$ на месец, а спестява време и придава гъвкавост в работата на много по-голяма сума. Ако, например, много ми поискаха да поема аналогичен проект, ще настоявам за мигрирането му на Plesk.по-Искам да споделя някои впечатления относно нуждата или ненуждата от нещо, като контролен панел за търговски едносерверен уеб проект при наличие на много частичен администратор.
Източник: habr.com
