क्या आपने कभी निराशा में अपने कंप्यूटर से पावर कॉर्ड को खींचकर बाहर निकाला है? हालांकि यह एक त्वरित समाधान की तरह लग सकता है, लेकिन इससे डेटा हानि और सिस्टम अस्थिरता हो सकती है। सॉफ़्टवेयर की दुनिया में, एक समान अवधारणा मौजूद है: हार्ड शटडाउन। यह अचानक समाप्ति इसके भौतिक समकक्ष की तरह ही समस्याएँ पैदा कर सकती है। शुक्र है, एक बेहतर तरीका है: शालीन शटडाउन। सुंदर शटडाउन को एकीकृत करके, हम सेवा को अग्रिम सूचना प्रदान करते हैं। यह इसे चल रहे अनुरोधों को पूरा करने, संभावित रूप से डिस्क पर स्थिति की जानकारी को सहेजने और अंततः शटडाउन के दौरान डेटा भ्रष्टाचार से बचने में सक्षम बनाता है। यह मार्गदर्शिका सुंदर शटडाउन की दुनिया में प्रवेश करेगी, विशेष रूप से कुबेरनेट्स पर चलने वाले में उनके कार्यान्वयन पर ध्यान केंद्रित करेगी। गो अनुप्रयोगों यूनिक्स सिस्टम में सिग्नल यूनिक्स-आधारित सिस्टम में सुंदर शटडाउन प्राप्त करने के लिए प्रमुख उपकरणों में से एक सिग्नल की अवधारणा है, जो सरल शब्दों में, एक प्रक्रिया से दूसरी प्रक्रिया तक एक विशिष्ट चीज़ को संप्रेषित करने का एक सरल तरीका है। सिग्नल कैसे काम करते हैं, यह समझकर हम अपने अनुप्रयोगों के भीतर नियंत्रित समाप्ति प्रक्रियाओं को लागू करने के लिए उनका लाभ उठा सकते हैं, जिससे एक सुचारू और डेटा-सुरक्षित शटडाउन प्रक्रिया सुनिश्चित होती है। कई संकेत हैं, और आप उन्हें पा सकते हैं, लेकिन हमारी चिंता केवल शटडाउन संकेत हैं: यहां - किसी प्रक्रिया को समाप्त करने के लिए अनुरोध करने के लिए भेजा जाता है। सबसे अधिक इस्तेमाल किया जाता है, और हम बाद में इस पर ध्यान केंद्रित करेंगे। SIGTERM - "तुरंत छोड़ो", इसमें हस्तक्षेप नहीं किया जा सकता। सिगकिल - व्यवधान संकेत (जैसे Ctrl+C) SIGINT - छोड़ने का संकेत (जैसे Ctrl+D) SIGQUIT ये संकेत उपयोगकर्ता (Ctrl+C / Ctrl+D), किसी अन्य प्रोग्राम/प्रक्रिया से, या स्वयं सिस्टम (कर्नेल/OS) से भेजे जा सकते हैं, उदाहरण के लिए, OS द्वारा एक उर्फ सेगमेंटेशन फॉल्ट भेजा जाता है। SIGSEGV हमारी गिनी पिग सेवा व्यावहारिक सेटिंग में सुंदर शटडाउन की दुनिया का पता लगाने के लिए, आइए एक सरल सेवा बनाएं जिसके साथ हम प्रयोग कर सकते हैं। इस "गिनी पिग" सेवा में एक एकल समापन बिंदु होगा जो Redis के कमांड को कॉल करके कुछ वास्तविक दुनिया के काम का अनुकरण करता है (हम थोड़ी देरी जोड़ेंगे)। हम यह परीक्षण करने के लिए एक बुनियादी Kubernetes कॉन्फ़िगरेशन भी प्रदान करेंगे कि प्लेटफ़ॉर्म समाप्ति संकेतों को कैसे संभालता है। INCR अंतिम लक्ष्य: सुनिश्चित करें कि हमारी सेवा बिना किसी अनुरोध/डेटा को खोए शटडाउन को सुचारू रूप से संभालती है। Redis में अंतिम काउंटर मान के साथ समानांतर में भेजे गए अनुरोधों की संख्या की तुलना करके, हम यह सत्यापित करने में सक्षम होंगे कि हमारा सुचारू शटडाउन कार्यान्वयन सफल है या नहीं। हम Kubernetes क्लस्टर और Redis की स्थापना के विवरण में नहीं जाएंगे, लेकिन आप पा सकते हैं। हमारे Github रिपॉजिटरी में पूर्ण सेटअप सत्यापन प्रक्रिया निम्नलिखित है: Redis और Go अनुप्रयोग को Kubernetes पर तैनात करें। 1000 अनुरोध (40 सेकंड में 25/s) भेजने के लिए उपयोग करें। वेजिटा का जब वेजिटा चल रहा हो, तो छवि टैग को अपडेट करके कुबेरनेट्स आरंभ करें। रोलिंग अपडेट “काउंटर” को सत्यापित करने के लिए Redis से कनेक्ट करें, यह 1000 होना चाहिए। आइये अपने बेस गो HTTP सर्वर से शुरुआत करें। हार्ड-शटडाउन/main.go package main import ( "net/http" "os" "time" "github.com/go-redis/redis" ) func main() { redisdb := redis.NewClient(&redis.Options{ Addr: os.Getenv("REDIS_ADDR"), }) server := http.Server{ Addr: ":8080", } http.HandleFunc("/incr", func(w http.ResponseWriter, r *http.Request) { go processRequest(redisdb) w.WriteHeader(http.StatusOK) }) server.ListenAndServe() } func processRequest(redisdb *redis.Client) { // simulate some business logic here time.Sleep(time.Second * 5) redisdb.Incr("counter") } जब हम इस कोड का उपयोग करके अपनी सत्यापन प्रक्रिया चलाते हैं तो हम देखते हैं कि कुछ अनुरोध विफल हो जाते हैं और (प्रत्येक बार संख्या भिन्न हो सकती है)। काउंटर 1000 से कम है इसका स्पष्ट अर्थ है कि हमने रोलिंग अपडेट के दौरान कुछ डेटा खो दिया है। गो में सिग्नल संभालना गो एक पैकेज प्रदान करता है जो आपको यूनिक्स सिग्नल को संभालने की अनुमति देता है। यह ध्यान रखना महत्वपूर्ण है कि डिफ़ॉल्ट रूप से, SIGINT और SIGTERM सिग्नल गो प्रोग्राम को बाहर निकलने का कारण बनते हैं। और हमारे गो एप्लिकेशन को अचानक से बाहर न निकलने के लिए, हमें आने वाले सिग्नल को संभालने की आवश्यकता है। सिग्नल ऐसा करने के दो विकल्प हैं। चैनल का उपयोग: c := make(chan os.Signal, 1) signal.Notify(c, syscall.SIGTERM) संदर्भ का उपयोग करना (आजकल पसंदीदा दृष्टिकोण): ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM) defer stop() मूल संदर्भ की एक प्रतिलिपि लौटाता है, जिसे पूर्ण के रूप में चिह्नित किया जाता है (इसका पूर्ण चैनल बंद हो जाता है), जब सूचीबद्ध संकेतों में से एक आता है, जब लौटाए गए फ़ंक्शन को कॉल किया जाता है, या जब मूल संदर्भ का पूर्ण चैनल बंद हो जाता है, जो भी पहले हो। NotifyContext, stop() HTTP सर्वर के हमारे वर्तमान कार्यान्वयन में कुछ समस्याएं हैं: हमारे पास एक धीमी प्रक्रिया अनुरोध गोरूटीन है, और चूंकि हम समाप्ति संकेत को संभाल नहीं पाते हैं, इसलिए प्रोग्राम स्वचालित रूप से बाहर निकल जाता है, जिसका अर्थ है कि सभी चल रहे गोरूटीन भी समाप्त हो जाते हैं। प्रोग्राम कोई भी कनेक्शन बंद नहीं करता है। आइये इसे पुनः लिखें। ग्रेसफुल-शटडाउन/main.go package main // imports var wg sync.WaitGroup func main() { ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM) defer stop() // redisdb, server http.HandleFunc("/incr", func(w http.ResponseWriter, r *http.Request) { wg.Add(1) go processRequest(redisdb) w.WriteHeader(http.StatusOK) }) // make it a goroutine go server.ListenAndServe() // listen for the interrupt signal <-ctx.Done() // stop the server if err := server.Shutdown(context.Background()); err != nil { log.Fatalf("could not shutdown: %v\n", err) } // wait for all goroutines to finish wg.Wait() // close redis connection redisdb.Close() os.Exit(0) } func processRequest(redisdb *redis.Client) { defer wg.Done() // simulate some business logic here time.Sleep(time.Second * 5) redisdb.Incr("counter") } अपडेट का सारांश इस प्रकार है: SIGTERM समाप्ति सिग्नल को सुनने के लिए जोड़ा गया। signal.NotifyContext इन-फ़्लाइट अनुरोधों (प्रोसेसरिक्वेस्ट गोरूटीन्स) को ट्रैक करने के लिए शुरुआत की गई। sync.WaitGroup की सर्वर को गोरूटीन में लपेटा गया तथा नये कनेक्शनों को स्वीकार करना सुचारू रूप से रोकने के लिए संदर्भ के साथ का प्रयोग किया गया। server.Shutdown आगे बढ़ने से पहले सभी इन-फ़्लाइट अनुरोधों (प्रोसेसरिक्वेस्ट गोरूटीन) को समाप्त करने के लिए उपयोग किया गया। wg.Wait() का संसाधन सफ़ाई: बाहर निकलने से पहले Redis कनेक्शन को ठीक से बंद करने के लिए जोड़ा गया। redisdb.Close() स्वच्छ निकास: सफल समाप्ति को इंगित करने के लिए उपयोग किया जाता है। os.Exit(0) का अब, यदि हम अपनी सत्यापन प्रक्रिया दोहराते हैं तो हम देखेंगे कि सभी 1000 अनुरोध सही ढंग से संसाधित किए गए हैं। वेब फ्रेमवर्क / HTTP लाइब्रेरी इको, जिन, फाइबर और अन्य जैसे फ्रेमवर्क प्रत्येक आने वाले अनुरोधों के लिए एक गोरूटीन बनाएंगे, इसे एक संदर्भ देंगे और फिर आपके द्वारा तय किए गए रूटिंग के आधार पर आपके फ़ंक्शन / हैंडलर को कॉल करेंगे। हमारे मामले में यह "/incr" पथ के लिए HandleFunc को दिया गया अनाम फ़ंक्शन होगा। जब आप सिग्नल को रोकते हैं और अपने फ्रेमवर्क को सुचारू रूप से बंद करने के लिए कहते हैं, तो 2 महत्वपूर्ण चीजें होती हैं (सरलीकृत करने के लिए): SIGTERM आपका फ्रेमवर्क आने वाले अनुरोधों को स्वीकार करना बंद कर देता है यह किसी भी मौजूदा आने वाले अनुरोध के समाप्त होने की प्रतीक्षा करता है (अंतर्निहित रूप से गोरूटीन के समाप्त होने की प्रतीक्षा करता है)। नोट: Kubernetes लोडबैलेंसर को समाप्त होने वाला लेबल देने के बाद, लोडबैलेंसर से आने वाले ट्रैफ़िक को आपके पॉड पर भेजना भी बंद कर देता है। वैकल्पिक: शटडाउन टाइमआउट किसी प्रक्रिया को समाप्त करना जटिल हो सकता है, खासकर अगर इसमें कई चरण शामिल हों जैसे कि कनेक्शन बंद करना। यह सुनिश्चित करने के लिए कि चीजें सुचारू रूप से चले, आप टाइमआउट सेट कर सकते हैं। यह टाइमआउट एक सुरक्षा जाल के रूप में कार्य करता है, अगर प्रक्रिया में अपेक्षा से अधिक समय लगता है तो प्रक्रिया से शालीनता से बाहर निकल जाता है। shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second) defer cancel() go func() { if err := server.Shutdown(shutdownCtx); err != nil { log.Fatalf("could not shutdown: %v\n", err) } }() select { case <-shutdownCtx.Done(): if shutdownCtx.Err() == context.DeadlineExceeded { log.Fatalln("timeout exceeded, forcing shutdown") } os.Exit(0) } Kubernetes समाप्ति जीवनचक्र चूँकि हमने अपनी सेवा को तैनात करने के लिए Kubernetes का उपयोग किया है, तो आइए इस बात पर गहराई से विचार करें कि यह पॉड्स को कैसे समाप्त करता है। एक बार जब Kubernetes पॉड को समाप्त करने का फैसला करता है, तो निम्नलिखित घटनाएँ घटित होंगी: पॉड को "समाप्त" स्थिति पर सेट किया जाता है और सभी सेवाओं की एंडपॉइंट सूची से हटा दिया जाता है। यदि Hook परिभाषित है तो उसे निष्पादित किया जाता है। preStop सिग्नल पॉड को भेजा जाता है। लेकिन अब हमारा एप्लीकेशन जानता है कि क्या करना है! SIGTERM Kubernetes एक अनुग्रह अवधि ( ) की प्रतीक्षा करता है, जो डिफ़ॉल्ट रूप से 30s होती है। terminationGracePeriodSeconds सिग्नल पॉड को भेजा जाता है, और पॉड को हटा दिया जाता है। SIGKILL जैसा कि आप देख सकते हैं, यदि आपके पास लंबे समय तक चलने वाली समाप्ति प्रक्रिया है, तो सेटिंग को बढ़ाना आवश्यक हो सकता है, जिससे आपके एप्लिकेशन को सुचारू रूप से बंद होने के लिए पर्याप्त समय मिल सके। endingGracePeriodSeconds निष्कर्ष ग्रेसफुल शटडाउन डेटा अखंडता की रक्षा करते हैं, एक सहज उपयोगकर्ता अनुभव बनाए रखते हैं, और संसाधन प्रबंधन को अनुकूलित करते हैं। अपने समृद्ध मानक पुस्तकालय और समवर्तीता पर जोर देने के साथ, Go डेवलपर्स को सहजता से ग्रेसफुल शटडाउन प्रथाओं को एकीकृत करने में सक्षम बनाता है - जो Kubernetes जैसे कंटेनरीकृत या ऑर्केस्ट्रेटेड वातावरण में तैनात अनुप्रयोगों के लिए एक आवश्यकता है। आप में गो कोड और कुबेरनेट्स मैनिफ़ेस्ट पा सकते हैं। हमारे गिटहब रिपॉजिटरी संसाधन ओएस/सिग्नल पैकेज कुबेरनेट्स पॉड जीवनचक्र
