Mon expérience avec Plesk

Je voudrais partager quelques impressions sur la nécessité ou l'inutilité d'un panneau de contrôle pour un projet Web commercial à serveur unique avec un administrateur à temps très partiel. L'histoire a commencé il y a quelques années, lorsque des amis d'amis m'ont demandé de les accompagner dans l'achat d'une entreprise - un site d'information - d'un point de vue technique. Il était nécessaire d'approfondir un peu ce qui fonctionnait sur quoi, de s'assurer que tous les détails nécessaires étaient transférés sous la forme et le volume appropriés et de déterminer stratégiquement ce qui pouvait être amélioré.

L'affaire était conclue, le violoniste n'était plus nécessaire. Fin. Pas vraiment.

Le site fonctionnait sur une machine virtuelle bicœur de 4 Go hébergée sur Linode, sur un serveur assez moussu. DebianUn serveur 5 avec 400 jours de disponibilité et une très longue liste de paquets non mis à jour. La partie web utilise un CMS personnalisé, nginx, PHP 5.3 FPM et une base de données MySQL Percona optimisée. Globalement, ça fonctionnait.

Parallèlement aux conversations avec moi, le nouveau propriétaire recherchait un programmeur pour mener le projet à la hauteur des attentes. Trouvé. Le programmeur a évalué le trafic et les volumes et a décidé qu'il savait comment optimiser et gérer les coûts. Il a migré l'intégralité du site vers un hébergement mutualisé à 700 roubles géré par son IS****er habituel. Quelques jours plus tard, un autre appel du propriétaire : « tout est lent et il semble que nous soyons en panne ». J'ai essayé de corriger la situation via le panneau, mais après un certain temps de tentatives infructueuses pour changer la version ou le gestionnaire PHP de fcgi en fpm, j'ai abandonné et suis entré dans le shell. Là, j'ai trouvé un débogage activé qui brillait sur tout Internet avec le mot de passe du muscle, 777 sur certains dossiers qui, à ce moment-là, craquaient avec des logiciels malveillants et des absurdités similaires. Le propriétaire s'est rendu compte et a décidé qu'il n'était pas bon d'économiser sur l'hébergement, un programmeur et un administrateur capable de surveiller l'évolution des choses.

Nous allons au RuVDS. Un peu plus proche que le British Linode, et si du coup vous souhaitez stocker des données personnelles et tout ça, vous n’aurez pas à vous déplacer ailleurs. Comme il était prévu d'étendre le projet, nous avons pris une VM pour la croissance : 4 cœurs, 8 Go de mémoire, 80 Go de disque. Ce n’est pas que je ne sais pas comment configurer manuellement les configurations nginx, je n’ai tout simplement pas eu l’enthousiasme de travailler si intimement sur ce projet (voir ci-dessus à propos du temps partiel). C'est pourquoi j'ai installé Plesk (ici j'omettrai les détails d'installation, car dans l'ensemble il n'y en a pas : j'ai lancé le programme d'installation, défini le mot de passe de l'administrateur, entré la clé - c'est tout), à cette époque c'était 17.0. Les paramètres de base fonctionnent assez bien, il existe fail2ban et les dernières versions disponibles de PHP et nginx. 

Cela vaut probablement la peine de s’arrêter et d’expliquer pourquoi. Comme je fais rarement de telles choses et que je n'ai pas d'outils spéciaux ni d'ensemble de préparations pour chaque cas, il était clair qu'une sorte d'automatisation des choses de base était nécessaire, afin que premièrement, rapidement, deuxièmement, en toute sécurité et troisièmement , toutes les bonnes pratiques quelqu'un l'a déjà mis en œuvre.

Alors, je l'ai installé. J'ai gagné beaucoup de temps, le redémarrage du site sur un nouveau serveur a été quasi instantané. Il ne restait plus qu'à éditer la configuration musculaire, en lui donnant la moitié de la mémoire et en augmentant le nombre de pools de tampons, et à donner à nginx la moitié des cœurs (Plesk ne touche pas aux configurations globales), et pendant quelques jours, allez dans le shell pour regarder aux statistiques de mysqltuner. Oui, et j'ai acheté ImunifyAV payant dans le catalogue d'extensions pour me débarrasser des logiciels malveillants inondés. Quelque 11000 XNUMX fichiers infectés ont été détectés. L'abomination est que des morceaux de code obscurcis ont été versés dans les statiques, et les nettoyer à la main aurait été complètement ennuyeux. J’ai d’abord essayé ClamAV, mais il s’est avéré que cela ne prend pas de telles choses, mais ImunifyAV le pourrait. De plus, les fichiers désinfectés restent en état de fonctionnement ; la partie contenant le malware est simplement supprimée.

Le calcul est simple : 50 $ par mois pour VMka, 10 $ pour Plesk (en fait moins, car vous l'avez acheté pour un an d'un coup avec une remise de deux mois) et 3 $ pour l'antivirus. Ou beaucoup d'argent pour mon temps, que j'aurais d'abord dépensé sur le serveur, en ratissant ces écuries manuellement. Le propriétaire était très satisfait de cet arrangement.

Entre-temps, ils ont trouvé un nouveau programmeur. Nous nous sommes mis d'accord avec lui sur la répartition des responsabilités, avons créé un sous-domaine pour la version test et le travail a commencé. Il était en train de créer une nouvelle version du site sur Laravel, et je regardais fail2ban%).

Fait intéressant, le flux de curieux ne s'arrête pas et il y a toujours une centaine d'adresses sur la liste des adresses interdites. L'effet est intéressant : en particulier, généralement, si je me connecte à un shell, je vois environ 20000 30000 à 2 70 tentatives infructueuses de connexion via SSH au message d'accueil. Avec fail0ban activé, environ 2. Efforts investis : XNUMX. Malheureusement, cela n’a pas été sans une goutte de pommade. Par défaut, WAF (modsecurity) était à moitié activé : en mode découverte. Autrement dit, il a écrit une activité suspecte dans le journal, mais n’a en réalité pris aucune mesure. Et failXNUMXban a lu sans discernement tous les journaux, selon les prisons activées, et a tué tout ce qui bougeait. Ainsi, nous avons banni la moitié des rédacteurs :D. J'ai dû désactiver cette prison et mettre sur liste blanche les adresses IP nécessaires pour des raisons de fiabilité. Des efforts sont investis : poussez deux fois la souris et apprenez aux éditeurs à vous indiquer votre adresse IP.

Ce que le programmeur a immédiatement apprécié, c'est la possibilité de télécharger des bases de données directement dans le panneau et un accès rapide à phpMyAdmin.

Ce que j'ai aimé, ce sont les journaux et les sauvegardes. Les journaux sont écrits et tournés hors de la boîte ; Les sauvegardes sont très simples à mettre en place. Aux moments les plus lents, une sauvegarde complète est effectuée, environ 10 Go, puis chaque jour une sauvegarde incrémentielle, de 200 Mo chacune, pendant une semaine. La récupération est granulaire, jusqu'à un fichier ou une base de données spécifique. Si vous avez besoin d'une restauration à partir d'une restauration incrémentielle, vous n'avez pas besoin de vous soucier d'abord d'une restauration complète et complète de la chaîne entière, Plesk fait tout lui-même. Vous pouvez télécharger des sauvegardes n'importe où : sur FTP, Dropbox, S3 Bucket, Google Drive, etc.

Jour F : le programmeur a finalement terminé le nouveau moteur, nous l'avons téléchargé en production, importé d'anciennes données et nous nous sommes assis pour choisir la couleur de notre future Maserati. Nous sommes toujours assis et choisissons.

Les premiers problèmes ont commencé. Le nouveau site était censé être plus lourd que l'ancien, mais le véritable avantage était que, pour attirer du trafic, ils utilisaient, entre autres, Yandex.Zen, qui attirait de nombreux visiteurs. Le site crashait avec 150 connexions simultanées (je ne parle pas du RPS, car ils ne l’ont pas mesuré). Nous avons commencé à appuyer sur les boutons et à les tourner dans la zone des paramètres de php_fpm :
 

Hé, il a déjà 500 connexions. À mesure que les cartes de crédit ont été ajoutées aux moyens de promotion, les vagues de trafic sont devenues plus importantes. La prochaine étape est celle des 1000 XNUMX connexions simultanées. Ici, nous avons dû retoucher le code et examiner l'âme du muscle. Les éclaboussures n’ont pas aidé, mais nous ne nous y attendions pas vraiment. Nous avons activé le journal des requêtes lentes, ajouté des index à la base de données, supprimé les requêtes inutiles du code et nettoyé à nouveau la configuration mysql selon les conseils de mysqltuner.

Nouveau défi - 2000 connexions. La version de Plesk 17.8 vient de sortir, dans laquelle, entre autres, la mise en cache nginx a été ajoutée. Mis à jour (étonnamment facile). Essayons. Travaux! Et puis ils ont marché du côté doux, le flux Yandex.Zen a cessé de fonctionner. Le site fonctionne, le flux ne fonctionne pas. Le flux ne fonctionne pas, il n'y a pas de trafic. L’atmosphère se réchauffe. Sous la pression des circonstances et par manque d'imagination, je me suis immédiatement rendu chez strace et nginx et j'ai trouvé ce que je cherchais. Il s'avère qu'à un moment donné, Nginx stupide a mis en cache la 500ème erreur parasite en réponse à Yandex get feed.xml. Correction du problème en ajoutant des exceptions aux paramètres du cache :

Il est clair que le propriétaire a besoin de PLUS, les vagues augmentent lentement. Nous nous en sortons pour l'instant, mais nous avons commencé à expérimenter Memcached à l'avance, heureusement, Laravel le prend en charge presque immédiatement. D'une manière ou d'une autre, je ne voulais pas installer memcached manuellement juste pour « jouer », alors j'ai installé une image Docker. Directement depuis le panneau.

Bon, d'accord, je mens, j'ai dû aller dans le shell et installer le module via pecl. Directement sur instructions. Il n'y a encore rien à dire sur l'augmentation du débit, il n'y a pas eu d'afflux suffisamment importants. Le moteur du site est connecté à localhost:11211, les statistiques sont affichées, la mémoire est consommée. Si vous l’aimez, nous verrons quoi faire ensuite. Soit nous le laisserons ainsi, soit nous placerons le « vrai » directement dans l’Axe. Ou essayons Redis de la même manière

Ensuite, il a fallu joindre une liste de diffusion. Pas de relais, seulement une authentification SMTP. J'ai créé une adresse postale et j'utilise ses coordonnées pour envoyer une newsletter via PHP.

Il n'y a pas si longtemps, Plesk Obsidian (18.0) est sorti, nous avons mis à jour sans crainte en nous basant sur l'expérience passée. Tout s’est très bien passé, il n’y a même pas de quoi parler. Ce qui est agréable, c'est que la qualité de l'interface s'est grandement améliorée, elle est devenue plus moderne et est devenue plus pratique à certains endroits. Chose cool, surveillance avancée sur Grafana.

Je ne l’ai pas encore traité en détail, mais vous pouvez par exemple paramétrer des alertes pour n’importe quel paramètre de votre email. Au propriétaire, mdr.

Pendant que je parle de l’interface, elle est réactive et fonctionne très bien sur le téléphone. Au début, alors que nous essayions de trouver les paramètres optimaux pour PHP et d’autres choses, cela nous a beaucoup aidé. Et surtout quand un programmeur, dans un accès d'enthousiasme au travail, fait quelque chose à 23hXNUMX, et que moi, dans un accès d'enthousiasme au travail, je bois de la vodka dans les bains publics, et j'ai besoin d'URGENCE de changer quelque chose.

Oh au fait. L'image montre que PHP Composer est apparu. Nous n'avons pas encore joué avec, mais, disons, pour Laravel, cela peut économiser quelques connexions shell et du temps pour l'installation des dépendances. Le même système existe pour Node.JS et Ruby.

Avec SSL, tout est simple. Si le domaine se résout comme prévu, Let's Encrypt se fait en un clic puis se met à jour, à la fois pour le domaine lui-même, pour les sous-domaines et même pour les services de messagerie.

Plesk lui-même en tant que logiciel est actuellement assez agréable et stable. Il se met à jour lui-même et l'Axis en silence, consomme peu de ressources et fonctionne sans problème. Je ne me souviens même pas d’avoir marché quelque part sur quelque chose, ce qui aurait été un défaut évident du produit. Il y a eu des problèmes, bien sûr, mais ils étaient soit dus à une configuration imparfaite, soit quelque part au niveau de la jonction, donc il n’y a rien à redire. Les impressions de travailler avec Plesk sont généralement agréables. Ce qu’il n’a pas, et nous devons le comprendre, c’est un (n’importe quel) clustering. Ni LB ni HA. Vous pouvez essayer, mais l’effort nécessaire sera tel qu’il vaut mieux faire les choses différemment dès le début.

Je pense que nous pouvons le résumer. Pour le cas où il n'y a pas d'administrateur, ou il n'y en a pas assez, lorsque le prix de l'hébergement et du ou des sites qui y tournent dépasse, disons, 100 USD, quand on ne parle pas de partage bestial de 1500 sites sur un serveur, lorsque le décideur est confronté à Si vous avez le choix d'embaucher un administrateur à temps partiel, ou d'acheter un logiciel et d'avoir un administrateur pour un demi-dollar, ou de ne pas en avoir du tout - cela a tout à fait du sens. Du point de vue de l'administrateur distant, c'est la même chose. 10 $ par mois, permet de gagner du temps et offre une flexibilité de travail pendant très longtempsоun montant plus important. Si par exemple on me demande fortement de prendre sous mon aile un projet similaire, j’insisterai pour le transférer chez Plesk.

Source: habr.com