अयशस्वी रीपब्लिशमुळे कार्यरत बॅकएंड कधीच हटवला जात नाही

२५ सप्टेंबरला एका अयशस्वी रीपब्लिशमुळे एका ॲपचा बॅकएंड हटवला गेला, जो सुमारे अडीच तास लाइव्ह आणि व्यवस्थित चालत होता. अयशस्वी प्रकाशन उलटवणारा कोड, प्रकाशन सुरू होण्यापूर्वीच सर्व्हर-ॲप्सवर परिणाम करणाऱ्या प्रत्येक ॲपला हटवत होता, त्यात आधीपासून चालू असलेल्या ॲप्सचाही समावेश होता. आता फक्त प्रकाशनाने तयार केलेले ॲप्सच हटवले जातात; आधीपासून असलेला ॲप त्याच्या आधीच्या अचूक आवृत्तीवर परत आणला जातो. त्याच दिवशी केलेल्या दोन पुढील सुधारणांमुळे, होस्टिंग प्लॅटफॉर्मचे स्वतःचे डिप्लॉय टूल अयशस्वी झाले तरीही ही उलटणारी प्रक्रिया चालते, आणि झोपलेल्या ॲपला केवळ झोपेत असल्यामुळे अयशस्वी ठरवले जात नाही, याची खात्री केली गेली.

बॅकएंड कसे प्रकाशित होते

तुमच्या Mythex ॲपमध्ये बॅकएंड असेल, म्हणजे फक्त स्टॅटिक फाइल्स नसून API किंवा सर्व्हर असेल, तर प्रकाशन Dockerfile (ॲपला इमेजमध्ये पॅक करण्याची पाककृती) वापरून त्याची बिल्ड करते आणि ती इमेज आमच्या होस्टिंग प्लॅटफॉर्मवरील मशीन्सवर रोल आउट करते. त्यानंतर नवीन आवृत्ती खरोखर सुरू होऊन स्थिरपणे चालू राहते की नाही, हे हेल्थ चेक तपासते; तोपर्यंत प्रकाशन लाइव्ह म्हणून चिन्हांकित होत नाही.

वाटेत काहीही अयशस्वी झाले, तर ते उलटवण्यासाठी रोलबॅक चालतो. हा रोलबॅक योग्यरीत्या चालणे, प्रकाशनातील जवळपास कोणत्याही गोष्टीइतकेच महत्त्वाचे आहे, कारण तो नेमका तेव्हाच चालतो जेव्हा आधीच काहीतरी चुकलेले असते.

समस्या 1: रोलबॅकने जे पुनर्संचयित करायला हवे होते तेच हटवले

रोलबॅक एका प्रकाशनाने डिप्लॉय केलेल्या सर्व्हर-ॲप्सची यादी ठेवत होता, आणि अपयश आल्यावर त्या प्रत्येकाला नष्ट करत होता. पहिल्या प्रकाशनासाठी हे बरोबर आहे: ॲप काही क्षणांपूर्वीच तयार झालेला असतो, त्यावर काहीही अवलंबून नसते, आणि तो हटवल्याने सर्व काही पूर्वीसारखे राहते.

रीपब्लिशसाठी मात्र हे अगदी चुकीचे आहे. ॲप आधीपासूनच अस्तित्वात होता आणि खऱ्या अभ्यागतांना सेवा देत होता. २५ सप्टेंबरला सुमारे अडीच तास लाइव्ह असलेला एका ॲपचा API एका अयशस्वी रीपब्लिशमुळे हटवला गेला.

त्याच कोडमध्ये आणखी एक अपयश लपलेले होते. डिलीट यशस्वी न झाल्यास, चुकीची नवीन इमेज मशीन्सवर तशीच राहत होती, तर आम्ही मालकाला सांगत होतो की त्यांची सध्याची साइट अजूनही लाइव्ह आहे. हेल्थ चेक अपयशी ठरू शकतो तोपर्यंत नवीन इमेज आधीच प्रत्येक मशीनवर रोल आउट झालेली असते. काहीही न करणे म्हणजे उलटवणे नव्हे.

उपाय: जे तयार केले तेवढेच नष्ट करा, बाकी पुनर्संचयित करा

आता प्रत्येक प्रकाशन, त्याने स्पर्श केलेल्या प्रत्येक सर्व्हर-ॲपसाठी खालील गोष्टी नोंदवते:

• हे प्रकाशन ते तयार करते का, आणि
• जर नाही, तर तो ॲप सुरू होण्यापूर्वी कोणती इमेज चालवत होता.

अपयश आल्यावर प्रत्येक ॲपवर तीनपैकी एक उपचार होतो:

1. या प्रकाशनाने तयार केलेला: पूर्वीप्रमाणे नष्ट करा.
2. आधीपासून होता, मागील इमेज माहीत आहे: त्याच कॉन्फिगरेशनसह आधीची इमेज पुन्हा डिप्लॉय करा. बिल्ड नाही, फक्त इमेज मागे हलते.
3. आधीपासून होता, मागील इमेज माहीत नाही: त्याला हात लावू नका. विद्यमान ॲप कधीच हटवला जात नाही, जरी तो पुनर्संचयित करता येत नसला तरी.

हे नियम एक छोटे, शुद्ध फंक्शन आहेत आणि त्यांच्या स्वतःच्या चाचण्या आहेत, त्यामुळे “सर्वकाही नष्ट करा” या निर्णयाकडे परत जाणे चाचणी अयशस्वी केल्याशिवाय होऊ शकत नाही.

समस्या 2: उलटवण्याची पद्धत लिहिण्यापूर्वीच डिप्लॉय टूल अयशस्वी होऊ शकत होते

ही सुधारणा झाल्यानंतर लगेच, तिच्यात एक अंतर आढळले. होस्टिंग प्लॅटफॉर्मचे डिप्लॉय टूल स्वतःचे स्मोक चेक चालवते: नवीन मशीन्स क्रॅश झाल्या तर ते एरर देऊन बाहेर पडते. पण ते हे नवीन इमेज मशीन्सवर आल्यानंतर करते.

आमचा कोड, टूल यशस्वी परत आल्यावरच ॲपची रोलबॅकसाठी नोंद करत होता. टूलनेच डिप्लॉय अयशस्वी केला तर ॲप अजून रोलबॅक-यादीत नसायचा, त्यामुळे काहीच पुनर्संचयित होत नव्हते. आमच्या स्टेजिंग वातावरणात, एका चुकलेल्या रीपब्लिशमुळे चुकीची इमेज चालूच राहिली.

उपाय: सुरू करण्यापूर्वी उलटण्याची नोंद करा

आता ॲप तयार झाल्यावर आणि त्यावर काहीही रोल आउट होण्यापूर्वी, तो रोलबॅकसाठी नोंदवला जातो, त्यात तो तयार केला होता की नाही आणि त्याने कोणती इमेज चालवली होती ही माहितीही असते. नंतर काहीही अपयशी झाले तरी, रोलबॅकला काय परत ठेवायचे हे माहीत असते. स्थानिक पातळीवर पडताळणी केली: एक चुकलेले रीपब्लिश डिप्लॉय टूलच्या स्वतःच्या स्मोक चेकमध्ये अयशस्वी झाले, आणि आधीची आवृत्ती उत्तर देत राहिली.

समस्या 3: झोपलेल्या ॲपला “कधीच सुरू झाला नाही” म्हणून अयशस्वी ठरवले

Mythex वरील प्रकाशित ॲप्स, तुमचे क्रेडिट्स वाचवण्यासाठी निष्क्रिय असताना झोपतात. रीपब्लिशमुळे झोपलेले मशीन थांबलेल्या अवस्थेत राहते, त्यामुळे हेल्थ चेकने त्याला जागे करणे आवश्यक असते. तो प्लॅटफॉर्मला मशीन एकदाच सुरू करण्यास सांगत होता, आणि त्या उत्तराकडे दुर्लक्ष करत होता.

२५ सप्टेंबरला, तो एकच सुरू करण्याची विनंती कुठेही पोहोचली नाही. एक निरोगी API पूर्ण पाच-मिनिटांच्या हेल्थ चेकपर्यंत थांबलेला राहिला आणि “1 machine never started (last state: stopped)” या कारणाने अयशस्वी ठरला.

प्लॅटफॉर्म कधीकधी सुरू करण्यास नकार देतो. हे पुनरुत्पादित करताना, आम्ही न चिथावता त्याने “lease currently held” असा संघर्ष-प्रतिसाद दिला, आणि मशीन अपडेट होत असताना तो सुरू होण्यास नकार देतो.

उपाय: विचारत राहा, आणि दार ठोठवा

आता हेल्थ चेक:

• प्रतीक्षा करताना, थांबलेले मशीन सुरू करण्यासाठी दर 20 सेकंदांनी पुन्हा विचारतो,
• प्लॅटफॉर्मने नकार दिला तेव्हा त्याने काय उत्तर दिले ते नोंदवतो, आणि
• ॲपला एक सामान्य विनंती पाठवतो, जसा एखादा अभ्यागत करेल. विनंती आली की झोपलेल्या मशीनला प्लॅटफॉर्मचा प्रॉक्सी जागे करतो.

पहिली सुरुवात नाकारलेल्या एका तात्पुरत्या ॲपसह, खऱ्या प्लॅटफॉर्मवर आम्ही हे पुनरुत्पादित केले. सुधारणेआधी प्रकाशन 91 सेकंदांनी अयशस्वी झाले; नंतर ते 20 सेकंदांत प्रकाशित झाले. बूट होतानाच खरोखर क्रॅश होणारा ॲप अजूनही अयशस्वी होतो, जसे व्हायला हवे.

आम्ही यातून काय शिकलो

• रोलबॅकला नवीन आणि विद्यमान यातील फरक कळला पाहिजे. तयार केलेल्या गोष्टीसाठी “उलटवणे” म्हणजे हटवणे. आधीपासून असलेल्या गोष्टीसाठी “उलटवणे” म्हणजे पुनर्संचयित करणे. दोन्हीला सारखे वागवल्यामुळेच एखादी सुरक्षा यंत्रणा चालणारा ॲप हटवते.
• कृती करण्यापूर्वी उलटण्याची पद्धत लिहून ठेवा. जर उलटण्याची नोंद एखादे पाऊल यशस्वी झाल्यानंतरच केली, तर अर्ध्या वाटेवर अयशस्वी झालेल्या पावलाला उलटवण्यासाठी काहीच उरत नाही.
• तुम्ही ज्या विनंतीवर अवलंबून आहात तिचे उत्तर कधीही दुर्लक्षित करू नका. एका दुर्लक्षित “नाही” मुळे एक निरोगी ॲप अयशस्वी प्रकाशनात बदलला.

त्याच दिवशीची संबंधित सुधारणा: प्रकाशनानंतर लगेच क्रॅश होणारे ॲप्स पकडणे. प्रकाशन तुमच्या बाजूने अयशस्वी झाल्यास काय होते, यासाठी डॉक्समधील प्रकाशन समस्यानिवारण पाहा.