தோல்வியடைந்த மறுவெளியீடு வேலை செய்யும் பின்தளத்தை ஒருபோதும் நீக்காது

செப்டம்பர் 25 அன்று, தோல்வியடைந்த ஒரு மறுவெளியீடு, இரண்டரை மணி நேரத்திற்கும் மேலாக நேரடியாக இயங்கிக் கொண்டிருந்த ஒரு ஆப்பின் பின்தளத்தை நீக்கிவிட்டது. தோல்வியடைந்த வெளியீட்டைத் திரும்பப் பெறும் குறியீடு, வெளியீடு தொட்ட ஒவ்வொரு சர்வர் ஆப்பையும் நீக்கியது — வெளியீடு தொடங்குவதற்கு முன்பே சேவை செய்துகொண்டிருந்தவற்றையும் சேர்த்து. இப்போது ஒரு வெளியீடு உருவாக்கிய ஆப்புகள் மட்டுமே நீக்கப்படுகின்றன; ஏற்கனவே இருந்த ஆப் அது முன்பு இயங்கிய சரியான பதிப்புக்குத் திரும்ப கொண்டுவரப்படுகிறது. அதே நாளில் வந்த இரண்டு பின்தொடர் திருத்தங்கள், ஹோஸ்டிங் தளத்தின் சொந்த டெப்லாய் கருவி தோல்வியடைந்தாலும் அந்தத் திரும்பப் பெறுதல் இயங்குவதை உறுதிசெய்தன; மேலும் தூங்கிக்கொண்டிருந்ததால் ஆரோக்கியமான ஒரு ஆப் தோல்வியாகக் குறிக்கப்படவில்லை என்பதையும் உறுதிசெய்தன.

பின்தளம் எவ்வாறு வெளியிடப்படுகிறது

உங்கள் Mythex ஆப்பிற்குப் பின்தளம் இருக்கும்போது — அதாவது நிலையான கோப்புகள் மட்டுமல்லாமல் ஒரு API அல்லது சர்வர் இருக்கும்போது — வெளியிடுவது ஒரு Dockerfile-இலிருந்து (ஆப்பை ஒரு படிமமாக (image) தொகுக்கும் செய்முறை) அதை உருவாக்கி, நாங்கள் பயன்படுத்தும் ஹோஸ்டிங் தளத்தின் இயந்திரங்களில் அந்தப் படிமத்தை உருட்டி ஏற்றுகிறது. அதன் பிறகு, புதிய பதிப்பு உண்மையாக எழுந்து நிலைத்து நிற்கும் வரை ஒரு ஆரோக்கிய சோதனை (health check) காத்திருக்கிறது; அதன் பின்னரே வெளியீடு நேரடியானதாகக் குறிக்கப்படுகிறது.

வழியில் ஏதாவது தோல்வியடைந்தால், அதைத் திரும்பப் பெற ஒரு rollback இயங்குகிறது. இந்த rollback சரியாக இருப்பது, வெளியீட்டில் வேறு எதைவிடவும் முக்கியமானது — ஏனெனில் ஏற்கனவே ஏதோ தவறாகிக்கொண்டிருக்கும் தருணத்தில்தான் அது இயங்குகிறது.

சிக்கல் 1: மீட்டெடுக்க வேண்டியதை rollback நீக்கிவிட்டது

Rollback, வெளியீடு பயன்படுத்திய சர்வர் ஆப்புகளின் பட்டியலை வைத்திருந்தது; தோல்வி ஏற்பட்டால், அவை ஒவ்வொன்றையும் அழித்தது. முதல் வெளியீட்டுக்கு இது சரியானது: ஆப் சில நொடிகளுக்கு முன்புதான் உருவாக்கப்பட்டது, எதுவும் அதைச் சார்ந்திருக்கவில்லை, அதை நீக்கினால் எல்லாம் முன்பிருந்த நிலைக்குத் திரும்பும்.

மறுவெளியீட்டுக்கு இது சரியாக எதிரானது. ஆப் ஏற்கனவே இருந்தது, உண்மையான பார்வையாளர்களுக்கு சேவை செய்துகொண்டிருந்தது. செப்டம்பர் 25 அன்று, இரண்டரை மணி நேரமாக நேரடியாக இயங்கிய ஒரு ஆப்பின் API, தோல்வியடைந்த ஒரு மறுவெளியீட்டால் நீக்கப்பட்டது.

அதே குறியீட்டில் இன்னொரு தோல்வி முறையும் மறைந்திருந்தது. நீக்கம் நடந்து சேராத இடத்தில், பழுதான புதிய படிமம் இயந்திரங்களிலேயே தொடர்ந்து இருந்தது — அதே நேரத்தில் உரிமையாளரிடம் அவர்களின் தற்போதைய தளம் இன்னும் நேரடியாக இருக்கிறது என்று சொல்லிக்கொண்டிருந்தோம். ஆரோக்கிய சோதனை தோல்வியடையக்கூடிய நேரத்தில், புதிய படிமம் ஏற்கனவே ஒவ்வொரு இயந்திரத்திலும் ஏற்றப்பட்டிருக்கும். எதுவும் செய்யாமல் இருப்பது, திரும்பப் பெறுவதற்குச் சமமல்ல.

திருத்தம்: நீ உருவாக்கியதை மட்டும் அழி, மற்றவற்றை மீட்டெடு

இப்போது ஒவ்வொரு வெளியீடும், அது தொடும் ஒவ்வொரு சர்வர் ஆப்புக்கும் பின்வருவனவற்றைப் பதிவு செய்கிறது:

• இந்த வெளியீடு அதை உருவாக்கியதா, மற்றும்
• இல்லையென்றால், வெளியீட்டுக்குச் சற்று முன் அது எந்தப் படிமத்தில் இயங்கியது.

தோல்வி ஏற்பட்டால், ஒவ்வொரு ஆப்பும் மூன்றில் ஒரு சிகிச்சையைப் பெறுகிறது:

1. இந்த வெளியீடு உருவாக்கியது: முன்பு போலவே அழிக்கப்படுகிறது.
2. ஏற்கனவே இருந்தது, முந்தைய படிமம் தெரியும்: அதே அமைப்புடன் முந்தைய படிமத்தை மீண்டும் வெளியிடுகிறது. கட்டமைப்பு (build) இல்லை — படிமம் மட்டுமே பின்னால் நகர்கிறது.
3. ஏற்கனவே இருந்தது, முந்தைய படிமம் தெரியவில்லை: அதைத் தொடுவதில்லை. ஏற்கனவே இருக்கும் ஆப் ஒருபோதும் நீக்கப்படாது, அதை மீட்டெடுக்க முடியாவிட்டாலும் கூட.

இந்த விதிகள் ஒரு சிறிய தூய செயல்பாடாகவும், அதற்கான சோதனைகளுடனும் உள்ளன. அதனால் “எல்லாவற்றையும் அழி” என்ற முடிவுக்கு மீண்டும் திரும்பினால், ஒரு சோதனை தோல்வியடையும்.

சிக்கல் 2: திரும்பப் பெறும் வழியை எழுதி வைப்பதற்கு முன்பே டெப்லாய் கருவி தோல்வியடையலாம்

அந்தத் திருத்தத்திற்குப் பிறகு விரைவிலேயே, அதில் ஒரு இடைவெளியைக் கண்டோம். ஹோஸ்டிங் தளத்தின் டெப்லாய் கருவி தனது சொந்த smoke சோதனைகளை இயக்குகிறது: புதிய இயந்திரங்கள் செயலிழந்தால், அது ஒரு பிழையுடன் வெளியேறுகிறது. ஆனால் அது புதிய படிமம் ஏற்கனவே இயந்திரங்களில் இருந்த பிறகுதான் அப்படிச் செய்கிறது.

எங்கள் குறியீடு, கருவி வெற்றிகரமாகத் திரும்பிய பின்புதான் ஒரு ஆப்பை rollback-க்குப் பதிவு செய்தது. கருவியே டெப்லாயை தோல்வியடையச் செய்தபோது, அந்த ஆப் இன்னும் rollback பட்டியலில் இல்லை; அதனால் எதுவும் மீட்டெடுக்கப்படவில்லை. எங்கள் staging சூழலில், பழுதான ஒரு மறுவெளியீடு, பழுதான படிமத்தையே சேவை செய்ய விட்டுவிட்டது.

திருத்தம்: தொடங்குவதற்கு முன்பே திரும்பப் பெறுதலைப் பதிவு செய்யுங்கள்

ஆப் தயார் செய்யப்பட்டவுடன், அதன் மீது எதுவும் ஏற்றப்படுவதற்கு முன்பே, அது rollback-க்குப் பதிவு செய்யப்படுகிறது — அது உருவாக்கப்பட்டதா என்பதும், என்ன படிமத்தில் இயங்கியது என்பதும் சேர்ந்து. அதன் பிறகு எது தோல்வியடைந்தாலும், திரும்ப வைக்க வேண்டியது எது என்பதை rollback அறியும். இதை உள்ளூரில் சரிபார்த்தோம்: பழுதான ஒரு மறுவெளியீடு டெப்லாய் கருவியின் சொந்த smoke சோதனைகளில் தோல்வியடைந்தது, முந்தைய பதிப்பு தொடர்ந்து பதிலளித்தது.

சிக்கல் 3: தூங்கிக்கொண்டிருந்த ஆப், “ஒருபோதும் தொடங்கவில்லை” என்று தோல்வியடைந்தது

Mythex-இல் வெளியிடப்பட்ட ஆப்புகள் வேலையில்லாதபோது உங்கள் கிரெடிட்களைச் சேமிக்க உறங்கிவிடுகின்றன. மறுவெளியீடு உறங்கும் இயந்திரத்தை நிறுத்தியபடியே விட்டுவிடுகிறது; அதனால் ஆரோக்கிய சோதனை அதை எழுப்ப வேண்டும். அது இயந்திரத்தைத் தொடங்கும்படி தளத்திடம் ஒரு முறை மட்டுமே கேட்டது, பதிலை புறக்கணித்தது.

செப்டம்பர் 25 அன்று, அந்த ஒரு தொடக்க கோரிக்கை எங்கும் போய்ச் சேரவில்லை. ஆரோக்கியமான ஒரு API, ஐந்து நிமிட ஆரோக்கிய சோதனை முழுவதும் நிறுத்தப்பட்டபடி இருந்தது; “1 இயந்திரம் ஒருபோதும் தொடங்கவில்லை (கடைசி நிலை: stopped)” என்று தோல்வியடைந்தது.

தளம் சில நேரங்களில் தொடக்கத்தை மறுக்கும் என்பது உண்மைதான். இதை மீண்டும் உருவாக்கிப் பார்த்தபோது, நாங்கள் தூண்டாமலேயே அது “lease currently held” மோதலைத் திருப்பி அனுப்பியது; ஒரு இயந்திரம் புதுப்பிக்கப்படும்போதும் அது தொடக்கங்களை மறுக்கிறது.

திருத்தம்: தொடர்ந்து கேளுங்கள், கதவைத் தட்டுங்கள்

ஆரோக்கிய சோதனை இப்போது:

• காத்திருக்கும்போது, நின்றுபோன இயந்திரத்தை ஒவ்வொரு 20 வினாடிக்கும் மீண்டும் தொடங்கக் கேட்கிறது,
• தளம் மறுக்கும்போது அது பதிலாகச் சொன்னதைப் பதிவு செய்கிறது, மற்றும்
• ஆப்பிற்கு ஒரு சாதாரண கோரிக்கையை அனுப்புகிறது — ஒரு பார்வையாளர் அனுப்புவதுபோல. கோரிக்கை வரும்போது, தளத்தின் proxy உறங்கும் இயந்திரத்தை எழுப்புகிறது.

ஒரு தொடக்கத்தை முதலில் மறுக்கும் ஒரு சோதனை ஆப் கொண்டு, உண்மையான தளத்தில் இதை மீண்டும் உருவாக்கினோம். திருத்தத்திற்கு முன், வெளியீடு 91 வினாடிகளுக்குப் பிறகு தோல்வியடைந்தது. திருத்தத்திற்குப் பிறகு, 20 வினாடிகளில் வெளியிடப்பட்டது. துவங்கும்போதே உண்மையாக செயலிழக்கும் ஆப், எதிர்பார்த்தபடியே இன்னும் தோல்வியடைகிறது.

இதிலிருந்து நாங்கள் கற்றது

• திரும்பப் பெறுதல் புதியதற்கும் ஏற்கனவே இருப்பதற்கும் உள்ள வேறுபாட்டை அறிந்திருக்க வேண்டும். நீங்கள் உருவாக்கிய ஒன்றுக்கான “திரும்பப் பெறுதல்” என்பது நீக்குதல். ஏற்கனவே இருந்த ஒன்றுக்கான “திரும்பப் பெறுதல்” என்பது மீட்டெடுத்தல். இரண்டையும் ஒன்றாகக் கையாள்வதால்தான் ஒரு பாதுகாப்பு அம்சம் வேலை செய்யும் ஆப்பை நீக்குகிறது.
• செயல்படுவதற்கு முன்பே, எப்படித் திரும்பப் பெறுவது என்பதை எழுதி வையுங்கள். ஒரு படி வெற்றி பெற்ற பின்னரே திரும்பப் பெறுதல் பதிவு செய்யப்பட்டால், பாதியில் தோல்வியடையும் ஒரு படிக்கு திரும்பப் பெற எதுவும் இருக்காது.
• நீங்கள் சார்ந்திருக்கும் ஒரு கோரிக்கைக்கான பதிலை ஒருபோதும் புறக்கணிக்காதீர்கள். ஒரு புறக்கணிக்கப்பட்ட “இல்லை” ஆரோக்கியமான ஒரு ஆப்பை தோல்வியடைந்த வெளியீடாக மாற்றியது.

அதே நாளின் தொடர்புடைய ஒரு திருத்தம்: வெளியிட்ட உடனே செயலிழக்கும் ஆப்புகளைப் பிடிப்பது. உங்கள் பக்கத்தில் வெளியீடு தோல்வியடையும்போது என்ன நடக்கும் என்பதற்கு, ஆவணங்களில் வெளியீட்டுச் சிக்கல் தீர்வு பார்க்கலாம்.