Freigeben über


Einsatz von Containern für monolithische Anwendungen

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook .NET Microservices Architecture for Containerized .NET Applications, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

.NET Microservices-Architektur für containerisierte .NET-Anwendungen eBook-Cover-Thumbnail.

Möglicherweise möchten Sie eine einzelne, monolithisch bereitgestellte Webanwendung oder einen einzelnen Dienst erstellen und als Container bereitstellen. Die Anwendung selbst ist möglicherweise nicht intern monolithisch, sondern als mehrere Bibliotheken, Komponenten oder sogar Ebenen strukturiert (Anwendungsschicht, Domänenschicht, Datenzugriffsschicht usw.). Extern ist es jedoch ein einzelner Container – ein einzelner Prozess, eine einzelne Webanwendung oder ein einzelner Dienst.

Zum Verwalten dieses Modells stellen Sie einen einzelnen Container bereit, der die Anwendung darstellt. Um die Kapazität zu erhöhen, skalieren Sie horizontal, indem Sie einfach weitere Kopien mit einem Lastverteiler davor hinzufügen. Die Einfachheit kommt aus der Verwaltung einer einzelnen Bereitstellung in einem einzelnen Container oder virtuellen Computer.

Diagramm, das die Komponenten einer monolithischen containerisierten Anwendung zeigt.

Abbildung 4-1. Beispiel für die Architektur einer containerisierten monolithischen Anwendung

Sie können mehrere Komponenten, Bibliotheken oder interne Ebenen in jeden Container einschließen, wie in Abbildung 4-1 dargestellt. Eine monolithische containerisierte Anwendung verfügt über die meisten Funktionen innerhalb eines einzelnen Containers, mit internen Ebenen oder Bibliotheken und skaliert durch Klonen des Containers auf mehreren Servern/VMs. Dieses monolithische Muster kann jedoch mit dem Containerprinzip "ein Container erledigt eine Aufgabe in einem Prozess", jedoch könnte es in einigen Fällen akzeptabel sein.

Der Nachteil dieses Ansatzes wird deutlich, wenn die Anwendung wächst, und sie muss skaliert werden. Wenn die gesamte Anwendung skaliert werden kann, ist dies kein Problem. In den meisten Fällen sind jedoch nur wenige Teile der Anwendung die Drosselpunkte, die eine Skalierung erfordern, während andere Komponenten weniger verwendet werden.

Beispielsweise müssen Sie in einer typischen E-Commerce-Anwendung das Produktinformationssubsystem wahrscheinlich skalieren, da viele mehr Kunden Produkte durchsuchen als sie kaufen. Mehr Kunden verwenden ihren Korb als die Zahlungspipeline. Weniger Kunden fügen Kommentare hinzu und sehen ihren Kaufverlauf an. Und Möglicherweise haben Sie nur eine Handvoll Mitarbeiter, die die Inhalte und Marketingkampagnen verwalten müssen. Wenn Sie das monolithische Design skalieren, wird der gesamte Code für diese verschiedenen Aufgaben mehrmals eingesetzt und im gleichen Maßstab skaliert.

Es gibt mehrere Möglichkeiten, eine anwendungs horizontale Duplizierung zu skalieren, verschiedene Bereiche der Anwendung aufzuteilen und ähnliche Geschäftskonzepte oder Daten zu partitionieren. Zusätzlich zum Problem der Skalierung aller Komponenten erfordern Änderungen an einer einzelnen Komponente jedoch eine vollständige Erneutes Testen der gesamten Anwendung und eine vollständige erneute Bereitstellung aller Instanzen.

Der monolithische Ansatz ist jedoch üblich, da die Entwicklung der Anwendung zunächst einfacher ist als bei Mikroservices-Ansätzen. So entwickeln sich viele Organisationen mit diesem architektonischen Ansatz. Während einige Organisationen gut genug Ergebnisse erzielt haben, stoßen andere an ihre Grenzen. Viele Organisationen haben ihre Anwendungen mit diesem Modell entworfen, da Tools und Infrastruktur es vor Jahren zu schwierig gemacht haben, dienstorientierte Architekturen (SOA) zu erstellen, und sie sahen nicht die Notwendigkeit, bis die Anwendung gewachsen ist.

Aus Infrastrukturperspektive kann jeder Server viele Anwendungen innerhalb desselben Hosts ausführen und ein akzeptables Verhältnis der Effizienz bei der Ressourcennutzung aufweisen, wie in Abbildung 4-2 dargestellt.

Diagramm mit einem Host, auf dem viele Apps in Containern ausgeführt werden.

Abbildung 4-2. Monolithischer Ansatz: Betreiben mehrerer Apps, wobei jede App als Container ausgeführt wird

Monolithische Anwendungen in Microsoft Azure können mit dedizierten VMs für jede Instanz bereitgestellt werden. Darüber hinaus können Sie mithilfe von Skalierungssätzen für virtuelle Azure-Computer ganz einfach die virtuellen Computer skalieren. Azure App Service kann auch monolithische Anwendungen ausführen und Instanzen problemlos skalieren, ohne dass Sie die virtuellen Computer verwalten müssen. Seit 2016 können Azure App Services auch einzelne Instanzen von Docker-Containern ausführen und die Bereitstellung vereinfachen.

Als QA-Umgebung oder eine eingeschränkte Produktionsumgebung können Sie mehrere Docker-Host-VMs bereitstellen und mit dem Azure-Balancer ausgleichen, wie in Abbildung 4-3 dargestellt. Auf diese Weise können Sie die Skalierung mit einem grobkörnigen Ansatz verwalten, da sich die gesamte Anwendung in einem einzigen Container befindet.

Diagramm mit mehreren Hosts, die die monolithischen App-Container ausführen.

Abbildung 4-3. Beispiel für mehrere Hosts zum Skalieren einer einzelnen Containeranwendung

Die Bereitstellung auf den verschiedenen Hosts kann mit herkömmlichen Bereitstellungstechniken verwaltet werden. Docker-Hosts können mit Befehlen wie docker run oder docker-compose manuell oder über Automatisierung wie z. B. CD-Pipelines (Continuous Delivery) verwaltet werden.

Bereitstellen einer monolithischen Anwendung in einem Container

Es gibt Vorteile bei der Verwendung von Containern zum Verwalten von monolithischen Anwendungsbereitstellungen. Das Skalieren von Containerinstanzen ist wesentlich schneller und einfacher als die Bereitstellung zusätzlicher VMs. Selbst wenn Sie Skalierungssätze für virtuelle Computer verwenden, nehmen virtuelle Computer zeit zum Starten. Wenn sie als herkömmliche Anwendungsinstanzen anstelle von Containern bereitgestellt wird, wird die Konfiguration der Anwendung als Teil der VM verwaltet, was nicht ideal ist.

Das Bereitstellen von Updates als Docker-Images ist viel schneller und netzwerkeffizient. Docker-Images beginnen in der Regel in Sekunden, wodurch rollouts beschleunigt werden. Das Abreißen einer Docker-Imageinstanz ist so einfach wie das Ausstellen eines docker stop Befehls und wird in der Regel in weniger als einer Sekunde abgeschlossen.

Da Container designbedingt unveränderlich sind, müssen Sie sich nie gedanken über beschädigte VMs machen. Im Gegensatz dazu können Updateskripts für einen virtuellen Computer vergessen, bestimmte Konfigurationen oder Dateien auf dem Datenträger zu berücksichtigen.

Während monolithische Anwendungen von Docker profitieren können, berühren wir nur die Vorteile. Zusätzliche Vorteile der Verwaltung von Containern stammen aus der Bereitstellung mit Container-Orchestratoren, die die verschiedenen Instanzen und den Lebenszyklus jeder Containerinstanz verwalten. Das Aufteilen der monolithischen Anwendung in Subsysteme, die skaliert, entwickelt und einzeln bereitgestellt werden können, ist Ihr Einstiegspunkt in den Bereich der Microservices.

Veröffentlichen einer einzelcontainerbasierten Anwendung in Azure App Service

Unabhängig davon, ob Sie eine Überprüfung eines containers erhalten möchten, der in Azure bereitgestellt wird oder wenn eine Anwendung einfach eine Einzelcontaineranwendung ist, bietet Azure App Service eine hervorragende Möglichkeit, skalierbare einzelcontainerbasierte Dienste bereitzustellen. Die Verwendung von Azure App Service ist einfach. Es bietet eine großartige Integration in Git, um den Code einfach zu übernehmen, ihn in Visual Studio zu erstellen und direkt in Azure bereitzustellen.

Screenshot des Dialogfelds

Abbildung 4-4. Veröffentlichen einer Einzelcontaineranwendung in Azure App Service aus Visual Studio 2022

Ohne Docker mussten Sie, wenn Sie andere Funktionen, Frameworks oder Abhängigkeiten benötigen, die in Azure App Service nicht unterstützt werden, warten, bis das Azure-Team diese Abhängigkeiten in App Service aktualisiert hat. Oder Sie mussten zu anderen Diensten wie Azure Cloud Services oder VMs wechseln, wo Sie weitere Kontrolle hatten und sie eine erforderliche Komponente oder ein erforderliches Framework für Ihre Anwendung installieren konnten.

Containerunterstützung in Visual Studio 2017 und höher bietet Ihnen die Möglichkeit, alles, was Sie in Ihrer Anwendungsumgebung wünschen, einzuschließen, wie in Abbildung 4-4 dargestellt. Da Sie sie in einem Container ausführen, können Sie beim Hinzufügen einer Abhängigkeit zu Ihrer Anwendung die Abhängigkeit in Ihr Dockerfile- oder Docker-Image einschließen.

Wie auch in Abbildung 4-4 gezeigt, überträgt der Veröffentlichungsfluss ein Image durch eine Container-Registry. Dies kann das Azure Container Registry sein, eine Registrierung in der Nähe Ihrer Bereitstellungen in Azure, sicher durch Azure Active Directory-Gruppen und -Konten, oder eine andere Docker-Registrierung wie Docker Hub oder eine lokale Registrierung.