Ich möchte einige Eindrücke zur Nützlichkeit oder Nutzlosigkeit eines Dashboards für kommerzielle Einzelserver-Webprojekte mit einem sehr teilzeit arbeitenden Administrator teilen. Die Geschichte begann vor ein paar Jahren, als Bekannte mich um Unterstützung beim Kauf eines Unternehmens — einer Nachrichtenwebsite — aus technischer Sicht baten. Es war notwendig, ein wenig zu verstehen, auf welchen Technologien alles läuft, sicherzustellen, dass alle erforderlichen Informationen korrekt und vollständig übermittelt wurden, und strategisch zu überlegen, was verbessert werden kann.
Der Deal wurde abgeschlossen, der Geiger war nicht mehr nötig. Ende. Tatsächlich nicht.
Die Website lief auf einer dual-core 4 GB VM bei Linode, auf einem etwas angestaubten Debian 5 mit einer Uptime von 400 Tagen und genau so einem nicht aktualisierten Paketumfang. Der Webbereich lief auf einem selbstgebauten CMS, nginx, php 5.3 FPM, mysql, optimiert mit Percona. Im Prinzip funktionierte es.
Während unserer Gespräche suchte der neue Eigentümer parallel einen Programmierer, um das Projekt den Erwartungen anzupassen. Er fand einen. Der Programmierer bewertete den Verkehr und die Volumina und entschloss sich, dass er sich mit Optimierung und Kostenmanagement auskannte. Er migrierte die gesamte Website auf ein Shared Hosting für 700 Rubel, verwaltet von dem ihm vertrauten IS****er. Nach ein paar Tagen erhielt ich erneut einen Anruf vom Eigentümer: "Alles läuft langsam und es scheint, als hätten sie uns gehackt." Ich versuchte, die Situation über das Panel zu beheben, gab aber nach einiger Zeit fruchtloser Versuche, die PHP-Version oder den Handler von fcgi auf fpm zu ändern, auf und stieg in die Shell ein. Dort fand ich das aktivierte Debugging, das das Passwort für MySQL im Internet offenbarte, sowie 777-Berechtigungen für einige Ordner, die zu diesem Zeitpunkt bereits von Malware überflutet waren und ähnliches Chaos. Der Eigentümer erkannte, dass es falsch war, beim Hosting, beim Programmierer und bei einem Admin, der gelegentlich nach dem Rechten sehen könnte, zu sparen.
Wir gehen zu RuVDS. Etwas näher als das britische Linode, und falls es nötig sein sollte, persönliche Daten zu speichern, muss man nicht mehr umziehen. Da das Projekt expansioniert werden sollte, haben wir eine VM "zum Wachsen" geholt: 4 Kerne, 8 GB RAM, 80 GB Speicher. Es ist nicht so, dass ich keine nginx-Konfigurationen per Hand kann, aber ich hatte einfach nicht die Leidenschaft, dieses Projekt so intensiv zu betreuen (siehe oben über Teilzeitarbeit). Also habe ich Plesk installiert (hier lasse ich die Installationsdetails weg, weil es im Grunde keine gibt: Installer gestartet, Admin-Passwort gesetzt, Schlüssel eingegeben – fertig), damals war es Version 17.0. Die Basiseinstellungen funktionieren anständig out of the box, es gibt fail2ban und die letzten verfügbaren PHP- und nginx-Versionen.
Vielleicht ist es an der Zeit, innezuhalten und zu erklären, warum ich es ausgewählt habe. Da ich solche Dinge selten mache und kein spezielles Werkzeug oder Set an Vorlagen für jeden Fall habe, war mir klar, dass ich eine Art Automatisierung für die grundlegenden Dinge benötige, um erstens schnell, zweitens sicher, und drittens um sicherzustellen, dass bereits alle Best Practices implementiert worden sind.
Ich habe also alles eingerichtet. Ich habe viel Zeit gespart, der Neustart der Website auf dem neuen Server war praktisch sofort. Ich musste nur die MySQL-Konfiguration anpassen, indem ich ihm die Hälfte des RAMs zugewiesen und die Anzahl der Buffer-Pools erhöht habe, und nginx die Hälfte der Kerne geben (Plesk ändert keine globalen Konfigurationen), und dann wollte ich ein paar Tage in die Shell schauen, um die Statistiken von mysqltuner zu beobachten. Übrigens habe ich die kostenpflichtige ImunifyAV aus dem Erweiterungskatalog gekauft, um die eingespielte Malware loszuwerden. Es wurden etwa 11.000 infizierte Dateien gefunden. Das Üble daran war, dass obfuskierten Code in die statischen Dateien eingeflossen war, und das manuell zu bereinigen wäre ziemlich öde gewesen. Zuerst habe ich ClamAV ausprobiert, aber das Programm hat solche Dinge nicht behandelt, während ImunifyAV das konnte. Zudem bleiben die bereinigten Dateien weiterhin funktionstüchtig, es wird nur der Teil mit der Malware entfernt.
Die Rechnung ist einfach: 50 $ pro Monat für die VM, 10 $ für Plesk (tatsächlich weniger, da wir sofort für ein Jahr mit einem Rabatt von zwei Monaten gekauft haben) und 3 $ für das Antivirenprogramm. Oder viele Koffer Geld für meine Zeit, die ich am Anfang damit verbringen würde, diese Ställe manuell zu räumen. Diese Regelung hat den Besitzer gut zufriedengestellt.
In der Zwischenzeit haben wir einen neuen Programmierer gefunden. Wir haben uns mit ihm über die Verteilung der Verantwortlichkeiten geeinigt, einen Subdomain für die Testversion erstellt, und die Arbeit begann. Er entwickelte die neue Version der Website mit Laravel, während ich auf fail2ban Acht gab %).
Es ist interessant, dass der Zustrom Neugieriger nicht abreißt und in der Liste der gesperrten Adressen immer etwa hundert Adressen stehen. Der Effekt ist interessant: Insbesondere sehe ich normalerweise, wenn ich mich in die Shell einlogge, beim Begrüßungsscreen etwa 20.000 bis 30.000 fehlgeschlagene SSH-Anmeldeversuche. Mit aktiviertem fail2ban liegen diese Zahlen bei etwa 70. Eingesetzte Anstrengungen: 0. Leider gab es nicht ohne einen kleinen Nachteil. Standardmäßig war das WAF (modsecurity) „halbaktiv“: im Erkennungsmodus. Das heißt, es protokollierte verdächtige Aktivitäten, unternahm jedoch keine tatsächlichen Maßnahmen. Fail2ban las jedoch alle Protokolle ohne Filterung entsprechend den verbundenen Jails und blockierte alles, was sich bewegte. Dadurch haben wir die Hälfte der Redaktion gesperrt :D. Wir mussten dieses Jail deaktivieren und die benötigten IP-Adressen zur Sicherheit in die Whitelist eintragen. Eingesetzte Anstrengungen: zweimal mit der Maus klicken und die Redakteure bitten, ihre IP-Adresse zu nennen.
Was Programmierern sofort gefiel, war die Möglichkeit, Datenbanken direkt im Panel hochzuladen und der schnelle Zugriff auf phpMyAdmin.
Was mir gefallen hat, sind die Protokolle und Backups. Die Protokolle werden sofort und automatisch rotiert, während die Backups sehr einfach eingerichtet werden können. Zu den ruhigsten Zeiten wird ein vollständiges Backup erstellt, etwa 10 Gigabyte groß, und dann jeden Tag ein inkrementelles Backup von etwa 200 Megabyte über eine Woche. Die Wiederherstellung erfolgt granula, bis hin zu einzelnen Dateien oder Datenbanken. Wenn eine Wiederherstellung aus einem inkrementellen Backup erforderlich ist, muss man sich nicht zuerst um das vollständige Backup kümmern und die gesamte Kette wiederherstellen, Plesk erledigt das alles automatisch. Backups können überallhin hochgeladen werden: auf FTP, Dropbox, S3-Bucket, Google Drive usw.
Tag X: Der Programmierer hat endlich die neue Engine fertiggestellt, wir haben sie in die Produktion überführt, die alten Daten importiert und uns hingesetzt, um die Farbe unserer zukünftigen Maseratis auszuwählen. Wir sitzen immer noch dabei, sie auszuwählen.
Die ersten Probleme traten auf. Die neue Seite war erwartungsgemäß schwerer als die alte, aber das wirkliche Dilemma war, dass zur Traffic-Generierung unter anderem Yandex.Zen genutzt wurde, das Besucher in Massen anlockte. Die Seite brach bei 150 gleichzeitigen Verbindungen zusammen (ich spreche nicht von RPS, da wir das nicht gemessen haben). Wir fingen an, Knöpfe zu drücken und die Einstellungen von php_fpm zu bedienen:
Oh, jetzt hält es 500 Verbindungen. Mit dem Aufstocken des Budgets für Promotionen wurden die Traffic-Wellen größer. Der nächste Meilenstein sind 1000 gleichzeitige Verbindungen. Hier mussten wir den Code bereits verfeinern und in die Tiefen von MySQL eintauchen. Der Einsatz von Plesk half dabei nicht, aber das hatten wir auch nicht wirklich erwartet. Wir schalteten das Slow Queries-Log ein, fügten Indizes zur Datenbank hinzu, entfernten überflüssige Anfragen aus dem Code und überarbeiteten die MySQL-Konfiguration nach den Empfehlungen von mysqltuner.
Neue Herausforderung – 2000 Verbindungen. Gerade rechtzeitig kam die Version Plesk 17.8 heraus, die unter anderem nginx-Caching implementiert hat. Wir haben auf die erstaunlich einfache Weise aktualisiert. Wir testen es. Es funktioniert! Doch dann gab es sofort Probleme: der Yandex Zen-Feed funktionierte nicht mehr. Die Website läuft, der Feed jedoch nicht. Kein Feed, kein Traffic. Die Stimmung wird angespannt. Unter dem Druck der Umstände und aufgrund mangelnder Ideen habe ich sofort angefangen, nginx zu strace'en und herausgefunden, wonach es suchte. Es stellte sich heraus, dass nginx zu einem gewissen Zeitpunkt einen unglücklichen 500er-Fehler als Antwort auf den Yandex GET feed.xml-Request gecached hatte. Wir haben das behoben, indem wir Ausnahmen in die Cache-Einstellungen aufgenommen haben:
Es ist klar, dass der Besitzer noch MEHR benötigt, die Wellen steigen allmählich. Wir kommen zurecht, haben aber rechtzeitig damit begonnen, mit memcached zu experimentieren, da Laravel es quasi sofort unterstützt. Es war mir nicht recht, memcached manuell für "herumzuspielen" einzurichten, also haben wir ein Docker-Image verwendet. Direkt aus dem Panel.
Na gut, ich gebe es zu, ich musste ins Shell gehen und das Modul über pecl installieren. Direkt über . Über das Wachstum der Bandbreite gibt es derzeit nichts zu berichten, es gab keinen nennenswerten Anstieg. Die Website ist auf localhost:11211 angebunden, die Statistiken werden angezeigt, der Speicher wird beansprucht. Wenn es gefällt, schauen wir, wie es weitergeht. Entweder lassen wir es so, oder wir installieren eine „echte“ Version direkt auf dem Host. Alternativ versuchen wir es auf die gleiche Weise mit Redis.
Dann war es nötig, einen E-Mail-Versand einzurichten. Keine Relays, nur SMTP-Authentifizierung. Ich habe eine E-Mail-Adresse eingerichtet und über deren Zugangsdaten mit PHP den Versand organisiert.
Vor nicht allzu langer Zeit ist Plesk Obsidian (18.0) erschienen, wir haben ohne Furcht basierend auf den bisherigen Erfahrungen ein Update durchgeführt. Alles verlief sehr reibungslos, nicht viel zu berichten. Positiv hervorzuheben ist die deutliche Verbesserung der Benutzeroberfläche, die modernisiert wurde und an einigen Stellen benutzerfreundlicher ist. Ein cooles Feature ist das Advanced Monitoring auf Grafana.
Ich habe mich noch nicht ausführlich damit beschäftigt, aber man kann beispielsweise Alarme für jeden Parameter per E-Mail konfigurieren. An den Besitzer, lol.
Da ich gerade über die Benutzeroberfläche spreche, sie ist anpassungsfähig und funktioniert tatsächlich gut auf dem Handy. In den frühen Phasen, während wir versucht haben, die optimalen PHP-Einstellungen und Ähnliches zu finden, war das eine große Hilfe. Besonders wenn ein Programmierer in einem Anfall von Arbeitsenthusiasmus um 23 Uhr etwas macht und ich in einem ähnlichen Enthusiasmus Wodka in der Sauna trinke, und DRINGEND etwas umgeschaltet werden muss.
Übrigens. Auf dem Bild sieht man, dass PHP Composer hinzugekommen ist. Wir haben noch nicht damit gespielt, aber er kann zum Beispiel für Laravel ein paar Logins in die Shell einsparen und Zeit bei der Installation von Abhängigkeiten. Ein ähnliches System gibt es für Node.JS und Ruby.
Mit SSL ist alles einfach. Wenn die Domain richtig aufgelöst wird, kann Let’s Encrypt mit einem Klick eingerichtet werden und aktualisiert sich selbständig, sowohl für die Hauptdomain als auch für Subdomains und sogar für E-Mail-Dienste.
Plesk als Software ist derzeit wirklich angenehm und stabil. Es aktualisiert sich selbst und das Betriebssystem leise, benötigt wenig Ressourcen und arbeitet zuverlässig. Ich kann mich nicht erinnern, dass ich irgendwo auf ein klares Produktfehler gestoßen bin. Sicher gab es Probleme, aber die resultieren entweder aus einer unzureichenden Konfiguration oder irgendwo an der Schnittstelle, sodass es kaum Kritikpunkte gibt. Die Erfahrung mit Plesk ist insgesamt positiv. Was ihm fehlt, und das sollte man verstehen, ist jegliche Art von Clusterbildung. Weder LB noch HA. Man kann es versuchen, aber der Aufwand wäre so groß, dass es besser ist, von Anfang an einen anderen Ansatz zu wählen.
Ich denke, man kann zusammenfassen. Wenn es keinen oder nur einen wenig erfahrenen Administrator gibt, wenn die Kosten für das Hosting und die darauf laufende Webseite(n) über, sagen wir, 100 € liegen, wenn es nicht um einen miserablen Shared Hosting mit 1500 Webseiten auf einem Server geht, und wenn bei der Entscheidungsfindung die Wahl besteht, einen halbtags Administrator einzustellen, oder Software zu kaufen und einen Administrator für «ein kleines Gehalt» zu engagieren, oder ihn ganz wegzulassen – dann macht es definitiv Sinn. Aus der Sicht eines externen Administrators gilt das gleiche. 10 $ im Monat, spart Zeit und gibt Flexibilität in der Arbeit.größtengrößeren Betrag. Wenn ich zum Beispiel stark gebeten werde, ein ähnliches Projekt zu übernehmen, werde ich auf den Umstieg auf Plesk bestehen.
Quelle: habr.com
