Mon expérience avec Plesk

Je souhaite partager quelques impressions sur l'utilité ou non d'un panneau de contrôle pour un projet web commercial sur un serveur unique, avec un administrateur très part-time. L'histoire a commencé il y a quelques années, lorsque des connaissances d'amis m'ont demandé d'assister à l'achat d'une entreprise — un site d'actualités — d'un point de vue technique. Il fallait examiner légèrement en quoi cela fonctionnait, s'assurer que tous les documents nécessaires étaient transmis correctement et stratégiquement envisager ce qui pouvait être amélioré.

L'affaire a été conclue, le violoniste n'était plus nécessaire. Fin. En réalité, non.

Le site fonctionnait sur une VM à deux cœurs avec 4 Go de RAM sur Linode, avec un Debian 5 très ancien et un uptime de 400 jours, et voilà une telle liste de paquets non mis à jour. La partie web était sur un CMS fait maison, nginx, php5.3 FPM, mysql optimisé avec Percona. En principe, ça marchait.

Parallèlement à mes discussions, le nouveau propriétaire cherchait un programmeur pour aligner le projet sur ses attentes. Il a trouvé. Le programmeur a évalué le trafic et les volumes et a décidé qu'il pouvait gérer l'optimisation et la gestion des coûts. Il a migré tout le site vers un hébergement partagé à 700 roubles sous la gestion de l'IS****er qui lui était familier. Quelques jours plus tard, nouvel appel du propriétaire : « tout ralentit et on a l'impression qu'ils nous ont piratés ». J'ai essayé de corriger la situation via le panneau, mais après un certain temps d'efforts infructueux pour changer la version de PHP ou le handler de fcgi à fpm, j'ai abandonné et suis allé dans le shell. J'y ai trouvé le débogage activé, qui exposait le mot de passe de MySQL à tout internet, 777 sur certains dossiers, qui à ce moment-là croulaient sous les malwares et d'autres aberrations. Le propriétaire a réalisé qu'économiser sur l'hébergement, le programmeur, et un administrateur qui garderait un œil sur les affaires n'était pas la bonne solution.

Nous allons chez RuVDS. Un peu plus proche que la britannique Linode, et si jamais on désire stocker des données personnelles et tout ça, il n'est plus nécessaire de déménager ailleurs. Comme le projet était destiné à s'étendre, nous avons pris une VM "pour l'avenir": 4 cœurs, 8 Go de RAM, 80 Go de disque. Ce n'est pas que je ne maîtrise pas les configurations nginx à la main, simplement je n'avais pas l'enthousiasme de gérer ce projet aussi intimement (voir ci-dessus sur le temps partiel). Donc, j'ai installé Plesk (je passerai les détails de l'installation, car en gros, il n'y en a pas : j'ai lancé l'installateur, placé un mot de passe pour l'administrateur, entré la clé – c'est tout), à l'époque c'était la version 17.0. Les réglages de base fonctionnent correctement dès la sortie de la boîte, il y a fail2ban et les dernières versions disponibles de PHP et nginx. 

Il convient probablement de s'arrêter et d'expliquer pourquoi lui. Étant donné que je fais ce genre de choses rarement, et que je n'ai pas d'outils spéciaux ou de modèles prêts pour chaque cas, il était évident qu'une certaine automatisation des tâches de base était nécessaire, pour être à la fois rapide, sécurisé et que tous les meilleures pratiques aient déjà été mises en œuvre par quelqu'un.

Donc, je l'ai installé. J'ai économisé pas mal de temps, le redémarrage du site sur le nouveau serveur a été quasiment instantané. Il restait à ajuster la configuration de MySQL, en lui allouant la moitié de la mémoire et en augmentant le nombre de buffer pools, et à donner la moitié des cœurs à nginx (Plesk ne touche pas aux configurations globales), et pendant quelques jours, j'ai jeté un œil dans le shell pour voir les stats de mysqltuner. Ah oui, et j'ai acheté ImunifyAV payant dans le catalogue des extensions pour me débarrasser de la malveillance téléchargée. Environ 11000 fichiers infectés ont été identifiés. Le problème, c'est que du code obfusqué était intégré dans la partie statique, et le nettoyer à la main aurait été assez pénible. J'ai d'abord essayé ClamAV, mais il s'est avéré qu'il ne traite pas ce genre de choses, alors qu'ImunifyAV a pu le faire. De plus, les fichiers réparés restent en bon état de fonctionnement, seul le morceau contenant la malveillance est supprimé.

Les calculs sont simples : 50 $ par mois pour la VM, 10 $ pour Plesk (en réalité moins, car nous avons acheté pour un an avec une réduction de deux mois) et 3 $ pour l'antivirus. Ou bien beaucoup de valises d'argent pour le temps que j'aurais passé sur le serveur dans les premiers temps à dégager ces écuries manuellement. Ce schéma convenait parfaitement au propriétaire.

Entre-temps, nous avons 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 de test, et le travail a commencé. Il développait une nouvelle version du site sur Laravel, tandis que je surveillais fail2ban.

Il est intéressant de noter que le flux des curieux ne s'arrête jamais et qu'il y a toujours environ une centaine d'adresses dans la liste noire. L'effet est intéressant : en général, lorsque je me connecte au shell, je vois environ 20 000 à 30 000 tentatives de connexion infructueuses via SSH. Avec fail2ban activé, il y a environ 70. Efforts investis : 0. Malheureusement, il n'y a pas eu de point positif sans un soupçon de négatif. Par défaut, WAF (modsecurity) était « semi-activé » : en mode détection. Cela signifie qu'il enregistrait l'activité suspecte dans les journaux, mais ne prenait effectivement aucune mesure. En revanche, fail2ban lisait sans distinction tous les journaux, selon les jails activés, et bloquait tout ce qui bougeait. Ainsi, nous avons banni la moitié de la rédaction :D. Nous avons dû désactiver ce jail et ajouter les adresses IP nécessaires à la liste blanche pour plus de fiabilité. Efforts déployés : cliquer deux fois avec la souris et apprendre aux éditeurs à dire leur adresse IP.

Ce qui a plu immédiatement au programmeur - 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é - les journaux et les sauvegardes. Les journaux s'écrivent et se tournent automatiquement dès la sortie de la boîte ; les sauvegardes se configurent très facilement. Pendant les périodes les plus calmes, une sauvegarde complète est effectuée, d'environ 10 Go, suivie chaque jour d'une sauvegarde incrémentielle d'environ 200 Mo, pendant une semaine. La restauration est granulaire, jusqu'à un fichier ou une base de données spécifiques. Si une restauration incrémentielle est nécessaire, il n'est pas nécessaire de recommencer avec la sauvegarde complète et de restaurer toute la chaîne, Plesk s'en occupe tout seul. Les sauvegardes peuvent être téléchargées n'importe où : sur FTP, Dropbox, S3 bucket, Google Drive, etc.

Jour J : le programmeur a enfin terminé le nouveau moteur, nous l'avons déployé en production, importé les anciennes données et nous sommes assis pour choisir la couleur de nos futures Maserati. Nous sommes encore en train de choisir.

Les premiers problèmes ont commencé. Le nouveau site était attendue plus lourd que l'ancien, mais la véritable tuile était que, pour attirer le trafic, nous utilisions entre autres Yandex.Zen, qui amenait des visiteurs en masse. Le site était en difficulté avec 150 connexions simultanées (je ne parle pas de RPS, car nous ne l'avons pas mesuré). Nous avons commencé à cliquer sur les boutons et à ajuster les réglages de php_fpm.
 

Oh, it already handles 500 connections. As the credit card is applied to the promotional funds, the traffic waves have grown larger. The next milestone is 1000 simultaneous connections. At this point, we had to refine the code and look into the muscle soul. Plesk didn’t help much, but we didn’t expect it to. We enabled the slow queries log, added some indexes to the database, removed unnecessary queries from the code, and tweaked the MySQL configuration again following the tips from mysqltuner.

The new challenge is 2000 connections. Just in time for the release of Plesk 17.8, which added nginx caching among other things. We updated (surprisingly easily). Let’s try it. It works! But then it suddenly got soft, and the Yandex Zen feed stopped working. The site is operational, but the feed is down. No feed means no traffic. The atmosphere is heating up. Under pressure from circumstances and a lack of imagination, I immediately started strace'ing nginx and found what I was looking for. It turns out that at some point, the silly nginx cached an incoming 500 error as a response to the Yandex get feed.xml. We fixed it by adding exceptions to the cache settings:

Of course, the owner needs MORE, and the waves are slowly increasing. We’re managing for now, but we started experimenting with memcached in advance, as Laravel supports it almost out of the box. I didn’t want to manually set up memcached just for "playing around," so we set up a Docker image directly from the panel.

Well, I admit, I had to go into the shell and install the module via pecl. Right from des instructions. I can’t say much about the increase in bandwidth yet, as there haven’t been any significantly large spikes. The site engine connected to localhost:11211, stats are showing, memory is being used. If we like it, we’ll see what to do next. Either we leave it as is or we’ll install a “real” one directly on the OS. Or we might try Redis in the same way.

Next, we needed to set up a mailing list. No relays, just smtp authentication. I created an email address and using its credentials, we’ll send out emails through PHP.

Not long ago, Plesk Obsidian (18.0) was released; we updated without fear based on past experience. Everything went smoothly; I don’t even have much to say. On the plus side, the quality of the interface has significantly improved, becoming more modern and convenient in some areas. The Advanced Monitoring feature on Grafana is a cool addition.

I haven't delved into it in detail yet, but you can, for instance, set alerts for any parameter to your email. To the owner, lol.

Puisque je parle de l'interface, elle est réactive et fonctionne vraiment bien sur téléphone. Aux premiers stades, alors que nous essayions de trouver les paramètres PHP optimaux et d'autres, cela nous a beaucoup aidés. Surtout lorsque le programmeur, dans un accès d'enthousiasme, travaille à 23 heures, et moi, dans un accès d'enthousiasme, je bois de la vodka dans le bain, et il est URGENT de changer quelque chose.

Oh, au fait. Sur l'image, on voit que PHP Composer est arrivé. Nous ne l'avons pas encore essayé, mais disons que pour Laravel, il peut économiser quelques connexions en shell et un certain temps lors de l'installation des dépendances. Il existe un système similaire pour Node.JS et Ruby.

Avec SSL, c'est simple. Si le domaine résout à la bonne adresse, Let’s Encrypt s'installe en un clic et se met à jour lui-même par la suite, tant pour le domaine que pour les sous-domaines, et même pour les services de messagerie.

Plesk en lui-même est assez agréable et stable au moment actuel. Il se met à jour tout seul et le système d'exploitation discrètement, consomme peu de ressources et fonctionne bien. Je ne me souviens même pas d'un moment où j'ai rencontré un défaut flagrant du produit. Il y a eu des problèmes, bien sûr, mais ils étaient soit dus à une mauvaise configuration, soit quelque part à la limite, donc je n'ai pas vraiment de reproches à faire. En général, les impressions de travail avec Plesk sont positives. Ce qu'il lui manque, et il faut le comprendre, c'est toute forme de (n'importe quelle) mise en cluster. Ni LB, ni HA. On peut essayer, mais l'effort investi sera tel qu'il vaut mieux faire quelque chose différemment dès le départ.

Je pense que l'on peut faire un résumé. Dans le cas où il n'y a pas d'administrateur, ou qu'il est peu présent, lorsque le prix de l'hébergement et des sites hébergés dépasse, disons, 100 unités monétaires, lorsqu'il ne s'agit pas de groupes d'hébergement bon marché avec 1500 sites sur un serveur, et que le décideur doit choisir d'embaucher un administrateur à temps partiel, d'acheter un logiciel et d'embaucher un administrateur à moitié prix, ou de ne pas en engager du tout — il y a certainement du sens. Du point de vue d'un administrateur distant — c'est la même chose. 10$ par mois, mais cela fait gagner du temps et procure de la flexibilité dans le travail sur une somme beaucoup plus élevée. Par exemple, si on me demande fortement de prendre un projet similaire sous mon aile, je vais insister pour le transférer sur Plesk.deJe veux partager quelques impressions sur l'utilité ou non d'un panneau de contrôle pour un projet web commercial mono-serveur en présence d'un administrateur très à temps partiel.

Source : habr.com