ABHÄNGIGKEITEN → STACKIT · ARCHITEKTUR
So bauen Sie einen Abhängigkeitsgraphen für die Migration auf
Beginnen Sie mit den Referenzen, die Ihr Terraform bereits nennt, lassen Sie sie die Reihenfolge im Ziel festlegen und ergänzen Sie von Hand die Verbindungen, die in der Anwendungskonfiguration stecken. StackToIT liest die Referenzen zwischen Ressourcen als Kanten, ordnet die Einheiten in Wellen, sodass nichts vor dem umzieht, wovon es abhängt, und sagt, wo der Graph blind ist. Diese Seite zeigt das an einem Webshop mit elf Einheiten, darunter ein explizites depends_on, das drei Einheiten um zwei Wellen verschiebt.
Drei Kantentypen, einer davon explizit
Eine kleine Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links Webserver, Elastic IP und DNS-Eintrag der Eingabe (Zeilen 83 bis 105; der Kommentar steht in der Eingabedatei). Rechts die vier Kanten des Graphen in assessment.json, die vom Server und vom DNS-Eintrag ausgehen, zur besseren Lesbarkeit neu eingerückt.
resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "m6i.large"
subnet_id = aws_subnet.web.id
vpc_security_group_ids = [aws_security_group.web.id]
# Nothing in the arguments refers to the database or the bucket:
# the application reads both from its configuration at run time.
depends_on = [aws_db_instance.shop]
}
resource "aws_eip" "web" {
instance = aws_instance.web.id
domain = "vpc"
}
resource "aws_route53_record" "www" {
zone_id = "Z0123456789EXAMPLE"
name = "www.shop.example.com"
type = "A"
ttl = 300
records = [aws_eip.web.public_ip]
}[
{
"from": "aws_instance.web",
"to": "aws_db_instance.shop",
"type": "DEPENDS_ON",
"via": "depends_on",
"explicit": true
},
{
"from": "aws_instance.web",
"to": "aws_security_group.web",
"type": "ATTACHED_TO",
"via": "vpc_security_group_ids"
},
{
"from": "aws_instance.web",
"to": "aws_subnet.web",
"type": "DEPLOYED_IN",
"via": "subnet_id"
},
{
"from": "aws_route53_record.www",
"to": "aws_eip.web",
"type": "DEPENDS_ON",
"via": "records"
}
]Drei Kantentypen
DEPLOYED_IN sagt, wo eine Ressource liegt (Subnetz, VPC). ATTACHED_TO sagt, was sie trägt (eine Security Group). DEPENDS_ON sagt, dass sie eine andere Ressource zuerst braucht. Jede Kante nennt das Argument, aus dem sie gelesen wurde.
Explizit statt stillschweigend
Der Server verweist in keinem Argument auf die Datenbank. Die Kante zur Datenbank gibt es nur, weil depends_on sie verlangt; sie trägt das Flag explicit.
Der Eintrag folgt der Adresse
Der DNS-Eintrag liest die öffentliche Adresse der Elastic IP, steht also hinter ihr, und diese hinter dem Server.
Was die explizite Verbindung mit den Wellen macht
Zwei Läufe derselben Umgebung, einer mit der Zeile depends_on, einer ohne. Wellen werden aus den Abhängigkeiten berechnet: Eine Einheit zieht erst um, wenn alles umgezogen ist, wovon sie abhängt, und Einheiten einer Welle können parallel umziehen.
| Einheit | Welle mit depends_on | Welle ohne |
|---|---|---|
| aws_s3_bucket.media | 1 | 1 |
| aws_vpc.shop | 1 | 1 |
| aws_security_group.web | 2 | 2 |
| aws_subnet.data_a | 2 | 2 |
| aws_subnet.data_b | 2 | 2 |
| aws_subnet.web | 2 | 2 |
| aws_security_group.db | 3 | 3 |
| aws_db_instance.shop | 4 | 4 |
| aws_instance.web | 5 | 3 |
| aws_eip.web | 6 | 4 |
| aws_route53_record.www | 7 | 5 |
Die Zusammenfassung zählt mit der Zeile 14 Abhängigkeiten zwischen Einheiten, ohne sie 13. Ohne sie teilt sich der Server die Welle 3 mit der Datenbank-Security-Group und wartet nicht mehr auf die Datenbank. Der Graph selbst listet im ersten Lauf 15 Kanten, weil die DB-Subnetzgruppe Teil der Datenbankeinheit ist und keine eigene Einheit.
Woher jeder Kantentyp kommt
| Kantentyp | Terraform-Argument, das ihn erzeugt | In diesem Lauf |
|---|---|---|
| DEPLOYED_IN | vpc_id, subnet_id, subnet_ids, db_subnet_group_name | Subnetze und Security Groups in der VPC; der Server in seinem Subnetz; die Datenbank in ihrer Subnetzgruppe (9 Kanten) |
| ATTACHED_TO | vpc_security_group_ids, ingress.security_groups | Beide Security Groups an ihren Ressourcen; die DB-Gruppe lässt die Web-Gruppe zu (3 Kanten) |
| DEPENDS_ON | instance, records, depends_on | Elastic IP am Server, Eintrag an der Elastic IP, Server an der Datenbank (3 Kanten) |
Zahlen aus dem ersten Lauf. Welche Argumente als Referenz zählen, entscheidet die Engine je Ressourcentyp.
Die Stelle, an der der Graph blind ist
Derselbe Lauf. Der DNS-Eintrag nennt seine Zone mit einer festen Kennung; es gibt also keine Referenz, der man folgen könnte. Links der Eintrag in der Eingabe. Rechts die Diagnose, die der Lauf dafür geschrieben hat (ohne ihr Feld provenance).
resource "aws_route53_record" "www" {
zone_id = "Z0123456789EXAMPLE"
name = "www.shop.example.com"
type = "A"
ttl = 300
records = [aws_eip.web.public_ip]
}[
{
"severity": "warning",
"message": "could not find the parent of aws_route53_record.www through attribute zone_id; assessed on its own",
"node_id": "aws_route53_record.www"
}
]Für sich bewertet
Der Eintrag wird trotzdem klassifiziert, und seine Adressänderung steht als Cutover-Schritt im Plan. Es fehlt die Verbindung zur Zone; der Plan verlangt, sie per Variable an eine STACKIT-DNS-Zone zu binden.
Die explizite Verbindung erreicht den Cutover-Schritt
Mit der Zeile depends_on nennt der Schritt, der die Datenbankverbindung umstellt, den Webserver als Client: Die Quelle verweist von aws_instance.web auf die Datenbank. Im Lauf ohne diese Zeile heißt es, dass keine Ressource der Quelle auf die Datenbank verweist, die Anwendungen außerhalb der Quelle liegen und ihr Verantwortlicher sie auflistet. Der Media-Bucket erhält in beiden Läufen die zweite Formulierung.
Den Graphen Schritt für Schritt aufbauen
1. Auf dem vorhandenen Terraform ausführen
Lassen Sie die Engine die Referenzen lesen. Ergebnis sind der Graph, die Wellen in migration/waves.csv und migration/technical-sequencing.md sowie eine Zeichnung in architecture/dependencies.mmd.
2. Die Diagnosen lesen
Öffnen Sie die Graph-Diagnosen in assessment.json. Eine feste Kennung, eine Data Source oder ein Wert, den der Lauf nicht auflösen konnte, bedeutet eine fehlende Kante; notieren Sie jede.
3. Anwendungsgruppen bestätigen
Der Lauf schlägt Gruppen aus Referenzen und Ingress-Regeln vor, hier eine Gruppe aus fünf Einheiten. Der Vorschlag ändert nichts, bis Sie in applications-template.yaml review: confirmed setzen und die Datei mit --applications zurückgeben.
4. Laufzeitverbindungen ergänzen
Fragen Sie die Verantwortlichen jeder Anwendung, welche Datenbanken, Buckets, Queues und APIs die Anwendung aus der Konfiguration liest. In diesem Lauf gehört der Media-Bucket zu keiner Gruppe und liegt in Welle 1: Das Terraform verbindet ihn mit nichts; ob der Shop ihn liest, kann also nur sein Verantwortlicher beantworten.
5. Erneut ausführen und vergleichen
Führen Sie den Lauf nach dem Ergänzen expliziter Verbindungen erneut aus und vergleichen Sie waves.csv. Eine Verbindung, die nichts verschiebt, ist entweder überflüssig oder an der falschen Einheit.
6. Aus Wellen einen Plan machen
Die Wellen sind Ausgangspunkt für den Wellenplan des Architekten, kein Terminplan. Ergänzen Sie Datenmengen, Schreibstopp-Fenster und die Cutover-Reihenfolge.
Fragen zur Abhängigkeitsanalyse
Erkennt StackToIT Abhängigkeiten aus laufenden Systemen?
Nein. Es liest Terraform-, OpenTofu- und RVTools-Eingaben. Abhängigkeiten, die erst zur Laufzeit bestehen, etwa ein Connection String in einer Konfigurationsdatei, stehen nicht im Graph; Sie ergänzen sie über die Anwendungsgruppen und die Entscheidungen.
Was ändert ein explizites depends_on außer den Wellen?
In diesem Lauf auch den Cutover-Plan. Mit der Zeile nennt der Schritt zur Umstellung der Datenbankverbindung den Webserver als bekannten Client; ohne sie heißt es, die Anwendungen lägen außerhalb der Quelle. Ein depends_on, das eine echte Laufzeitverbindung abbildet, dokumentiert also einen Client im Plan, nicht nur eine Reihenfolge.
Sind Wellen die Reihenfolge des Cutovers?
Nein. Sie sind die Reihenfolge, in der Einheiten wegen ihrer Abhängigkeiten gebaut oder verschoben werden können. Die Cutover-Fakten, etwa DNS und Adressumbindung, stehen getrennt in technical-sequencing.md.
Warum landet eine Einheit ohne Referenzen in Welle 1?
Sie hat nichts, worauf sie warten müsste. Der Media-Bucket liegt mit der VPC in Welle 1. Das sagt, dass das Terraform ihn mit nichts verbindet, nicht, dass ihn niemand nutzt.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.