Aller au contenu

Présentation

Ce cas d’usage gère le DNS faisant autorité sur F5 Distributed Cloud avec Terraform. Un plan réutilisable et compact crée une zone DNS primaire et ses enregistrements pour un domaine délégué, conserve son état dans Azure Blob Storage, et exécute plan-on-pull-request / apply-on-merge via GitHub Actions.

  • Un xcsh_dns_zone — une zone primaire faisant autorité dans le namespace system de F5 XC, avec des enregistrements A. Le nom de zone est le domaine délégué (une variable), de sorte que le reciblage est un changement de configuration, non un changement de code.
  • L’état Terraform distant dans Azure, afin que les exécutions soient partageables entre la machine d’un opérateur et l’intégration continue.
CoucheChoixPourquoi
Fournisseurf5-sales-demo/xcsh (registre Terraform)Généré à partir de l’OpenAPI F5 XC ; gère xcsh_dns_zone et les ressources d’équilibrage de charge DNS. S’authentifie avec un jeton API (Authorization: APIToken <token>).
Backend d’étatazurerm (Azure Blob Storage), authentification par clé d’accèsÉtat durable et partagé. L’authentification par clé d’accès est utilisée car l’abonnement n’accorde que le rôle Contributor, qui ne peut pas attribuer le rôle Storage Blob Data Contributor requis par l’authentification sans clé (OIDC / Azure AD).
AutomatisationGitHub ActionsPlan à chaque pull request, apply à la fusion vers main. Les coordonnées du backend et les entrées proviennent des variables du dépôt ; les informations d’identification proviennent des secrets.

Le parcours Démo couvre l’intégralité du cycle de vie de bout en bout : Construction de la zone avec Terraform, Validation de sa résolution, Basculement avec un équilibreur de charge DNS, et Démontage. Commencez par Phase 1 — Construction, qui est un guide complet pour déployer la zone, incluant chaque fichier Terraform, le workflow CI, ainsi que les variables et secrets requis.