Skip to main content
रोज़ का काम उसी जारी CLI के रीड-ओनली कमांड से शुरू करें जिसने वर्कस्पेस बनाया था:
उनका आउटपुट वर्कस्पेस के साथ रखें ताकि आप वर्तमान देखी गई स्थिति की तुलना आख़िरी सफल apply से कर सकें।

​
स्टैक की निगरानी करें

स्टैक का आकलन करने का समर्थित तरीका ये लाइफ़साइकिल जाँचें हैं। StackKits अवलोकन और सत्यापन प्रमाण स्थानीय रूप से रखता है और उसे किसी होस्टेड मॉनिटरिंग सेवा की ज़रूरत नहीं। जारी Uptime Kuma मॉड्यूल को शुरुआती नेटिव v2 StackSpec नहीं चुनता, इसलिए नए Basement या Cloud Kit में जनरेट किया गया कोई मॉनिटरिंग पता नहीं होता। यदि आप अलग मॉनिटर चलाते हैं, तो जाँचें केवल उन रूट के लिए जोड़ें जिन्हें मॉनिटर करने के लिए आप अधिकृत हैं। संरक्षित रूट के लिए जानबूझकर बनाया गया हेल्थ एंडपॉइंट या अपेक्षित ऑथेंटिकेशन प्रतिक्रिया चाहिए; HTTP 200 पाने के लिए रूट सुरक्षा कमज़ोर करना वैध मॉनिटर सेटअप नहीं है।

​
बदलाव से पहले

  1. StackSpec अपडेट करें, जनरेट किए गए आर्टिफ़ैक्ट नहीं।
  2. stackkit validate और stackkit generate चलाएँ।
  3. stackkit plan --json का निरीक्षण करें और किसी भी तैयारी अवरोध पर रुकें।
  4. आउटपुट की समीक्षा करें और बदलाव करने वाली कमांड से पहले स्थानीय ओनर की स्वीकृति लें।
  5. बदलाव के बाद stackkit verify --http --json चलाएँ।

​
मौजूदा वर्कस्पेस में वर्कलोड जोड़ें

नया वर्कलोड चुनने के लिए stackkit init दोबारा चलाने या शुरुआती StackSpec बदलने की ज़रूरत नहीं होती। मौजूदा StackSpec का workloads ब्लॉक संपादित करें, फिर दोबारा जनरेट करने से पहले सीक्रेट कस्टडी स्थापित करें:
StackKits v0.21.11 वर्कलोड चुनने और generate चलाने के बीच स्पष्ट चरण के रूप में stackkit secrets materialize जोड़ता है। कस्टडी स्थापित करें, फिर जनरेट और लागू करें; सीक्रेट मान न गढ़ें।

​
लागू किया गया वर्कलोड हटाएँ

stackkit remove स्थानीय ओनर की स्वीकृति से एक सटीक लागू वर्कलोड हटाता है:
CLI वर्तमान प्लान, जनरेशन, apply परिणाम और ओनर प्राधिकार को सत्यापित करता है, फिर डाइजेस्ट-पिन किए गए Standard निष्पादन चैनल के ज़रिए ओनर-हस्ताक्षरित हटाने का अनुरोध भेजता है जो पाँच मिनट तक मान्य रहता है। सफलता के लिए सटीक आवश्यकता, इंस्टेंस और लागू आर्टिफ़ैक्ट डाइजेस्ट का absent रीडबैक चाहिए। अनुरोध, परिणाम और सीमित टर्मिनल प्रमाण .stackkit/evidence/removal/ के नीचे सहेजे जाते हैं।

​
मल्टी-नोड परिणाम पर एक प्लेसमेंट को लक्षित करें

सत्यापित apply सारांश planHash, appliedRequestDigest और सीक्रेट-मुक्त appliedWorkloads सूची उपलब्ध कराता है। हर प्रविष्टि एक निर्धारक, हैश-बद्ध पहचान है जो वर्कलोड, रनटाइम ओनर, प्लेसमेंट, निष्पादन चैनल और संदर्भित आर्टिफ़ैक्ट डाइजेस्ट को बाँधती है। इसका उपयोग यह पहचानने में करें कि बाद के हटाने को किसे लक्षित करना है; यह अपने आप में न हटाने की अनुमति है और न अनुपस्थिति का प्रमाण। v0.21.12 से, जब apply परिणाम ने वर्कलोड को एक से अधिक Site या नोड पर रखा हो, तो उस एक सटीक प्लेसमेंट का नाम दें जिसका यह हटाना स्वामी है। मान appliedWorkloads प्रविष्टि से लें:
नामित प्लेसमेंट को सत्यापित apply परिणाम की ठीक एक प्रविष्टि से मेल खाना चाहिए। हर नोड-स्थानीय अनुपस्थिति रसीद साझा appliedRequestDigest के ज़रिए उसी मूल apply से सहसंबद्ध रहती है। stdout पर मशीन-पठनीय हटाने का रिकॉर्ड चाहिए तो --terminal-evidence-json जोड़ें।

​
सामान्य वर्कफ़्लो

StackSpec आशय बदलें

जारी आशय संपादित करें और शासित आउटपुट दोबारा जनरेट करें।

बैकअप और रिस्टोर

आइडेम्पोटेंट स्नैपशॉट बनाएँ और स्टेज्ड रिकवरी का अभ्यास करें।
सटीक कमांड सतह रिलीज़ के साथ वर्ज़न की जाती है। बैकअप, रिस्टोर, अपग्रेड या हटाना करने से पहले इंस्टॉल किए गए वर्ज़न के लिए stackkit --help और कमांड-विशिष्ट सहायता उपयोग करें।
Standard Mode में StackKits बिना निगरानी वाला होस्टेड-ऑपरेशन वर्कफ़्लो उपलब्ध नहीं कराता। हर बदलाव करने वाली कमांड को उस होस्ट पर स्थानीय ऑपरेशन मानें जिसे आप नियंत्रित करते हैं।
एजेंट-कनेक्टेड वर्कफ़्लो के लिए MCP कनेक्टर देखें।