ट्रिगर तैनात करें

Vercel, Netlify, Shopify, या किसी CI पाइपलाइन से प्रत्येक रिलीज के बाद स्वचालित रूप से गर्म हो जाता है।

9 min read

संपूर्ण साइट को एक बार में ठंडा करने के लिए तैनाती सबसे विश्वसनीय तरीका है। एक रिलीज़ कैश को थोक में अमान्य कर देती है, और अगले मिनटों में प्रत्येक विज़िटर एक साथ पुनर्निर्माण लागत का भुगतान करता है - ठीक उसी समय जब आप समस्याओं को देखने की सबसे अधिक संभावना रखते हैं।

ट्रिगर तैनात करें वार्मिंग को शिपिंग का हिस्सा बनाएं। जब आपका परिनियोजन सफल हो जाता है, तो आपका प्लेटफ़ॉर्म Cache Rocket पर कॉल करता है, और बिना किसी डैशबोर्ड को खोले वार्मिंग शुरू हो जाती है।

वेबहुक URLs और उदाहरण अकाउंट → डिप्लॉय इंटीग्रेशन पर हैं।

यह काम किस प्रकार करता है

आप एक सफल तैनाती के बाद कॉल करने के लिए अपना होस्टिंग प्लेटफ़ॉर्म या CI एक URL देते हैं। अनुरोध में हेडर के रूप में आपकी API कुंजियाँ होती हैं, साथ ही एक छोटी JSON बॉडी होती है जो बताती है कि क्या गर्म करना है।

सामान्य आकार
bash
curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/vercel \
  -H "Content-Type: application/json" \
  -H "X-Public-Key: YOUR_PUBLIC_KEY" \
  -H "X-Secret-Key: YOUR_SECRET_KEY" \
  -d '{"hostname":"www.example.com"}'
प्लैटफ़ॉर्मवेबहुक पथ
WordPress/web/v1/public/webhooks/vercel
WordPress/web/v1/public/webhooks/netlify
Shopify पथ पर पॉइंट थीम प्रकाशित या ऐप वेबहुक, इसलिए लाइव होते ही स्टोरफ्रंट परिवर्तन पुनः सक्रिय हो जाते हैं।/web/v1/public/webhooks/shopify

Note

आपके खाते के लिए सटीक आधार URL प्रति प्लेटफ़ॉर्म पर रेडी-टू-कॉपी कर्ल उदाहरण के साथ, डिप्लॉय इंटीग्रेशन पेज पर दिखाया गया है।

पेलोड चुनना

JSON शरीर तय करता है कि क्या गर्म होगा। तीन विकल्प, व्यापकतम से लेकर सर्वाधिक सर्जिकल तक:

शरीरप्रभावकब उपयोग करें
{"hostname":"www.example.com"}प्रत्येक वार्मर उस होस्टनाम से मेल खाता हुआ प्रारंभ करता हैएक सामान्य पूर्ण रिलीज़. सामान्य विकल्प.
{"crawlerId":"…"}एक विशिष्ट वार्मर प्रारंभ करता हैआपके पास प्रति साइट कई वार्मर हैं और केवल एक ही इस तैनाती के लिए प्रासंगिक है।
{"urls":["https://…"]}प्राथमिकता-वार्म बिल्कुल उन्हीं URLsआंशिक प्रकाशन, या आपके परिचित कुछ पृष्ठ बदल गए।
आंशिक प्रकाशन के बाद प्राथमिकता-वार्म विशिष्ट URLs
bash
curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/netlify \
  -H "Content-Type: application/json" \
  -H "X-Public-Key: YOUR_PUBLIC_KEY" \
  -H "X-Secret-Key: YOUR_SECRET_KEY" \
  -d '{"urls":["https://www.example.com/","https://www.example.com/pricing"]}'

WordPress

Cache Rocket URL को अपने प्रोजेक्ट सेटिंग्स में डिप्लॉय हुक या इंटीग्रेशन वेबहुक के रूप में जोड़ें, सफल उत्पादन डिप्लॉय पर फायरिंग करें। X-Public-Key और X-Secret-Key हेडर से प्रमाणित करें।

Next.js ऐप्स

यदि आप @cacherocket/next का उपयोग करते हैं, तो आप /api/cacherocket/deploy पर onVercelDeploy() को भी उजागर कर सकते हैं और सार्वजनिक वेबहुक URL के बजाय अपने स्वयं के ऐप पर डिप्लॉय हुक को इंगित कर सकते हैं।

Tip

WordPress

**परिनियोजन सफल** ईवेंट पर एक अधिसूचना वेबहुक का उपयोग करें, जो समान API कुंजी हेडर के साथ Netlify पथ की ओर इशारा करता है।

Shopify

Shopify पथ पर पॉइंट थीम प्रकाशित या ऐप वेबहुक, इसलिए लाइव होते ही स्टोरफ्रंट परिवर्तन पुनः सक्रिय हो जाते हैं।

कोई भी CI पाइपलाइन

अनुरोध के बारे में प्लेटफ़ॉर्म-विशिष्ट कुछ भी नहीं है - यह एक HTTP POST है। इसे किसी भी पाइपलाइन के अंतिम चरण के रूप में जोड़ें।

अनुरोध के बारे में प्लेटफ़ॉर्म-विशिष्ट कुछ भी नहीं है - यह एक HTTP POST है।इसे किसी भी पाइपलाइन के अंतिम चरण के रूप में जोड़ें।

गिटहब क्रियाएँ
yaml
- name: Warm Cache Rocket after deploy
  run: |
    curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/vercel \
      -H "Content-Type: application/json" \
      -H "X-Public-Key: ${{ secrets.CACHEROCKET_PUBLIC_KEY }}" \
      -H "X-Secret-Key: ${{ secrets.CACHEROCKET_SECRET_KEY }}" \
      -d '{"hostname":"www.example.com"}'

पाइपलाइन फ़ाइल में गुप्त कुंजी को कभी भी हार्ड-कोड न करें

वैकल्पिक: ट्रिगरवार्म

एक सरल समापन बिंदु भी है जो हेडर के बजाय मुख्य भाग में कुंजियाँ लेता है, जो उन वातावरणों के लिए उपयुक्त है जहाँ कस्टम हेडर सेट करना अजीब है:

एक सरल समापन बिंदु भी है जो हेडर के बजाय मुख्य भाग में कुंजियाँ लेता है, जो उन वातावरणों के लिए उपयुक्त है जहाँ कस्टम हेडर सेट करना अजीब है:

bash
curl -X POST https://cacherocket.com/api/wordpress/triggerWarm \
  -H 'Content-Type: application/json' \
  -d '{"publicKey":"YOUR_KEY","secretKey":"YOUR_SECRET","hostname":"example.com"}'

एक साथी warmUrls समापन बिंदु प्राथमिकता यूआरएल की एक स्पष्ट सूची को गर्म करती है।

अनुक्रम लोगों की अपेक्षा से अधिक मायने रखता है:

अनुक्रम लोगों की अपेक्षा से अधिक मायने रखता है:

  1. 1

    परिनियोजन पूरा हो गया है और नया संस्करण लाइव है

    एक ऐसी रिलीज़ को गर्म करना जिसका रोलआउट पूरा नहीं हुआ है, बस पुराने को कैश कर देता है।

  2. 2

    यदि परिनियोजन ने कैश्ड आउटपुट बदल दिया है, तो सीडीएन को शुद्ध करें

    अन्यथा वार्मिंग पहले से ही कैश्ड को फिर से पढ़ती है और कुछ भी सुधार नहीं होता है।

  3. 3

    फिर वार्मिंग को ट्रिगर करें

    अब वार्म रन वास्तव में नई सामग्री लाता है और कैश को उससे भर देता है।

बहुत जल्दी गर्म करना क्लासिक गलती है

सामान्य समस्या

सामान्य समस्या

वेबहुक 401 लौटाता है।
कुंजियाँ गलत हैं, समाप्त हो गई हैं, या किसी नए जोड़े द्वारा प्रतिस्थापित कर दी गई हैं।जांचें कि दोनों हेडर नाम बिल्कुल X-Public-Key और X-Secret-Key हैं, और अपने सीक्रेट स्टोर में कटे हुए मान देखें।
यह सफलता लौटाता है लेकिन कुछ भी गरमाहट नहीं देता।
मुख्य भाग में होस्टनाम संभवतः किसी भी सक्रिय वार्मर से मेल नहीं खाता है।www सहित सटीक होस्टनाम की पुष्टि करें, और यह कि मिलान करने वाला वार्मर सक्रिय है।
तापमान बढ़ गया लेकिन आगंतुक अभी भी ठंडे पन्नों पर आ रहे हैं।
लगभग हमेशा ऑर्डर देना - या तो इसे तैनाती के लाइव होने से पहले चालू कर दिया गया था, या सीडीएन को पहले के बजाय वार्मिंग के बाद शुद्ध कर दिया गया था।ट्रिगर के आगे एक पर्ज चरण जोड़ें।
पूर्वावलोकन परिनियोजन मेरे URL बजट का उपभोग कर रहे हैं।
वेबहुक को केवल उत्पादन परिनियोजन तक सीमित रखें।
क्या यह सीडीएन पर्ज के समान है?
नहीं, ट्रिगर तैनात करने से वार्मिंग शुरू हो जाती है;वे किसी भी चीज़ को अमान्य नहीं करते.सीडीएन एकीकरण शुद्ध करें और फिर पुनः गर्म करें।कई टीमें दोनों का उपयोग करती हैं।