Guía de sintaxis de diagramas de despliegue de PlantUML

¿Qué es un diagrama de despliegue?

Un diagrama de despliegue es un diagrama estructural diagrama UML que modela la arquitectura de ejecución física de un sistema de software. Como una norma fundamental de la especificación del Lenguaje Unificado de Modelado (UML), este tipo específico detipo de diagrama UML muestra cómo se despliegan físicamente los componentes de software sobre objetivos de alojamiento de hardware, elementos de infraestructura en la nube o entornos de contenedores. Proporciona a los ingenieros de sistemas, profesionales de DevOps y arquitectos de redes un diseño claro de los límites de los clústeres de servidores, los caminos de replicación de bases de datos, las capas de equilibradores de carga y los protocolos de red de hardware en regiones de desarrollo y producción.

Con VPasCode, no necesitas luchar con formas complejas de agrupación de vectores ni mapeo de coordenadas manual. Al usar bloques de script declarativos simples, nuestro motor agrupa, calcula y anida estructuras de nodos de hardware de forma limpia.

Guía de sintaxis principal: elementos y construcciones

Para diseñar un diagrama de despliegue UML preciso y conforme a las normas en PlantUML, debes dominar los nodos de hardware, los entornos de ejecución, los artefactos de despliegue y las conexiones de red.

1. Declaración de cubos de infraestructura (nodos)

En un diseño de despliegue, los recursos informáticos físicos se representan como cubos tridimensionales. Declaras estos elementos utilizando la palabra clavenodepalabra clave, o mediante la selección de variantes especializadas que brindan a los lectores un contexto visual inmediato sobre la capa de hardware:

node "Servidor de aplicación de metal desnudo" como CoreServer
node Server1
database "Servidor de base de datos" como DB_Node

2. Modelado de capas en la nube y entornos virtuales

Las aplicaciones modernas rara vez se despliegan directamente sobre hardware físico. PlantUML proporciona envoltorios de agrupación anidados para representar límites lógicos de ejecución, huellas de proveedores en la nube o entornos virtuales de contenedores como Docker y Kubernetes:

  • cloud — Representa niveles web públicos externos o límites de red en la nube (por ejemplo, AWS, Azure).
  • frame — Representa sistemas virtuales o regiones organizacionales.
  • storage — Representa configuraciones físicas de SAN o ubicaciones de almacén de objetos.
nube "Amazon Web Services VPC" {
    nodo "Instancia EC2 Linux" como NodoTrabajador
}

3. Definición de artefactos de despliegue (¿Qué se ejecuta dónde?)

Un artefacto representa el archivo físico real (como un archivo JAR compilado, una carpeta de compilación estática o un paquete comprimido) que se despliega en un nodo. Declaras un artefacto utilizando la artefactopalabra clave, o colócalo directamente dentro de tus bloques de hardware:

nodo "Servidor de aplicaciones" {
    artefacto "api_v1.0.war" como ArchivoAPI
}

4. Mapeo de enlaces de comunicación de red

Las conexiones entre elementos de infraestructura representan redes físicas concretas, rutas de cableado o canales inalámbricos. Mapeas estos enlaces utilizando dobles guiones sólidos (--), y añades texto entre comillas para definir explícitamente el protocolo de red utilizado (por ejemplo, HTTPS, TCP/IP, SSH):

nodo Servidor1
nodo NodoBaseDatos
Servidor1 -- NodoBaseDatos : "TCP/IP (Puerto 5432)"

Mejores prácticas para mapas de despliegue prácticos

  • Anida las estructuras correctamente: Siempre dibuja tus componentes internos o artefactos *dentro* de las llaves de tu nododeclaraciones para mostrar claramente la residencia de ejecución.
  • Etiqueta los protocolos de comunicación: Nunca dibujes una línea en blanco entre servidores. Etiqueta siempre la conexión con su protocolo de comunicación principal (por ejemplo, "HTTPS (Puerto 443)") para ayudar a las revisiones de red y seguridad.
  • Aisla las zonas de disponibilidad: Al documentar configuraciones de nube de alta disponibilidad, use envolventes separadas marco envolventes para ilustrar configuraciones de regiones divididas (por ejemplo, us-east-1a vs. us-east-1b).

Ejemplos de diagramas de despliegue de PlantUML en el mundo real

Ejemplo 1: Configuración clásica de tres niveles para web (nodos y protocolos)

Esta plantilla modela una estructura estándar moderna de aplicaciones corporativas, representando una red de distribución de contenido externa, un clúster de servidores de aplicaciones y una capa de hosts de base de datos interna segura.

@startuml
nube "Internet público" como red

nodo "Borde del CDN de Cloudflare" como cdn

marco "Zona desmilitarizada (DMZ)" {
    nodo "Servidor de equilibrador de carga Nginx" como proxy
}

marco "Subred privada de VPC de aplicación" {
    nodo "Servidor Ubuntu 22.04" como app_nodo {
        artefacto "core_api.jar" como aplicación
    }
}

base de datos "Capa de base de datos gestionada" {
    nodo "Clúster principal de PostgreSQL" como db_master
}

' Establecer cables de conexión topológica
red -- cdn : "HTTPS"
cdn -- proxy : "HTTPS (TLS 1.3)"
proxy -- app_nodo : "HTTP (Puerto 8080)"
app_nodo -- db_master : "TCP/IP (Puerto 5432)"
@enduml

Desglose de sintaxis: Este mapa define claramente los perímetros de seguridad. El activo compilado core_api.jar está anidado de forma segura dentro del app_nodo caja del servidor. Las rutas de red escalan limpiamente hacia adentro, estableciendo reglas estrictas de protocolo para cada segmento desde el borde web público hasta la capa de base de datos gestionada.

Ejemplo 2: Arquitectura de contenedores nativos en la nube (Kubernetes y AWS Mesh)

Este plano avanzado de empresa representa una implementación en la nube altamente escalable y multi-región. Utiliza diseños de nodos anidados para visualizar un sistema de contenedores de Kubernetes con equilibrio de carga que interactúa con bases de datos en la nube independientes.

@startuml
nube "Amazon Web Services (AWS)" {
    
    nodo "Equilibrador de carga de aplicaciones de AWS" como alb
    
    marco "Zona de disponibilidad: us-east-1a" {
        nodo "Nodo de trabajo EC2 Nodo A" como ec2_a {
            nodo "Pod de K8s: Frontend web" como pod_web_a
            nodo "Pod de K8s: API de pedidos" como pod_api_a
        }
    }
    
    marco "Zona de disponibilidad: us-east-1b" {
        nodo "Nodo de trabajo EC2 Nodo B" como ec2_b {
            nodo "Pod de K8s: Frontend web" como pod_web_b
            nodo "Pod de K8s: API de pedidos" como pod_api_b
        }
    }
    
    almacenamiento "Clústeres sin servidor de AWS Aurora" {
        base de datos "Base de datos de clientes" como rds_db
    }
}

' Rutas de líneas de orquestación de infraestructura
alb -- pod_web_a : "HTTP Round-Robin"
alb -- pod_web_b : "HTTP Round-Robin"

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

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

Desglose de sintaxis: Al anidar nodo objetivos dentro de nodoestructuras, esta plantilla modela perfectamente una disposición contenerizada (Pods que se ejecutan dentro de máquinas virtuales EC2). El balanceador de carga de aplicaciones distribuye sin problemas las solicitudes entrantes entre las zonas de disponibilidad, mientras que los componentes del clúster redirigen las llamadas a la base de datos de vuelta a un pool de almacenamiento compartido.

Scroll al inicio