🥇கன்டெய்னர் படங்களை "ஸ்மார்ட்" சுத்தம் செய்வதில் உள்ள பிரச்சனை மற்றும் அதன் தீர்வு வெர்ஃப்

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

அறிமுகம்

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

படங்களுக்கு ஒரு குறிப்பிட்ட எண்ணிக்கையிலான குறிச்சொற்களைப் பயன்படுத்தவும்;
படங்களை ஏதாவது ஒரு வழியில் சுத்தம் செய்யுங்கள்.

முதல் வரம்பு சில நேரங்களில் சிறிய அணிகளுக்கு ஏற்கத்தக்கது. டெவலப்பர்கள் போதுமான நிரந்தர குறிச்சொற்களை வைத்திருந்தால் (latest, main, test, boris முதலியன), பதிவேடு அளவு வீங்காது மற்றும் நீண்ட காலமாக அதை சுத்தம் செய்வது பற்றி நீங்கள் சிந்திக்க வேண்டியதில்லை. எல்லாவற்றிற்கும் மேலாக, அனைத்து பொருத்தமற்ற படங்களும் அழிக்கப்படுகின்றன, மேலும் சுத்தம் செய்வதற்கு எந்த வேலையும் இல்லை (எல்லாம் வழக்கமான குப்பை சேகரிப்பாளரால் செய்யப்படுகிறது).

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

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

ஆனால் ஒரு படம் பொருத்தமானதா என்பதை எப்படி தீர்மானிப்பது?

படத்தின் பொருத்தத்திற்கான அளவுகோல்கள்

பெரும்பாலான சந்தர்ப்பங்களில், முக்கிய அளவுகோல்கள்:

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

2. இரண்டாவது (குறைவான வெளிப்படையானது, ஆனால் மிகவும் முக்கியமானது மற்றும் மீண்டும் சுரண்டலுடன் தொடர்புடையது) - படங்கள் கடுமையான சிக்கல்களைக் கண்டறிந்தால் திரும்பப் பெறுவதற்குத் தேவை தற்போதைய பதிப்பில். எடுத்துக்காட்டாக, ஹெல்ம் விஷயத்தில், இவை வெளியீட்டின் சேமிக்கப்பட்ட பதிப்புகளில் பயன்படுத்தப்படும் படங்கள். (ஹெல்மில் முன்னிருப்பாக, வரம்பு 256 திருத்தங்கள் ஆகும், ஆனால் யாரும் உண்மையில் சேமிக்க வேண்டிய அவசியம் இல்லை அத்தகைய ஒரு அதிக எண்ணிக்கையிலான பதிப்புகள்? தேவைப்பட்டால் அவர்களிடம் "திரும்பவும்".

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

4. நான்காவது - படங்கள் என்று எங்கள் பயன்பாட்டின் பதிப்புகளுக்கு ஒத்திருக்கிறது, அதாவது இறுதி தயாரிப்பு: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, போன்றவை.

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

தகுதி மற்றும் ஏற்கனவே உள்ள தீர்வுகள்

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

* குறிப்பிட்ட கன்டெய்னர் ரெஜிஸ்ட்ரி செயலாக்கங்களைப் பொறுத்தது. பின்வரும் தீர்வுகளின் சாத்தியக்கூறுகளை நாங்கள் பரிசீலித்தோம்: Azure CR, Docker Hub, ECR, GCR, GitHub தொகுப்புகள், GitLab கண்டெய்னர் ரெஜிஸ்ட்ரி, Harbour Registry, JFrog Artifactory, Quay.io - செப்டம்பர்'2020 நிலவரப்படி.

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

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

முதல் இரண்டு அளவுகோல்களின் நிலைமை ஒத்ததாக உள்ளது: வெளிப்புற அமைப்பிலிருந்து தரவைப் பெறாமல் அவற்றை திருப்திப்படுத்த முடியாது - பயன்பாடுகள் பயன்படுத்தப்படும் இடம் (எங்கள் விஷயத்தில், குபெர்னெட்ஸ்).

Git இல் பணிப்பாய்வு பற்றிய விளக்கம்

நீங்கள் Git இல் இது போன்ற வேலை செய்கிறீர்கள் என்று வைத்துக்கொள்வோம்:

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

தூய்மைப்படுத்தும் கொள்கைகள் படங்களைத் தக்கவைக்க மட்டுமே அனுமதித்தால் என்ன நடக்கும் (நீக்கப்படாது) கொடுக்கப்பட்ட குறிச்சொல் பெயர்கள் மூலம்?

வெளிப்படையாக, அத்தகைய காட்சி யாரையும் மகிழ்ச்சியடையச் செய்யாது.

படங்களை நீக்காமல் இருக்க கொள்கைகள் அனுமதித்தால் என்ன மாறும்? கொடுக்கப்பட்ட நேர இடைவெளி / கடைசி கமிட்களின் எண்ணிக்கையின் படி?

இதன் விளைவாக மிகவும் சிறப்பாக உள்ளது, ஆனால் இன்னும் இலட்சியத்திலிருந்து வெகு தொலைவில் உள்ளது. எல்லாவற்றிற்கும் மேலாக, பிழைகளை பிழைத்திருத்துவதற்கு பதிவேட்டில் (அல்லது K8 களில் கூட) படங்கள் தேவைப்படும் டெவலப்பர்கள் எங்களிடம் உள்ளனர்...

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

இருப்பினும், வெவ்வேறு பதிவேடுகளைப் பயன்படுத்தி வெவ்வேறு குழுக்களுக்கான படத்தைத் தூய்மைப்படுத்துவதைத் தானியங்குபடுத்தும் உலகளாவிய தீர்வை நாங்கள் தேடுகிறோம்...

உலகளாவிய படத்தை சுத்தம் செய்வதற்கான எங்கள் பாதை

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

பதிவேட்டில் படங்களை வெளியிடுவது* (அவை கட்டமைக்கப்பட்ட உடனேயே) அத்தகைய பயன்பாட்டின் வெளிப்படையான செயல்பாடாகும். படங்கள் சேமிப்பிற்காக அங்கு வைக்கப்பட்டுள்ளதால், - உங்கள் சேமிப்பகம் வரம்பற்றதாக இல்லாவிட்டால் - அவற்றைத் தொடர்ந்து சுத்தம் செய்வதற்கு நீங்கள் பொறுப்பேற்க வேண்டும். குறிப்பிட்ட அனைத்து அளவுகோல்களையும் பூர்த்திசெய்து, இதில் வெற்றியை எவ்வாறு அடைந்தோம் என்பது மேலும் விவாதிக்கப்படும்.

* பதிவுகள் தாங்களாகவே வித்தியாசமாக இருந்தாலும் (Docker Registry, GitLab Container Registry, Harbour போன்றவை), அவற்றின் பயனர்கள் அதே பிரச்சனைகளை எதிர்கொள்கின்றனர். எங்கள் விஷயத்தில் உலகளாவிய தீர்வு பதிவேட்டை செயல்படுத்துவதை சார்ந்து இல்லை, ஏனெனில் பதிவேடுகளுக்கு வெளியே இயங்குகிறது மற்றும் அனைவருக்கும் ஒரே மாதிரியான நடத்தையை வழங்குகிறது.

நாங்கள் werf ஐ ஒரு எடுத்துக்காட்டு செயலாக்கமாகப் பயன்படுத்துகிறோம் என்றாலும், பயன்படுத்தப்படும் அணுகுமுறைகள் இதே போன்ற சிரமங்களை எதிர்கொள்ளும் மற்ற அணிகளுக்கு பயனுள்ளதாக இருக்கும் என்று நம்புகிறோம்.

அதனால் பிஸியாகி விட்டோம் வெளிப்புறம் படங்களை சுத்தம் செய்வதற்கான ஒரு பொறிமுறையை செயல்படுத்துதல் - ஏற்கனவே கொள்கலன்களுக்கான பதிவேடுகளில் கட்டமைக்கப்பட்ட அந்த திறன்களுக்கு பதிலாக. குறிச்சொற்களின் எண்ணிக்கை மற்றும் அவை உருவாக்கும் நேரம் (மேலே குறிப்பிட்டது) ஆகியவற்றிற்கான அதே பழமையான கொள்கைகளை உருவாக்க, டோக்கர் ரெஜிஸ்ட்ரி API ஐப் பயன்படுத்துவது முதல் படியாகும். அவர்களிடம் சேர்க்கப்பட்டது பயன்படுத்தப்பட்ட உள்கட்டமைப்பில் பயன்படுத்தப்படும் படங்களின் அடிப்படையில் பட்டியலை அனுமதிக்கவும், அதாவது குபெர்னெட்ஸ். பிந்தையவற்றிற்கு, பயன்படுத்தப்பட்ட அனைத்து ஆதாரங்களையும் மீண்டும் செய்யவும் மற்றும் மதிப்புகளின் பட்டியலைப் பெறவும் Kubernetes API ஐப் பயன்படுத்தினால் போதும். image.

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

குறியிடுதல் திட்டங்கள்

தொடங்குவதற்கு, இறுதிப் படம் சுத்தம் செய்வதற்குத் தேவையான தகவல்களைச் சேமிக்கும் அணுகுமுறையைத் தேர்ந்தெடுத்து, குறியிடுதல் திட்டங்களில் செயல்முறையை உருவாக்கினோம். ஒரு படத்தை வெளியிடும் போது, பயனர் குறிப்பிட்ட டேக்கிங் விருப்பத்தைத் தேர்ந்தெடுத்தார் (git-branch, git-commit அல்லது git-tag) மற்றும் தொடர்புடைய மதிப்பைப் பயன்படுத்தியது. CI அமைப்புகளில், சுற்றுச்சூழல் மாறிகளின் அடிப்படையில் இந்த மதிப்புகள் தானாகவே அமைக்கப்பட்டன. உண்மையாக இறுதிப் படம் ஒரு குறிப்பிட்ட Git primitive உடன் தொடர்புடையது, சுத்தம் செய்வதற்கு தேவையான தரவுகளை லேபிள்களில் சேமித்தல்.

இந்த அணுகுமுறை Git ஐ உண்மையின் ஒற்றை ஆதாரமாகப் பயன்படுத்த அனுமதிக்கும் கொள்கைகளின் தொகுப்பை விளைவித்தது:

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

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

புதிய அல்காரிதம்

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

புதிய துப்புரவு வழிமுறைக்கு, டேக்கிங் திட்டங்களிலிருந்து விலகி, உருவாக்க முடிவு செய்யப்பட்டது மெட்டா-பட செயல்முறை, ஒவ்வொன்றும் ஒரு கொத்து சேமிக்கிறது:

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

வேறு வார்த்தைகளில் கூறுவதானால், அது வழங்கப்பட்டது வெளியிடப்பட்ட குறிச்சொற்களை Git இல் உள்ள உறுதிகளுடன் இணைக்கிறது.

இறுதி கட்டமைப்பு மற்றும் பொது அல்காரிதம்

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

பல குறிப்புகள், அதாவது. ஸ்கேன் செய்யும் போது பயன்படுத்தப்படும் Git குறிச்சொற்கள் அல்லது Git கிளைகள்;
மற்றும் தொகுப்பிலிருந்து ஒவ்வொரு குறிப்புக்கும் தேடப்பட்ட படங்களின் வரம்பு.

விளக்குவதற்கு, இயல்புநிலை கொள்கை உள்ளமைவு இப்படித்தான் இருக்கத் தொடங்கியது:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

இந்த உள்ளமைவில் பின்வரும் விதிகளுக்கு இணங்க மூன்று கொள்கைகள் உள்ளன:

கடைசி 10 Git குறிச்சொற்களுக்கு படத்தைச் சேமிக்கவும் (குறிச்சொல் உருவாக்கிய தேதியின்படி).
கடந்த வாரத்தில் வெளியிடப்பட்ட 2 படங்களுக்கு மேல் சேமிக்க வேண்டாம்.
கிளைகளுக்கு 10 படங்களைச் சேமிக்கவும் main, staging и production.

இறுதி அல்காரிதம் பின்வரும் படிகளுக்குச் செல்கிறது:

கொள்கலன் பதிவேட்டில் இருந்து வெளிப்பாடுகளை மீட்டெடுக்கிறது.
குபர்னெட்டஸில் பயன்படுத்தப்படும் படங்களைத் தவிர்த்து, ஏனெனில் K8s API இல் வாக்களிப்பதன் மூலம் அவற்றை முன்பே தேர்ந்தெடுத்துள்ளோம்.
Git வரலாற்றை ஸ்கேன் செய்தல் மற்றும் குறிப்பிட்ட கொள்கைகளின் அடிப்படையில் படங்களைத் தவிர்த்து.
மீதமுள்ள படங்களை நீக்குகிறது.

எங்கள் விளக்கத்திற்குத் திரும்புகையில், வெர்ஃபின் விஷயத்தில் இதுதான் நடக்கிறது:

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

முடிவுக்கு

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

சோசலிஸ்ட் கட்சி

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

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

கொள்கலன் படங்களை "ஸ்மார்ட்" சுத்தம் செய்வதில் சிக்கல் மற்றும் வெர்ஃபில் அதன் தீர்வு