🥇3-வழி ஒன்றிணைப்பு: ஹெல்முடன் குபெர்னெட்டஸுக்கு "ஸ்டெராய்டுகளில்" பயன்படுத்துதல்

நாங்கள் (நாம் மட்டுமல்ல) நீண்ட காலமாக காத்திருந்தது நடந்தது: வெர்ஃப், பயன்பாடுகளை உருவாக்குவதற்கும் அவற்றை குபெர்னெட்டஸுக்கு வழங்குவதற்கும் எங்கள் திறந்த மூலப் பயன்பாடானது, இப்போது 3-வே மெர்ஜ் பேட்ச்களைப் பயன்படுத்தி மாற்றங்களைப் பயன்படுத்துவதை ஆதரிக்கிறது! இது தவிர, இந்த ஆதாரங்களை மீண்டும் உருவாக்காமல், ஏற்கனவே உள்ள K8s வளங்களை ஹெல்ம் வெளியீடுகளில் ஏற்றுக்கொள்ள முடியும்.

இது மிகவும் குறுகியதாக இருந்தால், நாங்கள் வைக்கிறோம் WERF_THREE_WAY_MERGE=enabled — நாங்கள் வரிசைப்படுத்தலைப் பெறுகிறோம் kubectl apply», совместимый с существующими инсталляциями на Helm 2 и даже немного больше.

ஆனால் கோட்பாட்டுடன் ஆரம்பிக்கலாம்: சரியாக 3-வழி-இணைப்பு இணைப்புகள் என்றால் என்ன, அவற்றை உருவாக்குவதற்கான அணுகுமுறையை மக்கள் எவ்வாறு கொண்டு வந்தனர், குபெர்னெட்ஸ் அடிப்படையிலான உள்கட்டமைப்புடன் கூடிய CI/CD செயல்முறைகளில் அவை ஏன் முக்கியமானவை? அதன் பிறகு, 3-way-merge in werf என்ன, முன்னிருப்பாக என்ன பயன்முறைகள் பயன்படுத்தப்படுகின்றன மற்றும் அதை எவ்வாறு நிர்வகிப்பது என்பதைப் பார்ப்போம்.

3-வே-மெர்ஜ் பேட்ச் என்றால் என்ன?

எனவே, YAML மெனிஃபெஸ்ட்டில் விவரிக்கப்பட்டுள்ள வளங்களை குபெர்னெட்டஸில் வெளியிடும் பணியுடன் தொடங்குவோம்.

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

kubectl கட்டாய கட்டளைகள்

Kubernetes இல் பொருட்களை நிர்வகிப்பதற்கான முதல் அணுகுமுறை, அந்த பொருட்களை உருவாக்க, மாற்ற மற்றும் நீக்க, kubectl கட்டாய கட்டளைகளைப் பயன்படுத்துவதாகும். எளிமையாக வை:

அணி kubectl run நீங்கள் வரிசைப்படுத்தல் அல்லது வேலையை இயக்கலாம்:
```
kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE
```
அணி kubectl scale - பிரதிகளின் எண்ணிக்கையை மாற்றவும்:
```
kubectl scale --replicas=3 deployment/mysql
```
மற்றும் பல.

இந்த அணுகுமுறை முதல் பார்வையில் வசதியானதாக தோன்றலாம். இருப்பினும், சிக்கல்கள் உள்ளன:

இது கடினமானது தானியங்கு.
எப்படி கட்டமைப்பை பிரதிபலிக்கிறது Git இல்? கிளஸ்டரில் ஏற்படும் மாற்றங்களை எவ்வாறு மதிப்பாய்வு செய்வது?
எப்படி வழங்குவது மறுஉருவாக்கம் конфигурации при перезапуске?
...

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

செயல்பாடுகளை உருவாக்கவும், பெறவும், மாற்றவும் மற்றும் நீக்கவும்

முதன்மையுடன் உருவாக்கம் இது எளிதானது: செயல்பாட்டிற்கு மேனிஃபெஸ்ட்டை அனுப்பவும் create kube api மற்றும் வளம் உருவாக்கப்பட்டது. மேனிஃபெஸ்ட்டின் YAML பிரதிநிதித்துவத்தை Git இல் சேமிக்கலாம் மற்றும் கட்டளையைப் பயன்படுத்தி உருவாக்கலாம் kubectl create -f manifest.yaml.

С நீக்குதல் எளிமையானது: அதையே மாற்றவும் manifest.yaml Git முதல் அணி வரை kubectl delete -f manifest.yaml.

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

Чтобы хранить конфигурацию в Git и обновлять с помощью replace, надо делать операцию get, Git இலிருந்து கட்டமைப்பை நாம் பெற்றவற்றுடன் இணைத்து, செயல்படுத்தவும் replace. இயல்பாக, kubectl கட்டளையைப் பயன்படுத்த மட்டுமே உங்களை அனுமதிக்கிறது kubectl replace -f manifest.yamlஅங்கு manifest.yaml — ஏற்கனவே முழுமையாக தயாரிக்கப்பட்ட (எங்கள் விஷயத்தில், ஒன்றிணைக்கப்பட்ட) மேனிஃபெஸ்ட் நிறுவப்பட வேண்டும். பயனர் ஒன்றிணைப்பு மேனிஃபெஸ்ட்டைச் செயல்படுத்த வேண்டும் என்று மாறிவிடும், இது ஒரு சிறிய விஷயம் அல்ல...

என்றாலும் என்பதும் குறிப்பிடத்தக்கது manifest.yaml மற்றும் Git இல் சேமிக்கப்படுகிறது, ஒரு பொருளை உருவாக்குவது அல்லது புதுப்பிக்க வேண்டுமா என்பதை முன்கூட்டியே அறிய முடியாது - இது பயனர் மென்பொருளால் செய்யப்பட வேண்டும்.

மொத்தம்: நாம் ஒரு தொடர்ச்சியான வெளியீட்டை உருவாக்க முடியுமா? உருவாக்குதல், மாற்றுதல் மற்றும் நீக்குதல் ஆகியவற்றைப் பயன்படுத்தி, உள்கட்டமைப்பு உள்ளமைவு குறியீடு மற்றும் வசதியான CI/CD உடன் Git இல் சேமிக்கப்படுவதை உறுதிசெய்கிறதா?

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

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

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

இருப்பினும், kube-apiserver ஆதாரங்களைப் புதுப்பிக்க மற்றொரு வழியை வழங்கும் போது சக்கரத்தை ஏன் மீண்டும் கண்டுபிடிக்க வேண்டும்: செயல்பாடு patch, விவரிக்கப்பட்ட சில சிக்கல்களில் இருந்து பயனரை விடுவிப்பது எது?

பேட்ச்

இப்போது நாம் இணைப்புகளுக்கு வருவோம்.

குபெர்னெட்டஸில் இருக்கும் பொருட்களில் மாற்றங்களைப் பயன்படுத்துவதற்கான முதன்மை வழி பேட்சுகள் ஆகும். ஆபரேஷன் patch இது இப்படி வேலை செய்கிறது:

kube-apiserver பயனர் JSON வடிவத்தில் ஒரு பேட்சை அனுப்ப வேண்டும் மற்றும் பொருளைக் குறிப்பிட வேண்டும்,
மற்றும் apiserver தானே பொருளின் தற்போதைய நிலையை சமாளித்து தேவையான வடிவத்திற்கு கொண்டு வரும்.

இந்த விஷயத்தில் நம்பிக்கையான பூட்டுதல் தேவையில்லை. முதலில் இது வேறு விதமாகத் தோன்றினாலும், இந்தச் செயல்பாடு மாற்றியமைப்பதைக் காட்டிலும் மிகவும் பிரகடனமானது.

இந்த வழியில்:

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

இருப்பினும், இதைச் செய்ய, நீங்கள் உருவாக்க வேண்டும் சரியான இணைப்பு!

ஹெல்ம் 2 இல் பேட்ச்கள் எப்படி வேலை செய்கின்றன: 2-வே-மெர்ஜ்

நீங்கள் முதலில் ஒரு வெளியீட்டை நிறுவும் போது, ஹெல்ம் செயல்பாட்டைச் செய்கிறது create விளக்கப்பட ஆதாரங்களுக்கு.

ஒவ்வொரு ஆதாரத்திற்கும் ஹெல்ம் வெளியீட்டைப் புதுப்பிக்கும்போது:

முந்தைய விளக்கப்படத்திலிருந்து ஆதாரப் பதிப்பிற்கும் தற்போதைய விளக்கப்படப் பதிப்பிற்கும் இடையே உள்ள பேட்சைக் கருதுகிறது,
இந்த இணைப்பு பொருந்தும்.

இதை பேட்ச் என்று அழைப்போம் 2-வழி இணைப்பு இணைப்பு, ஏனெனில் 2 அறிக்கைகள் அதன் உருவாக்கத்தில் ஈடுபட்டுள்ளன:

முந்தைய வெளியீட்டில் இருந்து ஆதாரம் வெளிப்படுத்தப்பட்டது,
தற்போதைய வளத்திலிருந்து ஆதாரம் வெளிப்படுகிறது.

செயல்பாட்டை அகற்றும் போது delete kube apiserver இல் முந்தைய வெளியீட்டில் அறிவிக்கப்பட்ட ஆதாரங்களுக்கு அழைக்கப்படுகிறது, ஆனால் தற்போதைய ஒன்றில் அறிவிக்கப்படவில்லை.

Подход с 2 way merge patch имеет проблему: он приводит к கிளஸ்டரில் உள்ள வளத்தின் உண்மையான நிலை மற்றும் Git இல் உள்ள மேனிஃபெஸ்ட் ஆகியவற்றுடன் ஒத்திசைக்கப்படவில்லை.

Иллюстрация проблемы на примере

Git இல், ஒரு விளக்கப்படம் புலத்தில் உள்ள மேனிஃபெஸ்ட்டைச் சேமிக்கிறது image у Deployment имеет значение ubuntu:18.04.
பயனர் மூலம் kubectl edit இந்த புலத்தின் மதிப்பை மாற்றியது ubuntu:19.04.
ஹெல்ம் விளக்கப்படத்தை மீண்டும் வரிசைப்படுத்தும்போது не генерирует патч, ஏனெனில் புலம் image வெளியீட்டின் முந்தைய பதிப்பிலும் தற்போதைய விளக்கப்படத்திலும் ஒரே மாதிரியானவை.
மீண்டும் வரிசைப்படுத்தப்பட்ட பிறகு image உள்ளது ubuntu:19.04, விளக்கப்படம் கூறினாலும் ubuntu:18.04.

நாங்கள் ஒத்திசைவு மற்றும் அறிவிப்பை இழந்தோம்.

ஒத்திசைக்கப்பட்ட வளம் என்றால் என்ன?

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

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

3-வழி இணைப்பு இணைப்பு

முக்கிய யோசனை 3-வழி இணைப்பு இணைப்பு: Git இலிருந்து மேனிஃபெஸ்ட்டின் கடைசியாகப் பயன்படுத்தப்பட்ட பதிப்பிற்கும் Git இலிருந்து மேனிஃபெஸ்ட்டின் இலக்குப் பதிப்பிற்கும் இடையே ஒரு பேட்சை உருவாக்குகிறோம். இதன் விளைவாக வரும் இணைப்பு ஒத்திசைக்கப்பட்ட ஆதார விதிக்கு இணங்க வேண்டும்:

இலக்கு பதிப்பில் சேர்க்கப்பட்ட புதிய புலங்கள் ஒரு பேட்சைப் பயன்படுத்தி சேர்க்கப்படுகின்றன;
கடைசியாகப் பயன்படுத்தப்பட்ட பதிப்பில் ஏற்கனவே உள்ள புலங்கள் மற்றும் இலக்கு பதிப்பில் இல்லாதவை பேட்சைப் பயன்படுத்தி மீட்டமைக்கப்படுகின்றன;
மேனிஃபெஸ்ட்டின் இலக்குப் பதிப்பிலிருந்து வேறுபட்ட பொருளின் தற்போதைய பதிப்பில் உள்ள புலங்கள் பேட்சைப் பயன்படுத்தி புதுப்பிக்கப்படும்.

Именно по такому принципу генерирует патчи kubectl apply:

மேனிஃபெஸ்ட்டின் கடைசிப் பயன்படுத்தப்பட்ட பதிப்பு, பொருளின் சிறுகுறிப்பில் சேமிக்கப்படுகிறது,
இலக்கு - குறிப்பிட்ட YAML கோப்பிலிருந்து எடுக்கப்பட்டது,
தற்போதையது இயங்கும் கிளஸ்டரிலிருந்து வந்தது.

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

werf இல் மாற்றங்களைப் பயன்படுத்துதல்

முன்னதாக, ஹெல்ம் 2 போன்ற வெர்ஃப், 2-வே-மெர்ஜ் பேட்ச்களைப் பயன்படுத்தியது.

பழுது இணைப்பு

புதிய வகை இணைப்புகளுக்கு மாறுவதற்காக - 3-வே-மெர்ஜ் - முதல் படி என்று அழைக்கப்படும் பழுது இணைப்புகள்.

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

ஒத்திசைவு நீக்கம் ஏற்பட்டால், வரிசைப்படுத்தலின் முடிவில், பயனர் தொடர்புடைய செய்தியுடன் ஒரு எச்சரிக்கையைப் பெறுவார் மற்றும் ஆதாரத்தை ஒத்திசைக்கப்பட்ட படிவத்திற்குக் கொண்டுவருவதற்குப் பயன்படுத்தப்பட வேண்டும். இந்த இணைப்பு ஒரு சிறப்பு சிறுகுறிப்பில் பதிவு செய்யப்பட்டுள்ளது werf.io/repair-patch. இது பயனரின் கைகள் என்று கருதப்படுகிறது сам применит этот патч: werf его применять не будет принципиально.

Генерация repair-патчей — это временная мера, которая позволяет испытать на деле создание патчей по принципу 3-way-merge, но автоматически эти патчи не применять. На данный момент такой режим работы включен по умолчанию.

புதிய வெளியீடுகளுக்கு மட்டும் 3-வே-மெர்ஜ் பேட்ச்

டிசம்பர் 1, 2019 முதல், வேர்ஃபின் பீட்டா மற்றும் ஆல்பா பதிப்புகள் தொடங்கும் இயல்பாக வெர்ஃப் மூலம் வெளியிடப்பட்ட புதிய ஹெல்ம் வெளியீடுகளுக்கு மட்டுமே மாற்றங்களைப் பயன்படுத்த முழு அளவிலான 3-வழி-ஒன்றிணைப்பு இணைப்புகளைப் பயன்படுத்தவும். தற்போதுள்ள வெளியீடுகள் 2-வே-மெர்ஜ் + ரிப்பேர் பேட்ச் அணுகுமுறையை தொடர்ந்து பயன்படுத்தும்.

இந்த இயக்க முறைமை அமைப்பதன் மூலம் வெளிப்படையாக இயக்கப்படும் WERF_THREE_WAY_MERGE_MODE=onlyNewReleases இப்போது.

கருத்து: இந்த அம்சம் பல வெளியீடுகளில் werf இல் தோன்றியது: ஆல்பா சேனலில் இது பதிப்புடன் தயாராகிவிட்டது v1.0.5-alpha.19, а в бета-канале — с v1.0.4-பீட்டா.20.

அனைத்து வெளியீடுகளுக்கும் 3-வழி-இணைப்பு இணைப்பு

டிசம்பர் 15, 2019 முதல், werf இன் பீட்டா மற்றும் ஆல்பா பதிப்புகள் எல்லா வெளியீடுகளிலும் மாற்றங்களைப் பயன்படுத்த இயல்புநிலையாக முழு 3-வழி-இணைப்பு இணைப்புகளைப் பயன்படுத்தத் தொடங்குகின்றன.

இந்த இயக்க முறைமை அமைப்பதன் மூலம் வெளிப்படையாக இயக்கப்படும் WERF_THREE_WAY_MERGE_MODE=enabled இப்போது.

ரிசோர்ஸ் ஆட்டோஸ்கேலிங்கில் என்ன செய்வது?

குபெர்னெட்டஸில் 2 வகையான ஆட்டோஸ்கேலிங் உள்ளன: HPA (கிடைமட்ட) மற்றும் VPA (செங்குத்து).

கிடைமட்டமானது தானாகவே பிரதிகளின் எண்ணிக்கையைத் தேர்ந்தெடுக்கிறது, செங்குத்து - வளங்களின் எண்ணிக்கை. பிரதிகளின் எண்ணிக்கை மற்றும் ஆதாரத் தேவைகள் இரண்டும் ஆதார மேனிஃபெஸ்டில் குறிப்பிடப்பட்டுள்ளன (வள மேனிஃபெஸ்டைப் பார்க்கவும்). spec.replicas அல்லது spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и другие).

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

Решений у проблемы два. Для начала лучше всего отказаться от явного указания автомасштабируемых значений в манифесте чарта. Если же этот вариант по каким-то причинам не подходит (например, потому что в чарте удобно задать начальные ограничения ресурсов и количество реплик), то werf предлагает следующие аннотации:

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

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

மேலும் விவரங்களுக்கு, திட்ட ஆவணங்களைப் பார்க்கவும் HPA и VPA.

3-வே-மெர்ஜ் பேட்சைப் பயன்படுத்துவதைத் தடைசெய்க

Пользователь пока может запретить использование новых патчей в werf с помощью переменной окружения WERF_THREE_WAY_MERGE_MODE=disabled. இருப்பினும், தொடங்குகிறது மார்ச் 1, 2020 முதல் இந்தத் தடை செல்லாது. மேலும் 3-வே-மெர்ஜ் பேட்ச்களை மட்டுமே பயன்படுத்த முடியும்.

werf இல் வளங்களை ஏற்றுக்கொள்வது

3-வே-மெர்ஜ் பேட்ச்களுடன் மாற்றங்களைப் பயன்படுத்துவதற்கான முறையை மாஸ்டர் செய்வது, ஹெல்ம் வெளியீட்டில் கிளஸ்டரில் இருக்கும் ஆதாரங்களை ஏற்றுக்கொள்வது போன்ற அம்சத்தை உடனடியாக செயல்படுத்த எங்களுக்கு அனுமதித்தது.

ஹெல்ம் 2 இல் ஒரு சிக்கல் உள்ளது: இந்த ஆதாரத்தை புதிதாக உருவாக்காமல், ஏற்கனவே கிளஸ்டரில் உள்ள விளக்கப்பட மேனிஃபெஸ்ட்களில் ஒரு ஆதாரத்தைச் சேர்க்க முடியாது (பார்க்க. #6031, #3275) தற்போதுள்ள ஆதாரங்களை வெளியிடுவதற்கு ஏற்றுக்கொள்வதை வெர்ஃபுக்கு கற்றுக் கொடுத்தோம். இதைச் செய்ய, இயங்கும் கிளஸ்டரிலிருந்து வளத்தின் தற்போதைய பதிப்பில் ஒரு சிறுகுறிப்பை நிறுவ வேண்டும் (எடுத்துக்காட்டாக, பயன்படுத்தி kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

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

கருத்து: அமைத்தல் WERF_THREE_WAY_MERGE_MODE வளங்களை ஏற்றுக்கொள்வதை பாதிக்காது - தத்தெடுப்பு விஷயத்தில், 3-வழி-இணைப்பு இணைப்பு எப்போதும் பயன்படுத்தப்படுகிறது.

விவரங்கள் - இல் ஆவணங்கள்.

முடிவுகள் மற்றும் எதிர்கால திட்டங்கள்

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

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

வள மேம்படுத்தல் முறைகள் மற்றும் தத்தெடுப்பு பற்றிய தகவல்களையும் இங்கே காணலாம் இந்த ஆவணப் பக்கம்.

ஹெல்ம் 3

சிறப்பு குறிப்புக்கு உரியது வெளியிடப்பட்டது மறுநாள் ஹெல்மின் புதிய பெரிய பதிப்பு - v3 - இது 3-வே-மெர்ஜ் பேட்ச்களைப் பயன்படுத்துகிறது மற்றும் டில்லரை நீக்குகிறது. ஹெல்மின் புதிய பதிப்பு தேவை இடம்பெயர்தல் புதிய வெளியீட்டு சேமிப்பக வடிவத்திற்கு மாற்றுவதற்கு இருக்கும் நிறுவல்கள்.

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

இருப்பினும், ஹெல்ம் 3 கோட்பேஸுக்கு வெர்ஃப் மாறுவது தவிர்க்க முடியாதது மற்றும் எதிர்காலத்தில் நடக்கும். மறைமுகமாக இது werf 1.1 அல்லது werf 1.2 ஆக இருக்கும் (தற்போது, werf இன் முக்கிய பதிப்பு 1.0 ஆகும்; werf பதிப்பு சாதனத்தைப் பற்றிய கூடுதல் தகவலுக்கு, பார்க்கவும் இங்கே) இந்த நேரத்தில், ஹெல்ம் 3 நிலைப்படுத்த நேரம் கிடைக்கும்.

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

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

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

வெர்ஃபுக்கு 3-வழி இணைப்பு: ஹெல்முடன் குபெர்னெட்டஸுக்கு "ஸ்டெராய்டுகளில்" பயன்படுத்துதல்