Zum Inhalt

spoke-Erstellung

Runbook für Operatoren für die Standardänderung Neuer workload / spoke / application landing zone (spoke canvas). Es nennt die Reihenfolge der Arbeit von der Anfrage bis zu einem pull request, der bereit für das Review ist. Die Felder, das JSON, was angelegt wird und wie du es verifizierst, stehen unter Neuer spoke und in der spoke-JSON-Referenz. Das Review steht unter spoke-pull-request-Review, das Deployment unter spoke-Deployment.

1. Die Anfrage prüfen

Wenn der Antragsteller einen pull request mit der spoke-Datei beigefügt hat, prüfe ihn sorgfältig auf Syntax und Vollständigkeit und gehe zu spoke-pull-request-Review. Prüfe andernfalls das Anfrageformular. Fang nicht an, bevor es vollständig ist.

Feld Pflicht Beispiel / Hinweis
Name ja Der workload. Ergibt workloadShortName (höchstens 6 Zeichen, später nicht änderbar).
Begründung ja
Umgebung ja dev, tst, acc, prd, shared. Ein spoke pro Umgebung.
Nutzungsart (Produktionsdaten ja oder nein) ja Bestimmt die management group und den tag pii, wenn personenbezogene Daten im Spiel sind.
IP-Bereich ja Zum Beispiel ein /24. Aus dem IP-Plan zugeteilt, nie erfunden.
Subnet-Name, Größe, Delegierungen, service endpoints nein Die Namen der Delegierungen stammen aus der Liste im Schema.
Welches Team braucht Zugriff ja Der Name einer bestehenden Gruppe in Entra ID.

Wenn etwas fehlt oder unklar ist, frage den Antragsteller oder den Owner des Plattform-Designs.

2. Vorbereiten

  1. Prüfe die Voraussetzungen aus Neuer spoke → Bevor du anfängst: Die subscription existiert, die management group existiert in der foundation-Konfiguration, die Team-Gruppen existieren, die Genehmigungen liegen vor, der Adressbereich ist im IP-Plan reserviert.
  2. Erstelle einen Branch von main im Konfigurations-Repository, mit der Ticketnummer im Namen, zum Beispiel change/<ticket-id>-spoke-<workload>.

3. Die spoke-Datei erstellen

  1. Starte von einem Template. Nimm immer das neueste spoke-Template oder einen aktuellen funktionierenden spoke derselben Art und kopiere ihn. Bearbeite nicht das Template selbst.
  2. Benenne die Datei nach der Namenskonvention deiner Plattform und sorge dafür, dass sie über alle Unterordner des Ordners spokes/ hinweg eindeutig ist, zum Beispiel canvas_<workload>_<environment>.json. Manche Plattformen nutzen ein Muster, das auch Produktion oder Nicht-Produktion zeigt. Die Datei muss in einem Unterordner liegen.
  3. Fülle alle Felder mit den Werten der Anfrage: Es dürfen keine Platzhalter übrig bleiben.
    • workloadShortName, environment, azureSubscriptionId, azureSubscriptionName, managementGroupId
    • tags mit owner, department, workload, pii, costcentre und environment
    • adInfo mit den Team-Gruppen und den PIM-Modi
    • targetRegions und die network-Einträge in resourceconfiguration
    • optionale Blöcke (storageaccount, keyvault, loganalytics, azdo) wie vereinbart
  4. Nutze die Platzhalter ##wlshortname##, ##environment## und ##region## in Ressourcennamen, wie in den Beispielen der Referenz.

4. Validieren

  1. Validiere die Datei gegen das spoke-Schema (JSON-Dateien mit Schema-Unterstützung bearbeiten). Behebe jeden Fehler und jede Warnung.
  2. Prüfe den Dateinamen gegen die Namenskonvention.
  3. Gleiche jeden Wert mit der Anfrage und mit den Quellsystemen ab (IP-Plan, subscription, Gruppen).
  4. Prüfe, dass alle Pflichtfelder gefüllt sind und dass die optionalen bewusst behandelt wurden.
  5. Führe die Config tests lokal aus, wenn du kannst (Die Tests lokal ausführen).
  6. Bitte vor dem pull request eine Kollegin oder einen Kollegen um ein Peer Review auf Struktur, Vollständigkeit und Korrektheit.

5. Committen, pushen und den pull request öffnen

  1. Committe mit einer Nachricht, die sagt, welcher spoke und für wen, und pushe den Branch.
  2. Öffne den pull request nach main, mit einem Titel und einer Beschreibung, die sagen, wofür der spoke ist. Verlinke das Ticket.
  3. Die Validierungs-pipeline läuft auf dem pull request. Behebe, was sie meldet, und pushe erneut: Die Prüfungen starten neu.
  4. Wenn die Prüfungen grün sind, bitte einen zweiten Engineer um das Review (spoke-pull-request-Review).

6. Deployen

Deploye den spoke nach Genehmigung und Merge mit der spoke-pipeline: spoke-Deployment. Der spoke ist fertig, wenn der pull request gemergt ist und der pipeline-Lauf beendet und verifiziert wurde.

7. Abschließen

  • Sag dem Antragsteller, was angelegt wurde: den Namen der subscription, den Bereich des virtuellen Netzwerks, die Gruppennamen und wie er die Rolle aktiviert, falls PIM gilt (Wie es weitergeht).
  • Halte komplexe Konfiguration für spätere Referenz fest.
  • Wenn der spoke Managed VMs bekommt, füge seinen Ordner zur Liste der spokes der Modul-pipeline hinzu (Managed-VM-Modul).
  • Firewallregeln für den Datenverkehr des spokes sind separate Änderungen (Firewallregeln).

Erstellung der subscription

Die spoke-pipeline braucht eine bestehende subscription ID. Wie die subscription angelegt wird, hängt vom Prozess der Organisation ab (und auf manchen Plattformen von einer separaten pipeline des Plattform-Teams): siehe Neuer spoke → Bevor du anfängst.