Хочу поділитися деякими враженнями про необхідність чи непотрібність такої речі, як контрольна панель для комерційного односерверного веб-проекту за наявності дуже part time адміну. Історія почалася кілька років тому, коли знайомі знайомих попросили мене супроводити покупку бізнесу — сайту новин — з технічної точки зору. Потрібно було трохи вникнути, що на чому працює, простежити, щоб усі необхідні реквізити були передані у належному вигляді та обсязі, і стратегічно прикинути, що можна покращити.
Угода відбулася, скрипаль став не потрібен. Кінець. Насправді ні.
Сайт крутився на двоядерній 4х-гіговій ВМці на Linode, на якомусь замшелому Debian5 з аптаймом днів у 400 і оооот таким списком неоновлених пакетів. Веб-частина на самописній ЦМСке, nginx, php5.3 FPM, mysql тюнена Percona. В принципі працювало.
Паралельно з розмовами зі мною новий власник шукав програміста для приведення проекту до очікувань. Знайшов. Програміст оцінив трафік та обсяги та вирішив, що вміє в оптимізацію та cost management. Він змігрував весь сайт на 700-рублевий шаред хостинг під керуванням звичного йому IS****er. Через кілька днів знову дзвінок від власника: "все гальмує і здається нас поламали". Я намагався виправити ситуацію через панель, але після деякого часу безплідних спроб змінити версію ПХП або хендлера з fcgi на fpm, здався, і поліз у шелл. Там я знайшов включений дебаг, який світив на весь інтернет паролем від м'яза, 777 на деякі папки, які на той момент тріщали від залитої малварі та подібну дичину. Власник усвідомив і вирішив, що економити на хостингу, програмісті та адміні, який би поглядав одним оком, як йдуть справи — неправильно.
Їдемо на RuVDS. Трохи ближче, ніж британська Linode, і якщо раптом захочеться зберігати персональні дані і все це, не доведеться більше нікуди переїжджати. Так як проект планувалося розширювати, взяли ВМку "на виріст": 4 ядра, 8 гіг пам'яті, 80ГБ диска. Не те щоб я не вмію в конфігі nginx руками, просто ентузіазму займатися цим проектом настільки інтимно у мене не було (див. вище про part time). Тому - поставив Plesk (тут я опущу подробиці установки, тому що їх за великим рахунком немає: запустив інсталер, поставив пароль на адміна, ввів ключ - все), на той час це був 17.0. Базові налаштування непогано працюють із коробки, є fail2ban та останні доступні версії PHP, nginx.
Мабуть, варто зупинитись і пояснити, чому його. Оскільки я займаюся такими речами рідко, і ніякого особливого інструментарію та набору заготовок на кожен випадок у мене немає, зрозуміло було, що потрібна якась автоматизація базових речей, щоб по-перше швидко, по-друге безпечно, по-третє, всі best practices хтось уже запровадив.
Отже, поставив. Часу заощадив пристойно, перезапуск сайту на новому сервері вийшов практично миттєвим. Залишалося пильнувати м'язовий конфіг, видавши йому половину пам'яті і збільшивши число buffer pools, і віддати nginx половину ядер (Плеск не чіпає глобальні конфіги), і протягом кількох днів заходити в шелл подивитися на стати mysqltuner. Так, і купив платний ImunifyAV з каталогу розширень, щоб позбутися залитої малварі. Знайшлися щось 11000 XNUMX заражених файлів. Гидота в тому, що в статику вливались шматки коду, і чистити це руками було б зовсім похмуро. Спочатку я спробував ClamAV, але він, як виявилось, такі штуки не бере, а ImunifyAV зміг. Причому вилікувані файли залишаються в робочому стані, просто видаляється шматок з малварью.
Арифметика проста: 50 $ на місяць за ВМку, 10 $ за Плеск (насправді менше, тому що купили відразу на рік зі знижкою в два місяці) та 3 $ за антивірус. Або багато валіз грошей за мій час, який я б провів на сервері спочатку розгрібаючи ці стайні вручну. Власника такий розклад цілком влаштував.
Тим часом знайшли нового програміста. Домовилися з ним про розподіл відповідальності, зробили піддомен для тестової версії та пішла робота. Він пиляв нову версію сайту на Laravel, а я поглядав на fail2ban%).
Цікаво, що потік тих, хто цікавиться, не припиняється і в списку забанених завжди близько сотні адрес. Ефект цікавий: зокрема, зазвичай, якщо я заходжу в шелл, на привітанні бачу близько 20000-30000 невдалих спроб заходу SSH. З увімкненим fail2ban близько 70. Вкладених зусиль: 0. Без крапельки дьогтю, на жаль, не обійшлося. За замовчуванням був напівувімкнений WAF (modsecurity): в режимі виявлення. Тобто він писав підозрілу активність у балку, але фактично ніяких дій не робив. А fail2ban без розбору читав усі логи, згідно з включеними jails, і мочив все, що ворушиться. Таким чином, ми забанили половину редакції :D. Довелося відключити цей jail, а потрібні IP-адреси для надійності внести до білого списку. Зусиль вкладено: двічі мишкою потикати і навчити редакторів сказати свою IP-адресу.
Що відразу припало до смаку програмісту — можливість заливати бази даних прямо в панелі та швидкий доступ до phpMyAdmin
Що мені сподобалося — логи та бекапи. Логи пишуться та ротуються самі з коробки; бекапи налаштовуються дуже просто. Наймлявіший час робиться повний бекап, десь на 10 гігів, і потім щодня по інкрементальному, мегабайт по 200, протягом тижня. Відновлення гранулярне до конкретного файлу або бази даних. Якщо потрібно відновити з інкрементального, то не потрібно коритися спочатку з повним і рестором всього ланцюжка, Плеск робить все сам. Заливати бекапи можна куди завгодно: на фтп, на dropbox, s3 bucket, google drive та інші.
День Ж: програміст нарешті докучав новий двигун, ми його залили в прод, імпортували старі дані і сіли вибирати колір своїх майбутніх Мазераті. Досі сидимо вибираємо.
Почалися перші проблеми. Новий сайт був очікувано важчим за старий, але реальна грабля була в тому, що для залучення трафіку користувалися серед іншого Yandex.Zen, який наганяв відвідувачів пачками. Сайт загинався при 150 одночасних підключеннях (я не говорю про RPS, тому що не заміряли). Почали тикати кнопки та крутити ручки в області налаштувань php_fpm:
Оп уже тримає 500 коннектів. У міру застосування кредитки до засобів просування хвилі трафіку стали більше. Наступний milestone 1000 одночасних підключень. Тут довелося порефайнувати код і подивитися в душу м'яз. Сплеск у цьому не допоміг, але цього особливо й не чекали. Включили slow queries log, навішували індексів на базу, прибрали зайві запити з коду, ще раз зачесали конфіг mysql за порадами mysqltuner.
Новий челендж - 2000 коннектів. Встигла вийти версія Plesk 17.8, в якій також прикрутили nginx caching. Обновилися (напрочуд легко). Пробуємо. Працює! І тут же настали у м'якому, перестав працювати фід Яндекс.дзена. Сайт працює, фід не працює. Не працює ФІД, немає трафіку. Атмосфера розжарюється. Під тиском обставин і від нестачі фантазії поліз одразу straceіть nginx і знайшов, що шукав. Виявляється, в якийсь момент дурний nginx закешував залітну 500 помилку в якості відповіді на яндексовий get feed.xml. Виправили, додавши винятки в налаштування кешу:
Зрозуміло, що власнику потрібно ЩЕ, хвилі потихеньку збільшуються. Поки справляємося, але заздалегідь почали експериментувати з memcached, благо Laravel підтримує його майже з коробки. Ставити memcached руками для "погратися" якось не хотілося, тому поставили докер образ. Прямо із панелі.
Ну гаразд, брешу, довелося зайти в шелл і поставити модуль через pecl. Прямо по . Сказати про приріст пропускної спроможності поки що нічого, чималих напливів не було. Двигун сайту підчепився на localhost:11211, стати показуються, пам'ять жерться. Якщо сподобається, побачимо, що робити далі. Або так і залишимо, або поставимо справжній прямо в Ось. Або так само спробуємо redis
Потім знадобилося зробити поштову розсилку. Жодних релеїв, тільки smtp authentication. Завів поштову адресу, через його реквізити через PHP робимо розсилку.
Нещодавно вийшов Plesk Obsidian (18.0), оновилися за минулим досвідом без страху. Все пройшло дуже гладко, навіть розповісти нема про що. Із приємного - сильно підтягнувся за якістю інтерфейс, осучаснився і став у деяких місцях зручнішим. Прикольна штука Advanced Monitoring на Grafana.
Поки що докладно з нею не розбирався, але можна, наприклад, налаштувати алерти за будь-яким параметром у пошту. Власнику, лол.
Якщо я говорю про інтерфейс, він адаптивний і реально непогано працює на телефоні. На ранніх стадіях, поки ми намагалися знайти оптимальні налаштування PHP та іншого, це сильно виручало. І особливо коли програміст у нападі робочого ентузіазму щось робить у 23 години, а я в приступі робочого ентузіазму п'ю горілку в лазні, і ТЕРМІНОВО треба щось переключити.
О, до речі. На зображенні видно, з'явився PHP Composer. Поки не гралися з ним, але, скажімо, для того ж Laravel він може секономити пару логінів в шелл і якийсь час на встановлення залежностей. Така сама система є для Node.JS та Ruby.
З SSL все просто. Якщо домен резолвується куди належить, Let's Encrypt робиться одним кліком і оновлюється далі сам, причому як сам домен, так і субдомени, і навіть поштові сервіси.
Сам Plesk як софтина на даний час досить приємний і стабільний. Оновлює сам себе і ось тихо, ресурсів споживає мало, працює рівно. Навіть не пам'ятаю, що десь на щось настав, що було б явним дефектом продукту. Проблеми звичайно були, але вони або від недосконалості конфігурації, або десь на стику, так що причепитися особливо нема до чого. Враження від роботи з Плеском загалом приємні. Чого в ньому немає, і треба це розуміти, так це будь-якої кластеризації. Ні LB, ні HA. Намагатися можна, але вкладених зусиль буде стільки, що краще робити щось по-іншому.
Думаю, можна підсумувати. Для випадку, коли адміну немає, або його мало, коли ціна хостингу і сайту(ів), що крутиться на ньому, перевищує, ну, скажімо, 100 у. стоїть вибір найняти адміна на півставки, або купити софт і завести адміна на «півшишки», або взагалі його не заводити - сенс безперечно є. З погляду віддаленого адміну — те саме. 1500 $ на місяць, а економить часу і надає гнучкості в роботі на дуже бобільшу суму. Якщо, наприклад, мене сильно попросять взяти аналогічний проект під крильце, я наполягатиму на перевезенні на Plesk.
Джерело: habr.com