Nachdem ich 10 Jahre in der IT gearbeitet habe, wurde mir klar, dass es einfach unrealistisch ist, sich auf Hardware zu verlassen. Es neigt dazu, zusammenzubrechen. Sehr oft. Unerwartet.
Zum Glück dreht sich die Welt weiter, und jedes Jahr erscheinen immer mehr Hochverfügbarkeitslösungen. Der Aufbau einer guten HA-Architektur ist nicht einfach. Um Qualität und Preis in Einklang zu bringen, habe ich Virtualisierung, DRDB, Pacemaker, Nginx, HAPROXY verwendet. Ich habe verschiedene hochverfügbare Datenbankcluster (Postgres, MySQL) mit automatischem Failover und so weiter gebaut.
Natürlich kann es nur so oft interessant sein, es manuell zu bauen. Später wurden diese Lösungen mit Hilfe von Puppet automatisiert, worauf in einem Jahr SaltStack folgte.
Alles schien gut zu funktionieren.
Es ist jedoch komplizierter als es klingt:
Zweifellos löst Virtualisierung die meisten dieser Probleme. Ich habe mich damals für KVM entschieden und alle neuen Umgebungen auf der Basis eingerichtet. Viele virtuelle Maschinen müssen gesteuert werden. Plattformen wie CloudStack, OpenStack und einige andere bewältigen diese Aufgabe hervorragend.
Solche Lösungen sind jedoch nur für mittlere und große Projekte wirksam. Wenn ein Projekt klein ist und dramatisch wächst, haben wir ein Problem. Entweder müssen wir zu viel bezahlen und ursprünglich eine komplizierte und sperrige Architektur einrichten oder mit der Umstellung auf die Cloud beginnen, obwohl bereits viel Produktionsverkehr anfällt. Und wie Sie alle wissen, ist die Umstellung der Produktion auf eine andere Architektur mit minimalen Ausfallzeiten eine große Herausforderung.
Dann fing ich an, mir Container anzusehen, FreeBSD war mein Favorit (um ehrlich zu sein, ich wäre fast ein FreeBSD-Fan geworden). Es war eine schnelle und mühelose Methode, einen Container mit der erforderlichen Software in einer isolierten Umgebung auszuführen, ihn einfach zu kontrollieren und zu klonen. Ich habe es geliebt, mit Jail und ZFS zu arbeiten, besonders mit ZFS, so sehr, dass ich ein Python-/Django-Hosting-Projekt von ZFS auf Jail umgestellt habe.
Der einzige Nachteil war, dass die Verwendung von FreeBSD überall schwierig war: Die Leute, insbesondere die Entwickler, gewöhnten sich an Linux. Das war verständlich; Linux hatte BSDN schon vor langer Zeit aus dem Hosting-Markt verdrängt.
Dann, im Jahr 2013, als ich irgendwo an der vietnamesischen Küste chillte, stieß ich auf ein OpenSource-Projekt namens Docker. Die Technologie war so inspirierend, dass ich nicht anders konnte, als eine einseitige Anwendung mit dem Titel Launch your site in 1 click zu schreiben.
Die Idee war einfach: Du hast auf einen großen Button geklickt und hast eine Domain, ein Git-Repository und einen SSH-Port bekommen. Du könntest deinen Code auf Python im Git platzieren und ihn auf der Site sehen sowie bei Bedarf einen Root-Zugriff auf den Container erhalten.
Am nächsten Morgen habe ich den Link zu dieser Seite in einer Python-eigenen Google+-Gruppe gepostet und mein Motorrad zum Leuchtturm an der Südküste gefahren. Als ich in mein Dorf zurückkehrte, hatte mein Telefon eine Internetverbindung und ich sah, dass mein Google+-Konto voller Nachrichten war. Tatsächlich beeilten sich Hunderte von Menschen, diesen Dienst zu testen!
Das Traurige war jedoch, dass jemand schrieb: „Ich habe deinen Server heruntergefahren.“ Ich fing sofort nach meiner Rückkehr an, mir das anzusehen. Es stellte sich heraus, dass auf der SSD-Festplatte auf dem Server der Speicherplatz ausgegangen war. Jemand hatte einfach ausgeführt:
„solange wahr; do date >> ~/1.bin; fertig“.
Diese Person hat sich in den Kommentaren identifiziert. Er sagte, dass Docker eine schlechte Technologie sei, dass sie in diesem Universum keine Chance habe und dass OpenVZ der ultimative Weg sei.
.jpg)
Ehrlich gesagt war ich frustriert über eine solche Wendung der Ereignisse. Der Speicherplatz für einen Docker-Container war in der Tat unbegrenzt. Ich habe mich an Kontingente in ZFS gewöhnt und konnte nicht verstehen, wie etwas Ähnliches in Docker erstellt werden könnte.
Alles in allem hat diese Person meine Begeisterung für Docker erschüttert und ich habe aufgehört, mich in diese Richtung zu entwickeln. Allerdings nicht für eine lange Zeit.
2014 hatte ich nur freiberufliche Jobs und hatte viele junge Projekte mit sehr ähnlichen Anforderungen. Jeder benötigte ähnliche Architekturlösungen, Standardtechnologien und ähnliche Geschäftsanforderungen:
Dann erinnerte ich mich an Docker. Ungefähr zur gleichen Zeit erfuhr ich von Gitlab (davor habe ich Gitolite + Redmine eingerichtet, was nicht sehr praktisch war).
Am Ende habe ich eine Lösung gefunden, die Docker mit Gitlab verband. Git hängte das Erstellen eines Images nach dem anderen einfach in ein Repository ein, schickte es an eine private Docker-Registry, startete Container-Tests und wenn alles in Ordnung war, befahlen sie den Servern verschiedener Umgebungen, den Container neu zu erstellen. Es hat sehr reibungslos funktioniert.
Zu diesem Zeitpunkt hatte ich wirklich gut gelernt, mit Docker Volume und dem Docker-Netzwerk zu arbeiten, und sammelte meine eigene Sammlung von Dockerfiles, die die meisten typischen Bilder enthielten, die in Projekten verwendet wurden.
Später erhielt ich Docker-Compose-Dateien, mit denen ich schnell Compose für die lokale Entwicklung entwickeln konnte.
Alles lief gut, bis das Projekt größer wurde. Bash Force reichte nicht mehr aus und es kam ein Problem mit der Container-Orchestrierung auf. Dann habe ich von Tutum erfahren (jetzt ist es https://cloud.docker.com/).
Tutum war ein Traum. Es bot die Gelegenheit, ein sehr dynamisches Projekt auf der Grundlage der Microservice-Architektur umzusetzen http://checkio.org in Container, ohne dass Probleme auftreten. Der einzige Nachteil ist, dass die Bilder auf den Servern gespeichert werden müssen. Nicht jeder Kunde würde dem zustimmen.
Mit jedem Monat wurde Docker stabiler und voll funktionsfähig. Nach einem Jahr habe ich sogar aufgehört, es mit FreeBSD Jail zu vergleichen! Das ging so bis zum Herbst 2016, als es notwendig wurde, einen Hochverfügbarkeitscluster mit Orchestrierung und Skalierung für ein Wettunternehmen aufzubauen.
Eine der wichtigsten Anforderungen war die Geschwindigkeit der Bereitstellung neuer Umgebungen, die Modularität und das Hosting auf ihren dedizierten Servern. Container passten gut in dieses Paradigma, aber es musste noch etwas anderes vorhanden sein, um die Verwaltung in einer Architektur mit mehreren Diensten zu vereinfachen.
Zu der Zeit gab es:
Ich habe meine Recherche mit Docker Swarm begonnen, da es viel stabiler war und dem Docker selbst näher kam. Swarm hat sich während der Tests recht gut bewährt, aber das Wichtigste, was mich dazu brachte, weiter zu suchen, war die mangelnde Flexibilität und sogar ein gewisses Maß an technologischer Knappheit.
Googles Kubernetes erwies sich als ein sehr großes und vielversprechendes Projekt mit flexiblen Einrichtungen und einem praktischen Manifestformat unter Verwendung von YAML.
Ich habe schnell einen Prototyp aus einem Master- und mehreren Minion-Nodes entwickelt und angefangen zu experimentieren. Im ersten Monat habe ich so viele Bugs gefunden, dass ich meine ganze Zeit damit verbracht habe, sie in Githib-Problemen zu überprüfen und, falls ein Bug neu war, ihn zu melden. Der Code wurde repariert und mit einer fantastischen Geschwindigkeit entwickelt!
Ich erinnere mich, dass ich einen Installationsfehler gemeldet habe und zum Bahnhof gegangen bin. Während ich in meinem Taxi war (ungefähr 40 Minuten), wurde der Fehler behoben und an den Master geschickt!
Ein paar Monate lang war meine Erfahrung mit Kubernetes so, als würde ich mir einen Weg durch dornige Sträucher irgendwo in den Bergen bahnen.
Mit jedem Tag wurde Kuber immer stabiler, und meine Fähigkeiten, damit zu arbeiten, verbesserten sich.
Kubernetes begann die Produktion mit minimalen Ausfallzeiten (ein paar Minuten, um Anfragen an die Datenbank umzuleiten) und da war es, es funktionierte hervorragend.
Durch die Bereitstellung mit Rolling Update (mehr dazu später) wurden Ausfallzeiten bei den meisten nachfolgenden Bereitstellungen vermieden. Die Architekturbeschreibung in Kubernetes-YAML-Dateien ermöglichte die superschnelle Bereitstellung neuer Umgebungen. Und dank der Gitlab-Integration konnten die Entwickler Probleme mit der Inkompatibilität verschiedener Bibliotheken in verschiedenen Umgebungen vergessen.
Später haben wir Grenzwerte eingerichtet, die dazu beitrugen, im Falle eines Speicherlecks auf einem der Mikroserver effizient zu arbeiten, und machen dieses Problem sogar für einen Benutzer kaum wahrnehmbar, bis es im Code behoben ist.
.jpg)
Die Überwachung half dabei, die Messungen nach bestimmten Servicegruppen zu sammeln und zu verstehen, wie sich Änderungen im Code auf Latenz und Ressourcenverbrauch auswirken.
In den letzten 6 Monaten hat sich unser Team auf Projekte spezialisiert, die sich mit Kryptowährungen befassen. Es ist ein extrem merkwürdiger und dynamischer Markt, und was noch wichtiger ist, unser Produkt und unsere Expertise entsprechen den Anforderungen der Branche — Hochverfügbarkeit, Sicherheit und Autoscaling. Bisher haben wir mehrere vorgefertigte Architekturlösungen für typische serverseitige Projekte entwickelt, die mit Blockchain arbeiten:
Jetzt arbeiten wir daran, einen REST-Service zu erstellen, der die Arbeit von Kryptowährungen mit Blockchain vereinfachen kann. Erstellen Sie Adressen, führen Sie Geldtransfers durch und senden Sie das Geld automatisch an die Remote-Wallet.
Wir arbeiten auch daran, ein automatisches Installationsprogramm HA Kubernetes in AWS mit Weboberfläche zu erstellen, das Ihnen einige unserer Lösungen vorstellen und Ihnen die Möglichkeit geben wird, sie zu testen.
Wir haben also viele Entdeckungen auf Lager, die mein Team und ich mit Ihnen teilen werden.
Die Reise hat begonnen.
.jpg)
