Guide de syntaxe des diagrammes de déploiement PlantUML

Qu’est-ce qu’un diagramme de déploiement ?

Un diagramme de déploiement est un diagramme structurel diagramme UML qui modélise l’architecture d’exécution physique d’un système logiciel. En tant que norme fondamentale de la spécification du langage de modélisation unifié (UML), ce type spécifique type de diagramme UML décrit comment les composants logiciels sont physiquement déployés sur des cibles matérielles d’hébergement, des éléments d’infrastructure cloud ou des environnements d’exécution de conteneurs. Il fournit aux ingénieurs système, aux professionnels DevOps et aux architectes réseaux une vue claire des limites des clusters serveurs, des chemins de réplication de base de données, des niveaux de répartiteur de charge et des protocoles réseau matériels à travers les régions de développement et de production.

Avec VPasCode, vous n’avez pas besoin de vous battre contre des formes vectorielles complexes ou des mappages de coordonnées manuels. En utilisant des blocs de script déclaratifs simples, notre moteur groupe automatiquement, calcule et imbrique vos structures de nœuds matériels de manière propre.

Guide de syntaxe fondamentale : éléments et constructions

Pour concevoir un diagramme de déploiement UML précis et conforme aux normes dans PlantUML, vous devez maîtriser les nœuds matériels, les environnements d’exécution, les artefacts de déploiement et les liaisons réseau.

1. Déclarer des cubes d’infrastructure (nœuds)

Dans une disposition de déploiement, les ressources informatiques physiques sont représentées sous forme de cubes tridimensionnels 3D. Vous déclarez ces éléments en utilisant le mot-clé nodemot-clé, ou en choisissant des variantes spécialisées qui donnent aux lecteurs un contexte visuel immédiat sur le niveau matériel :

node "Serveur d'application Bare Metal" comme CoreServer
node Server1
database "Serveur de base de données" comme DB_Node

2. Modélisation des couches cloud et des environnements virtuels

Les applications modernes sont rarement déployées directement sur du matériel physique. PlantUML fournit des enveloppes imbriquées pour représenter des limites d’exécution logiques, des empreintes de fournisseurs cloud ou des environnements d’exécution virtuels tels que Docker et Kubernetes :

• cloud — Représente des niveaux web publics externes ou des limites de réseau cloud (par exemple, AWS, Azure).
• frame — Représente des systèmes virtuels ou des régions organisationnelles.
• storage — Représente des configurations physiques de SAN ou des emplacements de stockage d’objets.

cloud "Amazon Web Services VPC" {
    node "Instance EC2 Linux" as WorkerNode
}

3. Définition des artefacts de déploiement (ce qui s’exécute où)

Un artefact représente le fichier physique réel (tel qu’un fichier JAR compilé, un dossier de build statique ou un package compressé) qui est déployé sur un nœud. Vous déclarez un artefact à l’aide du mot-clé artifactmot-clé, ou en le plaçant directement à l’intérieur de vos blocs matériels :

node "Serveur d'application" {
    artifact "api_v1.0.war" as API_File
}

4. Mappage des liens de communication réseau

Les connexions entre les éléments d’infrastructure représentent des réseaux physiques concrets, des chemins de câblage ou des canaux sans fil. Vous mappez ces liens à l’aide de tirets doubles pleins (--), et ajoutez du texte entre guillemets pour définir explicitement le protocole réseau utilisé (par exemple, HTTPS, TCP/IP, SSH) :

node Server1
node DB_Node
Server1 -- DB_Node : "TCP/IP (Port 5432)"

Meilleures pratiques pour les cartes de déploiement pratiques

• Intégrez correctement les structures : Dessinez toujours vos composants internes ou artefacts *à l’intérieur* des accolades de vos déclarations de node pour montrer clairement le lieu d’exécution.
• Étiquetez les protocoles de communication : Ne dessinez jamais de ligne vide entre les serveurs. Étiquetez toujours la connexion avec son protocole de communication principal (par exemple, "HTTPS (Port 443)") afin d’aider les revues réseau et de sécurité.
• Isolez les zones de disponibilité : Lors de la documentation de configurations cloud à haute disponibilité, utilisez des enveloppes séparées cadre enveloppes pour illustrer les configurations de région divisée (par exemple, us-east-1a vs. us-east-1b).

Exemples de diagrammes de déploiement PlantUML du monde réel

Exemple 1 : Architecture classique en trois niveaux pour un site web (nœuds et protocoles)

Ce modèle représente une structure d’application corporative moderne standard, en cartographiant un réseau de distribution de contenu externe, un cluster de serveurs d’applications et un niveau d’hôtes de base de données sécurisé interne.

@startuml
cloud "Internet public" as net

node "Edge Cloudflare CDN" as cdn

frame "Zone démilitarisée (DMZ)" {
    node "Serveur équilibreur de charge Nginx" as proxy
}

frame "Sous-réseau privé VPC Application" {
    node "Serveur Ubuntu 22.04" as app_node {
        artifact "core_api.jar" as application
    }
}

database "Niveau de base de données gérée" {
    node "Cluster principal PostgreSQL" as db_master
}

' Établir les connexions topologiques
net -- cdn : "HTTPS"
cdn -- proxy : "HTTPS (TLS 1.3)"
proxy -- app_node : "HTTP (Port 8080)"
app_node -- db_master : "TCP/IP (Port 5432)"
@enduml

Analyse de la syntaxe : Cette carte définit clairement les périmètres de sécurité. L’actif compilé core_api.jar est placé en toute sécurité à l’intérieur du app_node boîte serveur. Les chemins réseau s’échelonnent proprement vers l’intérieur, établissant des règles strictes de protocole pour chaque segment, depuis le bord public du web jusqu’au niveau de base de données gérée.

Exemple 2 : Architecture de conteneurs native cloud (Kubernetes et AWS Mesh)

Ce plan d’entreprise avancé représente un déploiement cloud multi-régions hautement évolutif. Il utilise des dispositions de nœuds imbriqués pour visualiser un système de conteneurs Kubernetes équilibré en charge, interagissant avec des bases de données cloud autonomes.

@startuml
cloud "Amazon Web Services (AWS)" {
    
    node "Équilibreur de charge d'application AWS" as alb
    
    frame "Zone de disponibilité : us-east-1a" {
        node "Nœud de travail EC2 Node A" as ec2_a {
            node "Pod K8s : Frontend web" as pod_web_a
            node "Pod K8s : API Commande" as pod_api_a
        }
    }
    
    frame "Zone de disponibilité : us-east-1b" {
        node "Nœud de travail EC2 Node B" as ec2_b {
            node "Pod K8s : Frontend web" as pod_web_b
            node "Pod K8s : API Commande" as pod_api_b
        }
    }
    
    storage "Clusters sans serveur AWS Aurora" {
        database "Base de données Clients" as rds_db
    }
}

' Lignes d'orchestration de l'infrastructure
alb -- pod_web_a : "HTTP Round-Robin"
alb -- pod_web_b : "HTTP Round-Robin"

pod_web_a -- pod_api_a : "gRPC interne"
pod_web_b -- pod_api_b : "gRPC interne"

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

Analyse de la syntaxe : En imbriquant nœud cibles à l’intérieur de nœudstructures, ce modèle représente parfaitement une disposition conteneurisée (des Pods s’exécutant à l’intérieur de machines virtuelles EC2). L’équilibreur de charge d’application répartit sans heurt les requêtes entrantes entre les zones de disponibilité, tandis que les composants du cluster redirigent les appels à la base de données vers un pool de stockage partagé.