Visão Geral
Este caso de uso gerencia o DNS autoritativo no F5 Distributed Cloud com Terraform. Um plano pequeno e reutilizável cria uma zona DNS primária e seus registros para um domínio delegado, mantém seu estado no Azure Blob Storage e executa plan-on-pull-request / apply-on-merge através do GitHub Actions.
O que é gerenciado
Seção intitulada “O que é gerenciado”- Um
xcsh_dns_zone— uma zona primária autoritativa no namespacesystemdo F5 XC, com registros A. O nome da zona é o domínio delegado (uma variável), portanto redirecionar o alvo é uma mudança de configuração, não uma mudança de código. - Estado remoto do Terraform no Azure, para que as execuções sejam compartilháveis entre a máquina de um operador e o CI.
Arquitetura
Seção intitulada “Arquitetura”| Camada | Escolha | Por quê |
|---|---|---|
| Provedor | f5-sales-demo/xcsh (registro Terraform) | Gerado a partir da OpenAPI do F5 XC; gerencia xcsh_dns_zone e os recursos de balanceador de carga DNS. Autentica com um token de API (Authorization: APIToken <token>). |
| Backend de estado | azurerm (Azure Blob Storage), autenticação por chave de acesso | Estado durável e compartilhado. A autenticação por chave de acesso é utilizada porque a assinatura concede apenas a função Contributor, que não pode atribuir a função Storage Blob Data Contributor exigida pela autenticação sem chave (OIDC / Azure AD). |
| Automação | GitHub Actions | Plan em todo pull request, apply ao fazer merge para main. As coordenadas do backend e as entradas vêm das variáveis do repositório; as credenciais vêm dos secrets. |
Por onde começar
Seção intitulada “Por onde começar”O arco Demo percorre todo o ciclo de vida de ponta a ponta: Build da zona com Terraform, Validate para verificar a resolução, Failover com um balanceador de carga DNS e Teardown. Comece pela Fase 1 — Build, que é um guia completo para implantação da zona, incluindo todos os arquivos Terraform, o fluxo de trabalho de CI e as variáveis e secrets necessários.