lizard restart
मौजूदा बिल्ड का रोलिंग रीस्टार्ट — बिना रीबिल्ड के।
उपयोग
lizard restart [nameOrId] [flags]फ्लैग्स
| फ्लैग | विवरण |
|---|---|
-s, --service <name> | सर्विस |
-p, --project <id> | प्रोजेक्ट का नाम, स्लग या ID |
--detach | रीस्टार्ट स्वीकार होते ही लौट आएँ, उसकी स्थिति जाँचे बिना |
--wait | नए रीस्टार्ट प्रयास के रेडी होने तक इंतज़ार करें; --json के साथ काम करता है |
--timeout <seconds> | --wait के साथ रेडीनेस के इंतज़ार की अधिकतम अवधि; डिफ़ॉल्ट 120 |
--json | स्क्रिप्ट्स के लिए JSON लौटाएँ |
उदाहरण
सर्विस रीस्टार्ट करें
lizard restart --service apiइंतज़ार किए बिना लौट आएँ
lizard restart --service api --detachअगला चेक चलाने से पहले इंतज़ार करें
lizard --json restart --service api --wait --timeout 120--wait के बिना JSON मोड रीस्टार्ट स्वीकार होते ही लौट आता है। --wait के साथ नतीजे में ok, status, attemptId और waitedMs होते हैं। CLI नए रीस्टार्ट प्रयास का इंतज़ार करता है, इसलिए रिक्वेस्ट से पहले की बिना बदली स्थिति को सफलता नहीं माना जाता। इंतज़ार फ़ेल होने या टाइमआउट होने पर कमांड नॉन-ज़ीरो एग्ज़िट कोड लौटाती है।
पॉज़ की गई सर्विस तब तक रीस्टार्ट नहीं होती, जब तक आप उसे रिज़्यूम न करें।
HTTP सर्विसेज़ के लिए CLI सर्विस का डोमेन भी दो बार जाँचता है। containerPort=0 वाले वर्कर्स बैकएंड से मिली रेडीनेस स्थिति का उपयोग करते हैं और उन्हें HTTP लिसनर की ज़रूरत नहीं होती, भले ही उनके पास जेनरेटेड डोमेन हो।
lizard --json restart --service worker --wait --timeout 60टाइमआउट रीस्टार्ट रिक्वेस्ट के बाद रेडीनेस के इंतज़ार पर लागू होता है। यह रीस्टार्ट को रद्द नहीं करता, और नेटवर्क कॉल की वजह से पूरी कमांड में ज़्यादा समय लग सकता है। अगर आपके वर्कफ़्लो को सिर्फ़ प्रोसेस के रेडी होने से ज़्यादा जानकारी चाहिए, तो कमांड के बाद ऐप्लिकेशन का डेटा या हेल्थ एंडपॉइंट जाँचें।
यह भी देखें
- lizard redeploy — मौजूदा बिल्ड को दोबारा चलाने के बजाय नया बिल्ड ट्रिगर करें
- lizard logs —
--restart latestया--restart <id>से रीस्टार्ट के आसपास के लॉग देखें - डिप्लॉयमेंट — रीस्टार्ट बनाम रीडिप्लॉय, और क्रैश के बाद रिकवरी
अपडेट: