ProHoster > බ්ලොග් > පරිපාලනය > වර්ෆ් එකතු කරන්නා තුළ අන්තර්ගත මත පදනම් වූ ටැග් කිරීම: එය ක්‍රියා කරන්නේ ඇයි සහ කෙසේද?

වර්ෆ් එකතු කරන්නා තුළ අන්තර්ගත මත පදනම් වූ ටැග් කිරීම: එය ක්‍රියා කරන්නේ ඇයි සහ කෙසේද?

වර්ෆ් එකතු කරන්නා තුළ අන්තර්ගත මත පදනම් වූ ටැග් කිරීම: එය ක්‍රියා කරන්නේ ඇයි සහ කෙසේද?

werf Kubernetes වෙත යෙදුම් තැනීම සහ බෙදා හැරීම සඳහා අපගේ විවෘත මූලාශ්‍ර GitOps CLI උපයෝගීතාව වේ. තුල නිකුත් කරන්න v1.1 පින්තූර එකතු කරන්නා තුළ නව විශේෂාංගයක් හඳුන්වා දෙන ලදී: අන්තර්ගතය අනුව පින්තූර ටැග් කිරීම හෝ අන්තර්ගතය මත පදනම් වූ ටැග් කිරීම. මේ වන තුරු, werf හි සාමාන්‍ය ටැග් කිරීමේ ක්‍රමයට Git tag, Git ශාඛාව හෝ Git commit මගින් Docker පින්තූර ටැග් කිරීම සම්බන්ධ විය. නමුත් මෙම සියලු යෝජනා ක්‍රම නව ටැග් කිරීමේ උපාය මාර්ගයෙන් සම්පූර්ණයෙන්ම විසඳන අවාසි ඇත. ඒ ගැන විස්තර සහ එය එතරම් හොඳ වන්නේ ඇයිද යන්න කපා හැර ඇත.

එක් Git ගබඩාවකින් ක්ෂුද්‍ර සේවා කට්ටලයක් පෙරළීම

යෙදුමක් වැඩි හෝ අඩු ස්වාධීන සේවාවන් වලට බෙදී ඇති විට තත්වයක් බොහෝ විට සිදු වේ. මෙම සේවාවන් නිකුත් කිරීම ස්වාධීනව සිදු විය හැක: එක් වරකට සේවා එකක් හෝ කිහිපයක් නිකුත් කළ හැකි අතර, ඉතිරිය කිසිදු වෙනසක් නොමැතිව දිගටම වැඩ කළ යුතුය. නමුත් කේත ගබඩා කිරීම සහ ව්‍යාපෘති කළමනාකරණය පිළිබඳ දෘෂ්ටි කෝණයෙන්, එවැනි යෙදුම් සේවාවන් තනි ගබඩාවක තබා ගැනීම වඩාත් පහසු වේ.

සේවාවන් සැබවින්ම ස්වාධීන වන අතර තනි යෙදුමක් සමඟ සම්බන්ධ නොවන අවස්ථා තිබේ. මෙම අවස්ථාවෙහිදී, ඒවා වෙනම ව්‍යාපෘතිවල ස්ථානගත කරනු ලබන අතර, එක් එක් ව්‍යාපෘතිවල වෙන වෙනම CI/CD ක්‍රියාවලීන් හරහා ඒවා මුදා හැරීම සිදු කෙරේ.

කෙසේ වෙතත්, යථාර්ථයේ දී, සංවර්ධකයින් බොහෝ විට තනි යෙදුමක් ක්ෂුද්‍ර සේවා කිහිපයකට බෙදා ඇත, නමුත් එක් එක් සඳහා වෙනම ගබඩාවක් සහ ව්‍යාපෘතියක් නිර්මාණය කිරීම ... පැහැදිලි අතිකි. මෙම තත්වය තවදුරටත් සාකච්ඡා කරනු ඇත: එවැනි ක්ෂුද්‍ර සේවා කිහිපයක් එක් ව්‍යාපෘති ගබඩාවක පිහිටා ඇති අතර නිකුත් කිරීම් 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

මෙම නව රූප නාමයන් Helm සැකිලි හරහා Kubernetes වින්‍යාසය වෙත යවනු ලැබේ. විධානය සමඟ යෙදවීම ආරම්භ කරන විට werf deploy ක්ෂේත්‍රය යාවත්කාලීන වෙමින් පවතී image Kubernetes සම්පතෙහි වෙනස් වූ රූපයේ නම හේතුවෙන් අනුරූප සම්පත් ප්‍රකාශ කිරීම සහ නැවත ආරම්භ කිරීම.

ප්රශ්නය: ඇත්ත වශයෙන්ම, රූපයේ අන්තර්ගතය පෙර පෙරළීමෙන් (Git ටැගය) වෙනස් වී නොමැති විට, නමුත් එහි ඩොකර් ටැගය පමණක් සිදු වේ. අමතර මෙම යෙදුම නැවත ආරම්භ කිරීම සහ, ඒ අනුව, යම් අක්‍රිය කාලයක් විය හැක. මෙම නැවත ආරම්භ කිරීමට සැබෑ හේතුවක් නොතිබුණද.

එහි ප්‍රතිඵලයක් වශයෙන්, දැනට පවතින ටැග් කිරීමේ ක්‍රමය සමඟින් වෙන වෙනම Git ගබඩා කිහිපයක් වැටක් බැඳීම අවශ්‍ය වන අතර මෙම නිධි කිහිපයක පෙරළිය සංවිධානය කිරීමේ ගැටලුව පැන නගී. පොදුවේ ගත් කල, එවැනි යෝජනා ක්රමයක් අධික ලෙස පටවා සංකීර්ණ වේ. අනවශ්‍ය නැවත පණ ගැන්වීම් සිදු නොවන පරිදි බොහෝ සේවාවන් එක් ගබඩාවකට ඒකාබද්ධ කර ඩොකර් ටැග් නිර්මාණය කිරීම වඩා හොඳය.

Git commit මගින් ටැග් කිරීම

werf සතුව Git commits හා සම්බන්ධ ටැග් කිරීමේ උපාය මාර්ගයක් ද ඇත.

Git-commit යනු Git ගබඩාවක අන්තර්ගතය සඳහා හඳුනාගැනීමක් වන අතර Git ගබඩාවේ ඇති ගොනු සංස්කරණ ඉතිහාසය මත රඳා පවතී, එබැවින් Docker Registry හි පින්තූර ටැග් කිරීම සඳහා එය භාවිතා කිරීම තර්කානුකූල බව පෙනේ.

කෙසේ වෙතත්, Git commit මගින් ටැග් කිරීම Git ශාඛා හෝ Git ටැග් මගින් ටැග් කිරීම හා සමාන අවාසි ඇත:

  • කිසිදු ගොනුවක් වෙනස් නොකරන හිස් කැපවීමක් සෑදිය හැක, නමුත් රූපයේ Docker ටැගය වෙනස් වනු ඇත.
  • ගොනු වෙනස් නොකරන ඒකාබද්ධ කැපවීමක් සෑදිය හැක, නමුත් රූපයේ ඩොකර් ටැගය වෙනස් වේ.
  • රූපයට ආයාත නොකළ Git හි ඇති ගොනු වෙනස් කිරීමට කැපවීමක් කළ හැකි අතර, රූපයේ Docker ටැගය නැවත වෙනස් කරනු ඇත.

Git ශාඛාවේ නම ටැග් කිරීම රූප අනුවාදය පිළිබිඹු නොකරයි

Git ශාඛා සඳහා ටැග් කිරීමේ උපාය මාර්ගය හා සම්බන්ධ තවත් ගැටලුවක් තිබේ.

ශාඛා නාමයෙන් ටැග් කිරීම එම ශාඛාවේ කැපවීම් කාලානුක්‍රමික අනුපිළිවෙලට අනුපිළිවෙලින් එකතු කරන තාක් කල් ක්‍රියා කරයි.

වත්මන් යෝජනා ක්‍රමයේදී පරිශීලකයා යම් ශාඛාවක් හා සම්බන්ධ පැරණි කැපවීමක් නැවත ගොඩනැංවීමට පටන් ගන්නේ නම්, පැරණි කැපවීම සඳහා රූපයේ අලුතින් සාදන ලද අනුවාදයක් සමඟ අනුරූප ඩොකර් ටැගය භාවිතයෙන් werf රූපය නැවත ලියයි. මෙතැන් සිට මෙම ටැගය භාවිතා කරන යෙදවීම් කරල් නැවත ආරම්භ කිරීමේදී රූපයේ වෙනත් අනුවාදයක් ඇද ගැනීමේ අවදානමක් ඇත, එහි ප්‍රතිඵලයක් ලෙස අපගේ යෙදුම CI පද්ධතිය සමඟ සම්බන්ධතාව නැති වී සමමුහුර්තකරණයට ලක් වේ.

ඊට අමතරව, ඒවා අතර කෙටි කාලයක් සහිත එක් ශාඛාවකට අනුප්‍රාප්තික තල්ලු කිරීම් සමඟ, පැරණි කැපවීම නව එකට වඩා පසුව සම්පාදනය කළ හැකිය: රූපයේ පැරණි අනුවාදය Git ශාඛා ටැගය භාවිතයෙන් අලුත් එක උඩින් ලියයි. එවැනි ගැටළු CI/CD පද්ධතියක් මගින් විසඳා ගත හැක (උදාහරණයක් ලෙස, GitLab CI හි දෙවැන්නෙහි නල මාර්ගය කැපවීම් මාලාවක් සඳහා දියත් කෙරේ). කෙසේ වෙතත්, සියලුම පද්ධති මෙයට සහාය නොදක්වන අතර එවැනි මූලික ගැටළුවක් වැලැක්වීම සඳහා වඩාත් විශ්වාසදායක ක්රමයක් තිබිය යුතුය.

අන්තර්ගතය මත පදනම් වූ ටැග් කිරීම යනු කුමක්ද?

ඉතින්, අන්තර්ගතය මත පදනම් වූ ටැග් කිරීම යනු කුමක්ද - අන්තර්ගතය අනුව පින්තූර ටැග් කිරීම.

Docker tags නිර්මාණය කිරීම සඳහා, Git primitives (Git ශාඛාව, Git ටැගය...) භාවිතා කරන්නේ නොව, මෙයට සම්බන්ධ චෙක්සම් එකක්:

  • රූපයේ අන්තර්ගතය. රූප ID ටැගය එහි අන්තර්ගතය පිළිබිඹු කරයි. නව අනුවාදයක් තැනීමේදී, රූපයේ ඇති ගොනු වෙනස් වී නොමැති නම්, මෙම හඳුනාගැනීම වෙනස් නොවේ;
  • Git හි මෙම රූපය නිර්මාණය කිරීමේ ඉතිහාසය. විවිධ Git ශාඛා සමඟ සම්බන්ධිත පින්තූර සහ werf හරහා විවිධ ගොඩනැගීමේ ඉතිහාසය වෙනස් ID ටැග් ඇත.

එවැනි හඳුනාගැනීමේ ටැගය ඊනියා වේ රූප අදියර අත්සන.

සෑම රූපයක්ම අදියර කිහිපයකින් සමන්විත වේ: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch ආදිය සෑම අදියරකටම එහි අන්තර්ගතය පිළිබිඹු කරන හඳුනාගැනීමක් ඇත - අදියර අත්සන (අදියර අත්සන).

මෙම අදියර වලින් සමන්විත අවසාන රූපය, මෙම අදියරවල කට්ටලයේ ඊනියා අත්සන සමඟ ටැග් කර ඇත - අදියර අත්සන, - රූපයේ සියලුම අදියර සඳහා සාමාන්යකරණය වේ.

වින්‍යාසයෙන් එක් එක් රූපය සඳහා werf.yaml සාමාන්‍ය නඩුවේදී, එහිම අත්සනක් ඇති අතර, ඒ අනුව, ඩොකර් ටැග් එකක් ඇත.

වේදිකා අත්සන මෙම සියලු ගැටලු විසඳයි:

  • හිස් Git කැපවීම් වලට ප්‍රතිරෝධී වේ.
  • රූපයට අදාල නොවන ගොනු වෙනස් කරන Git වලට ප්‍රතිරෝධය කරයි.
  • ශාඛාවක පැරණි Git කැපවීම් සඳහා ගොඩනැගීම් නැවත ආරම්භ කිරීමේදී රූපයේ වත්මන් අනුවාදය නැවත සකස් කිරීමේ ගැටලුවට මග පාදන්නේ නැත.

මෙය දැන් නිර්දේශිත ටැග් කිරීමේ උපාය මාර්ගය වන අතර සියලුම CI පද්ධති සඳහා werf හි පෙරනිමිය වේ.

verf සක්‍රීය කර භාවිතා කරන ආකාරය

විධානයට දැන් අනුරූප විකල්පයක් ඇත 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 Helm සැකිලි තුළ කිසිවක් වෙනස් කිරීමට අවශ්‍ය නැත: මෙම කාර්යයන් ස්වයංක්‍රීයව නිවැරදි රූප නාම ජනනය කරයි.

CI පද්ධතියක උදාහරණ වින්‍යාසය:

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

වින්‍යාසය පිළිබඳ වැඩි විස්තර ලේඛනවල ඇත:

එකතුව

  • නව විකල්පය 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 කැපවීම් සඳහා ගොඩනැගීම් නැවත ආරම්භ කිරීමේදී රූපයේ වත්මන් අනුවාදය නැවත සකස් කිරීමේ ගැටලුවට මග පාදන්නේ නැත.

එය භාවිතා කරන්න! ඒ වගේම අපිව බලන්න යන්න අමතක කරන්න එපා GitHubගැටලුවක් නිර්මාණය කිරීමට හෝ පවතින එකක් සොයා ගැනීමට, එකතු කිරීමක් එකතු කරන්න, PR එකක් සාදන්න හෝ ව්‍යාපෘතියේ සංවර්ධනය නැරඹීමට.

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න