Pages सक्षमीकरण रनबुक

यह रनबुक apothem.ahmedgad.com को एक नई GitHub Pages कॉन्फ़िगरेशन से एक 200 OK HTTPS लैंडिंग पेज तक चलाता है। यह प्रक्रिया उस ऑपरेटर के लिए लिखी गई है जो gh और एक DNS-प्रदाता कंसोल का उपयोग करता है; एक सक्षम नया योगदानकर्ता बिना पूर्व संदर्भ के इसका अनुसरण करता है।

रनबुक को एक प्रदाता-अज्ञेय कोर (GitHub-पक्ष और DNS-रिकॉर्ड चरण जो हर प्रदाता साझा करता है) के रूप में संरचित किया गया है, जिसके बाद Namecheap, Cloudflare, Route53 के लिए प्रदाता-विशिष्ट परिशिष्ट और एक सामान्य-DNS विकल्प आते हैं। कोर को क्रम में चलाएँ; एपेक्स डोमेन रजिस्ट्रार / DNS होस्ट से मेल खाने वाले परिशिष्ट पर जाएँ; सत्यापन के लिए कोर पर लौटें।

साइट को सार्वजनिक ahmed-g-gad/apothem रिपॉज़िटरी से GitHub Pages के माध्यम से होस्ट किया जाता है, जिसमें कस्टम-डोमेन CNAME ahmed-g-gad.github.io की ओर इंगित करता है। स्थैतिक-साइट बिल्ड site/dist/ में उत्सर्जित होता है; Pages वर्कफ़्लो उस बिल्ड आर्टिफ़ैक्ट को main पर हर पुश पर लाइव साइट पर उठाता है।

1. पूर्वापेक्षाएँ

ऑपरेटर आगे बढ़ने से पहले निम्नलिखित की पुष्टि करता है:

• रिपॉज़िटरी स्थिति। ahmed-g-gad/apothem सार्वजनिक है, इसमें Pages सक्षम है (Settings > Pages > Source: GitHub Actions), और publish-static-site.yml वर्कफ़्लो .github/workflows/publish-static-site.yml पर मौजूद है।
• DNS प्राधिकार। ऑपरेटर रजिस्ट्रार पर या किसी प्रत्यायोजित DNS होस्ट (Cloudflare, Route53, आदि) पर ahmedgad.com के लिए DNS को नियंत्रित करता है। DNS होस्ट की पहचान dig NS ahmedgad.com +short के माध्यम से की जाती है।
• उपकरण। gh (GitHub CLI) संस्करण 2.40 या नवीनतर, ahmed-g-gad खाते के विरुद्ध प्रमाणित; DNS सत्यापन के लिए dig (BIND dig या drill); HTTPS निरीक्षण के लिए एक ब्राउज़र।
• एपेक्स रुख। यह रनबुक केवल सबडोमेन apothem.ahmedgad.com को कॉन्फ़िगर करता है। एपेक्स ahmedgad.com अछूता रहता है। एपेक्स पर CNAME के लिए CNAME-फ़्लैटनिंग (Cloudflare) या ALIAS रिकॉर्ड (Route53) की आवश्यकता होती है; सबडोमेन पथ दोनों वर्गों की जटिलता से बचता है।

2. प्रदाता-अज्ञेय कोर

2.1 कस्टम डोमेन को Pages में जोड़ें

gh api -X PUT \
  /repos/ahmed-g-gad/apothem/pages \
  -F cname=apothem.ahmedgad.com \
  -F https_enforced=true

सत्यापित करें कि कॉल ने नया CNAME रिकॉर्ड लौटाया:

gh api /repos/ahmed-g-gad/apothem/pages \
  --jq '.cname, .https_enforced, .status'

अपेक्षित आउटपुट:

apothem.ahmedgad.com
true
built

built स्थिति पुष्टि करती है कि सबसे हालिया Pages बिल्ड सफल रहा। null स्थिति का अर्थ है कि CNAME लागू होने के बाद से Pages नहीं चला — बिल्ड को ट्रिगर करने के लिए main पर एक नो-ऑप कमिट पुश करें।

2.2 CNAME फ़ाइल की पुष्टि करें

GitHub Pages हर डिप्लॉय पर स्थैतिक-साइट बिल्ड आर्टिफ़ैक्ट के माध्यम से site/public/CNAME प्राप्त करता है। फ़ाइल में कस्टम डोमेन एक ही पंक्ति में होता है, बिना स्कीम, बिना ट्रेलिंग स्लैश:

apothem.ahmedgad.com

फ़ाइल site/public/CNAME पर रहती है। सत्यापित करें:

cat site/public/CNAME

यदि फ़ाइल गायब है, तो इसे site/public/CNAME पर पुनः बनाएँ और chore: restore Pages CNAME के तहत कमिट करें।

2.3 DNS रिकॉर्ड जोड़ें

Pages कस्टम डोमेन की सेवा तब करता है जब एपेक्स DNS प्रदाता GitHub के चार IP पतों में से एक (एपेक्स डोमेन के लिए) या <owner>.github.io की ओर इंगित करने वाला CNAME (सबडोमेन के लिए) लौटाता है। apothem.ahmedgad.com के लिए रिकॉर्ड वर्ग CNAME है:

रिकॉर्ड जोड़ने के लिए सटीक UI प्रवाह प्रति प्रदाता भिन्न होता है; नीचे मेल खाने वाले परिशिष्ट पर जाएँ, रिकॉर्ड सहेजे जाने पर यहाँ लौटें।

2.4 DNS प्रसार की प्रतीक्षा करें

कम-TTL रिकॉर्ड के लिए प्रसार पाँच मिनट के भीतर और डिफ़ॉल्ट 3600-सेकंड TTL के लिए एक घंटे के भीतर पूरा होता है — DNS-ज़ोन ट्रांसफ़र के दौरान प्रदाता एज इस विंडो को बढ़ा सकते हैं। प्रगति को ट्रैक करें:

dig apothem.ahmedgad.com CNAME +short

अपेक्षित आउटपुट:

ahmed-g-gad.github.io.

खाली आउटपुट का अर्थ है कि रिकॉर्ड अभी तक प्रसारित नहीं हुआ है। हर 30 सेकंड पर पुनः चलाएँ। यदि 30 मिनट के बाद भी रिकॉर्ड कभी प्रकट नहीं होता, तो DNS होस्ट से मेल खाने वाले परिशिष्ट पर लौटें और सत्यापित करें कि रिकॉर्ड प्रदाता पर कमिट है, ड्राफ़्ट स्थिति में लंबित नहीं है।

2.5 HTTPS सत्यापित करें

curl -sSI https://apothem.ahmedgad.com/ | head -5

अपेक्षित आउटपुट:

HTTP/2 200
server: GitHub.com
content-type: text/html; charset=utf-8
strict-transport-security: max-age=31536000

HTTP/2 200 और server: GitHub.com पंक्तियाँ एक साथ पुष्टि करती हैं कि Pages एक मान्य TLS प्रमाणपत्र के तहत साइट की सेवा कर रहा है। सादे-HTTP अनुरोध पर HTTPS URL की ओर एक 301 भी गेट को संतुष्ट करता है; HTTPS-प्रवर्तित चालू है।

यदि curl एक 526 (Cloudflare-विशिष्ट अमान्य-प्रमाणपत्र कोड) या 502 (बैड गेटवे) लौटाता है, तो प्रमाणपत्र अभी जारी नहीं हुआ है। CNAME के हल हो जाने पर Pages स्वचालित रूप से Let's Encrypt प्रमाणपत्र प्रावधानित करता है; पहली बार जारी करने के लिए 24 घंटे तक का समय दें। निदान के लिए:

gh api /repos/ahmed-g-gad/apothem/pages \
  --jq '.https_certificate.state, .https_certificate.description'

state: approved का अर्थ है कि जारी करना पूर्ण है। state: requesting का अर्थ है कि जारी करना प्रगति पर है; प्रतीक्षा करें। कोई भी अन्य स्थिति Pages रीस्टार्ट की माँग करती है (API के माध्यम से कस्टम डोमेन को बंद और चालू करें)।

2.6 डीप लिंक सत्यापित करें

curl -sSI https://apothem.ahmedgad.com/architecture/ | head -3

अपेक्षित आउटपुट:

HTTP/2 200
server: GitHub.com
content-type: text/html; charset=utf-8

डीप लिंक पर एक 404 का अर्थ है कि स्थैतिक-साइट बिल्ड ने पेज को नहीं उठाया है या डिप्लॉय पूरा नहीं हुआ है। gh workflow run publish-static-site.yml के माध्यम से एक रीबिल्ड ट्रिगर करें।

2.7 सत्यापन रिकॉर्ड करें

ऑपरेटर के साइट-स्थिति लॉग (या इस रनबुक के सत्यापन लॉग में, यदि इनलाइन रखरखाव किया जाता है) में तिथि, ऑपरेटर की पहचान, और gh api Pages-स्थिति आउटपुट के साथ एक पंक्ति जोड़ें। सत्यापन लॉग ऑडिट ट्रेल है — हर Pages-कॉन्फ़िग परिवर्तन एक पंक्ति छोड़ता है।

3. प्रदाता परिशिष्ट — Namecheap

Namecheap रजिस्ट्रार के "Advanced DNS" टैब के माध्यम से DNS को उजागर करता है। ऑपरेटर यहाँ ahmedgad.com का स्वामी होता है जब रजिस्ट्रार के NS रिकॉर्ड dns1.registrar-servers.com और dns2.registrar-servers.com (Namecheap डिफ़ॉल्ट) से मेल खाते हैं। dig NS ahmedgad.com +short से सत्यापित करें।

चरण:

1. Namecheap में साइन इन करें; डैशबोर्ड खोलें।
2. बाएँ नेविगेशन में Domain List पर क्लिक करें; ahmedgad.com खोजें; Manage पर क्लिक करें।
3. Advanced DNS टैब पर क्लिक करें।
4. Add New Record पर क्लिक करें। चुनें:
   • Type: CNAME Record
   • Host: apothem (कोई एपेक्स नहीं, कोई ट्रेलिंग डॉट नहीं)
   • Value: ahmed-g-gad.github.io. (ट्रेलिंग डॉट के साथ)
   • TTL: Automatic (Namecheap डिफ़ॉल्ट; 1800 सेकंड का सम्मान करता है)
5. सहेजने के लिए हरे चेकमार्क पर क्लिक करें।
6. Namecheap के एज प्रसार के लिए 5 से 10 मिनट प्रतीक्षा करें; फिर dig सत्यापन के लिए प्रदाता-अज्ञेय कोर §2.4 पर लौटें।

सामान्य विफलता: Namecheap का UI CNAME रिकॉर्ड को चुपचाप अस्वीकार करता है जब एक A रिकॉर्ड पहले से उसी होस्ट पर मौजूद हो। पहले विरोधी A रिकॉर्ड हटाएँ; RFC 1034 के अनुसार उसी होस्ट पर CNAME और A परस्पर अनन्य हैं।

4. प्रदाता परिशिष्ट — Cloudflare

Cloudflare DNS एपेक्स को तब होस्ट करता है जब रजिस्ट्रार के NS रिकॉर्ड *.ns.cloudflare.com (प्रत्यायोजन के बाद Cloudflare डिफ़ॉल्ट) की ओर इंगित करते हैं। dig NS ahmedgad.com +short से सत्यापित करें।

चरण:

1. Cloudflare में साइन इन करें; ahmedgad.com ज़ोन चुनें।
2. बाएँ नेविगेशन में DNS -> Records पर क्लिक करें।
3. Add record पर क्लिक करें। चुनें:
   • Type: CNAME
   • Name: apothem (Cloudflare स्वतः एपेक्स जोड़ता है)
   • Target: ahmed-g-gad.github.io (Cloudflare के UI में कोई ट्रेलिंग डॉट नहीं)
   • TTL: Auto (Cloudflare का डिफ़ॉल्ट; इसके एज के माध्यम से रूट करता है)
   • Proxy status: DNS only (ग्रे बादल, नारंगी नहीं)
4. Save पर क्लिक करें।

प्रॉक्सी-स्थिति का चुनाव भारवहन करता है। Cloudflare का प्रॉक्सी चालू करना (नारंगी बादल) GitHub Pages तक पहुँचने से पहले ट्रैफ़िक को Cloudflare के एज के माध्यम से रूट करता है; यह Pages के Let's Encrypt जारी करने को तोड़ देता है क्योंकि Cloudflare अपना स्वयं का प्रमाणपत्र प्रस्तुत करता है। प्रारंभिक सेटअप के लिए प्रॉक्सी बंद रखें; बाद में प्रॉक्सी चालू करें केवल यह तय करने के बाद कि प्रमाणपत्र को Cloudflare के एज पर प्रबंधित करना है या नहीं।

5. Cloudflare के एज प्रसार के लिए 1 से 2 मिनट प्रतीक्षा करें; फिर प्रदाता-अज्ञेय कोर §2.4 पर लौटें।

सामान्य विफलता: Cloudflare CNAME लक्ष्यों से ट्रेलिंग डॉट को चुपचाप हटा देता है। लक्ष्य फ़ील्ड ahmed-g-gad.github.io को ट्रेलिंग डॉट के बिना स्वीकार करता है; रिज़ॉल्वर क्वेरी समय पर ट्रेलिंग डॉट जोड़ता है। Cloudflare के UI में ट्रेलिंग डॉट न टाइप करें — यह एक डबल-डॉट रिकॉर्ड उत्पन्न करता है जो हल होने में विफल रहता है।

5. प्रदाता परिशिष्ट — Route53

Route53 ज़ोन को तब होस्ट करता है जब रजिस्ट्रार के NS रिकॉर्ड चार awsdns-*.com / awsdns-*.org / awsdns-*.co.uk / awsdns-*.net सर्वरों की ओर इंगित करते हैं। dig NS ahmedgad.com +short से सत्यापित करें।

चरण:

1. AWS Console खोलें; Route53 पर नेविगेट करें; Hosted zones पर क्लिक करें; ahmedgad.com ज़ोन चुनें।
2. Create record पर क्लिक करें।
3. कॉन्फ़िगर करें:
   • Record name: apothem (Route53 स्वतः एपेक्स जोड़ता है)
   • Record type: CNAME
   • Value: ahmed-g-gad.github.io (कोई ट्रेलिंग डॉट नहीं)
   • TTL: 300 (5 मिनट; Route53 के डिफ़ॉल्ट अधिक हैं; कटओवर के दौरान तेज़ प्रसार के लिए TTL कम करें)
   • Routing policy: Simple routing
4. Create records पर क्लिक करें।
5. Route53 प्रसार के लिए 1 से 5 मिनट प्रतीक्षा करें; §2.4 पर लौटें।

Route53 एलियास रिकॉर्ड का समर्थन करता है जो CNAME अप्रत्यक्षता के बिना क्वेरी समय पर हल होते हैं। एलियास रिकॉर्ड का उपयोग यहाँ नहीं किया जाता क्योंकि एलियास लक्ष्य AWS संसाधनों (CloudFront, S3, ELB, आदि) तक सीमित हैं और ahmed-g-gad.github.io एक AWS संसाधन नहीं है। CNAME सही है।

सामान्य विफलता: Route53 का UI विभिन्न रूटिंग नीतियों के साथ डुप्लिकेट रिकॉर्ड नामों को स्वीकार करता है; यह एक सरल CNAME के बजाय एक हेल्थचेक-शैली फ़ेलओवर रूटिंग के रूप में सामने आता है। सहेजने से पहले पुष्टि करें कि Routing policy Simple routing पढ़ता है।

6. प्रदाता परिशिष्ट — सामान्य DNS

नामित परिशिष्टों द्वारा कवर न किए गए DNS होस्ट (अधिकांश रजिस्ट्रारों के डिफ़ॉल्ट DNS पैनल — GoDaddy, Hover, Gandi, OVH, Porkbun, Domains.google, Network Solutions) के लिए, प्रदाता-अज्ञेय CNAME आकार लागू करें:

दो विफलता वर्ग जो सामान्य पैनलों में बार-बार आते हैं:

• ट्रेलिंग-डॉट असंगति। कुछ पैनल ट्रेलिंग डॉट की माँग करते हैं; अन्य इसे अस्वीकार करते हैं; कुछ किसी को भी स्वीकार करते हैं। जब रिकॉर्ड 30 मिनट के बाद प्रसारित होने में विफल रहता है, तो ट्रेलिंग डॉट को टॉगल करें और पुनः सहेजें।
• उसी होस्ट पर विरोधी A रिकॉर्ड। उसी होस्ट पर CNAME और A, RFC 1034 (Domain Names — Concepts and Facilities) के डोमेन-नाम वरीयताओं पर तीसरे खंड का उल्लंघन करते हैं। CNAME जोड़ने से पहले विरोधी A रिकॉर्ड हटाएँ।

रिकॉर्ड सहेजे जाने के बाद, dig सत्यापन के लिए §2.4 पर लौटें।

7. विफलता पुनर्प्राप्ति

Pages-सक्षमीकरण प्रक्रिया में चार प्रलेखित विफलता मोड हैं:

यदि मेल खाने वाले निदान के एक चक्र के बाद पुनर्प्राप्ति विफल रहती है, तो रिलीज़-पुनर्प्राप्ति रनबुक तक एस्केलेट करें (नए इतिहास के फ़ोर्स-पुश ने Pages कॉन्फ़िग को असंगत स्थिति में छोड़ दिया हो सकता है)।

8. क्रॉस-रेफ़रेंस

• स्पेक स्रोत। स्पेसिफ़िकेशन §2.5 इस रनबुक को Cluster 4 दस्तावेज़ीकरण डिलिवरेबल में सूचीबद्ध करता है।
• CNAME विहित स्थान। CNAME फ़ाइल site/public/CNAME पर रहती है और रिपॉज़िटरी में कमिट की जाती है; Pages इसे हर बिल्ड पर पढ़ता है।
• पुनर्प्राप्ति प्रवाह। रिलीज़-पुनर्प्राप्ति रनबुक तब पुनर्प्राप्ति स्नैपशॉट से Pages कॉन्फ़िगरेशन को पुनः लागू करता है जब कटओवर अनुक्रम बीच-उड़ान में विफल हो जाता है।
• रिलीज़ चक्र। हर रिलीज़ रन में एक Pages-बिल्ड जॉब शामिल होता है जो सत्यापित करता है कि साइट कस्टम डोमेन पर रेंडर होती है।