Ich möchte einige Eindrücke über die Notwendigkeit oder Nicht-Notwendigkeit eines Elements wie ein Dashboard für ein kommerzielles Einzelserver-Webprojekt mit einem sehr part-time Admin teilen. Die Geschichte begann vor ein paar Jahren, als Bekannte von Bekannten mich baten, sie aus technischer Perspektive beim Kauf eines Unternehmens – einer Nachrichtenwebsite – zu begleiten. Es war nötig, ein wenig zu verstehen, womit gearbeitet wird, sicherzustellen, dass alle erforderlichen Unterlagen in der richtigen Form und Menge übergeben wurden, und strategisch zu überlegen, was verbessert werden kann.
Der Deal wurde abgeschlossen, der Geiger wurde nicht mehr benötigt. Ende. Eigentlich nicht.
Die Website lief auf einer dual-core 4-GB-VM bei Linode, auf einem veralteten Debian5 mit einer Uptime von 400 Tagen und mit einer solchen Liste nicht aktualisierter Pakete. Der Web-Teil basierte auf einem selbstgeschriebenen CMS, nginx, php5.3 FPM, MySQL war auf Percona optimiert. Im Grunde funktionierte es.
Parallel zu den Gesprächen mit mir suchte der neue Besitzer einen Programmierer, um das Projekt an die Erwartungen anzupassen. Er fand einen. Der Programmierer schätzte den Traffic und die Last und entschied, dass er sich mit Optimierung und Kostenmanagement auskannte. Er migrierte die gesamte Website auf ein 700-Rubel-Shared Hosting unter der Verwaltung seines gewohnten IS****ers. Nach ein paar Tagen erhielt der Besitzer erneut einen Anruf: „Alles ist langsam und es scheint, als wären wir gehackt worden.“ Ich versuchte, die Situation über das Dashboard zu beheben, aber nach einiger Zeit fruchtloser Versuche, die PHP-Version oder den Handler von fcgi auf fpm zu ändern, gab ich auf und ging ins Shell. Dort fand ich das aktivierte Debugging, das das Passwort für MySQL über das gesamte Internet leuchtete, 777 auf einige Ordner, die zu diesem Zeitpunkt vor Malware strotzten, und solche Dinge. Der Besitzer erkannte und entschied, dass es falsch war, an Hosting, Programmierer und einem Admin zu sparen, der gelegentlich einen Blick darauf werfen würde, wie die Dinge laufen.
Wir fahren nach RuVDS. Etwas näher als das britische Linode, und falls man persönliche Daten und all das speichern möchte, muss man nicht noch einmal umziehen. Da das Projekt erweitert werden sollte, haben wir eine VM "zum Wachsen": 4 Kerne, 8 GB RAM, 80 GB Speicher. Nicht dass ich nicht in der Lage wäre, nginx-Konfigurationen von Hand zu machen, einfach hatte ich nicht den Enthusiasmus, mich so intim mit diesem Projekt zu beschäftigen (siehe oben zu Teilzeit). Daher habe ich Plesk installiert (hier lasse ich die Installationsdetails aus, weil es im Grunde genommen keine gibt: Installer gestartet, Admin-Passwort gesetzt, Schlüssel eingegeben – fertig), damals war es 17.0. Die grundlegenden Einstellungen funktionieren ganz ordentlich sofort, es gibt fail2ban und die neuesten verfügbaren Versionen von PHP, nginx.
Es lohnt sich wahrscheinlich, innezuhalten und zu erklären, warum ich es gemacht habe. Da ich mich selten mit solchen Dingen beschäftige und keine besonderen Werkzeuge oder Vorlagen für jeden Fall habe, war klar, dass eine Automatisierung grundlegender Dinge notwendig war, um erstens schnell, zweitens sicher und drittens um sicherzustellen, dass alle Best Practices bereits implementiert wurden.
Also, ich habe es installiert. Ich habe erheblich Zeit gespart, der Neustart der Website auf dem neuen Server war praktisch sofort. Es blieb nur noch, die MySQL-Konfiguration anzupassen, ihm die Hälfte des Speichers zu geben und die Anzahl der Buffer-Pools zu erhöhen, und nginx die Hälfte der Kerne zuzuweisen (Plesk kümmert sich nicht um globale Konfigurationen), und innerhalb von ein paar Tagen wollte ich im Shell nach den Statistiken von mysqltuner sehen. Ja, und ich habe das kostenpflichtige ImunifyAV aus dem Erweiterungskatalog gekauft, um die hochgeladene Malware loszuwerden. Es wurden etwa 11000 infizierte Dateien gefunden. Die Gemeinheit war, dass in die Statische obfuskierte Code-Stücke eingedrungen waren, und es wäre echt mühsam gewesen, das von Hand zu reinigen. Zuerst habe ich ClamAV ausprobiert, aber er hat, wie sich herausstellte, solche Dinge nicht erfasst, und ImunifyAV konnte es. Dabei bleiben die geheilten Dateien funktionsfähig, es wird lediglich der Teil mit der Malware gelöscht.
Die Rechnung ist einfach: 50 $ pro Monat für die VM, 10 $ für Plesk (eigentlich weniger, weil wir direkt für ein Jahr mit einem Rabatt von zwei Monaten gekauft haben) und 3 $ für das Antivirenprogramm. Oder viel Geld für meine Zeit, die ich anfangs auf dem Server verbringen würde, während ich diese Ställe manuell aufräume. Der Eigentümer war mit dieser Lösung vollkommen zufrieden.
In der Zwischenzeit haben wir einen neuen Entwickler gefunden. Wir haben mit ihm über die Verteilung der Verantwortlichkeiten gesprochen, eine Sub-Domain für die Testversion eingerichtet und die Arbeit hat begonnen. Er hat eine neue Version der Website mit Laravel entwickelt, während ich auf fail2ban geschaut habe %).
Es ist interessant, dass der Zustrom von Neugierigen nicht abreißt und in der Liste der gesperrten Adressen immer etwa einhundert Adressen stehen. Der Effekt ist interessant: Insbesondere sehe ich normalerweise, wenn ich mich in die Shell einlogge, etwa 20.000-30.000 fehlgeschlagene SSH-Anmeldeversuche. Mit aktiviertem fail2ban sind es etwa 70. Eingesetzte Mühe: 0. Leider gab es keinen ganz kleinen Wermutstropfen. Standardmäßig war der WAF (modsecurity) "halb aktiviert": im Erkennungsmodus. Das heißt, er hat verdächtige Aktivitäten in die Log-Dateien geschrieben, aber faktisch keine Maßnahmen ergriffen. Und fail2ban hat ungefiltert alle Logs gelesen, entsprechend den aktivierten Jails, und alles bekämpft, was sich bewegt. So haben wir die Hälfte der Redaktion gesperrt :D. Wir mussten dieses Jail deaktivieren und die benötigten IP-Adressen sicherheitshalber in die Whitelist eintragen. Aufwand: zweimal mit der Maus klicken und den Redakteuren beibringen, ihre IP-Adresse zu sagen.
Was dem Entwickler sofort gefiel – die Möglichkeit, Datenbanken direkt im Panel hochzuladen und schnellen Zugriff auf phpMyAdmin.
Was mir gefallen hat – die Logs und Backups. Die Logs werden von selbst erstellt und rotiert; die Backups sind sehr einfach einzustellen. Zu den ruhigsten Zeiten wird ein vollständiges Backup gemacht, etwa 10 Gigabyte, und dann täglich inkrementell, etwa 200 Megabyte, über eine Woche hinweg. Die Wiederherstellung ist granulär, bis hin zu einer bestimmten Datei oder Datenbank. Wenn eine Wiederherstellung aus einem inkrementellen Backup nötig ist, muss man sich nicht zuerst mit einem vollständigen Backup und der Wiederherstellung der gesamten Kette abmühen; Plesk erledigt alles selbst. Backups können überallhin hochgeladen werden: auf FTP, Dropbox, S3-Bucket, Google Drive und andere.
Tag J: Der Programmierer hat endlich die neue Engine fertiggestellt, wir haben sie in die Produktion geladen, die alten Daten importiert und uns daran gemacht, die Farbe unserer zukünftigen Maseratis auszuwählen. Wir sind immer noch dabei, auszuwählen.
Die ersten Probleme tauchten auf. Die neue Website war erwartungsgemäß schwerer als die alte, aber das wirkliche Problem war, dass wir zur Traffic-Ankurbelung unter anderem Yandex.Zen nutzten, das Besuchermengen anlockte. Die Website brach bei 150 gleichzeitigen Verbindungen zusammen (ich spreche nicht von RPS, weil wir das nicht gemessen haben). Wir begannen, an den Knöpfen zu drehen und in den php_fpm-Einstellungen zu schrauben:
Oh, bereits 500 Verbindungen gehalten. Mit der Verwendung der Kreditkarte für die Werbefonds hat sich der Traffic erhöht. Nächster Meilenstein: 1000 gleichzeitige Verbindungen. Hier musste der Code bereits verfeinert werden und man musste sich in die Tiefen von MySQL einarbeiten. Ein Plätschern hat dabei nicht geholfen, aber das hatten wir auch nicht erwartet. Wir haben das Slow-Query-Protokoll aktiviert, Indizes auf die Datenbank gelegt, überflüssige Abfragen aus dem Code entfernt und die MySQL-Konfiguration basierend auf den Tipps des MySQL-Tuners noch einmal überarbeitet.
Neue Herausforderung – 2000 Verbindungen. Gerade rechtzeitig kam die Version Plesk 17.8 heraus, die unter anderem Nginx-Caching hinzugefügt hat. Wir haben aktualisiert (überraschend einfach). Wir testen. Es funktioniert! Und dann geschah das Unerwartete: Der Feed von Yandex Zen funktionierte nicht mehr. Die Website läuft, der Feed nicht. Kein Feed, kein Traffic. Die Stimmung schlägt um. Unter dem Druck der Umstände und wegen Ideenmangel begann ich sofort mit strace an Nginx und fand, wonach ich suchte. Es stellte sich heraus, dass das dumme Nginx in einem Moment einen 500-Fehler als Antwort auf die Yandex-Anforderung für feed.xml zwischengespeichert hatte. Wir haben das Problem behoben, indem wir Ausnahmen in die Cache-Einstellungen hinzugefügt haben:
Nachvollziehbar, dass der Eigentümer noch MEHR will. Die Wellen nehmen allmählich zu. Bislang schaffen wir es, aber wir haben im Voraus damit begonnen, mit Memcached zu experimentieren, zum Glück unterstützt Laravel es beinahe von Anfang an. Memcached manuell für "zum Spielen" zu installieren war irgendwie nicht gewollt, also haben wir ein Docker-Image eingerichtet. Direkt aus dem Panel.
Na gut, ich gebe es zu, ich musste in die Shell gehen und das Modul über PECL installieren. Direkt über die . Über den Anstieg der Bandbreite kann ich bisher nichts sagen, es gab keine signifikanten Anstiege. Die Site-Engine hat sich mit localhost:11211 verbunden, Statistiken werden angezeigt, der Speicher wird genutzt. Wenn es gefällt, schauen wir weiter, was wir tun können. Entweder lassen wir es so oder installieren ein "echtes" direkt auf der OS. Oder wir probieren es auf die gleiche Weise mit Redis.
Dann mussten wir ein E-Mail-Versandsystem einrichten. Keine Relais, nur SMTP-Authentifizierung. Ich habe eine E-Mail-Adresse eingerichtet und wir versenden über deren Daten mit PHP.
Vor nicht allzu langer Zeit erschien Plesk Obsidian (18.0), wir haben ohne Angst basierend auf unseren früheren Erfahrungen aktualisiert. Alles lief sehr reibungslos, ich habe nicht einmal etwas Interessantes zu berichten. Positiv zu erwähnen ist, dass die Benutzeroberfläche erheblich an Qualität gewonnen hat, sie wurde modernisiert und ist an manchen Stellen benutzerfreundlicher geworden. Ein cooles Feature ist das Advanced Monitoring auf Grafana.
Ich habe mich noch nicht im Detail damit beschäftigt, aber man kann zum Beispiel Warnungen für jeden Parameter per E-Mail einrichten. Für den Eigentümer, lol.
Da ich gerade über die Benutzeroberfläche spreche, ist sie anpassungsfähig und funktioniert tatsächlich recht gut auf dem Handy. In den frühen Phasen, während wir versuchten, die optimalen PHP-Einstellungen und anderes auszuloten, hat es uns sehr geholfen. Besonders wenn der Programmierer um 23 Uhr aus einem Arbeitsrausch heraus etwas macht, während ich im Arbeitsrausch Wodka in der Sauna trinke und es DRINGEND erforderlich ist, etwas umzuschalten.
Oh, übrigens. Auf dem Bild sieht man, dass PHP Composer erschienen ist. Wir haben noch nicht damit experimentiert, aber sagen wir mal, für dasselbe Laravel könnte er ein paar Logins in die Shell sparen und etwas Zeit für die Installation von Abhängigkeiten. Ein ähnliches System gibt es für Node.JS und Ruby.
Bei SSL ist alles einfach. Wenn die Domain zu dem richtigen Ort aufgelöst wird, kann Let’s Encrypt mit einem Klick eingerichtet werden und aktualisiert sich dann von selbst, sowohl für die Hauptdomain als auch für Subdomains und sogar für E-Mail-Dienste.
Plesk selbst ist zurzeit softwaretechnisch recht angenehm und stabil. Es aktualisiert sich selbst und das Betriebssystem leise, benötigt wenig Ressourcen und arbeitet reibungslos. Ich kann mich nicht erinnern, irgendwo auf ein offensichtliches Produktdefekt gestoßen zu sein. Probleme gab es natürlich, aber diese kamen entweder von einer unausgereiften Konfiguration oder irgendwo an der Schnittstelle, weshalb man nicht wirklich viel daran auszusetzen hat. Insgesamt sind die Eindrücke bei der Arbeit mit Plesk angenehm. Was es nicht hat, und das sollte man verstehen, ist jegliche Art von (irgendeiner) Clusterbildung. Weder LB noch HA. Man kann es versuchen, aber der Aufwand dafür wäre so groß, dass es besser wäre, von Anfang an etwas anders zu machen.
Ich denke, man kann zusammenfassen. Für den Fall, dass kein Administrator vorhanden ist oder nur sehr wenig, wenn die Kosten für das Hosting und die darauf laufende(n) Website(s) über, sagen wir, 100 Währungseinheiten liegen, wenn es nicht um einen miserablen Shared Hosting mit 1500 Websites auf einem Server geht, wenn der Entscheidungsfindende die Wahl hat, einen Teilzeitanalytiker einzustellen oder Software zu kaufen und einen Administrator für "halbe Brötchen" zu engagieren, oder ihn ganz wegzulassen – da macht es definitiv Sinn. Aus Sicht eines Remote-Administrators ist es dasselbe. 10 $ im Monat, und es spart Zeit und verleiht eine Flexibilität in der Arbeit für eine deutlich höhere Summe. Wenn ich zum Beispiel stark gebeten werde, ein ähnliches Projekt unter meinen Fittichen zu nehmen, werde ich darauf bestehen, es auf Plesk zu migrieren.oIch möchte einige Eindrücke über die Notwendigkeit oder Unnötigkeit eines solchen Tools wie ein Kontrollpanel für ein kommerzielles, einzelnes Server-Webprojekt bei Vorhandensein eines sehr Teilzeit-Administrators teilen.
Quelle: habr.com
