Geekly articles weekly

5 Common-Sense-Prinzipien zum Erstellen von Cloud-nativen Apps

Cloud-basierte (Cloud-native) oder einfach nur Cloud-Anwendungen werden speziell für die Verwendung in Cloud-Infrastrukturen erstellt. Normalerweise werden sie als eine Reihe von lose gekoppelten Mikrodiensten erstellt, die in Containern verpackt sind, die wiederum von einer Cloud-Plattform verwaltet werden. Solche Anwendungen sind standardmäßig für Ausfälle bereit, was bedeutet, dass sie zuverlässig funktionieren und auch bei schwerwiegenden Ausfällen auf Infrastrukturebene skaliert werden können. Die Kehrseite der Medaille sind die Einschränkungen (Verträge), die die Cloud-Plattform Containeranwendungen auferlegt, um sie automatisch verwalten zu können.



Viele Unternehmen sind sich der Notwendigkeit und Wichtigkeit der Umstellung auf Cloud-Anwendungen bewusst und wissen immer noch nicht, wo sie anfangen sollen. In diesem Beitrag werden wir eine Reihe von Prinzipien betrachten, deren Einhaltung bei der Entwicklung von Containeranwendungen das Potenzial von Cloud-Plattformen erkennt und einen zuverlässigen Betrieb und eine zuverlässige Skalierung von Anwendungen ermöglicht, selbst bei schwerwiegenden Ausfällen auf der Ebene der IT-Infrastruktur. Das ultimative Ziel der hier beschriebenen Prinzipien ist es, zu lernen, wie Anwendungen erstellt werden, die automatisch von Cloud-Plattformen wie Kubernetes verwaltet werden können.

Prinzipien des Software-Designs


In der Welt der Programmierung werden Prinzipien als ziemlich allgemeine Regeln verstanden, die bei der Entwicklung von Software beachtet werden müssen. Sie können bei der Arbeit mit jeder Programmiersprache verwendet werden. Jedes Prinzip hat seine eigenen Ziele, die Vorlagen und Praktiken dienen normalerweise als Instrument für ihre Erreichung. Es gibt auch eine Reihe grundlegender Prinzipien für die Erstellung hochwertiger Software, aus denen alle anderen hervorgehen. Hier einige Beispiele für Grundprinzipien:

  • KISS (halte es einfach, dumm) - mach es nicht kompliziert;
  • DRY (Wiederhole dich nicht) - wiederhole nicht;
  • YAGNI (Du wirst es nicht brauchen) - erschaffe nichts, in dem es keine unmittelbare Notwendigkeit gibt;
  • SoC (Trennung von Bedenken) - um Verantwortlichkeiten zu teilen.

Wie Sie sehen können, legen diese Prinzipien keine spezifischen Regeln fest, sondern gehören zur Kategorie der sogenannten Überlegungen zum gesunden Menschenverstand, die auf praktischen Erfahrungen vieler Entwickler beruhen und auf die sie sich regelmäßig beziehen.
Darüber hinaus gibt es SOLID - eine Reihe der ersten fünf Prinzipien der objektorientierten Programmierung und Gestaltung, die von Robert Martin formuliert wurden. SOLID enthält ergänzende Prinzipien, die verallgemeinert und offen für Interpretationen sind und - wenn sie in Kombination angewendet werden - dazu beitragen, bessere Softwaresysteme zu erstellen und diese langfristig besser zu unterstützen.

SOLID-Prinzipien gelten für OOP und werden in Form von Konzepten und Konzepten wie Klassen, Schnittstellen und Vererbung formuliert. Analog dazu können Sie für Cloud-Anwendungen auch die Entwicklungsprinzipien formulieren. Nur das Grundelement ist hier keine Klasse, sondern ein Container. Nach diesen Grundsätzen können Sie containerisierte Anwendungen erstellen, die die Ziele von Cloud-Plattformen wie Kubernetes besser erfüllen.

Cloud-basierte Container: Red Hat-Ansatz


Heutzutage ist fast jede Anwendung relativ einfach in Behälter zu verpacken. Damit Anwendungen innerhalb einer Cloud-Plattform wie Kubernetes effizient automatisiert und orchestriert werden können, ist jedoch zusätzlicher Aufwand erforderlich.
Die unten vorgestellten Ideen basierten auf der Methodik der Zwölf-Faktoren-App und vielen anderen Arbeiten zu verschiedenen Aspekten der Erstellung von Webanwendungen, von der Quellcodeverwaltung bis hin zu Skalenmodellen. Die beschriebenen Prinzipien gelten nur für die Entwicklung von Containeranwendungen, die auf Microservices basieren und für Cloud-Plattformen wie Kubernetes konzipiert sind. Das Grundelement unserer Diskussion ist das Image des Containers, und die Laufzeit des Zielcontainers ist die Container-Orchestrierungsplattform. Der Zweck der vorgeschlagenen Prinzipien besteht darin, Container zu erstellen, für die Sie auf den meisten Orchestrierungsplattformen Planungsaufgaben (Planung - Auswahl eines Hosts zum Ausführen der Containerinstanz), Skalierung und Überwachung automatisieren können. Die Prinzipien sind in zufälliger Reihenfolge aufgeführt.

Single Concern Principle (SCP)


Dieses Prinzip ähnelt in vielerlei Hinsicht dem Single Responsibility Principle ( SRP ), das Teil der SOLID-Suite ist und besagt, dass jedes Objekt eine Verantwortung haben muss und diese Verantwortung vollständig in der Klasse enthalten sein muss. Das Wesentliche an SRP ist, dass jede Pflicht ein Grund für Änderungen ist und eine Klasse nur einen Grund für Änderungen haben muss.

In SCP verwenden wir anstelle des Wortes "Verantwortung" das Wort "Anliegen", um eine höhere Abstraktionsebene und einen breiteren Zweck des Containers im Vergleich zur OOP-Klasse anzuzeigen. Und wenn das Ziel von SRP darin besteht, nur einen Grund für Änderungen zu haben, möchte SCP die Möglichkeiten zur Wiederverwendung und zum Austausch von Containern erweitern. Indem Sie SRP folgen und einen Container erstellen, der eine einzelne Aufgabe löst und funktionsfähig macht, erhöhen Sie die Wahrscheinlichkeit, dass das Image dieses Containers in verschiedenen Anwendungskontexten wiederverwendet wird.

Das Prinzip von SCP besagt, dass jeder Container eine einzelne Aufgabe lösen und gut erledigen sollte. Darüber hinaus ist SCP in der Welt der Container einfacher zu erreichen als SRP in der Welt der OOP, da Container normalerweise einen einzigen Prozess ausführen und dieser Prozess meistens eine einzige Aufgabe löst.

Wenn ein Container-Mikroservice mehrere Probleme gleichzeitig lösen muss, kann er in Einzelaufgabencontainer unterteilt und mithilfe von Seitenwagenvorlagen und Init-Containern zu einem Pod (Einheit zum Bereitstellen einer Containerplattform) zusammengeführt werden. Darüber hinaus macht es SCP einfach, einen alten Container (z. B. einen Webserver oder einen Nachrichtenbroker) durch einen neuen zu ersetzen, der das gleiche Problem löst, jedoch über verbesserte Funktionen verfügt oder besser skaliert.



Prinzip der Bequemlichkeit der Überwachung (High Observability Principle, HOP)


Wenn Container als einheitliche Methode zum Verpacken und Starten von Anwendungen verwendet werden, werden die Anwendungen selbst als „Black Box“ betrachtet. Wenn es sich jedoch um Cloud-Container handelt, müssen sie der Laufzeit spezielle APIs zur Verfügung stellen, um den Zustand der Container zu überwachen und gegebenenfalls geeignete Maßnahmen zu ergreifen. Ohne dies ist es nicht möglich, die Automatisierung der Aktualisierung von Containern und die Verwaltung ihres Lebenszyklus zu vereinheitlichen, was wiederum die Stabilität und Benutzerfreundlichkeit des Softwaresystems verschlechtert.


In der Praxis sollte eine Containeranwendung mindestens eine API für verschiedene Arten von Gesundheitsprüfungen haben: Lebendigkeitstests und Bereitschaftstests. Wenn der Antrag behauptet, mehr zu sein, sollte er andere Mittel zur Überwachung seines Zustands bereitstellen. Protokollieren Sie beispielsweise wichtige Ereignisse über STDERR und STDOUT, um Protokolle mit Fluentd, Logstash und anderen ähnlichen Tools zu aggregieren. Sowie die Integration in Trace- und Sammlungsbibliotheken von Metriken wie OpenTracing, Prometheus usw.

Im Allgemeinen kann die Anwendung immer noch als „Black Box“ betrachtet werden, muss jedoch gleichzeitig mit allen APIs ausgestattet sein, die die Plattform benötigt, um sie optimal überwachen und verwalten zu können.

Lebenszyklus-Konformitätsprinzip (LCP)


LCP ist das Gegenteil von HOP. Wenn die HOP angibt, dass der Container der Plattform APIs zum Lesen bereitstellen muss, muss die Anwendung für LCP Informationen von der Plattform empfangen können. Darüber hinaus sollte der Container Ereignisse nicht nur empfangen, sondern auch anpassen, dh darauf reagieren. Daher der Name des Prinzips, der als Voraussetzung für die Bereitstellung von APIs zum Schreiben für die Plattform angesehen werden kann.


Plattformen verfügen über verschiedene Arten von Ereignissen, mit denen der Lebenszyklus des Containers verwaltet werden kann. Es liegt jedoch an der Anwendung, zu entscheiden, welche von ihnen wahrgenommen werden sollen und wie sie reagieren sollen.

Es ist klar, dass einige Ereignisse wichtiger sind als andere. Wenn eine Anwendung beispielsweise kein Herunterfahren im Notfall toleriert, muss sie Signal: Terminate (SIGTERM) -Nachrichten akzeptieren und den Beendigungsvorgang so bald wie möglich einleiten, um das nach SIGTERM kommende Signal: Kill (SIGKILL) abzufangen.

Darüber hinaus können Ereignisse wie PostStart und PreStop für den Anwendungslebenszyklus wichtig sein. Nach dem Starten der Anwendung kann es beispielsweise einige Zeit dauern, bis sie „aufgewärmt“ ist, bevor sie auf Anforderungen reagieren kann. Oder die Anwendung muss beim Herunterfahren Ressourcen freigeben.

Das Prinzip der Unveränderlichkeit des Behälterbildes (Image Immutability Principle, IIP)


Es ist allgemein anerkannt, dass containerisierte Anwendungen nach dem Zusammenbau unverändert bleiben müssen, auch wenn sie in verschiedenen Umgebungen ausgeführt werden. Dies impliziert die Notwendigkeit, den Datenspeicher zur Laufzeit zu externalisieren (dh externe Tools zu verwenden) und sich auf externe Konfigurationen zu verlassen, die für eine bestimmte Laufzeitumgebung konfiguriert sind, anstatt eindeutige Container für jede Umgebung zu ändern oder zu erstellen. Nach Änderungen an der Anwendung muss das Container-Image in allen verwendeten Umgebungen neu zusammengesetzt und bereitgestellt werden. Übrigens wird bei der Verwaltung von IT-Systemen ein ähnliches Prinzip verwendet, das als Prinzip der Unveränderlichkeit von Servern und Infrastruktur bekannt ist.

Das Ziel von IIP ist es, die Erstellung separater Container-Images für verschiedene Laufzeitumgebungen zu verhindern und überall dasselbe Image zusammen mit der entsprechenden Konfiguration für eine bestimmte Umgebung zu verwenden. Das Befolgen dieses Prinzips ermöglicht es Ihnen, so wichtige Vorgehensweisen im Hinblick auf die Automatisierung von Cloud-Systemen wie das Zurücksetzen und Zurücksetzen von Anwendungsaktualisierungen zu implementieren.


Process Disposability Principle (PDP)


Eines der wichtigsten Merkmale eines Containers ist seine Vergänglichkeit: Eine Containerinstanz kann leicht erstellt und leicht zerstört werden, sodass sie jederzeit leicht durch eine andere Instanz ersetzt werden kann. Es kann viele Gründe für einen solchen Austausch geben: Fehler beim Zustandstest, Anwendungsskalierung, Portierung auf einen anderen Host, Erschöpfung der Plattformressourcen oder andere Situationen.


Infolgedessen müssen Containeranwendungen ihren Status mit externen Mitteln beibehalten oder dafür interne verteilte Schaltkreise mit Redundanz verwenden. Darüber hinaus sollte die Anwendung schnell gestartet und schnell heruntergefahren werden und auf einen plötzlichen schwerwiegenden Hardwarefehler vorbereitet sein.

Eine Praxis, die zur Umsetzung dieses Prinzips beiträgt, besteht darin, kleine Container zu erstellen. Cloud-Umgebungen können automatisch einen Host zum Starten einer Containerinstanz auswählen. Je kleiner der Container, desto schneller wird er gestartet. Er wird einfach schneller über das Netzwerk auf den Zielhost kopiert.

Selbstbeherrschungsprinzip (S-CP)


Nach diesem Prinzip sind bei der Montage alle notwendigen Komponenten im Behälter enthalten. Der Container sollte in der Erwartung erstellt werden, dass das System nur einen sauberen Linux-Kernel hat, sodass alle erforderlichen zusätzlichen Bibliotheken im Container selbst abgelegt werden müssen. Dort sollten sich auch Dinge befinden, wie die Laufzeit für die entsprechende Programmiersprache, die Anwendungsplattform (falls erforderlich) und andere Abhängigkeiten, die während des Betriebs der Containeranwendung erforderlich sind.



Ausnahmen werden nur für Konfigurationen gemacht, die von Umgebung zu Umgebung variieren und zur Laufzeit bereitgestellt werden sollten, beispielsweise über Kubernetes ConfigMap.

Eine Anwendung kann mehrere containerisierte Komponenten enthalten, z. B. einen separaten DBMS-Container als Teil einer Webcontaineranwendung. Nach dem S-CP-Prinzip sollten diese Container nicht zu einem zusammengefasst werden, sondern so erstellt werden, dass der DBMS-Container alles enthält, was für das Funktionieren der Datenbank erforderlich ist, und der Webanwendungscontainer alles enthält, was für das Funktionieren der Webanwendung erforderlich ist, denselben Webserver . Daher hängt der Webanwendungscontainer zur Laufzeit vom DBMS-Container ab und greift bei Bedarf darauf zu.

Runtime Confinement Principle (RCP)


Das S-CP-Prinzip definiert, wie ein Container zusammengesetzt werden soll und was eine Binärbilddatei enthalten soll. Ein Container ist jedoch nicht nur eine „Black Box“, die nur ein Merkmal aufweist - die Dateigröße. Zur Laufzeit erhält der Container andere Dimensionen: den verwendeten Speicher, die Prozessorzeit und andere Systemressourcen.


Und hier ist das RCP-Prinzip nützlich, wonach der Container seine Anforderungen an Systemressourcen enthaupten und auf die Plattform übertragen muss. Mit den Ressourcenprofilen jedes Containers (wie viel CPU-, Speicher-, Netzwerk- und Festplattensystemressourcen benötigt werden) kann die Plattform die Planung und automatische Skalierung optimal durchführen, IT-Kapazitäten verwalten und SLA-Ebenen für Container unterstützen.

Neben der Erfüllung der Ressourcenanforderungen des Containers ist es auch wichtig, dass die Anwendung nicht über das von ihr festgelegte Framework hinausgeht. Andernfalls wird die Plattform bei Ressourcenknappheit eher in die Liste der Anwendungen aufgenommen, die unterbrochen oder migriert werden müssen.

Wenn wir über den Fokus auf die Cloud sprechen, meinen wir in erster Linie 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 Prinzipien zusätzliche fortgeschrittene Methoden und Techniken für die Arbeit mit Containern benötigen. Darüber hinaus haben wir einige kurze Empfehlungen, die spezifischer sind und je nach Situation angewendet (oder nicht angewendet) werden sollten:


Webinar zur neuen Version von OpenShift Container Platform - 4
11. Juni um 11.00 Uhr

Was Sie lernen werden:

  • Unveränderliches Red Hat Enterprise Linux CoreOS
  • Open-Shift-Service-Mesh
  • Operator Framework
  • Knativer Rahmen

Source: https://habr.com/ru/post/de455024/

More articles:


All Articles