Buch „Kubernetes Patterns: Native Cloud Application Development Patterns“

BildHallo habrozhiteli!

Mit der Entwicklung von Microservices und Containern haben sich die Ansätze für das Design, die Erstellung und den Start von Software geändert. Lernen Sie die neuen Entwurfsmuster und -prinzipien kennen, die für die Implementierung von Kubernetes-Cloud-Anwendungen erforderlich sind.

Dieses Buch richtet sich an Entwickler, die Cloud-basierte Anwendungen für die Kubernetes-Plattform entwerfen und entwickeln möchten. Der größte Vorteil davon sind Leser, die mit Containern zumindest ein wenig vertraut sind und ein neues Niveau erreichen möchten. Jedes Entwurfsmuster ist eine Beschreibung des tatsächlichen Problems, und die Lösung wird durch spezifische Codebeispiele unterstützt und veranschaulicht.

Auszug. Beiwagenmuster


Das Sidecar-Muster (Trailer) definiert einen Container, der die Funktionen eines vorhandenen Containers erweitert, ohne ihn zu ändern. Dies ist eines der grundlegenden Containermuster, mit denen Sie hochspezialisierte Container erstellen können, die eng zusammenarbeiten. In diesem Kapitel erfahren Sie alles über die Idee des Sidecar-Musters (Trailer). In den Kapiteln 16 und 17 lernen Sie spezielle Varianten dieses Musters kennen - das Adapter- bzw. das Ambassador-Muster.

Aufgabe


Container ist eine beliebte Verpackungstechnologie, mit der Entwickler und Systemadministratoren Anwendungen auf einheitliche Weise erstellen, bereitstellen und ausführen können. Ein Container repräsentiert die natürliche Grenze einer Funktionseinheit mit ihrer Laufzeit, ihrem Release-Zyklus, ihrer API und dem Entwicklungsteam, zu dem sie gehört. Ein typischer Container verhält sich unter Linux wie ein Prozess - löst ein Problem und macht es gut - und wird unter der Annahme erstellt, dass er ersetzt und wiederverwendet werden kann. Letzteres ist besonders wichtig, da Sie damit schnell Anwendungen mit vorhandenen Spezialcontainern erstellen können.

Derzeit müssen Sie zum Senden einer HTTP-Anfrage keine Client-Bibliothek schreiben, sondern nur die vorhandene verwenden. Um die Website zu pflegen, müssen Sie keinen Container mit einem Webserver erstellen, sondern nur den vorhandenen verwenden. Dieser Ansatz ermöglicht es Entwicklern, das Rad nicht neu zu erfinden und ein Ökosystem mit weniger Containern von besserer Qualität für die Wartung zu schaffen. Um jedoch hochspezialisierte wiederverwendbare Container verwenden zu können, sind Möglichkeiten erforderlich, ihre Fähigkeiten und Mittel zur Organisation von Interaktionen zwischen ihnen zu erweitern. Das Sidecar-Muster (Trailer) beschreibt eine solche Art der Organisation von Interaktionen, wenn ein Container die Funktionen eines anderen vorhandenen Containers erweitert.

Entscheidung


In Kapitel 1 haben wir gesehen, wie Sie mit Pods mehrere Container zu einem Block kombinieren können. Hinter den Kulissen befindet sich zur Laufzeit unter ebenfalls ein Container, der jedoch als angehaltener Prozess (buchstäblich mit dem Befehl pause) vor allen anderen Containern im Kamin beginnt. Es werden lediglich alle Linux-Namespaces gespeichert, mit denen Anwendungscontainer während des gesamten Pod-Lebenszyklus interagieren. Neben diesem Implementierungsdetail sind auch alle Merkmale von Interesse, die die Herdabstraktion bietet.

Unter ist ein so grundlegendes Grundelement, dass es auf vielen Cloud-Plattformen vorhanden ist, wenn auch unter verschiedenen Namen, aber immer mit ähnlichen Fähigkeiten. Unter legt als Bereitstellungseinheit bestimmte Laufzeitbeschränkungen für seine Container fest. Beispielsweise werden alle Container auf einem Knoten bereitgestellt und haben einen gemeinsamen Lebenszyklus. Darüber hinaus ermöglicht under seinen Containern, gemeinsam genutzte Volumes zu verwenden und Daten über ein lokales Netzwerk oder mithilfe von Host-Interprozess-Kommunikationstools auszutauschen. Aus diesem Grund kombinieren Benutzer Container zu Pods. Das Sidecar-Muster (Trailer), manchmal auch Sidekick (Companion) genannt, beschreibt das Szenario des Hinzufügens eines Containers zur Unterseite, um die Funktionen eines anderen Containers zu erweitern.

Ein typisches Beispiel für dieses Muster ist der HTTP-Server und der Synchronisationsmechanismus mit dem Git-Repository. Der HTTP-Servercontainer löst die Probleme, die mit der Wartung von Dateien über HTTP verbunden sind, und weiß nicht, wie und woher diese Dateien stammen. Ebenso besteht der einzige Zweck eines Containers, der mit Git synchronisiert wird, darin, Daten im lokalen Dateisystem mit Daten auf dem Git-Server zu synchronisieren. Es ist ihm egal, was nach der Synchronisierung mit den Dateien passiert. Seine einzige Aufgabe besteht darin, den Inhalt des lokalen Ordners mit dem Inhalt auf dem Remote-Git-Server zu synchronisieren. Listing 15.1 enthält eine Pod-Definition mit diesen beiden Containern, die für die Verwendung des Volumes für die Dateifreigabe konfiguriert sind.

Listing 15.1. Sidecar Pattern Implementierung (Trailer)

apiVersion: v1
kind: Pod
metadata:
    name: web-app
spec:
    containers:
    - name: app
      image: docker.io/centos/httpd ❶
      ports:
      - containerPort: 80
      volumeMounts:
      - mountPath: /var/www/html ❸
      name: git
    - name: poll
      image: axeclbr/git ❷
      volumeMounts:
      - mountPath: /var/lib/data ❸
        name: git
      env:
      - name: GIT_REPO
         value: https://github.com/mdn/beginner-html-site-scripted
      command:
      - "sh"
      - "-c"
      - "git clone $(GIT_REPO) . && watch -n 600 git pull"
      workingDir: /var/lib/data
volumes:
- emptyDir: {}
      name: git

(1) Der Hauptanwendungscontainer, der Dateien über HTTP bereitstellt.

(2) Hilfscontainer (Trailer), der parallel arbeitet und Daten vom Git-Server empfängt.

(3) Ein freigegebener Ordner zum Datenaustausch zwischen dem primären und dem sekundären Container.

Dieses Beispiel zeigt, wie ein Synchronisationscontainer mit Git Inhalte hinzufügt, die von einem HTTP-Server bereitgestellt werden sollen, und diese auf dem neuesten Stand hält. Sie können auch sagen, dass beide Container eng zusammenarbeiten und gleich wichtig sind, aber das Sidecar-Muster (Trailer) setzt das Vorhandensein eines Hauptcontainers (Hauptcontainers) und eines Zusatzcontainers voraus, die das kollektive Verhalten erweitern. Normalerweise wird der Hauptcontainer zuerst in der Liste der Container aufgeführt und stellt den Standardcontainer dar (der beispielsweise durch den Befehl kubectl exec gestartet wird).

Dieses einfache Muster, dargestellt in Abb. 15.1 gewährleistet eine enge Zusammenarbeit der Container zur Laufzeit und ermöglicht Ihnen gleichzeitig die Trennung von Aufgaben, die möglicherweise verschiedenen Entwicklerteams gehören, unter Verwendung verschiedener Programmiersprachen, mit unterschiedlichen Veröffentlichungszyklen neuer Versionen usw. Es fördert auch die Austauschbarkeit und Wiederverwendung von Containern - in dem Sinne, dass der HTTP-Server und der Git-Synchronisationsmechanismus in anderen Anwendungen und mit anderen Einstellungen sowohl unabhängig als auch in Verbindung mit anderen Containern wiederverwendet werden können.

Bild

Erläuterung


Es wurde bereits oben gesagt, dass Containerbilder Klassen ähnlich sind und Container wie Objekte in der objektorientierten Programmierung (OOP) sind. In Fortsetzung dieser Analogie können wir die Erweiterung der Containerfähigkeiten mit der Vererbung in OOP und die gemeinsame Arbeit mehrerer Container im Kamin mit dem Empfang einer Komposition in OOP vergleichen. Beide Ansätze ermöglichen die Wiederverwendung von Code, aber die Vererbung definiert eine engere Beziehung und repräsentiert die Ist-Beziehung zwischen Containern.

Die Zusammensetzung im Herd stellt die Beziehung „hat“ dar - sie ist flexibler, da während der Montage keine Kombination von Behältern erforderlich ist, sodass die Behälter später in der Herddefinition geändert werden können. Die Zusammensetzung impliziert jedoch auch das Vorhandensein mehrerer gleichzeitig arbeitender Container (Prozesse), die auf ihre Funktionsfähigkeit überprüft und neu gestartet werden müssen und die Ressourcen verbrauchen, sowie des Hauptanwendungscontainers. Das Sidecar-Muster (Trailer) beinhaltet die Erstellung kleiner Hilfscontainer, die nur minimale Ressourcen verbrauchen. Sie entscheiden jedoch, ob Sie einen separaten Prozess starten oder alle Aufgaben besser in einem Hauptcontainer kombinieren möchten.

Unter einem anderen Gesichtspunkt ähnelt die Zusammensetzung von Containern der aspektorientierten Programmierung. Wenn zusätzliche Container verwendet werden, werden dem Untercontainer orthogonale (unabhängige) Funktionen hinzugefügt, die sich nicht auf den Hauptcontainer beziehen. In den letzten Monaten hat das Sidecar-Muster an Popularität gewonnen, insbesondere für Netzwerkmanagement- und Dienstüberwachungsaufgaben, bei denen jeder Dienst auch in Form von Hilfscontainern angeboten wird.

»Weitere Informationen zum Buch finden Sie auf der Website des Herausgebers.
» Inhalt
» Auszug

für Khabrozhiteley 25% Rabatt auf den Gutschein - Kubernetes

Nach Zahlung der Papierversion des Buches wird ein elektronisches Buch per E-Mail verschickt.

All Articles