O que é um Diagrama de Implantação?
Um Diagrama de Implantação é um diagrama estrutural diagrama UML que modela a arquitetura de execução física de um sistema de software. Como uma especificação padrão central da Linguagem de Modelagem Unificada (UML), este tipo específico tipo de diagrama UML mapeia como os componentes de software são fisicamente implantados em alvos de hospedagem de hardware, elementos de infraestrutura em nuvem ou ambientes de execução de contêineres. Fornece aos engenheiros de sistemas, profissionais DevOps e arquitetos de redes uma visualização clara dos limites dos clusters de servidores, caminhos de replicação de banco de dados, níveis de balanceadores de carga e protocolos de rede de hardware em regiões de desenvolvimento e produção.
Com VPasCode, você não precisa se esforçar com formas complexas de agrupamento vetorial ou mapeamento manual de coordenadas. Ao usar blocos de script declarativos simples, nosso motor agrupa, calcula e aninha estruturas de nós de hardware de forma limpa.
Guia de Sintaxe Básica: Elementos e Construções
Para criar um diagrama de implantação UML preciso e compatível com padrões no PlantUML, você precisa dominar nós de hardware, ambientes de execução, artefatos de implantação e ligações de rede.
1. Declarando Cubos de Infraestrutura (Nós)
Em um layout de implantação, os recursos computacionais físicos são representados como cubos tridimensionais 3D. Você declara esses elementos usando a nodepalavra-chave, ou escolhendo variantes especializadas que dão aos leitores um contexto visual imediato sobre a camada de hardware:
node "Servidor de Aplicação Bare Metal" como CoreServer
node Server1
database "Servidor de Banco de Dados" como DB_Node
2. Modelando Camadas em Nuvem e Ambientes Virtuais
Aplicações modernas raramente são implantadas diretamente em hardware físico. O PlantUML fornece envoltórios de agrupamento aninhados para representar limites lógicos de execução, áreas de atuação de provedores em nuvem ou ambientes virtuais de contêineres, como Docker e Kubernetes:
cloud— Representa níveis públicos externos de web ou limites de rede em nuvem (por exemplo, AWS, Azure).frame— Representa sistemas virtuais ou regiões organizacionais.storage— Representa configurações físicas de SAN ou localizações de armazenamento de objetos.
cloud "Amazon Web Services VPC" {
node "Instância EC2 Linux" como WorkerNode
}
3. Definindo Artefatos de Implantação (O que Roda onde)
Um artefato representa o arquivo físico real (como um arquivo JAR compilado, uma pasta de compilação estática ou um pacote compactado) que é implantado em um nó. Você declara um artefato usando a artifactpalavra-chave, ou coloque-o diretamente dentro dos blocos de hardware:
node "Servidor de Aplicação" {
artifact "api_v1.0.war" como API_File
}
4. Mapeando Links de Comunicação de Rede
Conexões entre elementos de infraestrutura representam redes físicas concretas, caminhos de fio ou canais sem fio. Você mapeia esses links usando travessões duplos sólidos (--), e acrescente texto entre aspas para definir explicitamente o protocolo de rede usado (por exemplo, HTTPS, TCP/IP, SSH):
node Server1
node DB_Node
Server1 -- DB_Node : "TCP/IP (Porta 5432)"
Melhores Práticas para Mapas de Implantação Práticos
- Aninhe Estruturas Corretamente: Sempre desenhe seus componentes internos ou artefatos *dentro* das chaves curvas das suas
nodedeclarações para mostrar claramente a residência de execução. - Rotule os Protocolos de Comunicação: Nunca desenhe uma linha em branco entre servidores. Sempre rotule a conexão com seu protocolo de comunicação principal (por exemplo,
"HTTPS (Porta 443)") para ajudar na revisão de rede e segurança. - Isole Zonas de Disponibilidade: Ao documentar configurações de nuvem de alta disponibilidade, use envoltórios separados
quadroenvoltórios para ilustrar configurações de divisão de região (por exemplo,us-east-1avs.us-east-1b).
Exemplos de Diagramas de Implantação do PlantUML no Mundo Real
Exemplo 1: Configuração Clássica de Três Camadas para Web (Nós e Protocolos)
Este modelo padrão representa uma estrutura padrão de aplicativo corporativo moderno, mapeando uma rede de distribuição de conteúdo externa, um cluster de servidores de aplicativos e uma camada de hospedagem de banco de dados interna segura.
@startuml
nuvem "Internet Pública" como net
nó "Edge do CDN Cloudflare" como cdn
quadro "Zona Desmilitarizada (DMZ)" {
nó "Servidor de Balanceador de Carga Nginx" como proxy
}
quadro "Sub-rede Privada do VPC de Aplicação" {
nó "Servidor Ubuntu 22.04" como app_node {
artefato "core_api.jar" como application
}
}
banco de dados "Camada de Banco de Dados Gerenciado" {
nó "Cluster Primário PostgreSQL" como db_master
}
' Estabelecer fios de conexão topológica
net -- cdn : "HTTPS"
cdn -- proxy : "HTTPS (TLS 1.3)"
proxy -- app_node : "HTTP (Porta 8080)"
app_node -- db_master : "TCP/IP (Porta 5432)"
@enduml
Análise de Sintaxe: Este mapa define claramente os perímetros de segurança. O ativo compilado core_api.jar está aninhado com segurança dentro do app_node caixa do servidor. Os caminhos de rede escalonam-se limpidamente para dentro, estabelecendo regras rígidas de protocolo para cada segmento, desde a borda pública da web até a camada de banco de dados gerenciado.
Exemplo 2: Arquitetura de Contêineres Nativos na Nuvem (Kubernetes e AWS Mesh)
Este projeto avançado de empresa mapeia uma implantação em nuvem altamente escalonável e multi-região. Utiliza layouts de nós aninhados para visualizar um sistema de contêineres Kubernetes com balanceamento de carga interagindo com bancos de dados em nuvem autônomos.
@startuml
nuvem "Amazon Web Services (AWS)" {
nó "Balanceador de Carga de Aplicativo AWS" como alb
quadro "Zona de Disponibilidade: us-east-1a" {
nó "Nó de Trabalho EC2 Node A" como ec2_a {
nó "Pod K8s: Frontend Web" como pod_web_a
nó "Pod K8s: API de Pedido" como pod_api_a
}
}
quadro "Zona de Disponibilidade: us-east-1b" {
nó "Nó de Trabalho EC2 Node B" como ec2_b {
nó "Pod K8s: Frontend Web" como pod_web_b
nó "Pod K8s: API de Pedido" como pod_api_b
}
}
armazenamento "Clusters Serverless do AWS Aurora" {
banco de dados "Banco de Dados de Clientes" como rds_db
}
}
' Linhas de orquestração de infraestrutura
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
Análise de Sintaxe: Ao aninhar nó alvos dentro de nóestruturas, este modelo representa perfeitamente uma disposição containerizada (Pods executando dentro de máquinas virtuais EC2). O balanceador de carga de aplicação distribui sem problemas as requisições recebidas entre as zonas de disponibilidade, enquanto os componentes do cluster redirecionam as chamadas do banco de dados de volta para um pool de armazenamento compartilhado.