Exemples de diagrammes de déploiement

Le diagramme ci-dessus est celui qu'il vaut la peine de savoir dessiner de mémoire. Un navigateur, un serveur web qui termine le TLS, un serveur d'application, une base de données. Trois chemins de communication portant le protocole et le port, et trois artefacts posés sur les noeuds qui les exécutent.

Deux décisions y méritent d'être nommées. D'abord, les étiquettes de protocole sont la raison de l'utilité du diagramme : HTTPS, HTTP/8080, TCP/5432 constitue tout le contenu de la plupart des revues de sécurité, et un diagramme sans elles n'est que quatre boîtes que n'importe qui aurait devinées. Ensuite, les artefacts portent de vrais noms de fichiers - orders.jar, pas « application » - parce qu'un diagramme de déploiement parle de choses physiques, et qu'un build produit des fichiers qui ont des noms.

Les conteneurs font hésiter, parce qu'un conteneur est à la fois une chose qui tourne et une chose qui a été construite. UML sépare déjà les deux : le conteneur en cours d'exécution est un environnement d'exécution, donc un noeud, et l'image dont il est parti est un artefact, déployé dessus.

Rien dans la forme de ce diagramme ne diffère de celui à trois niveaux, et c'est bien le propos : l'environnement d'exécution a changé, pas la notation. Le répartiteur de charge est un «device» parce que c'est de l'infrastructure dans laquelle vous ne déployez pas. Le contrôleur d'ingress et le pod sont des «execution environment» parce que d'autres choses tournent dedans. Le tag d'image orders:1.4.2est un artefact parce qu'un build l'a produit, et mettre la version dans l'étiquette est ce qui permet au diagramme de répondre à « qu'est-ce qui tourne en production en ce moment ».

La base managée se tient en bordure comme un simple appareil. C'est le dessin honnête : on ne déploie pas d'artefacts sur un service exploité par quelqu'un d'autre, et prétendre que le schéma est installé « sur RDS » n'est vrai qu'au sens où il y a été appliqué une fois.

La raison la plus fréquente d'ouvrir un diagramme de déploiement est de savoir ce qui se passe quand une boîte meurt. Cette question a une forme, et il vaut la peine de la dessiner explicitement plutôt que de la laisser à une note de bas de page.

Trois noeuds d'application derrière un répartiteur, tous écrivant sur une seule base primaire. Dessiné ainsi, le point de défaillance unique est visible sans que personne ait à le dire : la couche applicative s'évase et la couche de données non. C'est une phrase sur laquelle quelqu'un agira, et elle n'a demandé aucune notation supplémentaire.

Quand le nombre varie à l'exécution, remplacez les trois noeuds par un seul portant une multiplicité - app-node [3..*] - plutôt que de dessiner un nombre arbitraire. Un diagramme qui affirme exactement trois est faux dès la première mise à l'échelle du groupe, et un diagramme réputé faux cesse d'être consulté.

Tout diagramme de déploiement qui devient inutile le devient de la même façon : quelqu'un a continué d'ajouter des noeuds. La discipline consiste à décider à quoi sert le diagramme avant que la deuxième boîte ne soit posée.

S'il vous faut la contrepartie qui montre le logiciel plutôt que les machines, c'est un diagramme de composants. Les deux se dessinent en général par paire, et celui de déploiement est le plus court.