Quay.io இல் போஸ்ட் மார்ட்டம் கிடைக்கவில்லை

குறிப்பு. மொழிபெயர்: ஆகஸ்ட் தொடக்கத்தில், Red Hat அதன் சேவையின் பயனர்கள் முந்தைய மாதங்களில் சந்தித்த அணுகல்தன்மை சிக்கல்களைத் தீர்ப்பது பற்றி பகிரங்கமாகப் பேசியது. Quay.io (இது CoreOS ஐ வாங்கியவுடன் நிறுவனம் பெற்ற கொள்கலன் படங்களுக்கான பதிவேட்டை அடிப்படையாகக் கொண்டது). இந்தச் சேவையில் உங்கள் ஆர்வத்தைப் பொருட்படுத்தாமல், நிறுவனத்தின் SRE பொறியாளர்கள் விபத்துக்கான காரணங்களைக் கண்டறிந்து அகற்றுவதற்கான பாதையை அறிவுறுத்துகிறது.

மே 19 அன்று, அதிகாலையில் (கிழக்கு பகல் நேரம், EDT), quay.io சேவை செயலிழந்தது. மென்பொருளை உருவாக்குவதற்கும் விநியோகிப்பதற்கும் ஒரு தளமாக quay.io ஐப் பயன்படுத்தும் quay.io நுகர்வோர் மற்றும் திறந்த மூல திட்டங்கள் ஆகிய இரண்டையும் விபத்து பாதித்தது. Red Hat இருவரின் நம்பிக்கையை மதிக்கிறது.

SRE இன்ஜினியர்களின் குழு உடனடியாக ஈடுபட்டு, குவே சேவையை விரைவில் நிலைப்படுத்த முயற்சித்தது. இருப்பினும், அவர்கள் இதைச் செய்யும்போது, ​​​​வாடிக்கையாளர்கள் புதிய படங்களைத் தள்ளும் திறனை இழந்தனர், மேலும் எப்போதாவது மட்டுமே அவர்களால் ஏற்கனவே உள்ள படங்களை இழுக்க முடிந்தது. சில அறியப்படாத காரணங்களுக்காக, சேவையை முழுத் திறனுக்கு அளவிட்ட பிறகு quay.io தரவுத்தளம் தடுக்கப்பட்டது.

«என்ன மாறிவிட்டது?" - இது பொதுவாக இதுபோன்ற சந்தர்ப்பங்களில் கேட்கப்படும் முதல் கேள்வி. சிக்கலுக்கு சற்று முன், OpenShift Dedicated cluster (quay.ioஐ இயக்கும்) பதிப்பு 4.3.19க்கு புதுப்பிக்கத் தொடங்கியதை நாங்கள் கவனித்தோம். quay.io Red Hat OpenShift Dedicated (OSD) இல் இயங்குவதால், வழக்கமான புதுப்பிப்புகள் வழக்கமானவை மற்றும் ஒருபோதும் சிக்கல்களை ஏற்படுத்தவில்லை. மேலும், கடந்த ஆறு மாதங்களில், சேவையில் எந்த இடையூறும் இல்லாமல் பலமுறை குவே கிளஸ்டர்களை மேம்படுத்தியுள்ளோம்.

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

மூல காரண பகுப்பாய்வு

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

இந்த பனிச்சரிவை ஏற்படுத்தக்கூடிய தரவுத்தள போக்குவரத்தில் ஒரு வடிவத்தை அடையாளம் காண முயற்சித்தோம். இருப்பினும், பதிவுகளில் எந்த வடிவங்களையும் எங்களால் கண்டுபிடிக்க முடியவில்லை. OSD 4.3.18 உடன் புதிய கிளஸ்டர் தயாராக இருக்கும் வரை காத்திருக்கும் போது, ​​நாங்கள் quay.io பாட்களை வெளியிட தொடர்ந்து முயற்சித்து வருகிறோம். ஒவ்வொரு முறையும் கிளஸ்டர் முழு கொள்ளளவை அடையும் போது, ​​தரவுத்தளம் உறைந்துவிடும். இதன் பொருள் அனைத்து quay.io பாட்களுக்கும் கூடுதலாக RDS நிகழ்வை மறுதொடக்கம் செய்வது அவசியம்.

மாலைக்குள், சேவையை படிக்க மட்டும் பயன்முறையில் நிலைப்படுத்தி, தரவுத்தளத்தின் சுமையைக் குறைக்க, முடிந்தவரை அத்தியாவசியமற்ற செயல்பாடுகளை (உதாரணமாக, பெயர்வெளி குப்பை சேகரிப்பு) முடக்கியுள்ளோம். உறைதல் நிறுத்தப்பட்டது ஆனால் காரணம் கண்டுபிடிக்கப்படவில்லை. புதிய OSD கிளஸ்டர் தயாராக உள்ளது, நாங்கள் சேவையை மாற்றினோம், டிராஃபிக்கை இணைத்தோம் மற்றும் தொடர்ந்து கண்காணிப்போம்.

Quay.io புதிய OSD கிளஸ்டரில் நிலையாக வேலை செய்தது, எனவே நாங்கள் தரவுத்தள பதிவுகளுக்குச் சென்றோம், ஆனால் அடைப்புகளை விளக்கும் ஒரு தொடர்பைக் கண்டுபிடிக்க முடியவில்லை. Red Hat OpenShift 4.3.19 இல் மாற்றங்கள் Quay இல் சிக்கல்களை ஏற்படுத்துமா என்பதைப் புரிந்துகொள்ள OpenShift பொறியாளர்கள் எங்களுடன் இணைந்து பணியாற்றினர். இருப்பினும், எதுவும் கிடைக்கவில்லை, மற்றும் ஆய்வக நிலைமைகளில் சிக்கலை மீண்டும் உருவாக்குவது சாத்தியமில்லை.

இரண்டாவது தோல்வி

மே 28 அன்று, மதியம் EDTக்கு சற்று முன், quay.io மீண்டும் அதே அறிகுறியுடன் செயலிழந்தது: தரவுத்தளம் தடுக்கப்பட்டது. மீண்டும் நாங்கள் விசாரணையில் எங்களின் அனைத்து முயற்சிகளையும் எறிந்தோம். முதலில், சேவையை மீட்டெடுப்பது அவசியம். எனினும் இந்த முறை RDS ஐ மறுதொடக்கம் செய்து quay.io பாட்களை மறுதொடக்கம் செய்வது எதற்கும் வழிவகுக்கவில்லை: இணைப்புகளின் மற்றொரு பனிச்சரிவு அடித்தளத்தை மூழ்கடித்துள்ளது. ஆனால் ஏன்?

குவே பைத்தானில் எழுதப்பட்டுள்ளது மற்றும் ஒவ்வொரு காய்களும் ஒற்றை ஒற்றைக் கொள்கலனாக இயங்குகிறது. கொள்கலன் இயக்க நேரம் ஒரே நேரத்தில் பல இணையான பணிகளை இயக்குகிறது. நாங்கள் நூலகத்தைப் பயன்படுத்துகிறோம் gevent கீழ் gunicorn இணைய கோரிக்கைகளை செயல்படுத்த. க்வேயில் ஒரு கோரிக்கை வரும்போது (எங்கள் சொந்த ஏபிஐ வழியாக அல்லது டோக்கர் ஏபிஐ வழியாக), அதற்கு ஒரு ஜெவென்ட் வொர்க்கர் ஒதுக்கப்படும். பொதுவாக இந்த பணியாளர் தரவுத்தளத்தை தொடர்பு கொள்ள வேண்டும். முதல் தோல்விக்குப் பிறகு, இயல்புநிலை அமைப்புகளைப் பயன்படுத்தி ஜெவென்ட் தொழிலாளர்கள் தரவுத்தளத்துடன் இணைவதைக் கண்டறிந்தோம்.

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

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

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

தடுப்பதற்கு வழிவகுக்கும் சிக்கலைத் தவிர்க்க முடிந்தது, அதன் உண்மையான காரணங்களை நாங்கள் கண்டுபிடிக்கவில்லை. இது OpenShift 4.3.19 இல் எந்த மாற்றங்களுடனும் தொடர்புடையது அல்ல என்பது உறுதி செய்யப்பட்டது, ஏனெனில் இது பதிப்பு 4.3.18 இல் நடந்தது, இது முன்பு எந்த பிரச்சனையும் இல்லாமல் Quay உடன் வேலை செய்தது.

கிளஸ்டரில் வேறு ஏதோ பதுங்கி இருப்பது தெளிவாக இருந்தது.

விரிவான ஆய்வு

Quay.io ஆறு ஆண்டுகளாக எந்த பிரச்சனையும் இல்லாமல் தரவுத்தளத்துடன் இணைக்க இயல்புநிலை அமைப்புகளைப் பயன்படுத்தியது. என்ன மாறியது? இந்த நேரத்தில் quay.io இல் போக்குவரத்து சீராக வளர்ந்து வருகிறது என்பது தெளிவாகிறது. எங்கள் விஷயத்தில், சில வரம்பு மதிப்பை அடைந்தது போல் தோன்றியது, இது இணைப்புகளின் பனிச்சரிவுக்கான தூண்டுதலாக செயல்பட்டது. இரண்டாவது தோல்விக்குப் பிறகு தரவுத்தளப் பதிவுகளைத் தொடர்ந்து ஆய்வு செய்தோம், ஆனால் வடிவங்கள் அல்லது வெளிப்படையான உறவுகள் எதுவும் கிடைக்கவில்லை.

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

Quay.io ஜூன் 9 வரை நன்றாக வேலை செய்தது. இன்று காலை (EDT) தரவுத்தள இணைப்புகளின் எண்ணிக்கையில் குறிப்பிடத்தக்க அதிகரிப்பு மீண்டும் காணப்பட்டது. இந்த முறை வேலையில்லா நேரம் இல்லை, புதிய அளவுரு அவற்றின் எண்ணிக்கையை வரம்புக்குட்படுத்தியது மற்றும் MySQL செயல்திறனை மீற அனுமதிக்கவில்லை. இருப்பினும், சுமார் அரை மணி நேரம், பல பயனர்கள் quay.io இன் மெதுவான செயல்திறனைக் குறிப்பிட்டனர். சேர்க்கப்பட்ட கண்காணிப்புக் கருவிகளைப் பயன்படுத்தி சாத்தியமான எல்லா தரவையும் விரைவாகச் சேகரித்தோம். திடீரென்று ஒரு மாதிரி தோன்றியது.

இணைப்புகள் அதிகரிப்பதற்கு சற்று முன்பு, ஆப் ரெஜிஸ்ட்ரி ஏபிஐக்கு ஏராளமான கோரிக்கைகள் வந்தன. ஆப் ரெஜிஸ்ட்ரி என்பது quay.io இன் அதிகம் அறியப்படாத அம்சமாகும். ஹெல்ம் விளக்கப்படங்கள் மற்றும் பணக்கார மெட்டாடேட்டா கொண்ட கொள்கலன்கள் போன்றவற்றைச் சேமிக்க இது உங்களை அனுமதிக்கிறது. பெரும்பாலான quay.io பயனர்கள் இந்த அம்சத்துடன் வேலை செய்யவில்லை, ஆனால் Red Hat OpenShift இதை தீவிரமாக பயன்படுத்துகிறது. OpenShift இன் ஒரு பகுதியாக OperatorHub அனைத்து ஆபரேட்டர்களையும் ஆப் ரெஜிஸ்ட்ரியில் சேமிக்கிறது. இந்த ஆபரேட்டர்கள் OpenShift பணிச்சுமை சுற்றுச்சூழல் அமைப்பு மற்றும் கூட்டாளர்-மைய இயக்க மாதிரி (நாள் 2 செயல்பாடுகள்) ஆகியவற்றின் அடிப்படையை உருவாக்குகின்றனர்.

ஒவ்வொரு OpenShift 4 கிளஸ்டரும் உள்ளமைக்கப்பட்ட OperatorHub இலிருந்து ஆபரேட்டர்களைப் பயன்படுத்தி, நிறுவலுக்குக் கிடைக்கும் ஆபரேட்டர்களின் பட்டியலை வெளியிடவும், ஏற்கனவே நிறுவப்பட்டவற்றிற்கு புதுப்பிப்புகளை வழங்கவும். OpenShift 4 இன் பிரபலமடைந்து வருவதால், உலகம் முழுவதும் உள்ள கிளஸ்டர்களின் எண்ணிக்கையும் அதிகரித்துள்ளது. இந்த கிளஸ்டர்கள் ஒவ்வொன்றும், quay.io க்குள் இருக்கும் ஆப் ரெஜிஸ்ட்ரியை பின்தளமாகப் பயன்படுத்தி, உள்ளமைக்கப்பட்ட OperatorHub ஐ இயக்க, ஆபரேட்டர் உள்ளடக்கத்தைப் பதிவிறக்குகிறது. சிக்கலின் மூலத்திற்கான எங்கள் தேடலில், OpenShift படிப்படியாக பிரபலமடைந்து வருவதால், அரிதாகப் பயன்படுத்தப்படும் quay.io செயல்பாடுகளில் ஒன்றின் சுமையும் அதிகரித்தது என்ற உண்மையை நாங்கள் தவறவிட்டோம்..

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

காரணங்களை நீக்குதல்

அடுத்த வாரத்தில், ஆப் ரெஜிஸ்ட்ரியின் குறியீட்டையும் அதன் சூழலையும் மேம்படுத்தினோம். தெளிவாக பயனற்ற SQL வினவல்கள் மறுவேலை செய்யப்பட்டன மற்றும் தேவையற்ற கட்டளை அழைப்புகள் அகற்றப்பட்டன tar (ஒவ்வொரு முறையும் ப்ளாப்களை மீட்டெடுக்கும் போது இது இயங்கும்), முடிந்தவரை கேச்சிங் சேர்க்கப்பட்டது. நாங்கள் விரிவான செயல்திறன் சோதனைகளை மேற்கொண்டோம் மற்றும் மாற்றங்களுக்கு முன்னும் பின்னும் ஆப் ரெஜிஸ்ட்ரியின் வேகத்தை ஒப்பிட்டுப் பார்த்தோம்.

முன்பு அரை நிமிடம் வரை எடுத்துக் கொண்ட API கோரிக்கைகள் இப்போது மில்லி விநாடிகளில் முடிக்கப்படுகின்றன. அடுத்த வாரம், உற்பத்தியில் மாற்றங்களைச் செய்தோம், அதன் பின்னர் quay.io நிலையானது. இந்த நேரத்தில், ஆப் ரெஜிஸ்ட்ரி எண்ட்பாயிண்டில் ட்ராஃபிக்கில் பல கூர்மையான ஸ்பைக்குகள் இருந்தன, ஆனால் செய்த மேம்பாடுகள் தரவுத்தள செயலிழப்பைத் தடுத்தன.

நாம் என்ன கற்றுக்கொண்டோம்?

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

1. உங்கள் சேவையை யார் பயன்படுத்துகிறார்கள், எப்படி பயன்படுத்துகிறார்கள் என்பது பற்றிய தரவு மிதமிஞ்சியதாக இருக்காது. Quay "இப்போது வேலை செய்ததால்," போக்குவரத்தை மேம்படுத்துவதற்கும் சுமைகளை நிர்வகிப்பதற்கும் நாங்கள் ஒருபோதும் நேரத்தை செலவிட வேண்டியதில்லை. இவை அனைத்தும் சேவையானது காலவரையின்றி அளவிடக்கூடிய தவறான பாதுகாப்பு உணர்வை உருவாக்கியது.
2. சேவை குறையும் போது, அதை மீட்டெடுத்து இயக்குவது முதன்மையானது.. முதல் செயலிழப்பின் போது க்வே பூட்டப்பட்ட தரவுத்தளத்தால் தொடர்ந்து அவதிப்பட்டதால், எங்களின் நிலையான நடைமுறைகள் எதிர்பார்த்த விளைவைக் கொண்டிருக்கவில்லை, மேலும் அவற்றைப் பயன்படுத்தி எங்களால் சேவையை மீட்டெடுக்க முடியவில்லை. செயல்பாட்டை மீட்டெடுப்பதில் அனைத்து முயற்சிகளிலும் கவனம் செலுத்துவதற்குப் பதிலாக, மூல காரணத்தைக் கண்டறியும் நம்பிக்கையில் தரவுகளை பகுப்பாய்வு செய்வதற்கும் சேகரிப்பதற்கும் நேரத்தை செலவிட வேண்டிய சூழ்நிலைக்கு இது வழிவகுத்தது.
3. ஒவ்வொரு சேவை அம்சத்தின் தாக்கத்தையும் மதிப்பீடு செய்யவும். வாடிக்கையாளர்கள் ஆப் ரெஜிஸ்ட்ரியை அரிதாகவே பயன்படுத்துகின்றனர், எனவே இது எங்கள் குழுவிற்கு முன்னுரிமை அளிக்கப்படவில்லை. சில தயாரிப்பு அம்சங்கள் அரிதாகவே பயன்படுத்தப்படும் போது, ​​அவற்றின் பிழைகள் அரிதாகவே தோன்றும், மேலும் டெவலப்பர்கள் குறியீட்டைக் கண்காணிப்பதை நிறுத்துகின்றனர். இது இப்படித்தான் இருக்க வேண்டும் என்ற தவறான கருத்துக்கு இரையாவது எளிது - திடீரென்று அந்த செயல்பாடு ஒரு பெரிய சம்பவத்தின் மையத்தில் தன்னைக் கண்டுபிடிக்கும் வரை.

அடுத்து என்ன?

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

1. முதன்மை RDS நிகழ்வில் சிக்கல்கள் ஏற்பட்டால், சேவையானது பொருத்தமான ட்ராஃபிக்கைக் கையாள உதவ, படிக்க-மட்டும் தரவுத்தளப் பிரதிகளைப் பயன்படுத்தவும்.
2. RDS நிகழ்வைப் புதுப்பிக்கிறது. தற்போதைய பதிப்பே பிரச்சனை இல்லை. மாறாக, தவறான பாதையை அகற்ற விரும்புகிறோம் (தோல்வியின் போது நாங்கள் பின்பற்றினோம்); மென்பொருளைப் புதுப்பித்த நிலையில் வைத்திருப்பது, எதிர்கால செயலிழப்புகள் ஏற்பட்டால் மற்றொரு காரணியை அகற்றும்.
3. முழு கிளஸ்டர் முழுவதும் கூடுதல் கேச்சிங். கேச்சிங் தரவுத்தளத்தில் சுமையை குறைக்கும் பகுதிகளை நாங்கள் தொடர்ந்து தேடுகிறோம்.
4. quay.io உடன் யார் இணைக்கிறார்கள், ஏன் என்று பார்க்க இணைய பயன்பாட்டு ஃபயர்வாலை (WAF) சேர்க்கிறது.
5. அடுத்த வெளியீட்டில் தொடங்கி, Red Hat OpenShift கிளஸ்டர்கள் quay.io இல் கிடைக்கும் கொள்கலன் படங்களின் அடிப்படையில் ஆபரேட்டர் பட்டியல்களுக்கு ஆதரவாக ஆப் ரெஜிஸ்ட்ரியை கைவிடும்.
6. ஆப் ரெஜிஸ்ட்ரிக்கான நீண்ட கால மாற்றமானது, திறந்த கொள்கலன் முன்முயற்சி (OCI) கலைப்பொருள் விவரக்குறிப்புகளுக்கான ஆதரவாக இருக்கலாம். இது தற்போது நேட்டிவ் க்வே செயல்பாடாக செயல்படுத்தப்பட்டு, விவரக்குறிப்பு இறுதி செய்யப்பட்டவுடன் பயனர்களுக்குக் கிடைக்கும்.

மேலே உள்ள அனைத்தும் quay.io இல் Red Hat இன் தற்போதைய முதலீட்டின் ஒரு பகுதியாகும் எங்கள் வாடிக்கையாளர்கள் பலர் தங்கள் அன்றாட வேலைகளில் (Red Hat! உட்பட) quay.io ஐ நம்பியிருப்பதை நாங்கள் அறிவோம், மேலும் சமீபத்திய செயலிழப்புகள் மற்றும் மேம்படுத்துவதற்கான முயற்சிகள் குறித்து முடிந்தவரை வெளிப்படையாக இருக்க முயற்சிக்கிறோம்.

மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

• «CoreOS கொள்கலன் படங்களுக்கான Red Hat திறந்த மூலப் பதிவேடு குறியீடு - Quay";
• «எங்கள் SRE அன்றாட வாழ்க்கையிலிருந்து நடைமுறைக் கதைகள். பகுதி 2";
• «குபெர்னெட்டஸில் உள்ள பாட் முன்னுரிமைகள் எப்படி கிராஃபானா லேப்ஸில் வேலையில்லா நேரத்தை ஏற்படுத்தியது".

ஆதாரம்: www.habr.com