Руководство по синтаксису диаграмм развертывания PlantUML

Что такое диаграмма развертывания?

А Диаграмма развертывания — это структурная диаграмма UML которая моделирует физическую архитектуру выполнения программного обеспечения. Как основной стандарт спецификации унифицированного языка моделирования (UML), эта конкретная тип диаграммы UML отображает, как программные компоненты физически развертываются на целевых устройствах хостинга, элементах облачной инфраструктуры или средах выполнения контейнеров. Она предоставляет системным инженерам, специалистам DevOps и архитекторам сетей четкую схему границ кластеров серверов, путей репликации баз данных, уровней балансировщиков нагрузки и протоколов аппаратных сетей в разработке и производственных регионах.

С помощью VPasCode, вам не нужно бороться с сложными фигурами векторной группировки или ручным сопоставлением координат. Используя простые блоки декларативного скрипта, наш движок автоматически группирует, рассчитывает и вложенно размещает структуры ваших аппаратных узлов.

Руководство по основному синтаксису: элементы и конструкции

Чтобы создать точную, соответствующую стандартам диаграмму развертывания UML в PlantUML, необходимо освоить аппаратные узлы, среды выполнения, артефакты развертывания и сетевые связи.

1. Объявление кубов инфраструктуры (узлов)

На схеме развертывания физические вычислительные ресурсы представлены в виде трехмерных кубов. Эти элементы объявляются с помощью ключевого слова node или с помощью специализированных вариантов, которые сразу дают читателям визуальное представление о слое аппаратного обеспечения:

node "Сервер приложений на физическом железе" as CoreServer
node Server1
database "Сервер базы данных" as DB_Node

2. Моделирование слоев облачной среды и виртуальных сред

Современные приложения редко развертываются непосредственно на физическом оборудовании. PlantUML предоставляет вложенные оболочки для группировки, чтобы отобразить логические границы выполнения, области действия поставщиков облачных услуг или виртуальные среды выполнения контейнеров, такие как Docker и Kubernetes:

• cloud — Представляет внешние публичные веб-уровни или границы облачных сетей (например, AWS, Azure).
• frame — Представляет виртуальные системы или организационные регионы.
• storage — Представляет физические конфигурации SAN или местоположения объектных хранилищ.

облако "Amazon Web Services VPC" {
    узел "EC2 Linux Instance" как WorkerNode
}

3. Определение развертываемых артефактов (что запускается где)

Артефакт представляет собой фактический физический файл (например, скомпилированный JAR-файл, статическая папка сборки или архивный пакет), который развертывается на узле. Вы объявляете артефакт с помощью ключевого словаартефактключевого слова, или разместите его непосредственно внутри блоков аппаратного обеспечения:

узел "Сервер приложений" {
    артефакт "api_v1.0.war" как API_File
}

4. Сопоставление сетевых коммуникационных связей

Соединения между элементами инфраструктуры представляют собой конкретные физические сети, проводные пути или беспроводные каналы. Вы отображаете эти связи с помощью сплошных двойных тире (--), и добавьте текст в кавычках, чтобы явно определить используемый сетевой протокол (например, HTTPS, TCP/IP, SSH):

узел Server1
узел DB_Node
Server1 -- DB_Node : "TCP/IP (Порт 5432)"

Рекомендации по практическим картам развертывания

• Правильно вкладывайте структуры: Всегда рисуйте внутренние компоненты или артефакты *внутри* фигурных скобок ваших объявленийузел чтобы чётко показать местоположение выполнения.
• Маркируйте протоколы связи: Никогда не оставляйте пустую строку между серверами. Всегда помечайте соединение основным протоколом связи (например, "HTTPS (Порт 443)"), чтобы облегчить проверку сети и безопасности.
• Выделяйте зоны доступности: При документировании конфигураций облачных систем с высокой доступностью используйте отдельные рамки обертки для иллюстрации настроек разделённых регионов (например, us-east-1a против us-east-1b).

Примеры диаграмм развертывания PlantUML из реального мира

Пример 1: Классическая трехуровневая веб-конфигурация (узлы и протоколы)

Этот шаблон моделирует стандартную современную структуру корпоративного приложения, отображая внешнюю сеть распространения контента, кластер серверов приложений и защищенный внутренний уровень хостов базы данных.

@startuml
cloud "Публичная интернет-сеть" as net

node "Крайний сервер Cloudflare CDN" as cdn

frame "Зона демилитаризации (DMZ)" {
    node "Сервер балансировки нагрузки Nginx" as proxy
}

frame "Частная подсеть VPC приложения" {
    node "Сервер Ubuntu 22.04" as app_node {
        artifact "core_api.jar" as application
    }
}

database "Управляемый уровень базы данных" {
    node "Основной кластер PostgreSQL" as db_master
}

' Установить топологические соединительные линии
net -- cdn : "HTTPS"
cdn -- proxy : "HTTPS (TLS 1.3)"
proxy -- app_node : "HTTP (порт 8080)"
app_node -- db_master : "TCP/IP (порт 5432)"
@enduml

Разбор синтаксиса: На этой схеме чётко определены границы безопасности. Скомпилированный объект core_api.jar находится в безопасной оболочке внутри app_node серверной коробки. Сетевые пути чисто масштабируются внутрь, устанавливая строгие правила протокола для каждого сегмента от внешнего края публичного веб-интерфейса до управляемого уровня базы данных.

Пример 2: Архитектура контейнеров, ориентированная на облако (Kubernetes и AWS Mesh)

Этот продвинутый корпоративный чертёж отображает масштабируемую многооблачную развертывание. Он использует вложенные макеты узлов для визуализации системы контейнеров Kubernetes с балансировкой нагрузки, взаимодействующей с автономными облачными базами данных.

@startuml
cloud "Amazon Web Services (AWS)" {
    
    node "Балансировщик нагрузки приложений AWS" as alb
    
    frame "Зона доступности: us-east-1a" {
        node "Рабочий узел EC2 Node A" as ec2_a {
            node "Под K8s: Веб-интерфейс" as pod_web_a
            node "Под K8s: API заказов" as pod_api_a
        }
    }
    
    frame "Зона доступности: us-east-1b" {
        node "Рабочий узел EC2 Node B" as ec2_b {
            node "Под K8s: Веб-интерфейс" as pod_web_b
            node "Под K8s: API заказов" as pod_api_b
        }
    }
    
    storage "Кластеры AWS Aurora Serverless" {
        database "База данных клиентов" as rds_db
    }
}

' Линии маршрутизации инфраструктурной оркестрации
alb -- pod_web_a : "HTTP Round-Robin"
alb -- pod_web_b : "HTTP Round-Robin"

pod_web_a -- pod_api_a : "Внутренний gRPC"
pod_web_b -- pod_api_b : "Внутренний gRPC"

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

Разбор синтаксиса: Вложив node цели внутри дочерних узелструктуры, этот шаблон идеально моделирует размещение в контейнерах (поды выполняются внутри виртуальных машин EC2). Балансировщик нагрузки приложений бесшовно распределяет входящие запросы по зонам доступности, в то время как компоненты кластера направляют вызовы базы данных обратно в общий хранилищный пулы.