Бих искал да споделя някои впечатления относно необходимостта или ненужността на такова нещо като контролен панел за комерсиален едносървърен уеб проект с много постоянен администратор. Историята започна преди няколко години, когато приятели на приятели ме помолиха да съдействам за закупуването на бизнес - новинарски сайт - от техническа гледна точка. Беше необходимо да се задълбочим малко в това какво работи върху какво, да се уверим, че всички необходими подробности са прехвърлени в правилната форма и обем, и стратегически да разберем какво може да се подобри.
Сделката беше завършена, цигуларят вече не беше необходим. Край. Не точно.
Сайтът работеше на двуядрена 4-GB виртуална машина на Linode, на някакъв мъхест Debian5 с време на работа от 400 дни и такъв списък с неактуализирани пакети. Уеб част на собствено написана CMS, nginx, php5.3 FPM, mysql настроена Percona. По принцип се получи.
Успоредно с разговорите с мен, новият собственик търсеше програмист, който да доведе проекта до очакванията. Намерени. Програмистът оцени трафика и обемите и реши, че знае как да оптимизира и управлява разходите. Той мигрира целия сайт към споделен хостинг за 700 рубли, управляван от обичайния му IS****er. Няколко дни по-късно имаше още едно обаждане от собственика: „всичко върви бавно и изглежда, че сме разбити“. Опитах се да коригирам ситуацията чрез панела, но след известно време на безплодни опити да сменя PHP версията или манипулатора от fcgi на fpm, се отказах и влязох в shell-а. Там намерих активиран дебъг, който светеше в целия интернет с паролата от мускула, 777 на някои папки, които по това време се кракваха със зловреден софтуер и подобни глупости. Собственикът осъзна и реши, че е грешно да се пести от хостинг, програмист и администратор, който да следи как вървят нещата.
Отиваме в RuVDS. Малко по-близо от британския Linode и ако изведнъж искате да съхранявате лични данни и всичко това, няма да се налага да се местите никъде другаде. Тъй като проектът беше планиран да бъде разширен, взехме VM за растеж: 4 ядра, 8 гигабайта памет, 80 GB диск. Не че не знам как да конфигурирам ръчно конфигурациите на nginx, просто нямах ентусиазма да работя по този проект толкова интимно (вижте по-горе за непълно работно време). Ето защо инсталирах Plesk (тук ще пропусна подробностите за инсталацията, защото като цяло няма такива: стартирах инсталатора, зададох паролата за администратора, въведох ключа - това е всичко), по това време беше 17.0. Основните настройки работят сносно извън кутията, има fail2ban и последните налични версии на PHP и nginx.
Вероятно си струва да спрем и да обясним защо. Тъй като рядко правя такива неща и нямам специални инструменти или набор от препарати за всеки случай, беше ясно, че е необходима някаква автоматизация на основни неща, така че първо бързо, второ безопасно и трето , всички най-добри практики някой вече го е приложил.
И така, инсталирах го. Спестих много време, рестартирането на сайта на нов сървър беше почти моментално. Всичко, което остана, беше да редактирам мускулната конфигурация, давайки й половината памет и увеличавайки броя на буферните пулове, и да дам на nginx половината ядра (Plesk не докосва глобалните конфигурации) и за няколко дни отидете в обвивката, за да погледнете в статистиката на mysqltuner. Да, и купих платения ImunifyAV от каталога с разширения, за да се отърва от наводнения зловреден софтуер. Открити са около 11000 XNUMX заразени файла. Отвратителното е, че в статиката бяха изсипани объркани парчета код и почистването на ръка би било напълно скучно. Първо опитах ClamAV, но както се оказа, той не приема такива неща, но ImunifyAV може. Освен това дезинфекцираните файлове остават в работно състояние, частта със зловреден софтуер просто се изтрива.
Аритметиката е проста: $50 на месец за VMka, $10 за Plesk (всъщност по-малко, защото сте го купили за една година наведнъж с двумесечна отстъпка) и $3 за антивирусна. Или много пари за времето ми, което щях да похарча на сървъра в началото, рейквайки тези конюшни ръчно. Собственикът беше много доволен от това споразумение.
Междувременно намериха нов програмист. С него се разбрахме за разпределението на отговорността, създадохме поддомейн за тестовата версия и работата започна. Той изрязваше нова версия на сайта на Laravel, а аз гледах fail2ban%).
Интересното е, че потокът от любопитни хора не спира и в списъка на забранените винаги има около стотина адреса. Ефектът е интересен: по-специално, обикновено, ако вляза в shell, виждам около 20000 30000-2 70 неуспешни опита за влизане през SSH при поздрава. С активиран fail0ban, около 2. Инвестирани усилия: XNUMX. За съжаление не мина без капка мехлем. По подразбиране WAF (modsecurity) беше наполовина активиран: в режим на откриване. Тоест той записва подозрителна активност в дневника, но всъщност не предприема никакви действия. И failXNUMXban прочете безразборно всички логове, според активираните затвори, и уби всичко, което се движи. Така баннахме половината редактори :D. Трябваше да деактивирам този затвор и да поставя в белия списък необходимите IP адреси за надеждност. Инвестирани са усилия: бутнете мишката два пъти и научете редакторите да ви кажат вашия IP адрес.
Това, което програмистът веднага хареса, беше възможността за качване на бази данни директно в панела и бърз достъп до phpMyAdmin
Това, което ми хареса, бяха регистрационните файлове и архивите. Дневниците се записват и завъртат извън кутията; Архивирането се настройва много лесно. В най-бавните времена се прави пълен бекъп, около 10 гига, а след това всеки ден инкрементален, по 200 мегабайта, за една седмица. Възстановяването е детайлно, до конкретен файл или база данни. Ако трябва да възстановите от инкрементален, тогава не е нужно първо да се занимавате с пълно и възстановяване на цялата верига, Plesk прави всичко сам. Можете да качвате резервни копия навсякъде: на FTP, dropbox, s3 bucket, google диск и др.
Ден F: програмистът най-накрая завърши новия двигател, качихме го в производство, импортирахме стари данни и седнахме да изберем цвета на нашето бъдещо Maserati. Още седим и избираме.
Започнаха първите проблеми. Новият сайт беше очаквано по-тежък от стария, но истинската печалба беше, че за привличане на трафик те използваха, наред с други неща, Yandex.Zen, който доведе много посетители. Сайтът се срина със 150 едновременни връзки (не говоря за RPS, защото не го мериха). Започнахме да натискаме бутони и да въртим копчета в областта за настройки на php_fpm:
Хей, той вече има 500 връзки. Тъй като кредитните карти бяха добавени към средствата за промоция, вълните от трафик станаха по-големи. Следващият етап е 1000 едновременни връзки. Тук трябваше да преработим кода и да надникнем в душата на мускула. Пръскането не помогна, но всъщност не го очаквахме. Активирахме журнала на бавните заявки, добавихме индекси към базата данни, премахнахме ненужните заявки от кода и отново почистихме конфигурацията на mysql според съвета на mysqltuner.
Ново предизвикателство - 2000 връзки. Току-що успя да бъде пусната версията на Plesk 17.8, в която, наред с други неща, беше добавено кеширане на nginx. Актуализирано (изненадващо лесно). Да опитаме. Върши работа! И тогава те стъпиха на меката страна, емисията Yandex.Zen спря да работи. Сайтът работи, фийдът не работи. Захранването не работи, няма трафик. Атмосферата се нажежава. Под натиск на обстоятелствата и поради липса на въображение, веднага отидох на strace и nginx и намерих това, което търсех. Оказва се, че в някакъв момент глупавият nginx е кеширал заблудената 500-та грешка като отговор на Yandex get feed.xml. Поправено е чрез добавяне на изключения към настройките на кеша:
Ясно е, че собственикът има нужда от ОЩЕ, вълните бавно се увеличават. Засега се справяме, но започнахме да експериментираме с memcached предварително, за щастие Laravel го поддържа почти веднага. Някак си не исках да инсталирам memcached ръчно само за да си „играя“, затова инсталирах докер изображение. Направо от панела.
Е, добре, лъжа, трябваше да вляза в shell-а и да инсталирам модула чрез pecl. Точно на . За увеличението на пропускателната способност все още няма какво да се каже, няма достатъчно големи напливи. Енджинът на сайта е свързан към localhost:11211, показва се статистика, паметта се изразходва. Ако ти харесва, ще видим какво ще правим по-нататък. Или ще го оставим така, или ще поставим „истинския“ точно в Оста. Или нека опитаме redis по същия начин
След това беше необходимо да се прикачи пощенски списък. Без релета, само smtp удостоверяване. Настройвам имейл адрес и използвам данните му, за да изпращам бюлетин чрез PHP.
Неотдавна беше пуснат Plesk Obsidian (18.0), ние актуализирахме въз основа на предишен опит без страх. Всичко мина много гладко, дори няма какво да говорим. Приятното е, че качеството на интерфейса се подобри значително, той стана по-модерен и на места стана по-удобен. Готино нещо Advanced Monitoring на Grafana.
Все още не съм се занимавал с него подробно, но можете например да настроите предупреждения за всеки параметър в имейла си. До собственика, хаха.
Докато говоря за интерфейса, той е отзивчив и работи много добре на телефона. В ранните етапи, докато се опитвахме да намерим оптималните настройки за PHP и други неща, това помогна много. И особено когато програмист, в пристъп на работен ентусиазъм, прави нещо в 23:XNUMX, а аз, в пристъп на работен ентусиазъм, пия водка в банята и СПЕШНО трябва да сменя нещо.
О, между другото. Картината показва, че PHP Composer се появи. Все още не сме си играли с него, но, да речем, за Laravel може да спести няколко влизания в shell и известно време за инсталиране на зависимости. Същата система съществува за Node.JS и Ruby.
С SSL всичко е просто. Ако домейнът се разреши според очакванията, Let’s Encrypt се извършва с едно щракване и след това се актуализира, както за самия домейн, така и за поддомейни и дори за пощенски услуги.
Самият Plesk като софтуер в момента е доста приятен и стабилен. Актуализира себе си и Axis тихо, консумира малко ресурси и работи гладко. Дори не си спомням някъде да съм стъпил на нещо, което би било явен дефект на продукта. Имаше проблеми, разбира се, но те се дължаха или на несъвършена конфигурация, или някъде на кръстовището, така че няма какво да се оплаквате. Впечатленията от работата с Plesk като цяло са приятни. Това, което няма и трябва да разберем това, е всяко (всяко) групиране. Нито LB, нито HA. Можете да опитате, но вложените усилия ще бъдат толкова много, че е по-добре да направите нещо различно от самото начало.
Мисля, че можем да го обобщим. За случая, когато няма администратор или той е недостатъчен, когато цената на хостинга и въртящия се на него сайт(ове) надвишава, да речем, 100 USD, когато не говорим за зверско споделяне на 1500 сайтове на сървър, когато вземащият решение е изправен пред Ако имате избор да наемете администратор на непълен работен ден или да закупите софтуер и да имате администратор за половин долар, или изобщо да нямате такъв - определено има смисъл. От гледна точка на отдалечения администратор - същата работа. $10 на месец, и спестява време и дава гъвкавост в работата за много дълго времеопо-голяма сума. Ако, например, настоятелно ме помолят да взема подобен проект под мое крило, ще настоявам да го прехвърля на Plesk.
Източник: www.habr.com