Archyno
UMLDiagramy štruktúry

Príklady diagramov nasadenia

Tri diagramy nasadenia systémov, ktoré poznáte - trojvrstvová webová aplikácia, Kubernetes klaster a pool za load balancerom - vždy s odôvodnením, čo bolo nakreslené a čo zámerne vynechané.

8 min čítaniaUML 2.5.122 z 35

Krátka odpoveď

  • Štyri uzly, tri označené komunikačné cesty a tri šípky nasadenia sú úplný diagram: prehliadač, webový server, aplikačný server, databáza.
  • Bežiaci kontajner je vykonávacie prostredie, a teda uzol. Obraz, z ktorého bol spustený, je artefakt. Kresliť obraz ako uzol je obvyklá chyba.
  • Redundanciu ukážte násobnosťou, napríklad 3..* na jednom uzle. Diagram tvrdiaci presne tri inštancie je nesprávny hneď po prvom autoškálovaní.
  • Kreslite len toľko, aby to odpovedalo na otázku, kvôli ktorej ste kreslili. Každý ďalší uzol je tvrdenie, ktoré musí niekto po ďalšej migrácii udržať pravdivé.
Trojvrstvový UML diagram nasadenia. Zariadenie s prehliadačom sa cez HTTPS pripája k prostrediu nginx, ktoré sa cez HTTP na porte 8080 pripája k aplikačnému serveru, ktorý sa cez TCP na porte 5432 pripája k zariadeniu s databázou Postgres. Zhora sú na ne nasadené tri artefakty: web-ui.tar.gz na nginx, orders.jar na aplikačný server a schema.sql na databázu.
Trojvrstvový stack: štyri uzly, tri protokoly, tri artefakty. Väčšina prvých diagramov nasadenia je tento diagram s inými menami.

01Príklad 1: trojvrstvová webová aplikácia#

Diagram vyššie je ten, ktorý sa oplatí vedieť nakresliť spamäti. Prehliadač, webový server ukončujúci TLS, aplikačný server, databáza. Tri komunikačné cesty nesúce protokol a port a tri artefakty položené na uzly, ktoré ich spúšťajú.

Dve rozhodnutia v ňom stojí za to pomenovať. Po prvé, popisky protokolov sú dôvodom, prečo je diagram užitočný: HTTPS, HTTP/8080, TCP/5432 je celým obsahom väčšiny bezpečnostných posudkov a diagram bez nich sú štyri boxy, ktoré by uhádol každý. Po druhé, artefakty sú skutočné názvy súborov - orders.jar, nie „aplikácia“ - lebo diagram nasadenia je o fyzických veciach a build produkuje súbory s menami.

02Príklad 2: klaster Kubernetes#

Kontajnery ľudí zneisťujú, lebo kontajner je zároveň vec, ktorá beží, aj vec, ktorá bola zostavená. UML tie dve už oddeľuje: bežiaci kontajner je vykonávacie prostredie, čo je uzol, a image, z ktorého sa spustil, je artefakt, ktorý je naň nasadený.

UML diagram nasadenia v Kubernetes. Zariadenie load balancera sa cez HTTPS pripája k prostrediu ingress-nginx, ktoré sa cez HTTP na porte 8080 pripája k prostrediu podu orders, ktoré sa cez TCP na porte 5432 pripája k zariadeniu spravovanej databázy. Zhora sú na ne nasadené: ingress.yaml na ingress, image kontajnera orders:1.4.2 na pod a schema.sql na databázu.

Tvar tohto diagramu sa nijako nelíši od toho trojvrstvového, a o to práve ide: zmenilo sa behové prostredie a notácia nie. Load balancer je «device», lebo je to infraštruktúra, do ktorej nenasadzujete. Ingress kontrolér a pod sú «execution environment», lebo vnútri nich bežia ďalšie veci. Tag image orders:1.4.2je artefakt, lebo ho vyprodukoval build, a práve dať verziu do popisky je to, čo robí diagram schopným odpovedať na otázku „čo beží práve teraz v produkcii“.

Spravovaná databáza sedí na okraji ako obyčajné zariadenie. To je poctivá kresba: artefakty nenasadzujete na službu, ktorú prevádzkuje niekto iný, a predstierať, že schéma je nainštalovaná „na RDS“, je pravda len v tom zmysle, že tam raz bola aplikovaná.

03Príklad 3: pool za load balancerom#

Najčastejším dôvodom, prečo si niekto otvorí diagram nasadenia, je zistiť, čo sa stane, keď jeden box zomrie. Tá otázka má tvar a oplatí sa ho nakresliť výslovne, nie nechať ho na poznámku pod čiarou.

UML diagram nasadenia ukazujúci horizontálne škálovanie. Jedno zariadenie load balancera haproxy sa smerom nadol pripája k trom identickým aplikačným uzlom app-01, app-02 a app-03. Všetky tri sa smerom nadol pripájajú k jedinému primárnemu databázovému uzlu.

Tri aplikačné uzly za jedným load balancerom, všetky zapisujúce do jediného primárneho. Nakreslené takto je jediné miesto zlyhania viditeľné bez toho, aby ho musel niekto vysloviť: aplikačná vrstva sa vejárovito rozťahuje a dátová nie. To je veta, na ktorú niekto zareaguje, a nestála žiadnu notáciu navyše.

Keď sa počet za behu mení, nahraďte tie tri uzly jedným, ktorý nesie násobnosť - app-node [3..*] - namiesto kreslenia ľubovoľného počtu. Diagram, ktorý tvrdí presne tri, je nepravdivý pri prvom škálovaní skupiny, a diagram, o ktorom sa vie, že je nepravdivý, prestane byť konzultovaný.

04Čo vynechať#

Každý diagram nasadenia, ktorý sa stane zbytočným, sa ním stane rovnako: niekto stále pridával uzly. Disciplínou je rozhodnúť, na čo diagram je, skôr než pribudne druhý box.

Siahnite po ňom, keď

  • Protokoly a porty na každej komunikačnej ceste - je to obsah väčšiny posudkov.
  • Skutočné názvy artefaktov s verziami, aby diagram odpovedal, čo beží teraz.
  • Jedna reprezentatívna inštancia na rolu, s násobnosťou, keď sa počet mení.
  • Spravované služby ako obyčajné zariadenia na okraji, s viditeľnou hranicou toho, čo prevádzkujete.

Siahnite po niečom inom, keď

  • Logické vrstvy - nemajú adresu a nič sa na ne nenasadzuje.
  • Každú mikroslužbu vo veľkom prostredí. Radšej kreslite jeden podsystém na diagram.
  • Monitoring, logovanie a CI agentov, pokiaľ diagram nie je o nich.
  • Živé počty inštancií, ktoré sú v čase posudzovania diagramu už zlé.

Ak potrebujete náprotivok, ktorý ukazuje softvér namiesto strojov, je to diagram komponentov. Tie dva sa zvyčajne kreslia ako pár a ten na nasadenie je z nich kratší.

05Čo si zapamätať#

Po jednom riadku na každé

  1. 01Štyri uzly, označené protokoly a pomenované artefakty už sú kompletným diagramom nasadenia.
  2. 02Bežiaci kontajner je uzol; image, z ktorého sa spustil, je artefakt. Zámena tých dvoch je obvyklá kontajnerová chyba.
  3. 03Popisky protokolu a portu sú tým, čo robí diagram hodným otvorenia pri posudku.
  4. 04Kreslite jednu inštanciu na rolu a použite násobnosť, keď sa počet za behu mení.
  5. 05Ak sa na box nedá pingnúť, na tento diagram nepatrí.

06Časté otázky#

Aký je jednoduchý príklad diagramu nasadenia?

Prehliadač sa pripája na webový server, ten na aplikačný server a ten na databázu, pričom na každom je nasadený jeden artefakt. Štyri uzly, tri komunikačné cesty označené protokolom a tri šípky nasadenia sú úplný a užitočný diagram.

Ako nakresliť diagram nasadenia pre Kubernetes?

Behové časti klastra modelujte ako uzly a obrazy ako artefakty. Load balancer je zariadenie, ingress kontrolér a každý pod sú behové prostredia a obraz kontajnera je artefakt nasadený na pod. Spravované služby ako hostovaná databáza zostávajú zariadeniami na okraji diagramu.

Sú kontajnery v UML uzly alebo artefakty?

Oboje, podľa toho, ktorý kontajner myslíte. Bežiaci kontajner je behové prostredie, teda uzol, lebo v ňom beží niečo ďalšie. Obraz, z ktorého bol spustený, je artefakt, lebo je to súbor z buildu. Kresliť obraz ako uzol je najčastejšia chyba na kontajnerovom diagrame.

Ako zobraziť redundanciu na diagrame nasadenia?

Buď nakreslite jednotlivé inštancie, čo je poctivé, ale nefunguje nad štyri, alebo nakreslite jeden uzol s násobnosťou v rohu, napríklad app-node s 3..*. Druhú možnosť použite, keď sa počet mení za behu - diagram tvrdiaci presne tri je nesprávny hneď po prvom autoškálovaní.

Koľko detailu patrí na diagram nasadenia?

Toľko, aby odpovedal na otázku, kvôli ktorej vznikol. Infraštruktúrny prehľad chce protokoly a porty na komunikačných cestách; onboarding diagram chce štyri boxy a nič viac. Každý ďalší uzol je tvrdenie, ktoré musí niekto po ďalšej migrácii udržať pravdivé.

V tejto sérii

Súvisiace články

Všetky články