mono-repository හි මාතෘකාව එක් වරකට වඩා සාකච්ඡා කර ඇති අතර, නීතියක් ලෙස, ඉතා ක්රියාශීලී මතභේදයක් ඇති කරයි. නිර්මාණය කිරීමෙනි Git සිට Docker රූප දක්වා යෙදුම් කේතය ගොඩනැගීමේ ක්රියාවලිය වැඩිදියුණු කිරීම සඳහා නිර්මාණය කර ඇති විවෘත මූලාශ්‍ර මෙවලමක් ලෙස (පසුව ඒවා Kubernetes වෙත ලබා දීම), අපි වඩාත් සුදුසු තේරීම ගැන වැඩිය සිතන්නේ නැත. අප සඳහා, විවිධ මතවල ආධාරකරුවන් සඳහා අවශ්ය සියල්ල සැපයීම මූලික වේ (මෙය සාමාන්ය බුද්ධියට පටහැනි නොවේ නම්, ඇත්ත වශයෙන්ම).
werf හි මෑතකාලීන mono-repo සහාය මෙයට හොඳ උදාහරණයකි. නමුත් පළමුව, මෙම සහාය සාමාන්‍යයෙන් werf භාවිතා කිරීමට සම්බන්ධ වන්නේ කෙසේද සහ ඩොකර් රෙජිස්ට්‍රිය එයට සම්බන්ධ වන්නේ කුමක්දැයි සොයා බලමු ...
ගැටලු
එවැනි තත්වයක් අපි සිතමු. සමාගමට ස්වාධීන ව්යාපෘති මත වැඩ කරන බොහෝ සංවර්ධන කණ්ඩායම් ඇත. බොහෝ යෙදුම් Kubernetes මත ධාවනය වන අතර එම නිසා බහාලුම් වේ. බහාලුම්, පින්තූර ගබඩා කිරීම සඳහා, ඔබට රෙජිස්ට්රි (රෙජිස්ට්රි) අවශ්ය වේ. එවැනි ලියාපදිංචි කිරීමක් ලෙස, සමාගම තනි ගිණුමක් සමඟ Docker Hub භාවිතා කරයි COMPANY. බොහෝ ප්‍රභව කේත ගබඩා පද්ධති වලට සමාන, Docker Hub කැදැලි ගබඩා ධුරාවලියට ඉඩ නොදේ, ආදි COMPANY/PROJECT/IMAGE. එසේ නම්... එක් එක් ව්‍යාපෘතිය සඳහා වෙනම ගිණුමක් සාදා නොගෙන මෙම සීමාව සමඟින් ඔබට මොනොලිතික් නොවන යෙදුම් රෙජිස්ට්‍රිය තුළ ගබඩා කරන්නේ කෙසේද?
සමහර විට, විස්තර කරන ලද තත්වය යමෙකුට මුලින්ම හුරුපුරුදු විය හැකිය, නමුත් පොදුවේ යෙදුම් ගබඩාව සංවිධානය කිරීමේ ගැටළුව සලකා බලමු, i.e. ඉහත උදාහරණය සහ Docker Hub වෙත යොමු නොවී.
විසඳුම්
අයදුම්පත නම් මොනොලිතික්, එක් රූපයකින් පැමිණේ, එවිට ප්‍රශ්න කිසිවක් නොමැති අතර අපි හුදෙක් ව්‍යාපෘතියේ බහාලුම් රෙජිස්ට්‍රිය වෙත පින්තූර සුරකිමු.
යෙදුමක් බහු සංරචක ලෙස ඉදිරිපත් කරන විට, ක්ෂුද්ර සේවා, එවිට යම් ප්රවේශයක් අවශ්ය වේ. රූප දෙකකින් සමන්විත සාමාන්ය වෙබ් යෙදුමක උදාහරණය මත: frontend и backend - හැකි විකල්ප වනුයේ:
- පින්තූර වෙනම කැදලි ගබඩාවල ගබඩා කරන්න:
- සෑම දෙයක්ම එක් ගබඩාවක ගබඩා කර, ටැගය තුළ රූපයේ නම සලකා බලන්න, උදාහරණයක් ලෙස, පහත පරිදි:
NB: ඇත්ත වශයෙන්ම, විවිධ ගබඩාවල ඉතිරි කිරීම සමඟ තවත් විකල්පයක් ඇත, PROJECT-frontend и PROJECT-backend, නමුත් පරිශීලකයින් අතර සහයෝගය, සංවිධානය සහ අයිතිවාසිකම් බෙදා හැරීමේ සංකීර්ණත්වය නිසා අපි එය සලකා බලන්නේ නැත.
werf සහාය
මුලදී, werf කැදැලි ගබඩාවලට සීමා විය - වාසනාවකට මෙන්, බොහෝ රෙජිස්ට්රි මෙම විශේෂාංගයට සහය දක්වයි. අනුවාදයෙන් ආරම්භ වේ , ලේඛන සමඟ වැඩ එකතු කරන ලදී කූඩුව සඳහා සහය නොදක්වයි, සහ Docker Hub ඉන් එකකි. එතැන් සිට, යෙදුම් පින්තූර ගබඩා කරන්නේ කෙසේද යන්න පිළිබඳ තේරීමක් පරිශීලකයාට ඇත.
විකල්පය යටතේ ක්රියාත්මක කිරීම ලබා ගත හැකිය --images-repo-mode=multirepo|monorepo (පෙරනිමිය multirepo, i.e. කැදලි ගබඩාවල ගබඩා කිරීම). එය රෙජිස්ට්රි තුළ පින්තූර ගබඩා කර ඇති රටා නිර්වචනය කරයි. මූලික විධානයන් භාවිතා කරන විට අවශ්ය මාදිලිය තෝරා ගැනීමට ප්රමාණවත් වන අතර අනෙක් සියල්ල නොවෙනස්ව පවතිනු ඇත.
බොහෝ werf විකල්ප සැකසිය හැකි නිසා පාරිසරික විචල්යයන්, CI / CD පද්ධතිවල, ගබඩා මාදිලිය සාමාන්‍යයෙන් සමස්ත ව්‍යාපෘතිය සඳහා ගෝලීය වශයෙන් සැකසීමට පහසුය. උදාහරණ වශයෙන්, GitLab සම්බන්ධයෙන් ව්යාපෘති සැකසුම් තුළ පරිසර විචල්‍යයක් එක් කරන්න: සැකසීම් -> CI / CD -> විචල්යයන්: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
අපි පින්තූර ප්‍රකාශයට පත් කිරීම සහ යෙදුම් පෙරළීම ගැන කතා කරන්නේ නම් (ඔබට මෙම ක්‍රියාවලීන් පිළිබඳව අදාළ ලේඛන ලිපිවල විස්තරාත්මකව කියවිය හැකිය: и ), එවිට මාදිලිය ඔබට රූපය සමඟ වැඩ කළ හැකි අච්චුව පමණක් තීරණය කරයි.
යක්ෂයා විස්තරයේ ඇත
නව ගබඩා කිරීමේ ක්රමයක් එකතු කිරීමේදී වෙනස සහ ප්රධාන දුෂ්කරතාවය වන්නේ රෙජිස්ට්රි පිරිසිදු කිරීමේ ක්රියාවලිය තුළය (වර්ෆ් විසින් සහාය දක්වන පිරිසිදු කිරීමේ විශේෂාංග සඳහා, බලන්න ).
පිරිසිදු කරන විට, werf Kubernetes පොකුරු වල භාවිතා වන පින්තූර මෙන්ම පරිශීලකයා විසින් වින්‍යාස කර ඇති ප්‍රතිපත්ති ද සැලකිල්ලට ගනී. ප්‍රතිපත්ති පදනම් වන්නේ ටැග් උපාය මාර්ගවලට බෙදීම මතය. දැනට සහාය දක්වන උපාය මාර්ග:
- ටැගය, ශාඛාව සහ කැපවීම වැනි Git ප්‍රාථමිකයන් විසින් සම්බන්ධ කරන ලද උපාය මාර්ග 3ක්;
- අත්තනෝමතික අභිරුචි ටැග් සඳහා 1 උපාය මාර්ගයක්.
අවසාන රූපයේ ලේබලවල රූපය ප්‍රකාශනය කිරීමේදී අපි ටැග් උපාය මාර්ගය පිළිබඳ තොරතුරු සුරකිමු. අර්ථය ම ඊනියා ය මෙටා ටැගය - සමහර ප්‍රතිපත්ති යෙදීමට අවශ්ය වේ. උදාහරණයක් ලෙස, Git ගබඩාවකින් ශාඛාවක් හෝ ටැගයක් මකා දැමීමේදී, අදාළ ඒවා මකා දැමීම තාර්කික වේ. භාවිතයට නොගත් අපගේ ප්‍රතිපත්තිවල කොටසකින් ආවරණය වන රෙජිස්ට්‍රියේ පින්තූර.
එක් ගබඩාවක සුරකින විට (monorepo), රූප ටැගය තුළ, මෙටා ටැගයට අමතරව, රූපයේ නම ද ගබඩා කළ හැක: PROJECT:frontend-META-TAG. ඒවා වෙන් කිරීම සඳහා, අපි නිශ්චිත බෙදුම්කරුවෙකු හඳුන්වා නොදුන් නමුත්, ප්‍රකාශනය කිරීමේදී අවසාන රූපයේ ලේබලයට අවශ්ය අගය එකතු කළෙමු.
NB: ඔබ werf මූලාශ්‍ර කේතයේ විස්තර කර ඇති සියල්ල දෙස බැලීමට උනන්දු වන්නේ නම්, ආරම්භක ස්ථානය විය හැක .
මෙම ලිපියෙන්, අපගේ ප්‍රවේශයේ ගැටළු සහ යුක්තිසහගත කිරීම කෙරෙහි අපි වැඩි අවධානයක් යොමු නොකරමු: ටැග් කිරීමේ උපාය මාර්ග, ලේබලවල දත්ත ගබඩා කිරීම සහ සමස්තයක් ලෙස ප්‍රකාශන ක්රියාවලිය - මේ සියල්ල දිමිත්‍රි ස්ටොලියාරොව්ගේ මෑත වාර්තාවක විස්තරාත්මකව විස්තර කර ඇත: “".
සාරාංශ ගත කිරීමට
අනවසර ලියාපදිංචි කිරීම් සඳහා සහය නොමැතිකම අපට හෝ අප දන්නා werf පරිශීලකයින්ට අවහිර කිරීමේ සාධකයක් නොවීය - සියල්ලට පසු, ඔබට සැම විටම වෙනම රූප රෙජිස්ට්‍රියක් (හෝ Google Cloud හි කොන්දේසි සහිත බහාලුම් රෙජිස්ට්‍රියකට මාරු විය හැක) ... කෙසේ වෙතත්, පුළුල් DevOps ප්‍රජාවට මෙවලම වඩාත් පහසු වීම සඳහා එවැනි සීමාවක් ඉවත් කිරීම තාර්කික බවක් පෙනෙන්නට තිබුණි. එය ක්රියාත්මක කිරීම, බහාලුම් රෙජිස්ට්රි පිරිසිදු කිරීමේ යාන්ත්රණය නැවත සකස් කිරීමේ ප්රධාන දුෂ්කරතාවයට අපි මුහුණ දුන්නා. දැන් සෑම දෙයක්ම සූදානම් බැවින්, එය යමෙකුට පහසු වී ඇති බව වටහා ගැනීම සතුටක් වන අතර, අපට (ව්‍යාපෘතියේ ප්රධාන සංවර්ධකයින් ලෙස) මෙම විශේෂාංගයට තවදුරටත් සහාය දැක්වීමේදී සැලකිය යුතු දුෂ්කරතා ඇති නොවේ.
අප සමඟ රැඳී සිටින්න, ඉතා ඉක්මනින් අපි ඔබට වෙනත් නවෝත්පාදන ගැන කියන්නෙමු !
ප්රාදේශීය සභා
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «»;
- «".
මූලාශ්රය: www.habr.com