werf - குபெர்னெட்டஸில் உள்ள CI/CDக்கான எங்கள் கருவி (மதிப்பாய்வு மற்றும் வீடியோ அறிக்கை)

மே 27 அன்று திருவிழாவின் ஒரு பகுதியாக நடைபெற்ற DevOpsConf 2019 மாநாட்டின் பிரதான மண்டபத்தில் RIT++ 2019, “தொடர்ச்சியான டெலிவரி” பிரிவின் ஒரு பகுதியாக, “வெர்ஃப் - குபெர்னெட்டஸில் உள்ள CI/CDக்கான எங்கள் கருவி” என்ற அறிக்கை வழங்கப்பட்டது. அது அவர்களைப் பற்றி பேசுகிறது Kubernetes க்கு அனுப்பும் போது அனைவரும் எதிர்கொள்ளும் பிரச்சனைகள் மற்றும் சவால்கள், அத்துடன் உடனடியாக கவனிக்க முடியாத நுணுக்கங்கள் பற்றி. சாத்தியமான தீர்வுகளை பகுப்பாய்வு செய்வதன் மூலம், திறந்த மூலக் கருவியில் இது எவ்வாறு செயல்படுத்தப்படுகிறது என்பதைக் காட்டுகிறோம் வெர்ஃப்.

விளக்கக்காட்சியில் இருந்து, எங்கள் பயன்பாடு (முன்னர் டாப் என அறியப்பட்டது) ஒரு வரலாற்று மைல்கல்லை எட்டியுள்ளது GitHub இல் 1000 நட்சத்திரங்கள் — பல DevOps இன்ஜினியர்களின் வாழ்க்கையை எளிதாக்கும் அதன் வளர்ந்து வரும் பயனர்களின் சமூகம் என்று நாங்கள் நம்புகிறோம்.

எனவே, அறிமுகப்படுத்துவோம் அறிக்கையின் வீடியோ (~47 நிமிடங்கள், கட்டுரையை விட அதிக தகவல்) மற்றும் உரை வடிவத்தில் அதிலிருந்து முக்கிய சாறு. போ!

குபெர்னெட்டஸுக்கு குறியீட்டை வழங்குதல்

பேச்சு இனி werf பற்றி இருக்காது, ஆனால் Kubernetes இல் CI/CD பற்றியதாக இருக்கும், இது எங்கள் மென்பொருள் டோக்கர் கொள்கலன்களில் தொகுக்கப்பட்டுள்ளது என்பதைக் குறிக்கிறது. (நான் இதைப் பற்றி பேசினேன் 2016 அறிக்கை), மற்றும் K8s உற்பத்தியில் அதை இயக்க பயன்படுத்தப்படும் (இதைப் பற்றி மேலும் 2017 ஆண்டு).

குபர்னெட்டஸில் டெலிவரி எப்படி இருக்கும்?

• குறியீடு மற்றும் அதை உருவாக்குவதற்கான வழிமுறைகளுடன் ஒரு Git களஞ்சியம் உள்ளது. பயன்பாடு ஒரு டோக்கர் படத்தில் கட்டமைக்கப்பட்டு, டோக்கர் பதிவேட்டில் வெளியிடப்பட்டது.
• அதே களஞ்சியத்தில் பயன்பாட்டை எவ்வாறு வரிசைப்படுத்துவது மற்றும் இயக்குவது என்பதற்கான வழிமுறைகளும் உள்ளன. வரிசைப்படுத்தல் கட்டத்தில், இந்த வழிமுறைகள் குபெர்னெட்டஸுக்கு அனுப்பப்படுகின்றன, இது பதிவேட்டில் இருந்து விரும்பிய படத்தைப் பெற்று அதைத் தொடங்குகிறது.
• கூடுதலாக, பொதுவாக சோதனைகள் உள்ளன. ஒரு படத்தை வெளியிடும்போது இவற்றில் சிலவற்றைச் செய்யலாம். நீங்கள் (அதே வழிமுறைகளைப் பின்பற்றி) பயன்பாட்டின் நகலை (தனி K8s பெயர்வெளி அல்லது தனி கிளஸ்டரில்) வரிசைப்படுத்தலாம் மற்றும் அங்கு சோதனைகளை இயக்கலாம்.
• இறுதியாக, Git (அல்லது பொத்தான் கிளிக்) இலிருந்து நிகழ்வுகளைப் பெறும் மற்றும் அனைத்து நியமிக்கப்பட்ட நிலைகளையும் அழைக்கும் CI அமைப்பு உங்களுக்குத் தேவை: உருவாக்க, வெளியிட, வரிசைப்படுத்த, சோதனை.

இங்கே சில முக்கியமான குறிப்புகள் உள்ளன:

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

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

மேடை கட்டவும்

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

1. படத்தின் எடை முக்கியமானது, எனவே பயன்படுத்தவும் பல நிலைசெயல்பாட்டிற்கு உண்மையில் தேவையான பயன்பாட்டை மட்டும் படத்தில் விடவும்.
2. அடுக்குகளின் எண்ணிக்கை சங்கிலிகளை இணைப்பதன் மூலம் குறைக்கப்பட வேண்டும் RUN- அர்த்தத்தின் படி கட்டளைகள்.
3. இருப்பினும், இது சிக்கல்களைச் சேர்க்கிறது பிழைத்திருத்தம், ஏனெனில் சட்டசபை செயலிழக்கும்போது, ​​சிக்கலை ஏற்படுத்திய சங்கிலியிலிருந்து சரியான கட்டளையை நீங்கள் கண்டுபிடிக்க வேண்டும்.
4. சட்டசபை வேகம் முக்கியமானது, ஏனென்றால் மாற்றங்களை விரைவாகச் செய்து முடிவுகளைப் பார்க்க விரும்புகிறோம். எடுத்துக்காட்டாக, ஒவ்வொரு முறையும் நீங்கள் பயன்பாட்டை உருவாக்கும் போது மொழி நூலகங்களில் சார்புகளை மீண்டும் உருவாக்க விரும்பவில்லை.
5. பெரும்பாலும் ஒரு Git களஞ்சியத்திலிருந்து உங்களுக்குத் தேவைப்படும் பல படங்கள், இது டாக்கர்ஃபைல்களின் தொகுப்பு (அல்லது ஒரு கோப்பில் நிலைகள் என்று பெயரிடப்பட்டது) மற்றும் ஒரு பாஷ் ஸ்கிரிப்ட் ஆகியவற்றின் மூலம் தீர்க்கப்படும்.

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

1. பெரும்பாலும் சட்டசபை கட்டத்தில் நமக்கு ஏதாவது தேவை ஏற்ற (எடுத்துக்காட்டாக, மூன்றாம் தரப்பு கோப்பகத்தில் apt போன்ற கட்டளையின் முடிவை தேக்ககப்படுத்தவும்).
2. எங்களுக்கு வேண்டும் Ansible ஷெல்லில் எழுதுவதற்கு பதிலாக.
3. எங்களுக்கு வேண்டும் டோக்கர் இல்லாமல் உருவாக்கவும் (எங்களிடம் ஏற்கனவே ஒரு குபெர்னெட்ஸ் கிளஸ்டர் இருக்கும்போது, ​​​​இதற்காக எல்லாவற்றையும் உள்ளமைக்க வேண்டிய கூடுதல் மெய்நிகர் இயந்திரம் நமக்கு ஏன் தேவை? அதில் நாம் கொள்கலன்களை இயக்க முடியும்?).
4. இணை சட்டசபை, இது வெவ்வேறு வழிகளில் புரிந்து கொள்ளப்படலாம்: Dockerfile இலிருந்து வெவ்வேறு கட்டளைகள் (பல-நிலை பயன்படுத்தப்பட்டால்), ஒரே களஞ்சியத்தின் பல கமிட்கள், பல Dockerfiles.
5. விநியோகிக்கப்பட்ட சட்டசபை: "எபிமரல்" என்பதால் காய்களில் பொருட்களை சேகரிக்க விரும்புகிறோம் அவற்றின் தற்காலிக சேமிப்பு மறைந்துவிடும், அதாவது அது எங்காவது தனித்தனியாக சேமிக்கப்பட வேண்டும்.
6. இறுதியாக, ஆசைகளின் உச்சம் என்று பெயரிட்டேன் தானியங்கி: களஞ்சியத்திற்குச் சென்று, சில கட்டளைகளைத் தட்டச்சு செய்து, எப்படி, எதைச் சரியாகச் செய்ய வேண்டும் என்பதைப் பற்றிய புரிதலுடன் கூடிய ஒரு ஆயத்தப் படத்தைப் பெறுவது சிறந்ததாக இருக்கும். இருப்பினும், எல்லா நுணுக்கங்களையும் இந்த வழியில் முன்னறிவிக்க முடியும் என்று தனிப்பட்ட முறையில் எனக்குத் தெரியவில்லை.

மற்றும் இங்கே திட்டங்கள் உள்ளன:

• moby/பில்ட்கிட் - Docker Inc இலிருந்து ஒரு பில்டர் (ஏற்கனவே டோக்கரின் தற்போதைய பதிப்புகளில் ஒருங்கிணைக்கப்பட்டுள்ளது), இது அனைத்து சிக்கல்களையும் தீர்க்க முயற்சிக்கிறது;
• கனிகோ - Docker இல்லாமல் உருவாக்க உங்களை அனுமதிக்கும் Google இலிருந்து ஒரு பில்டர்;
• Buildpacks.io - CNCF இன் தானியங்கி மாயத்தை உருவாக்குவதற்கான முயற்சி மற்றும், குறிப்பாக, அடுக்குகளுக்கான மறுவடிவமைப்புடன் ஒரு சுவாரஸ்யமான தீர்வு;
• மற்றும் பிற பயன்பாடுகள், போன்ற பில்டா, genuinetools/img...

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

வெர்ஃபில் சட்டசபை

எனவே நாம் கிடைத்தது வெர்ஃப் (முன்னர் பிரபலமானது டாப் போல) - Flant நிறுவனத்திடமிருந்து ஒரு திறந்த மூல பயன்பாடு, நாங்கள் பல ஆண்டுகளாக செய்து வருகிறோம். இது அனைத்தும் 5 ஆண்டுகளுக்கு முன்பு டாக்கர்ஃபைல்களின் அசெம்பிளியை மேம்படுத்தும் பாஷ் ஸ்கிரிப்ட்களுடன் தொடங்கியது, மேலும் கடந்த 3 ஆண்டுகளாக முழு அளவிலான வளர்ச்சி அதன் சொந்த ஜிட் களஞ்சியத்துடன் ஒரு திட்டத்தின் கட்டமைப்பிற்குள் மேற்கொள்ளப்படுகிறது. (முதலில் ரூபியில், பின்னர் மீண்டும் எழுதப்பட்டது செல்ல, அதே நேரத்தில் மறுபெயரிடப்பட்டது). werf இல் என்ன சட்டசபை சிக்கல்கள் தீர்க்கப்படுகின்றன?

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

பதிவேட்டில் வெளியீட்டின் நிலை (வெளியீடு)

டயல் செய்தோம் docker push... - பதிவேட்டில் ஒரு படத்தை பதிவேற்றுவதில் என்ன கடினமாக இருக்கலாம்? பின்னர் கேள்வி எழுகிறது: "படத்தில் நான் என்ன குறிச்சொல்லை வைக்க வேண்டும்?" நம்மிடம் உள்ள காரணத்திற்காக இது எழுகிறது Gitflow (அல்லது பிற Git உத்தி) மற்றும் Kubernetes, மற்றும் தொழில்துறையானது குபெர்னெட்டஸில் நடப்பது Gitல் நடப்பதைப் பின்பற்றுவதை உறுதிசெய்ய முயற்சிக்கிறது. எல்லாவற்றிற்கும் மேலாக, கிட் மட்டுமே எங்களின் உண்மையின் ஆதாரம்.

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

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

குறியிடும் உத்திகள்

முதலாவது எளிமையானது git டேக். என குறியிடப்பட்ட படத்துடன் கூடிய பதிவேடு எங்களிடம் உள்ளது 1.0. குபெர்னெட்டஸ் மேடை மற்றும் தயாரிப்பைக் கொண்டுள்ளது, அங்கு இந்தப் படம் பதிவேற்றப்பட்டது. Git இல் நாம் உறுதிமொழிகளைச் செய்கிறோம் மற்றும் ஒரு கட்டத்தில் குறியிடுகிறோம் 2.0. களஞ்சியத்திலிருந்து வரும் வழிமுறைகளின்படி அதை சேகரித்து, குறிச்சொல்லுடன் பதிவேட்டில் வைக்கிறோம் 2.0. நாங்கள் அதை மேடையில் உருட்டுகிறோம், எல்லாம் நன்றாக இருந்தால், பின்னர் உற்பத்திக்கு.

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

இரண்டாவது விருப்பம் - git உறுதி + குறிச்சொல். முதன்மைக் கிளைக்கு ஒரு குறிச்சொல் உள்ளது 1.0; பதிவேட்டில் அதற்கான - ஒரு படம் உற்பத்திக்கு பயன்படுத்தப்பட்டது. கூடுதலாக, குபெர்னெட்ஸ் கிளஸ்டரில் முன்னோட்டம் மற்றும் ஸ்டேஜிங் வரையறைகள் உள்ளன. அடுத்து நாம் Gitflow ஐப் பின்தொடர்கிறோம்: மேம்பாட்டிற்கான முக்கிய கிளையில் (develop) நாங்கள் புதிய அம்சங்களை உருவாக்குகிறோம், இதன் விளைவாக அடையாளங்காட்டியுடன் உறுதியளிக்கிறோம் #c1. நாங்கள் அதை சேகரித்து, இந்த அடையாளங்காட்டியைப் பயன்படுத்தி பதிவேட்டில் வெளியிடுகிறோம் (#c1) அதே அடையாளங்காட்டியுடன் நாங்கள் முன்னோட்டத்திற்குச் செல்கிறோம். கமிட்களிலும் நாங்கள் அதையே செய்கிறோம் #c2 и #c3.

போதுமான அம்சங்கள் உள்ளன என்பதை நாம் உணர்ந்தவுடன், எல்லாவற்றையும் உறுதிப்படுத்தத் தொடங்குகிறோம். Git இல் ஒரு கிளையை உருவாக்கவும் release_1.1 (அடிப்படையில் #c3 из develop) இந்த வெளியீட்டை சேகரிக்க வேண்டிய அவசியம் இல்லை, ஏனென்றால்... இது முந்தைய கட்டத்தில் செய்யப்பட்டது. எனவே, நாம் அதை வெறுமனே மேடைக்கு உருட்டலாம். பிழைகளை சரிசெய்கிறோம் #c4 மற்றும் இதேபோல் ஸ்டேஜிங்கிற்கு வெளியே செல்லவும். அதே நேரத்தில், வளர்ச்சியும் நடந்து வருகிறது develop, மாற்றங்கள் அவ்வப்போது எடுக்கப்படும் release_1.1. ஒரு கட்டத்தில், நாங்கள் ஒரு உறுதிமொழியை தொகுத்து மேடையில் பதிவேற்றம் செய்கிறோம், அதில் நாங்கள் மகிழ்ச்சியடைகிறோம் (#c25).

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

ஸ்டேஜிங்கில் ஒரே ஒரு படம் பதிவேற்றப்பட்டதில் குறைபாடு உள்ளது (#c25), மற்றும் உற்பத்தியில் இது வேறுபட்டது (1.1), ஆனால் "உடல் ரீதியாக" இவை பதிவேட்டில் இருந்து அதே படம் என்பதை நாங்கள் அறிவோம்.

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

நாம் இன்னும் மேலே சென்று ஒரு தந்திரம் செய்யலாம்... ஒரு எளிய Dockerfile இன் உதாரணத்தைப் பார்ப்போம்:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

பின்வரும் கொள்கையின்படி அதிலிருந்து ஒரு கோப்பை உருவாக்குவோம்:

• SHA256 பயன்படுத்திய படங்களின் அடையாளங்காட்டிகளில் இருந்து (ruby:2.3 и nginx:alpine), அவை அவற்றின் உள்ளடக்கங்களின் செக்சம்கள்;
• அனைத்து அணிகள் (RUN, CMD மற்றும் பல.);
• சேர்க்கப்பட்ட கோப்புகளிலிருந்து SHA256.

... மற்றும் அத்தகைய கோப்பிலிருந்து செக்சம் (மீண்டும் SHA256) எடுக்கவும். இது கையெழுத்து டோக்கர் படத்தின் உள்ளடக்கங்களை வரையறுக்கும் அனைத்தும்.

வரைபடத்திற்கு திரும்புவோம் மற்றும் உறுதிமொழிகளுக்குப் பதிலாக அத்தகைய கையொப்பங்களைப் பயன்படுத்துவோம், அதாவது கையொப்பங்களுடன் படங்களைக் குறிக்கவும்.

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

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

werf இல் குறியிடுதல்

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

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

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

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

பதிவேட்டை சுத்தம் செய்தல்

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

சுத்தம் செய்யும் உத்திகள் என்ன?

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

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

நாம் என்ன வந்தோம் வெர்ஃப்? நாங்கள் சேகரிக்கிறோம்:

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

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

வரிசைப்படுத்து நிலை

நம்பகமான அறிவிப்பு

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

1. அடையாளங்காட்டிகள்;
2. சேவை தகவல்;
3. பல இயல்புநிலை மதிப்புகள்;
4. தற்போதைய நிலை கொண்ட பிரிவு;
5. சேர்க்கை வெப்ஹூக்கின் ஒரு பகுதியாக செய்யப்பட்ட மாற்றங்கள்;
6. பல்வேறு கட்டுப்படுத்திகளின் (மற்றும் திட்டமிடுபவர்) வேலையின் விளைவு.

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

இந்த அணுகுமுறை அழைக்கப்படுகிறது 2-வழி இணைப்பு. இது ஹெல்மில் பயன்படுத்தப்படுகிறது.

கூட உள்ளது 3-வழி இணைப்பு, இதில் வேறுபடுகிறது:

• ஒப்பிடுதல் கடைசியாக விண்ணப்பித்தது и புதிய, நீக்கப்பட்டதைப் பார்க்கிறோம்;
• ஒப்பிடுதல் புதிய и வாழ, என்ன சேர்க்கப்பட்டது அல்லது மாற்றப்பட்டது என்பதைப் பார்க்கிறோம்;
• சுருக்கப்பட்ட இணைப்பு பயன்படுத்தப்படுகிறது வாழ.

ஹெல்முடன் 1000+ பயன்பாடுகளை நாங்கள் பயன்படுத்துகிறோம், எனவே நாங்கள் உண்மையில் 2-வழி இணைப்பில் வாழ்கிறோம். எவ்வாறாயினும், ஹெல்ம் சாதாரணமாக வேலை செய்ய உதவும் பல சிக்கல்களை நாங்கள் எங்கள் இணைப்புகளுடன் தீர்த்துள்ளோம்.

உண்மையான வெளியீடு நிலை

எங்கள் CI அமைப்பு அடுத்த நிகழ்வின் அடிப்படையில் Kubernetes க்கான புதிய உள்ளமைவை உருவாக்கிய பிறகு, அது அதை பயன்பாட்டிற்கு அனுப்புகிறது (விண்ணப்பிக்கவும்) ஒரு கிளஸ்டருக்கு - ஹெல்ம் பயன்படுத்தி அல்லது kubectl apply. அடுத்து, ஏற்கனவே விவரிக்கப்பட்ட N-வழி இணைப்பு நிகழ்கிறது, இதற்கு Kubernetes API CI அமைப்புக்கும், அதன் பயனருக்கும் ஒப்புதல் அளிக்கும் வகையில் பதிலளிக்கிறது.

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

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

வெர்ஃப் மட்டத்தில் இந்த டிராக்கரின் நடத்தை, வரிசைப்படுத்தல்கள் அல்லது ஸ்டேட்ஃபுல்செட்களில் வைக்கப்பட்டுள்ள சிறுகுறிப்புகளைப் பயன்படுத்தி கட்டமைக்கப்படுகிறது. முக்கிய குறிப்பு - fail-mode - பின்வரும் அர்த்தங்களைப் புரிந்துகொள்கிறது:

• IgnoreAndContinueDeployProcess - இந்த கூறுகளை உருட்டுவதில் உள்ள சிக்கல்களை நாங்கள் புறக்கணித்து, வரிசைப்படுத்தலைத் தொடர்கிறோம்;
• FailWholeDeployProcessImmediately - இந்த கூறுகளில் ஒரு பிழை வரிசைப்படுத்தல் செயல்முறையை நிறுத்துகிறது;
• HopeUntilEndOfDeployProcess — இந்த கூறு வரிசைப்படுத்தலின் முடிவில் வேலை செய்யும் என்று நம்புகிறோம்.

எடுத்துக்காட்டாக, இந்த வளங்கள் மற்றும் சிறுகுறிப்பு மதிப்புகளின் கலவை fail-mode:

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

வெர்ஃபில் குபெடாக் என்பதற்கு மேலும் இரண்டு சிறுகுறிப்புகள் உள்ளன:

• failures-allowed-per-replica - ஒவ்வொரு பிரதிக்கும் அனுமதிக்கப்பட்ட வீழ்ச்சிகளின் எண்ணிக்கை;
• show-logs-until - அனைத்து உருட்டப்பட்ட காய்களிலிருந்தும் (stdout இல்) பதிவுகளை வெர்ஃப் காண்பிக்கும் தருணத்தை ஒழுங்குபடுத்துகிறது. இயல்புநிலை ஆகும் PodIsReady (போட்க்கு போக்குவரத்து வரத் தொடங்கும் போது நாம் விரும்பாத செய்திகளைப் புறக்கணிக்க), ஆனால் மதிப்புகளும் செல்லுபடியாகும்: ControllerIsReady и EndOfDeploy.

வரிசைப்படுத்தலில் இருந்து வேறு என்ன வேண்டும்?

ஏற்கனவே விவரிக்கப்பட்டுள்ள இரண்டு புள்ளிகளுக்கு கூடுதலாக, நாங்கள் விரும்புகிறோம்:

• பார்க்க பதிவுகள் - மற்றும் தேவையானவை மட்டுமே, மற்றும் ஒரு வரிசையில் எல்லாம் இல்லை;
• தடம் முன்னேற்றம், ஏனெனில் வேலை பல நிமிடங்களுக்கு "அமைதியாக" தொங்கினால், அங்கு என்ன நடக்கிறது என்பதைப் புரிந்துகொள்வது முக்கியம்;
• иметь தானியங்கி திரும்புதல் ஏதேனும் தவறு நடந்தால் (எனவே வரிசைப்படுத்தலின் உண்மையான நிலையை அறிவது மிகவும் முக்கியமானது). வெளியீடு அணுவாக இருக்க வேண்டும்: ஒன்று அது இறுதிவரை செல்லும், அல்லது அனைத்தும் அதன் முந்தைய நிலைக்குத் திரும்பும்.

முடிவுகளை

ஒரு நிறுவனமாக எங்களுக்கு, விநியோகத்தின் வெவ்வேறு நிலைகளில் விவரிக்கப்பட்ட அனைத்து நுணுக்கங்களையும் செயல்படுத்த (உருவாக்க, வெளியிட, வரிசைப்படுத்த), ஒரு CI அமைப்பு மற்றும் பயன்பாடு போதுமானது. வெர்ஃப்.

ஒரு முடிவுக்கு பதிலாக:

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

வீடியோக்கள் மற்றும் ஸ்லைடுகள்

செயல்திறன் வீடியோ (~47 நிமிடங்கள்):

அறிக்கையின் விளக்கக்காட்சி:

சோசலிஸ்ட் கட்சி

எங்கள் வலைப்பதிவில் Kubernetes பற்றிய பிற அறிக்கைகள்:

• «குபெர்னெட்ஸில் ஆட்டோஸ்கேலிங் மற்றும் வள மேலாண்மை» (டிமிட்ரி ஸ்டோலியாரோவ்; ஏப்ரல் 27, 2019 அன்று “வேலைநிறுத்தம்”);
• «குபெர்னெட்டஸை விரிவுபடுத்துதல் மற்றும் நிரப்புதல்» (Andrey Polovov; ஏப்ரல் 8, 2019 செயிண்ட் ஹைலோடில்++);
• «தரவுத்தளங்கள் மற்றும் குபெர்னெட்ஸ்» (டிமிட்ரி ஸ்டோலியாரோவ்; நவம்பர் 8, 2018 ஹைலோட்++ இல்);
• «கண்காணிப்பு மற்றும் குபெர்னெட்ஸ்» (Dmitry Stolyarov; மே 28, 2018 RootConf இல்);
• «குபெர்னெட்ஸ் மற்றும் கிட்லேப் உடன் சிஐ/சிடி சிறந்த நடைமுறைகள்» (டிமிட்ரி ஸ்டோலியாரோவ்; நவம்பர் 7, 2017 ஹைலோட்++ இல்);
• «சிறிய திட்டங்களில் குபெர்னெட்டுடனான எங்கள் அனுபவம்» (Dmitry Stolyarov; ஜூன் 6, 2017 RootConf இல்).

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