Zo bouwt u een migratie-afhankelijkheidsgraaf

Drie edge-typen, waarvan één expliciet

Een kleine omgeving die voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld. Links: de webserver, zijn elastic IP en het DNS-record uit de invoer (regels 83 tot 105; de opmerking staat in het invoerbestand). Rechts: de vier edges van de graaf in assessment.json die bij de server en bij het DNS-record beginnen, voor de leesbaarheid opnieuw ingesprongen.

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"
  }
]

• Drie edge-typen

  DEPLOYED_IN zegt waar een resource staat (een subnet, een VPC). ATTACHED_TO zegt wat de resource draagt (een security group). DEPENDS_ON zegt dat een andere resource eerst moet bestaan. Elke edge noemt het argument waaruit hij is gelezen.

• Expliciet gaat boven stil

  De server verwijst in geen enkel argument naar de database. De edge naar de database bestaat alleen omdat depends_on het zegt, en de edge draagt de vlag explicit.

• Het record volgt het adres

  Het DNS-record leest het publieke adres van de elastic IP, dus het staat erachter, en die staat achter de server.

Wat de expliciete koppeling met de golven doet

Twee runs van dezelfde omgeving, één met de regel depends_on en één zonder. Golven worden berekend uit de afhankelijkheden: een eenheid verhuist pas na alles waarvan die afhangt, en eenheden in één golf kunnen parallel verhuizen.

De samenvatting telt 14 afhankelijkheden tussen eenheden met de regel en 13 zonder. Zonder de regel deelt de server golf 3 met de security group van de database en wacht hij niet meer op de database. De graaf zelf noemt 15 edges voor de eerste run, omdat de database subnet group deel uitmaakt van de database-eenheid en geen eenheid op zich is.

Waar elk edge-type vandaan komt

Aantallen komen uit de eerste run. Welke argumenten als verwijzing gelden, bepaalt de engine per resourcetype.

De plek waar de graaf blind is

Dezelfde run. Het DNS-record noemt zijn zone met een letterlijke identifier, dus er is geen verwijzing om te volgen. Links: het record in de invoer. Rechts: de diagnose die de run ervoor schreef (het veld provenance is weggelaten).

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"
  }
]

• Op zichzelf beoordeeld

  Het record wordt nog steeds geclassificeerd en zijn adreswijziging staat als cutoverstap in de lijst. Wat ontbreekt, is zijn koppeling met de zone, die het plan u laat binden aan een STACKIT DNS-zone via een variabele.

• De expliciete koppeling reikt tot de cutoverstap

  Met de regel depends_on noemt de stap die de databaseverbinding omschakelt de webserver als client: de bron verwijst vanuit aws_instance.web naar de database. In de run zonder die regel staat dat geen enkele resource van de bron naar de database verwijst, dat de applicaties buiten de bron liggen en dat hun eigenaar ze opsomt. De mediabucket krijgt in beide runs de tweede formulering.

De graaf opbouwen, stap voor stap

1. 01

   1. Draai op de Terraform die u hebt

   Laat de engine de verwijzingen lezen. Het resultaat is de graaf, de golven in migration/waves.csv en migration/technical-sequencing.md, en een tekening in architecture/dependencies.mmd.

2. 02

   2. Lees de diagnoses

   Open de diagnoses van de graaf in assessment.json. Een letterlijke identifier, een data source of een waarde die de run niet kon oplossen betekent een ontbrekende edge; noteer ze stuk voor stuk.

3. 03

   3. Bevestig de applicatiegroepen

   De run stelt groepen voor op basis van verwijzingen en ingressregels, hier één groep van vijf eenheden. Het voorstel verandert niets totdat u in applications-template.yaml review: confirmed zet en het bestand met --applications teruggeeft.

4. 04

   4. Voeg de runtimekoppelingen toe

   Vraag elke applicatie-eigenaar welke databases, buckets, wachtrijen en API's de applicatie uit de configuratie leest. In deze run hoort de mediabucket bij geen enkele groep en staat hij in golf 1: de Terraform koppelt die aan niets, dus of de shop de bucket leest, kan alleen de eigenaar ervan beantwoorden.

5. 05

   5. Draai opnieuw en vergelijk

   Draai na het toevoegen van expliciete koppelingen opnieuw en vergelijk waves.csv. Een koppeling die niets verschuift, is overbodig of staat op de verkeerde eenheid.

6. 06

   6. Maak van golven een plan

   De golven zijn een vertrekpunt voor het golfplan van de architect, geen planning. Voeg datavolumes, vensters voor de schrijfstop en de volgorde van de cutover toe.

Vragen over het in kaart brengen van afhankelijkheden

Bronnen

• Overzicht van STACKIT DNS
• Werken met hosted zones (Amazon Route 53)
• Overzicht van STACKIT PostgreSQL Flex