अवलोकन

यह उपयोग मामला Terraform के साथ F5 Distributed Cloud पर आधिकारिक DNS का प्रबंधन करता है। एक छोटी, पुनः उपयोग योग्य योजना एक प्राथमिक DNS ज़ोन और उसके रिकॉर्ड को एक डेलीगेटेड डोमेन के लिए बनाती है, इसकी state को Azure Blob Storage में रखती है, और GitHub Actions के माध्यम से pull-request पर plan / merge पर apply चलाती है।

यह क्या प्रबंधित करता है

• एक xcsh_dns_zone — F5 XC system नामस्थान में एक आधिकारिक प्राथमिक ज़ोन, A रिकॉर्ड के साथ। ज़ोन नाम डेलीगेटेड डोमेन (एक वेरिएबल) है, इसलिए पुनः लक्ष्यीकरण एक कॉन्फ़िगरेशन परिवर्तन है, न कि कोड परिवर्तन।
• Azure में Remote Terraform state, ताकि runs एक ऑपरेटर की मशीन और CI के बीच साझा करने योग्य हों।

आर्किटेक्चर

परत	विकल्प	कारण
Provider	f5-sales-demo/xcsh (Terraform रजिस्ट्री)	F5 XC OpenAPI से जनरेट किया गया; xcsh_dns_zone और DNS लोड-बैलेंसर संसाधनों का प्रबंधन करता है। एक API टोकन (Authorization: APIToken <token>) से प्रमाणीकरण करता है।
State backend	azurerm (Azure Blob Storage), access-key auth	टिकाऊ, साझा state। Access-key auth का उपयोग किया जाता है क्योंकि subscription केवल Contributor प्रदान करता है, जो Storage Blob Data Contributor भूमिका नहीं सौंप सकता जिसकी keyless (OIDC / Azure AD) auth को आवश्यकता होती है।
स्वचालन	GitHub Actions	हर pull request पर Plan, main में merge पर apply। Backend coordinates और inputs रिपॉजिटरी variables से आते हैं; क्रेडेंशियल secrets से।

टिप्पणी

सभी F5 XC DNS ऑब्जेक्ट system नामस्थान में होने चाहिए — API अन्य नामस्थानों को अस्वीकार करता है। योजना namespace को एक input के रूप में उजागर नहीं करती: provider इसे API spec के namespace constraint से system पर निर्धारित करता है, इसलिए इसे पूरी तरह से छोड़ दिया गया है।

कहाँ से शुरू करें

Demo arc पूर्ण जीवनचक्र को end-to-end देखता है: Terraform के साथ ज़ोन Build करें, Validate करें कि यह resolve होता है, DNS लोड बैलेंसर के साथ Failover करें, और Teardown करें। Phase 1 — Build से शुरू करें, जो ज़ोन को deploy करने के लिए एक संपूर्ण how-to है, जिसमें प्रत्येक Terraform फ़ाइल, CI workflow, और आवश्यक variables और secrets शामिल हैं।