„Cloud-native“ oder einfach „Cloud“-Anwendungen werden speziell für den Einsatz in Cloud-Infrastrukturen erstellt. Sie bestehen typischerweise aus einer Reihe lose gekoppelter Mikrodienste, die in Containern verpackt sind und wiederum von einer Cloud-Plattform verwaltet werden. Solche Anwendungen sind standardmäßig auf Ausfälle vorbereitet, was bedeutet, dass sie auch bei schwerwiegenden Ausfällen auf Infrastrukturebene zuverlässig funktionieren und skalieren. Die andere Seite der Medaille sind die Beschränkungen (Verträge), die die Cloud-Plattform Containeranwendungen auferlegt, um diese automatisch verwalten zu können.
Viele Unternehmen sind sich zwar der Notwendigkeit und Bedeutung der Umstellung auf Cloud-basierte Anwendungen voll bewusst, wissen jedoch immer noch nicht, wo sie anfangen sollen. In diesem Beitrag befassen wir uns mit einer Reihe von Grundsätzen, die es Ihnen, wenn Sie bei der Entwicklung von Containeranwendungen befolgt werden, ermöglichen, das Potenzial von Cloud-Plattformen auszuschöpfen und einen zuverlässigen Betrieb und eine Skalierung von Anwendungen auch bei schwerwiegenden Ausfällen der IT-Infrastruktur zu erreichen Ebene. Das ultimative Ziel der hier dargelegten Prinzipien besteht darin, zu lernen, wie man Anwendungen erstellt, die automatisch von Cloud-Plattformen wie Kubernetes verwaltet werden können.
Prinzipien des Softwaredesigns
In der Programmierwelt beziehen sich Prinzipien auf ziemlich allgemeine Regeln, die bei der Entwicklung von Software befolgt werden müssen. Sie können bei der Arbeit mit jeder Programmiersprache verwendet werden. Jedes Prinzip hat seine eigenen Ziele, die Werkzeuge zur Erreichung sind in der Regel Vorlagen und Praktiken. Es gibt auch eine Reihe grundlegender Prinzipien für die Erstellung hochwertiger Software, aus denen sich alle anderen ergeben. Hier einige Beispiele für Grundprinzipien:
- (Halten Sie es einfach, dumm) – machen Sie es nicht kompliziert;
- (Wiederholen Sie sich nicht) – Wiederholen Sie sich nicht;
- (Sie werden es nicht brauchen) – Erschaffen Sie nichts, was nicht sofort benötigt wird;
- Trennung der Anliegen – gemeinsame Verantwortung.
Wie Sie sehen, legen diese Prinzipien keine konkreten Regeln fest, sondern gehören zur Kategorie der sogenannten gesunden Menschenverstandsüberlegungen, die auf praktischen Erfahrungen basieren und von vielen Entwicklern geteilt werden und auf die sie regelmäßig verweisen.
Außerdem gibt es – Eine Reihe der ersten fünf Prinzipien der objektorientierten Programmierung und des objektorientierten Designs, formuliert von Robert Martin. SOLID umfasst umfassende, offene, komplementäre Prinzipien, die – wenn sie gemeinsam angewendet werden – dazu beitragen, bessere Softwaresysteme zu schaffen und diese langfristig besser zu warten.
Die SOLID-Prinzipien gehören zum Bereich OOP und werden in der Sprache von Konzepten und Konzepten wie Klassen, Schnittstellen und Vererbung formuliert. Analog lassen sich auch Entwicklungsprinzipien für Cloud-Anwendungen formulieren, nur dass das Grundelement hier keine Klasse, sondern ein Container sein wird. Wenn Sie diese Prinzipien befolgen, können Sie Containeranwendungen erstellen, die die Ziele und Vorgaben von Cloud-Plattformen wie Kubernetes besser erfüllen.
Cloud-native Container: der Red Hat-Ansatz
Heutzutage lässt sich nahezu jede Anwendung relativ einfach in Container verpacken. Doch damit Anwendungen innerhalb einer Cloud-Plattform wie Kubernetes effektiv automatisiert und orchestriert werden können, ist zusätzlicher Aufwand erforderlich.
Grundlage für die im Folgenden skizzierten Ideen war die Methodik und viele andere Arbeiten zu verschiedenen Aspekten der Erstellung von Webanwendungen, von der Quellcodeverwaltung bis hin zu Skalierungsmodellen. Die beschriebenen Prinzipien gelten nur für die Entwicklung von Containeranwendungen, die auf Microservices aufbauen und für Cloud-Plattformen wie Kubernetes konzipiert sind. Das Grundelement unserer Diskussion ist das Container-Image, und die Ziel-Container-Laufzeit ist die Container-Orchestrierungsplattform. Das Ziel der vorgeschlagenen Prinzipien besteht darin, Container zu erstellen, für die Planungs-, Skalierungs- und Überwachungsaufgaben auf den meisten Orchestrierungsplattformen automatisiert werden können. Die Grundsätze werden in keiner bestimmten Reihenfolge dargestellt.
Single-Concern-Prinzip (SCP)
Dieses Prinzip ähnelt in vielerlei Hinsicht dem Prinzip der Einzelverantwortung. ), das Teil der SOLID-Menge ist und besagt, dass jedes Objekt eine Verantwortung haben muss und diese Verantwortung vollständig in einer Klasse gekapselt sein muss. Der Sinn von SRP besteht darin, dass jede Verantwortung ein Grund für Veränderungen ist und eine Klasse nur einen einzigen Grund für Veränderungen haben darf.
In SCP verwenden wir das Wort „Bedenken“ anstelle des Wortes „Verantwortung“, um auf die höhere Abstraktionsebene und den umfassenderen Zweck eines Containers im Vergleich zu einer OOP-Klasse hinzuweisen. Und wenn das Ziel von SRP darin besteht, nur einen Grund für Veränderungen zu haben, dann steht hinter SCP der Wunsch, die Fähigkeit zur Wiederverwendung und zum Austausch von Containern zu erweitern. Indem Sie der SRP folgen und einen Container erstellen, der ein einzelnes Problem löst und dies funktional vollständig erledigt, erhöhen Sie die Chancen, dieses Container-Image in verschiedenen Anwendungskontexten wiederzuverwenden.
Das SCP-Prinzip besagt, dass jeder Container ein einzelnes Problem lösen und es gut machen soll. Darüber hinaus ist SCP in der Containerwelt einfacher zu erreichen als SRP in der OOP-Welt, da Container normalerweise einen einzigen Prozess ausführen und dieser Prozess meistens eine einzige Aufgabe löst.
Wenn ein Container-Microservice mehrere Probleme gleichzeitig lösen muss, kann er in Einzeltask-Container unterteilt und mithilfe von Sidecar- und Init-Container-Vorlagen in einem Pod (einer Einheit der Containerplattformbereitstellung) kombiniert werden. Darüber hinaus erleichtert SCP das Ersetzen eines alten Containers (z. B. eines Webservers oder eines Nachrichtenbrokers) durch einen neuen, der das gleiche Problem löst, aber über erweiterte Funktionalität verfügt oder besser skaliert.
High-Observability-Prinzip (HOP)
Wenn Container als einheitliche Methode zum Verpacken und Ausführen von Anwendungen verwendet werden, werden die Anwendungen selbst als Blackbox behandelt. Wenn es sich jedoch um Cloud-Container handelt, müssen diese der Laufzeit spezielle APIs zur Verfügung stellen, um den Zustand der Container zu überwachen und gegebenenfalls entsprechende Maßnahmen zu ergreifen. Ohne dies wird es nicht möglich sein, die Automatisierung der Aktualisierung von Containern und der Verwaltung ihres Lebenszyklus zu vereinheitlichen, was wiederum die Stabilität und Benutzerfreundlichkeit des Softwaresystems verschlechtern wird.
In der Praxis sollte eine Containeranwendung mindestens über eine API für verschiedene Arten von Gesundheitsprüfungen verfügen: Liveness-Tests und Bereitschaftstests. Wenn eine Anwendung behauptet, mehr zu leisten, muss sie andere Möglichkeiten zur Überwachung ihres Zustands bereitstellen. Beispielsweise die Protokollierung wichtiger Ereignisse über STDERR und STDOUT zur Protokollaggregation mit Fluentd, Logstash und anderen ähnlichen Tools. Sowie die Integration mit Tracing- und Metriksammlungsbibliotheken wie OpenTracing, Prometheus usw.
Im Allgemeinen kann die Anwendung immer noch als Blackbox behandelt werden, sie muss jedoch mit allen APIs ausgestattet sein, die die Plattform benötigt, um sie bestmöglich überwachen und verwalten zu können.
Life-Cycle-Konformitätsprinzip (LCP)
LCP ist das Gegenteil von HOP. Während HOP angibt, dass der Container der Plattform Lese-APIs zur Verfügung stellen muss, erfordert LCP, dass die Anwendung in der Lage ist, Informationen von der Plattform zu akzeptieren. Darüber hinaus muss der Container Ereignisse nicht nur empfangen, sondern sich auch anpassen, also auf sie reagieren. Daher der Name des Prinzips, das als Voraussetzung angesehen werden kann, um der Plattform Schreib-APIs zur Verfügung zu stellen.
Plattformen verfügen über verschiedene Arten von Ereignissen, die bei der Verwaltung des Lebenszyklus eines Containers helfen. Es liegt jedoch an der Anwendung selbst, zu entscheiden, welche davon sie wahrnimmt und wie sie reagiert.
Es ist klar, dass einige Ereignisse wichtiger sind als andere. Wenn eine Anwendung beispielsweise Abstürze nicht gut toleriert, muss sie Signal: Terminate-Nachrichten (SIGTERM) akzeptieren und ihre Beendigungsroutine so schnell wie möglich initiieren, um das Signal: Kill (SIGKILL) abzufangen, das nach SIGTERM kommt.
Darüber hinaus können Ereignisse wie PostStart und PreStop für den Lebenszyklus einer Anwendung wichtig sein. Nach dem Start einer Anwendung kann es beispielsweise eine gewisse Aufwärmzeit benötigen, bevor sie auf Anfragen reagieren kann. Oder die Anwendung muss beim Herunterfahren auf besondere Weise Ressourcen freigeben.
Das Bildunveränderlichkeitsprinzip (IIP)
Es ist allgemein anerkannt, dass Containeranwendungen nach der Erstellung unverändert bleiben sollten, auch wenn sie in unterschiedlichen Umgebungen ausgeführt werden. Dies erfordert die Notwendigkeit, die Datenspeicherung zur Laufzeit zu externalisieren (mit anderen Worten, dafür externe Tools zu verwenden) und sich auf externe, laufzeitspezifische Konfigurationen zu verlassen, anstatt für jede Umgebung einzigartige Container zu ändern oder zu erstellen. Nach Änderungen an der Anwendung muss das Container-Image neu erstellt und in allen verwendeten Umgebungen bereitgestellt werden. Bei der Verwaltung von IT-Systemen kommt übrigens ein ähnliches Prinzip zum Einsatz, das sogenannte Prinzip der Unveränderlichkeit von Servern und Infrastruktur.
Ziel von IIP ist es, die Erstellung separater Container-Images für verschiedene Laufzeitumgebungen zu verhindern und überall das gleiche Image zusammen mit der entsprechenden umgebungsspezifischen Konfiguration zu verwenden. Wenn Sie diesem Prinzip folgen, können Sie im Hinblick auf die Automatisierung von Cloud-Systemen so wichtige Praktiken wie Rollback und Rollforward von Anwendungsaktualisierungen implementieren.
Prozessverfügbarkeitsprinzip (PDP)
Eine der wichtigsten Eigenschaften eines Containers ist seine Flüchtigkeit: Eine Instanz eines Containers lässt sich leicht erstellen und leicht zerstören, sodass sie jederzeit problemlos durch eine andere Instanz ersetzt werden kann. Für einen solchen Austausch kann es viele Gründe geben: Fehlschlagen eines Wartungstests, Skalierung der Anwendung, Übertragung auf einen anderen Host, Erschöpfung der Plattformressourcen oder andere Situationen.
Folglich müssen Containeranwendungen ihren Zustand mithilfe externer Mittel aufrechterhalten oder hierfür interne verteilte Schemata mit Redundanz verwenden. Darüber hinaus muss die Anwendung schnell gestartet und beendet werden und auf einen plötzlichen schwerwiegenden Hardwareausfall vorbereitet sein.
Eine Praxis, die zur Umsetzung dieses Prinzips beiträgt, besteht darin, die Behälter klein zu halten. Cloud-Umgebungen können automatisch einen Host auswählen, auf dem eine Containerinstanz gestartet werden soll. Je kleiner der Container, desto schneller wird er gestartet – er wird einfach schneller über das Netzwerk auf den Zielhost kopiert.
Prinzip der Selbsteindämmung (S-CP)
Nach diesem Prinzip werden bei der Montage alle notwendigen Komponenten in den Container aufgenommen. Der Container sollte unter der Annahme erstellt werden, dass das System nur über einen reinen Linux-Kernel verfügt, daher sollten alle erforderlichen zusätzlichen Bibliotheken im Container selbst platziert werden. Es sollte auch Dinge wie die Laufzeit für die entsprechende Programmiersprache, die Anwendungsplattform (falls erforderlich) und andere Abhängigkeiten enthalten, die während der Ausführung der Containeranwendung erforderlich sind.
Ausnahmen gelten für Konfigurationen, die von Umgebung zu Umgebung variieren und zur Laufzeit bereitgestellt werden müssen, beispielsweise über eine Kubernetes ConfigMap.
Eine Anwendung kann mehrere Container-Komponenten umfassen, beispielsweise einen separaten DBMS-Container innerhalb einer Container-Webanwendung. Nach dem S-CP-Prinzip sollten diese Container nicht zu einem zusammengefasst werden, sondern so gestaltet sein, dass der DBMS-Container alles Notwendige für den Betrieb der Datenbank und der Webanwendungscontainer alles Notwendige für den Betrieb des Webs enthält Anwendung, derselbe Webserver. Dadurch ist der Webanwendungscontainer zur Laufzeit vom DBMS-Container abhängig und greift bei Bedarf auf ihn zu.
Runtime-Confinement-Prinzip (RCP)
Das S-CP-Prinzip definiert, wie der Container aufgebaut sein soll und was die Image-Binärdatei enthalten soll. Aber ein Container ist nicht nur eine „Black Box“, die nur eine Eigenschaft hat – die Dateigröße. Während der Ausführung nimmt der Container andere Dimensionen an: die Menge des verwendeten Speichers, die CPU-Zeit und andere Systemressourcen.
Und hier kommt das RCP-Prinzip zum Tragen, nach dem der Container seinen Bedarf an Systemressourcen enthaupten und auf die Plattform übertragen muss. Mit den Ressourcenprofilen jedes Containers (wie viel CPU-, Speicher-, Netzwerk- und Festplattenressourcen er benötigt) kann die Plattform die Planung und automatische Skalierung optimal durchführen, die IT-Kapazität verwalten und SLA-Level für Container einhalten.
Neben der Erfüllung der Ressourcenanforderungen des Containers ist es auch wichtig, dass die Anwendung ihre eigenen Grenzen nicht überschreitet. Andernfalls ist es bei einem Ressourcenmangel wahrscheinlicher, dass die Plattform diese in die Liste der Anwendungen aufnimmt, die beendet oder migriert werden müssen.
Wenn wir davon sprechen, Cloud-First zu sein, meinen wir die Art und Weise, wie wir arbeiten.
Oben haben wir eine Reihe allgemeiner Prinzipien formuliert, die die methodische Grundlage für die Erstellung hochwertiger Containeranwendungen für Cloud-Umgebungen bilden.
Beachten Sie, dass Sie zusätzlich zu diesen allgemeinen Grundsätzen auch weitere fortgeschrittene Methoden und Techniken für die Arbeit mit Containern benötigen. Darüber hinaus haben wir einige kurze Empfehlungen, die konkreter sind und je nach Situation angewendet (oder auch nicht angewendet) werden sollten:
- Versuchen Sie, die Größe der Bilder zu reduzieren: Löschen Sie temporäre Dateien und installieren Sie keine unnötigen Pakete – je kleiner die Containergröße, desto schneller wird sie zusammengestellt und über das Netzwerk auf den Zielhost kopiert.
- Konzentrieren Sie sich auf beliebige Benutzer-IDs: Verwenden Sie nicht den Befehl sudo oder eine spezielle Benutzer-ID, um Ihre Container zu starten.
- Markieren Sie wichtige Ports: Sie können Portnummern zur Laufzeit festlegen. Es ist jedoch besser, sie mit dem Befehl EXPOSE anzugeben. Dies erleichtert anderen Personen und Programmen die Verwendung Ihrer Bilder.
- Speichern Sie persistente Daten auf Volumes: Daten, die nach der Zerstörung des Containers verbleiben sollen, sollten auf Volumes geschrieben werden.
- Bildmetadaten schreiben: Tags, Beschriftungen und Anmerkungen erleichtern die Verwendung von Bildern – andere Entwickler werden es Ihnen danken.
- Host und Bilder synchronisieren: Bei einigen Containeranwendungen muss der Container anhand bestimmter Attribute wie Zeit oder Maschinen-ID mit dem Host synchronisiert werden.
- Abschließend stellen wir Ihnen Vorlagen und Best Practices vor, die Ihnen dabei helfen, die oben aufgeführten Grundsätze effektiver umzusetzen:
11. Juni um 11.00 Uhr
Was wirst du lernen:
- Unveränderliches Red Hat Enterprise Linux CoreOS
- OpenShift-Service-Mesh
- Operator-Framework
- Knative-Framework
Source: habr.com