Zum Inhalt

Firewallregel-Deployment

Operator-Runbook für das Deployment einer genehmigten und gemergten Änderung an Firewallregeln oder IP groups. Beide liegen im firewall layer. Lies es zusammen mit Firewallregeln und Pipelines und Workflows.

1. Bevor du beginnst

  • Der pull request ist genehmigt und in main gemergt.
  • Du hast Zugriff auf die pipelines der richtigen Plattform und auf das Ticket.

2. Die pipeline für canary ausführen

  1. Öffne die pipelines des Projekts und wähle die hub-pipeline (hub).
  2. Führe sie von main aus. Wo deine Entry-pipeline eine Auswahl erlaubt, wähle:
    • Umgebung: canary;
    • layer: firewall;
    • Region: die Region der Änderung (zum Beispiel weu) oder jede Region, die die Änderung berührt.
  3. Lies den plan. Nur der firewall layer darf Änderungen zeigen, und nur für die Gruppen, die du angefasst hast (Den plan prüfen).
  4. Genehmige ihn, wenn er passt, und verfolge den Lauf bis zum Ende.

Wie viel du zur Laufzeit wählen kannst, hängt von der Entry-pipeline deiner Plattform ab: Manche legen Umgebung, layer und Modus in der Entry-Datei fest (Parameter, die du ändern wirst).

Bei einem Time-out anhalten

Eine Änderung mit vielen rule collection groups kann in das Apply-Time-out laufen, weil Azure keine parallelen Updates derselben Policy akzeptiert. Wenn canary bereits Time-outs zeigt, mache nicht mit der Produktion weiter. Teile die Änderung in kleinere pull requests auf. Siehe Wenn eine große Änderung ins Time-out läuft.

3. Das Apply prüfen

Nachdem die Apply-Stage grün ist:

  1. Öffne das Log des Apply-Schritts.
  2. Prüfe, dass die gewünschte Änderung ausgeführt wurde: Die rule collection group, die collection oder die IP group erscheint als hinzugefügt oder geändert.
  3. Verlasse dich nicht nur auf die grüne Stage. Wenn die Änderung nicht in der Apply-Ausgabe steht, schließe das Ticket nicht. Untersuche es und frage bei Bedarf einen zweiten Engineer.
  4. Prüfe im Portal, dass die Regel vorhanden ist, und teste den Traffic, wenn der Anfragende helfen kann (Prüfen).

4. Die pipeline für prod ausführen

Wiederhole Schritt 2 für prod. Der Produktions-plan wartet auf die Genehmigung eines zweiten Engineers. Prüfe den plan noch einmal. Verfolge dann den Lauf und prüfe das Apply wie in Schritt 3.

5. Das Ticket schließen

  1. Öffne das Ticket der Anfrage. Der pull request verlinkt darauf.
  2. Füge der Diskussion eine Zeile hinzu, die sagt, dass die Änderung deployt ist, in welchen Umgebungen und was der Anfragende testen kann.
  3. Weise das Ticket dem Anfragenden zu und setze es auf Resolved. Der Anfragende validiert es und setzt es auf Done (Der Standardänderungsprozess).

Wenn etwas schiefgeht

  • Ein pipeline-Fehler: Lies das Log, behebe die Ursache mit einem neuen pull request und führe erneut aus. Eine Regel, die in der Produktion falsch ist, wird mit einem pull request zurückgenommen (Rollback).
  • Already exists nach einem Time-out: Importiere die vorhandene Gruppe in den state. Zerstöre sie nicht in der Produktion (Häufige Probleme).