Zum Inhalt springen

Übersicht

Dieser Anwendungsfall verwaltet autoritatives DNS auf F5 Distributed Cloud mit Terraform. Ein kleiner, wiederverwendbarer Plan erstellt eine primäre DNS-Zone und deren Einträge für eine delegierte Domain, speichert den Status in Azure Blob Storage und führt Plan-bei-Pull-Request / Apply-bei-Merge über GitHub Actions aus.

  • Eine xcsh_dns_zone — eine autoritative primäre Zone im F5 XC-Namespace system, mit A-Einträgen. Der Zonenname ist die delegierte Domain (eine Variable), sodass eine Neuausrichtung eine Konfigurationsänderung und keine Codeänderung ist.
  • Remote-Terraform-Status in Azure, sodass Ausführungen zwischen dem Rechner eines Operators und CI geteilt werden können.
EbeneAuswahlWarum
Providerf5-sales-demo/xcsh (Terraform-Registry)Aus der F5 XC OpenAPI generiert; verwaltet xcsh_dns_zone und die DNS-Load-Balancer-Ressourcen. Authentifiziert sich mit einem API-Token (Authorization: APIToken <token>).
Status-Backendazurerm (Azure Blob Storage), Access-Key-AuthentifizierungDauerhafter, gemeinsam genutzter Status. Access-Key-Authentifizierung wird verwendet, da das Abonnement nur Contributor-Rechte gewährt, die nicht die Rolle Storage Blob Data Contributor zuweisen können, die die schlüssellose (OIDC / Azure AD) Authentifizierung benötigt.
AutomatisierungGitHub ActionsPlan bei jedem Pull Request, Apply bei Merge in main. Backend-Koordinaten und Eingaben stammen aus Repository-Variablen; Anmeldeinformationen aus Secrets.

Der Demo-Bereich führt durch den vollständigen Lebenszyklus von Anfang bis Ende: Aufbauen der Zone mit Terraform, Validieren, dass sie aufgelöst wird, Failover mit einem DNS-Load-Balancer und Teardown. Beginnen Sie mit Phase 1 — Aufbauen, einem vollständigen Leitfaden zur Bereitstellung der Zone, einschließlich aller Terraform-Dateien, des CI-Workflows sowie der erforderlichen Variablen und Secrets.