Panoramica
Questo caso d’uso gestisce il DNS autorevole su F5 Distributed Cloud con Terraform. Un piano piccolo e riutilizzabile crea una zona DNS primaria e i relativi record per un dominio delegato, mantiene il proprio stato in Azure Blob Storage ed esegue plan-on-pull-request / apply-on-merge tramite GitHub Actions.
Cosa gestisce
Sezione intitolata “Cosa gestisce”- Una
xcsh_dns_zone— una zona primaria autorevole nel namespacesystemdi F5 XC, con record A. Il nome della zona corrisponde al dominio delegato (una variabile), quindi il reindirizzamento è una modifica di configurazione, non una modifica al codice. - Stato Terraform remoto in Azure, in modo che le esecuzioni siano condivisibili tra la macchina dell’operatore e la CI.
Architettura
Sezione intitolata “Architettura”| Livello | Scelta | Perché |
|---|---|---|
| Provider | f5-sales-demo/xcsh (registro Terraform) | Generato dall’OpenAPI di F5 XC; gestisce xcsh_dns_zone e le risorse del load balancer DNS. Esegue l’autenticazione con un token API (Authorization: APIToken <token>). |
| Backend dello stato | azurerm (Azure Blob Storage), autenticazione tramite chiave di accesso | Stato durevole e condiviso. L’autenticazione tramite chiave di accesso è utilizzata perché la sottoscrizione concede solo il ruolo Contributor, che non può assegnare il ruolo Storage Blob Data Contributor richiesto dall’autenticazione senza chiave (OIDC / Azure AD). |
| Automazione | GitHub Actions | Plan su ogni pull request, apply al merge su main. Le coordinate del backend e gli input provengono dalle variabili del repository; le credenziali dai segreti. |
Da dove iniziare
Sezione intitolata “Da dove iniziare”Il percorso Demo illustra l’intero ciclo di vita end-to-end: Build della zona con Terraform, Validate che si risolva correttamente, Failover con un load balancer DNS e Teardown. Iniziare con Fase 1 — Build, che è una guida completa per il deployment della zona, inclusi tutti i file Terraform, il workflow CI e le variabili e i segreti richiesti.