வேர்ஃப் சேகரிப்பாளரில் உள்ளடக்க அடிப்படையிலான குறிச்சொல்: ஏன் மற்றும் எப்படி வேலை செய்கிறது?

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

ஒரு Git களஞ்சியத்திலிருந்து மைக்ரோ சர்வீஸின் தொகுப்பை வெளியிடுகிறது

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

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

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

Git கிளை மற்றும் Git டேக் மூலம் குறியிடுதல்

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

ஒரு புதிய Git டேக் உருவாக்கப்படும் போது - எடுத்துக்காட்டாக, ஒரு புதிய பதிப்பு வெளியிடப்படும் போது - Docker Registry இல் உள்ள அனைத்து திட்டப் படங்களுக்கும் ஒரு புதிய Docker டேக் உருவாக்கப்படும்:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

இந்தப் புதிய படப் பெயர்கள் ஹெல்ம் டெம்ப்ளேட்கள் மூலம் குபெர்னெட்ஸ் உள்ளமைவுக்கு அனுப்பப்படுகின்றன. கட்டளையுடன் வரிசைப்படுத்தலைத் தொடங்கும் போது werf deploy புலம் புதுப்பிக்கப்படுகிறது image குபெர்னெட்டஸ் வளத்தில் மாற்றப்பட்ட படத்தின் பெயர் காரணமாக தொடர்புடைய ஆதாரங்களை வெளிப்படுத்துகிறது மற்றும் மறுதொடக்கம் செய்கிறது.

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

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

Git கமிட் மூலம் குறியிடுதல்

werf ஆனது Git commits உடன் தொடர்புடைய டேக்கிங் உத்தியையும் கொண்டுள்ளது.

Git-commit என்பது Git களஞ்சியத்தின் உள்ளடக்கங்களுக்கான அடையாளங்காட்டியாகும் மற்றும் Git களஞ்சியத்தில் உள்ள கோப்புகளின் திருத்த வரலாற்றைப் பொறுத்தது, எனவே Docker Registry இல் படங்களைக் குறியிடுவதற்கு இதைப் பயன்படுத்துவது தர்க்கரீதியாகத் தெரிகிறது.

இருப்பினும், Git கமிட் மூலம் குறியிடுவது Git கிளைகள் அல்லது Git குறிச்சொற்கள் மூலம் குறியிடுவது போன்ற அதே தீமைகளைக் கொண்டுள்ளது:

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

Git கிளையின் பெயரைக் குறிப்பது படத்தின் பதிப்பைப் பிரதிபலிக்காது

Git கிளைகளுக்கான டேக்கிங் உத்தியுடன் தொடர்புடைய மற்றொரு சிக்கல் உள்ளது.

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

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

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

உள்ளடக்கம் சார்ந்த டேக்கிங் என்றால் என்ன?

எனவே, உள்ளடக்க அடிப்படையிலான டேக்கிங் என்றால் என்ன - உள்ளடக்கத்தின் அடிப்படையில் படங்களைக் குறியிடுதல்.

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

• படத்தின் உள்ளடக்கங்கள். படத்தின் ஐடி குறிச்சொல் அதன் உள்ளடக்கத்தை பிரதிபலிக்கிறது. புதிய பதிப்பை உருவாக்கும்போது, ​​படத்தில் உள்ள கோப்புகள் மாறவில்லை என்றால், இந்த அடையாளங்காட்டி மாறாது;
• Git இல் இந்தப் படத்தை உருவாக்கிய வரலாறு. வெவ்வேறு Git கிளைகளுடன் தொடர்புடைய படங்கள் மற்றும் werf வழியாக வெவ்வேறு உருவாக்க வரலாறுகள் வெவ்வேறு ஐடி குறிச்சொற்களைக் கொண்டிருக்கும்.

அத்தகைய அடையாளங்காட்டி குறிச்சொல் என்று அழைக்கப்படும் பட நிலை கையொப்பம்.

ஒவ்வொரு படமும் நிலைகளின் தொகுப்பைக் கொண்டுள்ளது: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch முதலியன ஒவ்வொரு நிலையிலும் அதன் உள்ளடக்கங்களை பிரதிபலிக்கும் அடையாளங்காட்டி உள்ளது - மேடை கையெழுத்து (மேடை கையொப்பம்).

இந்த நிலைகளைக் கொண்ட இறுதிப் படம், இந்த நிலைகளின் தொகுப்பின் கையொப்பம் என்று அழைக்கப்படுவதன் மூலம் குறிக்கப்பட்டுள்ளது - நிலைகளில் கையெழுத்து, - இது படத்தின் அனைத்து நிலைகளுக்கும் பொதுமைப்படுத்துகிறது.

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

மேடை கையொப்பம் இந்த எல்லா சிக்கல்களையும் தீர்க்கிறது:

• வெற்று Git கமிட்களுக்கு எதிர்ப்பு.
• படத்திற்குப் பொருந்தாத கோப்புகளை மாற்றும் Git க்கு எதிர்ப்பு
• கிளையின் பழைய Git கமிட்களுக்கான பில்ட்களை மறுதொடக்கம் செய்யும் போது படத்தின் தற்போதைய பதிப்பை மாற்றியமைப்பதில் சிக்கல் ஏற்படாது.

இது இப்போது பரிந்துரைக்கப்பட்ட குறியிடல் உத்தி மற்றும் அனைத்து CI அமைப்புகளுக்கும் werf இல் இயல்புநிலையாகும்.

werf இல் எவ்வாறு இயக்குவது மற்றும் பயன்படுத்துவது

கட்டளைக்கு இப்போது பொருத்தமான விருப்பம் உள்ளது werf publish: --tag-by-stages-signature=true|false

CI அமைப்பில், குறியிடல் உத்தி கட்டளையால் குறிப்பிடப்படுகிறது werf ci-env. முன்னதாக, அதற்கான அளவுரு வரையறுக்கப்பட்டது werf ci-env --tagging-strategy=tag-or-branch. இப்போது, ​​நீங்கள் குறிப்பிட்டால் werf ci-env --tagging-strategy=stages-signature அல்லது இந்த விருப்பத்தை குறிப்பிட வேண்டாம், முன்னிருப்பாக டேக்கிங் உத்தியை werf பயன்படுத்தும் stages-signature. குழு werf ci-env கட்டளைக்குத் தேவையான கொடிகளை தானாகவே அமைக்கும் werf build-and-publish (அல்லது werf publish), எனவே இந்த கட்டளைகளுக்கு கூடுதல் விருப்பங்கள் எதுவும் குறிப்பிடப்பட வேண்டியதில்லை.

உதாரணமாக, கட்டளை:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...பின்வரும் படங்களை உருவாக்கலாம்:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

இது 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d படத்தின் நிலைகளின் கையொப்பமாகும் backendமற்றும் f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - பட நிலைகளின் கையொப்பம் frontend.

சிறப்பு செயல்பாடுகளை பயன்படுத்தும் போது werf_container_image и werf_container_env ஹெல்ம் டெம்ப்ளேட்களில் எதையும் மாற்ற வேண்டிய அவசியமில்லை: இந்த செயல்பாடுகள் தானாகவே சரியான படப் பெயர்களை உருவாக்கும்.

CI அமைப்பில் உள்ளமைவின் எடுத்துக்காட்டு:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

உள்ளமைவு பற்றிய கூடுதல் தகவல்கள் ஆவணத்தில் கிடைக்கின்றன:

• அடைவு → வெளியீடு (வெளியிடு);
• CI/CD உடன் பணிபுரிதல் → பொது தகவல் → நிலைகள்-கையொப்பம்;
• GitLab CI/CD உடன் ஒருங்கிணைப்பு → .gitlab-ci.yml.

மொத்தம்

• புதிய விருப்பம் werf publish --tag-by-stages-signature=true|false.
• புதிய விருப்ப மதிப்பு werf ci-env --tagging-strategy=stages-signature|tag-or-branch (குறிப்பிடப்படவில்லை என்றால், இயல்புநிலை இருக்கும் stages-signature).
• Git commits க்கான டேக்கிங் விருப்பங்களை நீங்கள் முன்பு பயன்படுத்தியிருந்தால் (WERF_TAG_GIT_COMMIT அல்லது விருப்பம் werf publish --tag-git-commit COMMIT), பின்னர் குறியிடும் உத்திக்கு மாறுவதை உறுதி செய்யவும் நிலைகள்-கையொப்பம்.
• புதிய திட்டங்களை உடனடியாக புதிய டேக்கிங் திட்டத்திற்கு மாற்றுவது நல்லது.
• werf 1.1 க்கு மாற்றும் போது, ​​பழைய திட்டங்களை புதிய டேக்கிங் திட்டத்திற்கு மாற்றுவது நல்லது, ஆனால் பழையது குறி-அல்லது-கிளை இன்னும் ஆதரிக்கப்படுகிறது.

உள்ளடக்க அடிப்படையிலான குறியிடல் கட்டுரையில் உள்ள அனைத்து சிக்கல்களையும் தீர்க்கிறது:

• காலியான Git கமிட்களுக்கு டோக்கர் டேக் பெயர் எதிர்ப்பு.
• Git க்கு டோக்கர் டேக் பெயரின் பின்னடைவு, படத்திற்குப் பொருத்தமற்ற கோப்புகளை மாற்றுகிறது.
• Git கிளைகளுக்கான பழைய Git கமிட்களுக்கான கட்டமைப்பை மறுதொடக்கம் செய்யும் போது படத்தின் தற்போதைய பதிப்பை மாற்றியமைப்பதில் சிக்கல் ஏற்படாது.

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

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

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

• «werf 1.1 வெளியீடு: பில்டருக்கு இன்று மேம்பாடுகள் மற்றும் எதிர்காலத்திற்கான திட்டங்கள்»
• «werf 1.0 stable ஐ அறிமுகப்படுத்துகிறது: GitOps க்கும் இதற்கும் என்ன சம்பந்தம், நிலை மற்றும் திட்டங்கள்»
• «werf - குபெர்னெட்டஸில் உள்ள CI/CDக்கான எங்கள் கருவி (மதிப்பாய்வு மற்றும் வீடியோ அறிக்கை)";
• வெர்ஃபில் புதுமைகளைப் பற்றிய தொடர் குறிப்புகள்:
  • «வெர்ஃபுக்கு 3-வழி இணைப்பு: ஹெல்முடன் குபெர்னெட்டஸுக்கு "ஸ்டெராய்டுகளில்" பயன்படுத்துதல்";
  • «சிக்கலான ஹெல்ம் விளக்கப்படங்களை உருவாக்க werf ஐப் பயன்படுத்துதல்";
  • «werf இல் monorepo மற்றும் multirepo க்கான ஆதரவு மற்றும் Docker Registryக்கும் இதற்கும் என்ன சம்பந்தம்";
  • «நீங்கள் இப்போது வழக்கமான Dockerfile ஐப் பயன்படுத்தி verf இல் Docker படங்களை உருவாக்கலாம்".

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