Was ist ein Bereitstellungsdiagramm?
Ein Bereitstellungsdiagramm ist ein struktureller UML-Diagramm das die physische Ausführungsarchitektur eines Softwaresystems modelliert. Als Kernstandard der Unified Modeling Language (UML)-Spezifikation stellt diese spezifische UML-Diagrammtyp zeigt auf, wie Softwarekomponenten physisch auf Hardware-Hosting-Ziele, Cloud-Infrastrukturkomponenten oder Containerruntimes bereitgestellt werden. Es bietet Systemingenieuren, DevOps-Profis und Netzwerkarchitekten eine klare Darstellung der Server-Cluster-Grenzen, Datenbank-Replikationspfade, Lastverteilungsebenen und Hardware-Netzwerkprotokolle über Entwicklung- und Produktionsregionen hinweg.
Mit VPasCode, müssen Sie sich nicht mit komplexen Vektorgruppierungsformen oder manueller Koordinatennachverfolgung abmühen. Durch die Verwendung einfacher deklarativer Skriptblöcke gruppiert, berechnet und verschachtelt unsere Engine Ihre Hardware-Knotenstrukturen sauber automatisch.
Kern-Syntaxleitfaden: Elemente und Konstrukte
Um ein genaues, standardskonformes UML-Bereitstellungsdiagramm in PlantUML zu erstellen, müssen Sie Hardware-Knoten, Ausführungs-Umgebungen, Bereitstellungs-Artefakte und Netzwerkverbindungen beherrschen.
1. Deklaration von Infrastrukturwürfeln (Knoten)
In einer Bereitstellungsanordnung werden physische Rechenressourcen als 3D-dreidimensionale Würfel dargestellt. Sie deklarieren diese Elemente mit dem Schlüsselwort node oder durch Auswahl spezialisierter Varianten, die den Lesern sofort visuellen Kontext über die Hardware-Ebene geben:
node "Bare Metal Anwendungsserver" als CoreServer
node Server1
database "Datenbankserver" als DB_Node
2. Modellierung von Cloud-Ebenen und virtuellen Umgebungen
Moderne Anwendungen werden selten direkt auf physischer Hardware bereitgestellt. PlantUML bietet verschachtelte Gruppierungscontainer, um logische Ausführungs-Grenzen, Cloud-Anbieter-Abdeckungen oder virtuelle Containerruntimes wie Docker und Kubernetes darzustellen:
cloud— Stellt externe öffentliche Web-Ebenen oder Cloud-Netzwerk-Grenzen dar (z. B. AWS, Azure).frame— Stellt virtuelle Systeme oder organisatorische Regionen dar.storage— Stellt physische SAN-Konfigurationen oder Objektspeicher-Orte dar.
cloud "Amazon Web Services VPC" {
node "EC2 Linux-Instanz" als WorkerNode
}
3. Definition von Bereitstellungskomponenten (Was läuft wo)
Eine Komponente stellt die tatsächliche physische Datei (z. B. eine kompilierte JAR-Datei, ein statischer Build-Ordner oder ein komprimiertes Paket) dar, die auf einem Knoten bereitgestellt wird. Sie deklarieren eine Komponente mit dem artifactSchlüsselwort oder platzieren Sie sie direkt innerhalb Ihrer Hardwareblöcke:
node "Anwendungsserver" {
artifact "api_v1.0.war" als API_Datei
}
4. Abbildung von Netzwerk-Kommunikationsverbindungen
Verbindungen zwischen Infrastrukturelementen stellen konkrete physische Netzwerke, Kabelwege oder Funkkanäle dar. Sie mappen diese Verbindungen mit festen Doppelpunkten (--), und fügen Text in Anführungszeichen hinzu, um den verwendeten Netzwerkprotokoll explizit zu definieren (z. B. HTTPS, TCP/IP, SSH):
node Server1
node DB_Node
Server1 -- DB_Node : "TCP/IP (Port 5432)"
Best Practices für praktische Bereitstellungskarten
- Strukturen korrekt verschachteln: Zeichnen Sie Ihre internen Komponenten oder Artefakte immer *innerhalb* der geschweiften Klammern Ihrer
nodeDeklarationen, um die Ausführungsresidenz eindeutig zu zeigen. - Kommunikationsprotokolle benennen: Zeichnen Sie niemals eine leere Zeile zwischen Servern. Kennzeichnen Sie die Verbindung immer mit ihrem primären Kommunikationsprotokoll (z. B.
"HTTPS (Port 443)") um Netzwerk- und Sicherheitsüberprüfungen zu unterstützen. - Verfügbarkeitszonen isolieren: Bei der Dokumentation von Hochverfügbarkeits-Cloud-Konfigurationen sollten separate
frameWrapper verwendet werden, um getrennte Regionen-Setup zu veranschaulichen (z. B.us-east-1avs.us-east-1b).
Beispiele für echte PlantUML-Bereitstellungsdiagramme
Beispiel 1: Klassische dreistufige Web-Setup (Knoten & Protokolle)
Dieses Mustermodell beschreibt eine standardmäßige moderne Unternehmensanwendungstruktur, die ein externes Content-Distributionsnetzwerk, einen Anwendungsserver-Cluster und eine gesicherte interne Datenbank-Host-Ebene abbildet.
@startuml
cloud "Öffentliches Internet" als net
node "Cloudflare CDN Edge" als cdn
frame "Demilitarisierte Zone (DMZ)" {
node "Nginx-Lastenausgleichsserver" als proxy
}
frame "Privates Anwendungs-VPC-Subnetz" {
node "Ubuntu-Server 22.04" als app_node {
artifact "core_api.jar" als application
}
}
database "Verwaltete Datenbank-Ebene" {
node "PostgreSQL-Primär-Cluster" als db_master
}
' Topologische Verbindungsleitungen herstellen
net -- cdn : "HTTPS"
cdn -- proxy : "HTTPS (TLS 1.3)"
proxy -- app_node : "HTTP (Port 8080)"
app_node -- db_master : "TCP/IP (Port 5432)"
@enduml
Syntax-Aufschlüsselung: Diese Karte definiert eindeutig Sicherheitsperimeter. Das kompilierte Asset core_api.jar befindet sich sicher innerhalb des app_node Serverkasten. Die Netzwerkpfade skaliert sauber nach innen und legt strenge Protokollregeln für jedes Segment vom öffentlichen Web-Rand bis zur verwalteten Datenbank-Ebene fest.
Beispiel 2: Cloud-nativ architektur für Container (Kubernetes & AWS Mesh)
Dieser fortgeschrittene Unternehmens-Blueprint beschreibt eine hochskalierbare, mehrregionale Cloud-Bereitstellung. Er nutzt verschachtelte Knotenanordnungen, um ein lastverteiltes Kubernetes-Container-System darzustellen, das mit eigenständigen Cloud-Datenbanken interagiert.
@startuml
cloud "Amazon Web Services (AWS)" {
node "AWS-Anwendungs-Lastenausgleicher" als alb
frame "Verfügbarkeitszone: us-east-1a" {
node "EC2-Arbeitsserver-Knoten A" als ec2_a {
node "K8s-Pod: Web-Frontend" als pod_web_a
node "K8s-Pod: Bestell-API" als pod_api_a
}
}
frame "Verfügbarkeitszone: us-east-1b" {
node "EC2-Arbeitsserver-Knoten B" als ec2_b {
node "K8s-Pod: Web-Frontend" als pod_web_b
node "K8s-Pod: Bestell-API" als pod_api_b
}
}
storage "AWS-Aurora-Serverless-Cluster" {
database "Kunden-Datenbank" als rds_db
}
}
' Infrastruktur-Orchestrierungsleitungen verlegen
alb -- pod_web_a : "HTTP Round-Robin"
alb -- pod_web_b : "HTTP Round-Robin"
pod_web_a -- pod_api_a : "Internes gRPC"
pod_web_b -- pod_api_b : "Internes gRPC"
pod_api_a -- rds_db : "SSL/TCP"
pod_api_b -- rds_db : "SSL/TCP"
@enduml
Syntax-Aufschlüsselung: Durch die Verschachtelung von node Zielobjekten innerhalb von Kind-KnotenStrukturen, modelliert dieser Template eine containerisierte Anordnung perfekt (Pods, die innerhalb von EC2-Virtual Machines ausgeführt werden). Der Anwendungs-Loadbalancer verteilt eingehende Anfragen nahtlos über Verfügbarkeitszonen hinweg, während die Clusterkomponenten Datenbankaufrufe zurück in einen gemeinsam genutzten Speicherpool weiterleiten.