Jedes Team hat dieses eine Architekturdiagramm. Es war wunderschön an dem Tag, an dem jemand es erstellt hat, und etwa eine Woche später falsch. Ein Service ist umgezogen, ein Cache ist aufgetaucht, eine Queue kam dazu, und niemand wollte das Zeichentool wieder öffnen und Kästen herumschieben.
Also verrottet das Diagramm still vor sich hin, und neue Engineers lernen das System, indem sie YAML lesen. Die gute Nachricht: Genau dieses YAML reicht völlig aus, um das Bild für dich zu zeichnen. LetDraw liest deine Compose- oder Kubernetes-Datei und legt die Architektur an, sodass das Diagramm aus der Quelle der Wahrheit kommt, statt sich von ihr zu entfernen.
docker-compose.yml visualisieren: die Zehn-Sekunden-Version
Öffne den Dialog „Aus Code generieren“, füge deine Datei ein, und du bekommst ein fertig angeordnetes Diagramm aus echten, editierbaren Formen. Keine Kästen ziehen, keine Pfeile von Hand verbinden. Hier ist eine Compose-Datei, die die meisten wiedererkennen werden:
services: web: image: nginx depends_on: [api] api: image: app:latest depends_on: [db, redis] db: image: postgres:16 redis: image: redis:7
Füge das ein, und LetDraw macht daraus Folgendes:
Die Datenbank wurde zum Zylinder, der Cache hat sein eigenes Icon bekommen, und die depends_on-Kanten wurden zu Pfeilen, die um deine Kästen herumgeführt werden statt mitten hindurch. Es ist ein Diagramm, kein Screenshot einer Konfiguration.
Was dabei wirklich passiert
Der Dialog macht drei Dinge, die eine Erwähnung wert sind:
- Er erkennt das Format automatisch. Du wählst nicht „Compose“ oder „Kubernetes“ aus einem Menü. Füge es ein, und LetDraw erkennt, was es ist.
- Er gruppiert zusammengehörige Teile. Kubernetes-Manifeste werden so gruppiert, dass das Layout deine Namespaces widerspiegelt, statt einer flachen Suppe aus Knoten.
- Er setzt die richtigen Icons. Services, Datenbanken und Queues bekommen erkennbare Produkt-Icons, sodass sich das Diagramm auf einen Blick lesen lässt.
Das Diagramm kommt jetzt aus der Quelle der Wahrheit, also stimmt es per Konstruktion, nicht durch Disziplin.
Es ist nicht nur Compose
Derselbe Dialog nimmt weit mehr als ein Format an, und genau darum geht es. Wenn etwas Infrastruktur oder ein System beschreibt, zeichnet er es wahrscheinlich:
- Kubernetes-Manifeste, nach Namespace gruppiert
- Terraform und Helm für Infrastruktur und Releases
- Graphviz DOT, SQL DDL, eine OpenAPI-Spezifikation oder sogar ein git log
- Mermaid und D2, falls du Diagramme bereits als Code pflegst
Dann mach es zu deinem
Auto-Layout bringt dich 90 Prozent des Weges, und in den letzten 10 Prozent steckt der Wert. Weil das Ergebnis aus echten Formen besteht, kannst du:
- Einen Kasten verschieben, eine Notiz hinzufügen oder den riskanten Pfad hervorheben
- Die Teile gruppieren, die zu einem Team oder einem Bounded Context gehören
- Als PNG, SVG oder PDF für ein Dokument exportieren oder direkt in die Zwischenablage kopieren
- Die Zeichnung zurück in Mermaid oder D2 verwandeln, wenn du wieder Code willst
Und wenn das Bild in deiner Doku leben soll, füge ein Embed-Snippet in eine README oder ein Wiki ein, und es bleibt eine lebendige, schreibgeschützte Ansicht. Kein veraltetes PNG mehr, an dessen erneuten Export jemand denken muss.
Warum das für DevOps wichtig ist
Architekturdiagramme sollen ein gemeinsames mentales Modell sein. Sobald sie der Realität hinterherhinken, werden sie zur Falle: Sie bringen neuen Leuten das Falsche bei und geben Reviewern falsche Sicherheit. Wenn du sie aus den Dateien erzeugst, die du ohnehin pflegst, schließt sich diese Lücke. Das Diagramm ist billig zu erstellen, also ist es auch billig, es aktuell zu halten, und ein aktuelles Diagramm ist das einzige, das sich zu haben lohnt.
Füge deine docker-compose.yml ein und sieh zu, wie sich dein Stack selbst zeichnet. Das dauert etwa so lange wie das Lesen dieses Satzes.