I want to share some impressions about the need or uselessness of such a thing as a control panel for a commercial single-server web project with a very part time admin. The story began a couple of years ago, when acquaintances of acquaintances asked me to accompany the purchase of a business - a news site - from a technical point of view. It was necessary to understand a little what works on what, make sure that all the necessary details were transferred in the proper form and volume, and strategically figure out what could be improved.
The deal went through, the violinist was no longer needed. End. Not really.
The site was running on a dual-core 4-gigabyte VM on Linode, on some mossy Debian5 with an uptime of 400 days and with such a list of unupdated packages. Web part on self-written CMS, nginx, php5.3 FPM, mysql tuned Percona. Basically, it worked.
In parallel with talking to me, the new owner was looking for a programmer to bring the project to expectations. Found. The programmer assessed the traffic and volumes and decided that he was good at optimization and cost management. He migrated the entire site to a 700-ruble shared hosting managed by his usual IS****er. A few days later, another call from the owner: “everything slows down and it seems we have been broken.” I tried to fix the situation through the panel, but after some time of fruitless attempts to change the version of PHP or the handler from fcgi to fpm, I gave up and got into the shell. There I found the included debug, which shone on the entire Internet with a password from the muscle, 777 on some folders, which by that time were cracking from flooded malware and similar game. The owner realized and decided that saving on hosting, a programmer, and an admin who would look with one eye at how things are going is wrong.
We are going to RuVDS. A little closer than the British Linode, and if you suddenly want to store personal data and all that, you won’t have to move anywhere else. Since the project was planned to be expanded, we took the VMK "for growth": 4 cores, 8 GB of memory, 80 GB of disk. It’s not that I don’t know how to use nginx configs with my hands, I just didn’t have the enthusiasm to deal with this project so intimately (see above about part time). Therefore, I installed Plesk (here I will omit the installation details, because by and large they are not there: I launched the installer, set the password for the admin, entered the key - that's it), at that time it was 17.0. The basic settings work tolerably out of the box, there is fail2ban and the latest versions of PHP, nginx available.
Perhaps we should stop and explain why. Since I rarely do such things, and I don’t have any special tools and a set of blanks for each case, it was clear that some kind of automation of basic things was needed, so that, firstly, quickly, secondly, safely, thirdly, all best practices someone has already implemented it.
So, I put it. I saved a lot of time, restarting the site on a new server turned out to be almost instantaneous. All that was left was to tweak the muscle config, giving it half the memory and increasing the number of buffer pools, and give nginx half the cores (Splash does not touch global configs), and go to the shell to look at the mysqltuner stats for a couple of days. Yes, and I bought a paid ImunifyAV from the extensions catalog to get rid of flooded malware. Some 11000 infected files were found. The abomination is that obfuscated pieces of code were poured into the statics, and it would be completely dull to clean it by hand. At first I tried ClamAV, but, as it turned out, he doesn’t take such things, but ImunifyAV could. Moreover, the cured files remain in working condition, just a piece with malware is removed.
The arithmetic is simple: $50 per month for a VMka, $10 for Plesk (actually less, because they bought it for a year with a two-month discount) and $3 for an antivirus. Or a lot of suitcases of money for my time, which I would have spent on the server at first raking these stables by hand. The owner was quite satisfied with this arrangement.
Meanwhile, they found a new programmer. We agreed with him on the distribution of responsibility, made a subdomain for the test version, and work began. He sawed a new version of the site on Laravel, and I looked at fail2ban%).
It is interesting that the flow of curious people does not stop and there are always about a hundred addresses in the list of banned ones. The effect is interesting: in particular, usually, if I go into the shell, I see about 20000-30000 unsuccessful SSH login attempts on the greeting. With fail2ban enabled, about 70. Effort invested: 0. Unfortunately, it didn't go without a drop of tar. WAF (modsecurity) was "semi-enabled" by default: in discovery mode. That is, he wrote suspicious activity to the log, but in fact did not take any action. And fail2ban read all the logs indiscriminately, according to the included jails, and wet everything that moves. So we banned half of the editors :D. I had to disable this jail, and whitelist the necessary IP addresses for reliability. Effort invested: poke the mouse twice and teach editors to say their IP address.
What the programmer immediately liked was the ability to upload databases directly to the panel and quick access to phpMyAdmin
What I liked - logs and backups. Logs are written and rotated out of the box; backups are very easy to set up. At the most sluggish time, a full backup is made, somewhere around 10 gigs, and then every day incremental, 200 megabytes each, during the week. Recovery is granular, to a specific file or database. If you need to restore from an incremental one, then you don’t need to struggle first with the full and restore of the entire chain, Splash does everything himself. You can upload backups anywhere: ftp, dropbox, s3 bucket, google drive and more.
Day G: the programmer finally completed the new engine, we uploaded it to the production, imported the old data and sat down to choose the color of our future Maserati. We are still choosing.
The first problems began. The new site was expectedly heavier than the old one, but the real rake was that, among other things, Yandex.Zen was used to attract traffic, which was catching up with visitors in batches. The site was bent at 150 simultaneous connections (I'm not talking about RPS, because I didn't measure it). We started poking buttons and turning knobs in the php_fpm settings area:
Op, already holds 500 connections. As credit cards were added to promotional vehicles, the waves of traffic got bigger. Next milestone 1000 concurrent connections. Here I had to refinish the code and look into the soul of the muscle. Splashing did not help, but this was not particularly expected. We turned on slow queries log, hung indexes on the database, removed unnecessary queries from the code, brushed the mysql config again following the advice of mysqltuner.
New challenge — 2000 connections. The Plesk 17.8 version has just been released, in which, among other things, nginx caching was added. Updated (surprisingly easy). We try. Works! And then they stepped into the soft, the Yandex.zen feed stopped working. The site is working, the feed is not working. Feed not working, no traffic. The atmosphere is heating up. Under the pressure of circumstances and from a lack of imagination, I immediately got into straceit nginx and found what I was looking for. It turns out that at some point, stupid nginx cached the stray 500th error as a response to the Yandex get feed.xml. Fixed by adding exceptions to the cache settings:
It is clear that the owner needs ESCHO, the waves are slowly increasing. So far we are coping, but we started experimenting with memcached in advance, since Laravel supports it almost out of the box. I somehow didn’t want to install memcached with my hands to “play around”, so we installed a docker image. Straight from the panel.
Well, I'm lying, I had to go into the shell and put the module through pecl. Right on . There is nothing to say about the increase in throughput yet, there were no sufficiently large influxes. The site engine got hooked on localhost:11211, the stats are shown, the memory is being eaten. If you like it, we'll see what to do next. Either we leave it like that, or we put the “real” one right in the Axis. Or let's try redis in the same way
Then it was necessary to attach the mailing list. No relays, just smtp authentication. I set up a mailing address, using its details via PHP we make a mailing list.
Not so long ago, Plesk Obsidian (18.0) was released, updated according to past experience without fear. Everything went very smoothly, there is nothing to even talk about. From the pleasant - the interface has greatly improved in quality, modernized and has become more convenient in some places. Cool thing Advanced Monitoring on Grafana.
So far I have not dealt with it in detail, but you can, for example, set up alerts for any parameter in the mail. Owner lol.
Since I'm talking about the interface, it's responsive and works really well on a phone. In the early stages, while we were trying to find the optimal settings for PHP and other things, it helped a lot. And especially when a programmer, in a fit of working enthusiasm, does something at 23:XNUMX, and I, in a fit of working enthusiasm, drink vodka in a bathhouse, and URGENTLY need to switch something.
Oh, by the way. The picture shows that PHP Composer has appeared. We haven’t played with it yet, but, say, for the same Laravel, it can save a couple of shell logins and some time to install dependencies. The same system exists for Node.JS and Ruby.
With SSL, everything is simple. If the domain resolves where it should be, Let's Encrypt is done with one click and updated on its own, both on the domain itself and on subdomains, and even mail services.
Plesk itself as a software is currently quite pleasant and stable. It updates itself and the Axis quietly, it consumes few resources, it works smoothly. I don’t even remember that somewhere I stepped on something that would be an obvious defect in the product. Of course, there were problems, but they were either from the imperfection of the configuration, or somewhere at the junction, so there was nothing to complain about. Impressions from working with Plesk are generally pleasant. What it does not have, and one must understand this, is any (any) clustering. Neither LB nor HA. You can try, but there will be so much effort invested that it is better to do something differently initially.
I think we can summarize. For the case when there is no admin, or it is not enough, when the price of hosting and the site (s) spinning on it exceeds, let's say, 100 USD, when we are not talking about a bestial shared of 1500 sites on the server, when the decision maker there is a choice to hire an admin part-time, or buy software and start an admin for half a shot, or not start it at all - it definitely makes sense. From the point of view of the remote administrator - the same. $10 per month, and saves time and gives flexibility in work for a very long time.оmore amount. If, for example, I am strongly asked to take a similar project under my wing, I will insist on moving to Plesk.
Source: habr.com