බහාලුම් රූපවල "ස්මාර්ට්" පිරිසිදු කිරීමේ ගැටළුව සහ වර්ෆ්හි එහි විසඳුම

Kubernetes වෙත ලබා දෙන ක්ලවුඩ් ස්වදේශීය යෙදුම් සඳහා නවීන CI/CD නල මාර්ගවල යථාර්ථයන් තුළ බහාලුම් ලේඛනවල (ඩොකර් රෙජිස්ට්‍රිය සහ එහි ප්‍රතිසමයන්) එකතු වන පින්තූර පිරිසිදු කිරීමේ ගැටළු ලිපිය සාකච්ඡා කරයි. රූපවල අදාළත්වය සඳහා වන ප්‍රධාන නිර්ණායක සහ ස්වයංක්‍රීය පිරිසිදු කිරීම, ඉඩ ඉතිරි කිරීම සහ කණ්ඩායම්වල අවශ්‍යතා සපුරාලීමේ දුෂ්කරතා ලබා දී ඇත. අවසාන වශයෙන්, විශේෂිත විවෘත මූලාශ්‍ර ව්‍යාපෘතියක උදාහරණය භාවිතා කරමින්, මෙම දුෂ්කරතා ජය ගත හැකි ආකාරය අපි ඔබට කියන්නෙමු.

හැඳින්වීම

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

1. පින්තූර සඳහා ස්ථාවර ටැග් ගණනක් භාවිතා කරන්න;
2. පින්තූර යම් ආකාරයකින් පිරිසිදු කරන්න.

පළමු සීමාව කුඩා කණ්ඩායම් සඳහා සමහර විට පිළිගත හැකිය. සංවර්ධකයින්ට ප්‍රමාණවත් ස්ථිර ටැග් තිබේ නම් (latest, main, test, boris යනාදිය), රෙජිස්ට්‍රිය ප්‍රමාණයෙන් ඉදිමෙන්නේ නැති අතර දිගු වේලාවක් ඔබට එය පිරිසිදු කිරීම ගැන සිතීමට අවශ්‍ය නොවේ. සියල්ලට පසු, සියලු අදාළ නොවන රූප මකා දමනු ලබන අතර, පිරිසිදු කිරීම සඳහා කිසිදු කාර්යයක් ඉතිරි නොවේ (සියල්ල නිතිපතා කසළ එකතු කරන්නෙකු විසින් සිදු කරනු ලැබේ).

කෙසේ වෙතත්, මෙම ප්‍රවේශය සංවර්ධනය බෙහෙවින් සීමා කරන අතර නවීන CI/CD ව්‍යාපෘති සඳහා කලාතුරකින් අදාළ වේ. සංවර්ධනයේ අනිවාර්ය අංගයක් විය ස්වයංක්රීයකරණය, එය ඔබට වඩා වේගයෙන් පරිශීලකයින්ට නව ක්‍රියාකාරිත්වය පරීක්ෂා කිරීමට, යෙදවීමට සහ ලබා දීමට ඉඩ සලසයි. උදාහරණයක් ලෙස, අපගේ සියලුම ව්‍යාපෘති වලදී, එක් එක් කැපවීම සමඟ CI නල මාර්ගයක් ස්වයංක්‍රීයව නිර්මාණය වේ. එහි, රූපය එකලස් කර, පරීක්ෂා කර, නිදොස්කරණය සහ ඉතිරි චෙක්පත් සඳහා විවිධ Kubernetes පරිපථ වෙත රෝල් කර ඇත, සහ සියල්ල හොඳින් නම්, වෙනස්කම් අවසාන පරිශීලකයා වෙත ළඟා වේ. මෙය තවදුරටත් රොකට් විද්‍යාව නොවේ, නමුත් බොහෝ දෙනෙකුට එදිනෙදා සිදුවීමකි - ඔබ මෙම ලිපිය කියවන බැවින් බොහෝ දුරට ඔබට.

දෝෂ නිවැරදි කිරීම සහ නව ක්‍රියාකාරීත්වය වර්ධනය කිරීම සමාන්තරව සිදු කරනු ලබන අතර, නිකුත් කිරීම් දිනකට කිහිප වතාවක් සිදු කළ හැකි බැවින්, සංවර්ධන ක්‍රියාවලිය සැලකිය යුතු කැපවීම් සංඛ්‍යාවක් සමඟ ඇති බව පැහැදිලිය. රෙජිස්ට්රි එකේ පින්තූර විශාල සංඛ්යාවක්. ප්රතිඵලයක් වශයෙන්, රෙජිස්ට්රි ඵලදායී පිරිසිදු කිරීම සංවිධානය කිරීමේ ගැටළුව පැන නගී, i.e. අදාළ නොවන රූප ඉවත් කිරීම.

නමුත් රූපයක් අදාළ දැයි ඔබ තීරණය කරන්නේ කෙසේද?

රූපයේ අදාළත්වය සඳහා නිර්ණායක

බොහෝ අවස්ථාවන්හීදී, ප්රධාන නිර්ණායක වනුයේ:

1. පළමු (සියල්ලටම වඩා පැහැදිලි සහ වඩාත්ම විවේචනාත්මක) රූප වේ දැනට Kubernetes හි භාවිතා වේ. මෙම රූප ඉවත් කිරීමෙන් සැලකිය යුතු නිෂ්පාදන අක්‍රීය කාල පිරිවැයක් ඇති විය හැක (උදාහරණයක් ලෙස, රූප අනුකරණය සඳහා අවශ්‍ය විය හැක) හෝ ඕනෑම ලූපයක දෝශ නිරාකරණය කිරීමේ කණ්ඩායමේ උත්සාහයන් ප්‍රතික්ෂේප කරයි. (මේ හේතුව නිසා අපි විශේෂයක් පවා කළා Prometheus අපනයනකරු, ඕනෑම Kubernetes පොකුරක් තුළ එවැනි රූප නොමැති වීම නිරීක්ෂණය කරයි.)

2. දෙවන (අඩු පැහැදිලි, නමුත් ඉතා වැදගත් සහ නැවතත් සූරාකෑමට සම්බන්ධ) - රූප බරපතල ගැටළු හඳුනාගැනීමේදී ආපසු හැරීම සඳහා අවශ්ය වේ වත්මන් අනුවාදයේ. උදාහරණයක් ලෙස, Helm සම්බන්ධයෙන් ගත් කල, මේවා නිකුතුවේ සුරකින ලද අනුවාදවල භාවිතා වන පින්තූර වේ. (මාර්ගය වන විට, හෙල්ම් හි පෙරනිමියෙන් සීමාව සංශෝධන 256 කි, නමුත් කිසිවෙකුට සැබවින්ම සුරැකීමට අවශ්‍ය යැයි සිතිය නොහැක. එවැනි අනුවාද විශාල සංඛ්‍යාවක්? අවශ්ය නම් ඔවුන් වෙත "ආපසු පෙරළන්න".

3. තෙවන - සංවර්ධක අවශ්යතා: ඔවුන්ගේ වත්මන් කාර්යයට සම්බන්ධ සියලුම පින්තූර. උදාහරණයක් ලෙස, අපි PR එකක් ගැන සලකා බලන්නේ නම්, අවසාන කැපවීමට අනුරූප රූපයක් තැබීම අර්ථවත් කරයි සහ පෙර කැපවීම කියන්න: මේ ආකාරයෙන් සංවර්ධකයාට ඕනෑම කාර්යයකට ඉක්මනින් ආපසු ගොස් නවතම වෙනස්කම් සමඟ වැඩ කළ හැකිය.

4. හතරවන - රූප බව අපගේ යෙදුමේ අනුවාද වලට අනුරූප වේ, i.e. අවසාන නිෂ්පාදනය වේ: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, ආදිය.

සැ.යු: මෙහි නිර්වචනය කර ඇති නිර්ණායක විවිධ සමාගම්වල සංවර්ධන කණ්ඩායම් දුසිම් ගනනක් සමඟ අන්තර් ක්‍රියා කිරීමේ අත්දැකීම් මත පදනම්ව සකස් කර ඇත. කෙසේ වෙතත්, ඇත්ත වශයෙන්ම, සංවර්ධන ක්‍රියාවලීන්හි විශේෂතා සහ භාවිතා කරන යටිතල පහසුකම් මත පදනම්ව (උදාහරණයක් ලෙස, Kubernetes භාවිතා නොකෙරේ), මෙම නිර්ණායක වෙනස් විය හැකිය.

සුදුසුකම් සහ පවතින විසඳුම්

බහාලුම් රෙජිස්ට්‍රාර් සමඟ ජනප්‍රිය සේවාවන්, රීතියක් ලෙස, ඔවුන්ගේම රූප පිරිසිදු කිරීමේ ප්‍රතිපත්ති ඉදිරිපත් කරයි: ඒවා තුළ ඔබට රෙජිස්ට්‍රියෙන් ටැගයක් ඉවත් කරන කොන්දේසි නිර්වචනය කළ හැකිය. කෙසේ වෙතත්, මෙම කොන්දේසි නම්, නිර්මාණ කාලය සහ ටැග් ගණන වැනි පරාමිති වලින් සීමා වේ*.

* විශේෂිත බහාලුම් රෙජිස්ට්රි ක්රියාත්මක කිරීම් මත රඳා පවතී. අපි පහත විසඳුම්වල හැකියාවන් සලකා බැලුවෙමු: Azure CR, Docker Hub, ECR, GCR, GitHub පැකේජ, GitLab බහාලුම් රෙජිස්ට්‍රිය, වරාය ලියාපදිංචිය, JFrog Artifactory, Quay.io - සැප්තැම්බර්'2020 වන විට.

මෙම පරාමිතීන් සමූහය සිව්වන නිර්ණායකය සපුරාලීමට ප්‍රමාණවත් වේ - එනම්, අනුවාදවලට අනුරූප වන රූප තෝරා ගැනීමට. කෙසේ වෙතත්, අනෙකුත් සියලුම නිර්ණායක සඳහා, යමෙකුට යම් ආකාරයක සම්මුති විසඳුමක් (දැඩි හෝ, අනෙක් අතට, වඩාත් ලිහිල් ප්‍රතිපත්තියක්) තෝරා ගත යුතුය - අපේක්ෂාවන් සහ මූල්‍ය හැකියාවන් මත පදනම්ව.

උදාහරණයක් ලෙස, තුන්වන නිර්ණායකය - සංවර්ධකයින්ගේ අවශ්‍යතා හා සම්බන්ධ - කණ්ඩායම් තුළ ක්‍රියාවලි සංවිධානය කිරීමෙන් විසඳිය හැකිය: රූපවල නිශ්චිත නම් කිරීම, විශේෂ අවසර ලැයිස්තු සහ අභ්‍යන්තර ගිවිසුම් පවත්වා ගැනීම. නමුත් අවසානයේ එය තවමත් ස්වයංක්රීයව අවශ්ය වේ. තවද සූදානම් කළ විසඳුම්වල හැකියාවන් ප්රමාණවත් නොවේ නම්, ඔබ ඔබේම දෙයක් කළ යුතුය.

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

Git හි වැඩ ප්‍රවාහයේ නිදර්ශනය

අපි හිතමු ඔබ Git හි මේ වගේ දෙයක් වැඩ කරනවා කියලා:

රූප සටහනේ හිසක් සහිත නිරූපකය, දැනට Kubernetes හි ඕනෑම පරිශීලකයෙකු සඳහා (අවසන් පරිශීලකයින්, පරීක්ෂකයින්, කළමනාකරුවන්, ආදිය) යොදවා ඇති හෝ නිදොස්කරණය සහ ඒ හා සමාන අරමුණු සඳහා සංවර්ධකයින් විසින් භාවිතා කරන බහාලුම් රූප දක්වයි.

පිරිසිදු කිරීමේ ප්‍රතිපත්ති පමණක් පින්තූර රඳවා තබා ගැනීමට ඉඩ දෙන්නේ නම් (මකා නොදැමුවහොත්) කුමක් සිදුවේද? දී ඇති ටැග් නම් වලින්?

නිසැකවම, එවැනි දර්ශනයක් කිසිවෙකු සතුටු නොකරනු ඇත.

ප්‍රතිපත්ති මගින් පින්තූර මැකීමට ඉඩ නොදෙන්නේ නම් වෙනස් වන්නේ කුමක්ද? දී ඇති කාල පරතරය / අවසාන කැපවීම් ගණන අනුව?

ප්රතිඵලය වඩා හොඳ වී ඇත, නමුත් තවමත් පරමාදර්ශයෙන් ඈත් වී ඇත. සියල්ලට පසු, දෝෂ නිදොස් කිරීම සඳහා රෙජිස්ට්‍රියේ (හෝ K8s තුළ පවා යොදවා ඇති) පින්තූර අවශ්‍ය සංවර්ධකයින් අප සතුව ඇත...

වත්මන් වෙළඳපල තත්ත්වය සාරාංශ කිරීම සඳහා: බහාලුම් රෙජිස්ට්රිවල ඇති කාර්යයන් පිරිසිදු කිරීමේදී ප්රමාණවත් නම්යශීලී බවක් ලබා නොදෙන අතර මෙයට ප්රධාන හේතුව වන්නේ බාහිර ලෝකය සමඟ සම්බන්ධ වීමට ක්රමයක් නැත. එවැනි නම්‍යශීලී බවක් අවශ්‍ය කණ්ඩායම් වලට ඩොකර් රෙජිස්ට්‍රි ඒපීඅයි (හෝ අදාළ ක්‍රියාත්මක කිරීමේ ස්වදේශීය ඒපීඅයි) භාවිතා කරමින් “පිටතෙන්” රූප මකාදැමීම ස්වාධීනව ක්‍රියාත්මක කිරීමට බල කෙරෙන බව පෙනේ.

කෙසේ වෙතත්, අපි විවිධ රෙජිස්ට්‍රි භාවිතා කරමින් විවිධ කණ්ඩායම් සඳහා රූප පිරිසිදු කිරීම ස්වයංක්‍රීය කරන විශ්වීය විසඳුමක් සොයමින් සිටියෙමු...

විශ්වීය රූප පිරිසිදු කිරීම සඳහා අපගේ මාර්ගය

මෙම අවශ්යතාව පැමිණෙන්නේ කොහෙන්ද? කාරණය නම් අපි වෙනම සංවර්ධකයින් කණ්ඩායමක් නොව, ඔවුන්ගෙන් බොහෝ දෙනෙකුට එකවර සේවය කරන කණ්ඩායමක් වන අතර, CI/CD ගැටළු පුළුල් ලෙස විසඳීමට උපකාරී වේ. තවද මේ සඳහා ප්‍රධාන තාක්ෂණික මෙවලම වන්නේ විවෘත මූලාශ්‍ර උපයෝගීතාවයයි werf. එහි විශේෂත්වය වන්නේ එය තනි කාර්යයක් ඉටු නොකිරීමයි, නමුත් සෑම අදියරකදීම අඛණ්ඩ බෙදාහැරීමේ ක්රියාවලීන් සමඟ: එකලස් කිරීමේ සිට යෙදවීම දක්වා.

රෙජිස්ට්‍රිය වෙත පින්තූර ප්‍රකාශනය කිරීම* (ඒවා තැනූ වහාම) එවැනි උපයෝගීතාවයක පැහැදිලි කාර්යයකි. පින්තූර ගබඩා කිරීම සඳහා එහි තබා ඇති බැවින් - ඔබේ ගබඩාව අසීමිත නොවේ නම් - ඒවා පසුව පිරිසිදු කිරීම සඳහා ඔබ වගකිව යුතුය. සියලුම නිශ්චිත නිර්ණායක තෘප්තිමත් කරමින් අප මෙහි සාර්ථකත්වය අත්කර ගත්තේ කෙසේද යන්න තවදුරටත් සාකච්ඡා කරනු ඇත.

* ලියාපදිංචි කිරීම් වෙනස් විය හැකි වුවද (Docker Registry, GitLab Container Registry, Harbour, ආදිය), ඔවුන්ගේ පරිශීලකයින් එකම ගැටළු වලට මුහුණ දෙයි. අපගේ නඩුවේ විශ්වීය විසඳුම රෙජිස්ට්රි ක්රියාත්මක කිරීම මත රඳා නොපවතී, මන්ද රෙජිස්ට්‍රි වලින් පිටත දිවෙන අතර සෑම කෙනෙකුටම එකම හැසිරීමක් ලබා දෙයි.

අපි උදාහරණ ක්‍රියාත්මක කිරීමක් ලෙස werf භාවිතා කරන නමුත්, භාවිතා කරන ප්‍රවේශයන් සමාන දුෂ්කරතාවන්ට මුහුණ දෙන අනෙකුත් කණ්ඩායම් සඳහා ප්‍රයෝජනවත් වනු ඇතැයි අපි බලාපොරොත්තු වෙමු.

ඉතින් අපි කාර්යබහුල වුණා බාහිර පින්තූර පිරිසිදු කිරීම සඳහා යාන්ත්රණයක් ක්රියාත්මක කිරීම - දැනටමත් බහාලුම් සඳහා රෙජිස්ට්රි තුළ ගොඩනගා ඇති එම හැකියාවන් වෙනුවට. පළමු පියවර වූයේ ටැග් ගණන සහ ඒවා නිර්මාණය කළ කාලය (ඉහත සඳහන් කර ඇති) සඳහා එකම ප්‍රාථමික ප්‍රතිපත්ති නිර්මාණය කිරීම සඳහා Docker Registry API භාවිතා කිරීමයි. ඒවාට එකතු කළා යොදවා ඇති යටිතල ව්‍යුහය තුළ භාවිතා කරන රූප මත පදනම්ව ලැයිස්තුවට ඉඩ දෙන්න, i.e. කුබර්නෙටස්. දෙවැන්න සඳහා, යොදවා ඇති සියලුම සම්පත් හරහා පුනරාවර්තනය කිරීමට සහ අගයන් ලැයිස්තුවක් ලබා ගැනීමට Kubernetes API භාවිතා කිරීම ප්‍රමාණවත් විය. image.

මෙම සුළු විසඳුම වඩාත් තීරණාත්මක ගැටළුව විසඳා ඇත (නිර්ණායක අංක 1), නමුත් පිරිසිදු කිරීමේ යාන්ත්රණය වැඩිදියුණු කිරීම සඳහා අපගේ ගමනේ ආරම්භය පමණි. ඊළඟ - සහ වඩාත් සිත්ගන්නා පියවර වූයේ තීරණයයි ප්‍රකාශිත පින්තූර Git ඉතිහාසය සමඟ සම්බන්ධ කරන්න.

ටැග් කිරීමේ යෝජනා ක්රම

ආරම්භ කිරීම සඳහා, අපි අවසාන රූපය පිරිසිදු කිරීම සඳහා අවශ්‍ය තොරතුරු ගබඩා කළ යුතු ප්‍රවේශයක් තෝරාගෙන, ටැග් කිරීමේ යෝජනා ක්‍රම මත ක්‍රියාවලිය ගොඩනඟා ගත්තෙමු. රූපයක් ප්‍රකාශයට පත් කරන විට, පරිශීලකයා විශේෂිත ටැග් කිරීමේ විකල්පයක් තෝරා ගත්තේය (git-branch, git-commit හෝ git-tag) සහ අනුරූප අගය භාවිතා කරන ලදී. CI පද්ධතිවල, පරිසර විචල්‍යයන් මත පදනම්ව මෙම අගයන් ස්වයංක්‍රීයව සකසා ඇත. ඇත්ත වශයෙන්ම අවසාන රූපය නිශ්චිත Git ප්‍රාථමිකයක් සමඟ සම්බන්ධ විය, ලේබල්වල පිරිසිදු කිරීම සඳහා අවශ්ය දත්ත ගබඩා කිරීම.

මෙම ප්‍රවේශය සත්‍යයේ තනි මූලාශ්‍රය ලෙස Git භාවිතා කිරීමට ඉඩ සලසන ප්‍රතිපත්ති මාලාවක් ඇති කළේය:

• Git හි ශාඛාවක්/ටැගයක් මකා දැමීමේදී, රෙජිස්ට්‍රියේ ඇති සම්බන්ධිත පින්තූර ස්වයංක්‍රීයව මකා දමනු ලැබේ.
• Git ටැග් සහ කැපවීම් සමඟ සම්බන්ධිත රූප සංඛ්‍යාව, තෝරාගත් යෝජනා ක්‍රමයේ භාවිතා කර ඇති ටැග් ගණන සහ ඒ ආශ්‍රිත කැපවීම සෑදූ කාලය මගින් පාලනය කළ හැක.

සමස්තයක් වශයෙන්, ප්‍රතිඵලයක් ලෙස ක්‍රියාත්මක කිරීම අපගේ අවශ්‍යතා තෘප්තිමත් කළ නමුත්, නව අභියෝගයක් ඉක්මනින් අප බලා සිටියේය. කාරණය නම් Git primitives මත පදනම් වූ tagging Schemes භාවිතා කරන විට, අපට අඩුපාඩු රැසකට මුහුණ දීමට සිදු විය. (ඔවුන්ගේ විස්තරය මෙම ලිපියේ විෂය පථයෙන් ඔබ්බට ඇති බැවින්, සෑම කෙනෙකුටම විස්තර සමඟ හුරුපුරුදු විය හැකිය මෙහි.) එබැවින්, ටැග් කිරීම (අන්තර්ගතය මත පදනම් වූ ටැග් කිරීම) සඳහා වඩාත් කාර්යක්ෂම ප්රවේශයක් වෙත මාරු වීමට තීරණය කර ඇති අතර, රූප පිරිසිදු කිරීම ක්රියාත්මක කිරීම නැවත සලකා බැලීමට සිදු විය.

නව ඇල්ගොරිතම

ඇයි? අන්තර්ගතය මත පදනම් වූ ටැග් කිරීම සමඟින්, එක් එක් ටැගයට Git හි බහුවිධ කැපවීම් තෘප්තිමත් කළ හැක. පින්තූර පිරිසිදු කරන විට, ඔබට තවදුරටත් උපකල්පනය කළ නොහැක පමණි රෙජිස්ට්‍රි එකට අලුත් ටැග් එක දාපු කමිට් එකෙන්.

නව පිරිසිදු කිරීමේ ඇල්ගොරිතම සඳහා, ටැග් කිරීමේ යෝජනා ක්රම වලින් ඉවත් වී ගොඩනැගීමට තීරණය විය මෙටා-රූප ක්රියාවලිය, ඒ සෑම එකක්ම පොකුරක් ගබඩා කරයි:

• ප්‍රකාශනය සිදු කරන ලද කැපවීම (රූපය එකතු කිරීම, වෙනස් කිරීම හෝ බහාලුම් ලේඛනයේ එලෙසම පැවතීම වැදගත් නොවේ);
• සහ එකලස් කරන ලද රූපයට අනුරූප වන අපගේ අභ්යන්තර හඳුනාගැනීම.

වෙනත් වචන වලින් කිවහොත්, එය සපයන ලදී Git හි කැපවීම් සමඟ ප්‍රකාශිත ටැග් සම්බන්ධ කිරීම.

අවසාන වින්‍යාසය සහ සාමාන්‍ය ඇල්ගොරිතම

පිරිසිදු කිරීම වින්‍යාස කරන විට, පරිශීලකයින්ට දැන් වත්මන් රූප තෝරන ප්‍රතිපත්ති වෙත ප්‍රවේශය ඇත. එවැනි සෑම ප්‍රතිපත්තියක්ම අර්ථ දක්වා ඇත:

• බොහෝ යොමු කිරීම්, i.e. ස්කෑන් කිරීමේදී භාවිතා කරන 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

මෙම වින්‍යාසය පහත නීතිවලට අනුකූල වන ප්‍රතිපත්ති තුනක් අඩංගු වේ:

1. අවසාන Git ටැග් 10 සඳහා රූපය සුරකින්න (ටැග් සාදන දිනය අනුව).
2. පසුගිය සතියේ ක්‍රියාකාරකම් සහිත නූල් 2කට වඩා වැඩි ප්‍රමාණයක් සඳහා පසුගිය සතියේ ප්‍රකාශිත පින්තූර 10කට වඩා සුරකින්න.
3. ශාඛා සඳහා පින්තූර 10 ක් සුරකින්න main, staging и production.

අවසාන ඇල්ගොරිතම පහත පියවර දක්වා පහත වැටේ:

• බහාලුම් ලේඛනයෙන් මැනිෆෙස්ටස් ලබා ගැනීම.
• Kubernetes හි භාවිතා වන පින්තූර හැර, මන්ද අපි දැනටමත් K8s API මත ඡන්ද විමසීමෙන් ඒවා කලින් තෝරාගෙන ඇත.
• Git ඉතිහාසය පරිලෝකනය කිරීම සහ නිශ්චිත ප්‍රතිපත්ති මත පදනම්ව පින්තූර බැහැර කිරීම.
• ඉතිරි පින්තූර ඉවත් කිරීම.

අපගේ නිදර්ශනය වෙත ආපසු යාම, වර්ෆ් සමඟ සිදු වන්නේ මෙයයි:

කෙසේ වෙතත්, ඔබ werf භාවිතා නොකළත්, උසස් රූප පිරිසිදු කිරීම සඳහා සමාන ප්‍රවේශයක් - එක් ක්‍රියාත්මක කිරීමකින් හෝ වෙනත් ආකාරයකින් (පින්තූර ටැග් කිරීමට කැමති ප්‍රවේශය අනුව) - වෙනත් පද්ධති/උපයෝගිතා සඳහා යෙදිය හැක. මෙය සිදු කිරීම සඳහා, පැන නගින ගැටළු මතක තබා ගැනීම සහ ඒවායේ විසඳුම හැකි තරම් සුමට ලෙස ඒකාබද්ධ කිරීමට ඔබට ඉඩ සලසන ඔබේ තොගයේ ඇති අවස්ථා සොයා ගැනීම ප්‍රමාණවත් වේ. අප ගමන් කළ මාර්ගය නව විස්තර සහ සිතුවිලි සමඟ ඔබේ විශේෂිත අවස්ථාව දෙස බැලීමට ඔබට උපකාරී වනු ඇතැයි අපි බලාපොරොත්තු වෙමු.

නිගමනය

• ඉක්මනින් හෝ පසුව, බොහෝ කණ්ඩායම් රෙජිස්ට්රි පිටාර ගැලීමේ ගැටලුවකට මුහුණ දෙයි.
• විසඳුම් සෙවීමේදී, රූපයේ අදාළත්වය සඳහා වන නිර්ණායක තීරණය කිරීම මුලින්ම අවශ්ය වේ.
• ජනප්‍රිය බහාලුම් රෙජිස්ට්‍රි සේවාවන් විසින් පිරිනමනු ලබන මෙවලම් මඟින් "බාහිර ලෝකය" සැලකිල්ලට නොගන්නා ඉතා සරල පිරිසිදු කිරීමක් සංවිධානය කිරීමට ඔබට ඉඩ සලසයි: කුබර්නෙටේස් හි භාවිතා කරන පින්තූර සහ කණ්ඩායමේ කාර්ය ප්‍රවාහයේ සුවිශේෂතා.
• නම්‍යශීලී සහ කාර්යක්ෂම ඇල්ගොරිතමයකට CI/CD ක්‍රියාවලි පිළිබඳ අවබෝධයක් තිබිය යුතු අතර ඩොකර් රූප දත්ත සමඟ පමණක් නොව ක්‍රියා කරයි.

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

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

• «වර්ෆ් එකතු කරන්නා තුළ අන්තර්ගත මත පදනම් වූ ටැග් කිරීම: එය ක්‍රියා කරන්නේ ඇයි සහ කෙසේද?»;
• «3-way merge to werf: Helm සමඟ "ස්ටෙරොයිඩ් මත" Kubernetes වෙත යෙදවීම»;
• «werf හි monorepo සහ multirepo සඳහා සහය සහ Docker Registry එයට සම්බන්ධ වන්නේ කුමක්ද?»;
• «werf 1.1 නිකුතුව: අද තනන්නාට වැඩිදියුණු කිරීම් සහ අනාගතය සඳහා සැලසුම්".

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