Przewodnik po składni diagramu wdrożenia PlantUML

Co to jest diagram wdrożenia?

A Diagram wdrożenia to strukturalny diagram UML który modeluje architekturę wykonania fizycznego systemu oprogramowania. Jako podstawowy standard specyfikacji języka Unified Modeling Language (UML), ten konkretny typ diagramu UML pokazuje, jak składniki oprogramowania są fizycznie wdrażane na celach hostujących sprzętowych, elementach infrastruktury chmury lub środowiskach kontenerów. Zapewnia inżynierów systemów, specjalistów DevOps oraz architektów sieci wyraźny układ granic klastrów serwerów, ścieżek replikacji baz danych, poziomów balansowania obciążenia oraz protokołów sieciowych sprzętu w regionach rozwojowych i produkcyjnych.

Z VPasCode, nie musisz się męczyć z złożonymi kształtami grupowania wektorowego ani ręcznym mapowaniem współrzędnych. Korzystając z prostych bloków skryptów deklaratywnych, nasz silnik automatycznie grupuje, oblicza i zagnieżdża struktury węzłów sprzętowych w sposób czysty.

Podstawowy przewodnik składniowy: elementy i konstrukcje

Aby stworzyć dokładny, zgodny ze standardami diagram wdrożenia UML w PlantUML, musisz opanować węzły sprzętowe, środowiska wykonawcze, artefakty wdrażania oraz połączenia sieciowe.

1. Deklarowanie sześcianów infrastruktury (węzłów)

W układzie wdrażania zasoby obliczeniowe fizyczne są przedstawiane jako sześciany trójwymiarowe. Deklarujesz te elementy za pomocą słowa kluczowego nodesłowo kluczowe, albo wybierając specjalistyczne warianty, które dają czytelnikom natychmiastowy wizualny kontekst dotyczący poziomu sprzętu:

node "Serwer aplikacji typu Bare Metal" jako CoreServer
node Server1
database "Serwer bazy danych" jako DB_Node

2. Modelowanie warstw chmury i środowisk wirtualnych

Nowoczesne aplikacje rzadko są wdrażane bezpośrednio na sprzęcie fizycznym. PlantUML zapewnia zagnieżdżone kontenery grupujące do przedstawienia granic logicznych wykonania, stref dostawców chmury lub wirtualnych środowisk kontenerów takich jak Docker i Kubernetes:

• cloud — Reprezentuje zewnętrzne publiczne poziomy internetowe lub granice sieci chmury (np. AWS, Azure).
• frame — Reprezentuje systemy wirtualne lub obszary organizacyjne.
• storage — Reprezentuje fizyczne konfiguracje SAN lub lokalizacje magazynów obiektów.

chmura "Amazon Web Services VPC" {
    węzeł "EC2 Linux Instance" jako WorkerNode
}

3. Definiowanie artefaktów wdrożenia (co działa gdzie)

Artefakt reprezentuje rzeczywisty plik fizyczny (taki jak skompilowany plik JAR, statyczny folder kompilacji lub spakowany pakiet), który jest wdrażany na węźle. Deklarujesz artefakt za pomocą słowa kluczowegoartefaktlub umieszczasz go bezpośrednio w blokach sprzętu:

węzeł "Serwer aplikacji" {
    artefakt "api_v1.0.war" jako API_File
}

4. Mapowanie połączeń komunikacyjnych sieciowych

Połączenia między elementami infrastruktury reprezentują konkretne sieci fizyczne, ścieżki przewodów lub kanały bezprzewodowe. Mapujesz te połączenia za pomocą pełnych podwójnych myślników (--), a dołączasz tekst w cudzysłowach, aby jasno określić używany protokół sieciowy (np. HTTPS, TCP/IP, SSH):

węzeł Server1
węzeł DB_Node
Server1 -- DB_Node : "TCP/IP (Port 5432)"

Najlepsze praktyki dla praktycznych map wdrożeń

• Poprawnie zagnieżdżaj struktury: Zawsze rysuj swoje komponenty wewnętrzne lub artefakty *wewnątrz* klamr twoich deklaracjiwęzeł aby jasno pokazać lokalizację wykonania.
• Oznacz protokoły komunikacji: Nigdy nie rysuj pustej linii między serwerami. Zawsze oznacz połączenie jego głównym protokołem komunikacji (np. "HTTPS (Port 443)") aby wspomóc przeglądy sieciowe i bezpieczeństwa.
• Wyodrębnij strefy dostępności: Podczas dokumentowania konfiguracji chmury o wysokiej dostępności używaj osobnych ramki otoczeń, aby przedstawić konfiguracje podzielonych regionów (np. us-east-1a vs. us-east-1b).

Przykłady diagramów wdrożenia PlantUML z rzeczywistego świata

Przykład 1: Klasyczna trójwarstwowa konfiguracja sieci web (węzły i protokoły)

Ten szablon modeluje standardową współczesną strukturę aplikacji korporacyjnej, przedstawiając zewnętrzny system dystrybucji treści, klaster serwerów aplikacji oraz zabezpieczoną wewnętrzna warstwę hostów bazy danych.

@startuml
chmura "Publiczny Internet" jako net

węzeł "Krawędź CDN Cloudflare" jako cdn

ramka "Zona demilitaryzowana (DMZ)" {
    węzeł "Serwer balansujący obciążenie Nginx" jako proxy
}

ramka "Prywatna podsieć VPC aplikacji" {
    węzeł "Serwer Ubuntu 22.04" jako app_node {
        artefakt "core_api.jar" jako application
    }
}

baza danych "Warstwa zarządzanej bazy danych" {
    węzeł "Główna grupa PostgreSQL" jako db_master
}

' Ustanów połączenia topologiczne
net -- cdn : "HTTPS"
cdn -- proxy : "HTTPS (TLS 1.3)"
proxy -- app_node : "HTTP (Port 8080)"
app_node -- db_master : "TCP/IP (Port 5432)"
@enduml

Analiza składni: Ten schemat jasno określa strefy zabezpieczeń. Skompilowany zasób core_api.jar znajduje się bezpiecznie wewnątrz app_node pudełka serwera. Ścieżki sieciowe skaliują się czysto wewnątrz, ustanawiając rygorystyczne zasady protokołu dla każdego odcinka od krawędzi publicznej sieci web aż do zarządzanej warstwy bazy danych.

Przykład 2: Architektura kontenerów oparta na chmurze (Kubernetes i AWS Mesh)

Ten zaawansowany szablon przedsiębiorstwa modeluje wysoko skalowalne wdrożenie chmury wieloregionowej. Wykorzystuje zagnieżdżone układy węzłów do wizualizacji systemu kontenerów Kubernetes z balansowaniem obciążenia, który współdziała z samodzielnie działającymi bazami danych w chmurze.

@startuml
chmura "Amazon Web Services (AWS)" {
    
    węzeł "Balansujący obciążenie aplikacji AWS" jako alb
    
    ramka "Strefa dostępności: us-east-1a" {
        węzeł "Węzeł roboczy EC2 Node A" jako ec2_a {
            węzeł "Pojemnik K8s: Frontend strony internetowej" jako pod_web_a
            węzeł "Pojemnik K8s: Interfejs API zamówienia" jako pod_api_a
        }
    }
    
    ramka "Strefa dostępności: us-east-1b" {
        węzeł "Węzeł roboczy EC2 Node B" jako ec2_b {
            węzeł "Pojemnik K8s: Frontend strony internetowej" jako pod_web_b
            węzeł "Pojemnik K8s: Interfejs API zamówienia" jako pod_api_b
        }
    }
    
    pamięć "Klastery serwerów AWS Aurora bezserwerowych" {
        baza danych "Baza klientów" jako rds_db
    }
}

' Linie orchestrowania infrastruktury
alb -- pod_web_a : "HTTP Round-Robin"
alb -- pod_web_b : "HTTP Round-Robin"

pod_web_a -- pod_api_a : "Wewnętrzny gRPC"
pod_web_b -- pod_api_b : "Wewnętrzny gRPC"

pod_api_a -- rds_db : "SSL/TCP"
pod_api_b -- rds_db : "SSL/TCP"
@enduml

Analiza składni: Poprzez zagnieżdżanie węzła celów wewnątrz dziecięcych węzełstruktury, ten szablon idealnie oddaje układ z kontenerami (pods działające wewnątrz maszyn wirtualnych EC2). Równoważenie obciążenia aplikacji bezproblemowo dystrybuuje przychodzące żądania między strefami dostępności, podczas gdy składniki klastra przekierowują wywołania do bazy danych z powrotem do wspólnej puli przechowywania.