werf - Kubernetes හි CI / CD සඳහා අපගේ මෙවලම (දළ විශ්ලේෂණය සහ වීඩියෝ වාර්තාව)

උත්සවයේ කොටසක් ලෙස පවත්වන ලද DevOpsConf 27 සමුළුවේ ප්‍රධාන ශාලාවේදී මැයි 2019 RIT++ 2019, “අඛණ්ඩ බෙදා හැරීම” කොටසේ කොටසක් ලෙස, වාර්තාවක් ලබා දෙන ලදී “werf - Kubernetes හි CI/CD සඳහා අපගේ මෙවලම”. ඒ අය ගැන තමයි කතා කරන්නේ Kubernetes වෙත යෙදවීමේදී සෑම කෙනෙකුම මුහුණ දෙන ගැටළු සහ අභියෝග, මෙන්ම ක්ෂණිකව නොපෙනෙන සූක්ෂ්මතා ගැන. හැකි විසඳුම් විශ්ලේෂණය කරමින්, විවෘත මූලාශ්‍ර මෙවලමක් තුළ මෙය ක්‍රියාත්මක වන ආකාරය අපි පෙන්වමු werf.

ඉදිරිපත් කිරීමෙන් පසු, අපගේ උපයෝගීතාව (කලින් dapp ලෙස හැඳින්විණි) ඓතිහාසික සන්ධිස්ථානයකට ළඟා වී ඇත. GitHub මත තරු 1000ක් - එහි වර්ධනය වන පරිශීලක ප්‍රජාව බොහෝ DevOps ඉංජිනේරුවන් සඳහා ජීවිතය පහසු කරනු ඇතැයි අපි බලාපොරොත්තු වෙමු.

ඉතින්, අපි හඳුන්වා දෙමු වාර්තාවේ වීඩියෝව (~ 47 විනාඩි, ලිපියට වඩා බොහෝ තොරතුරු) සහ එහි ප්‍රධාන උපුටා ගැනීම පෙළ ආකාරයෙන්. යන්න!

Kubernetes වෙත කේතය ලබා දීම

කතාව තවදුරටත් වර්ෆ් ගැන නොව Kubernetes හි CI/CD ගැන වනු ඇත, එයින් ඇඟවෙන්නේ අපගේ මෘදුකාංගය ඩොකර් බහාලුම්වල ඇසුරුම් කර ඇති බවයි. (මම මේ ගැන කතා කළේ 2016 වාර්තාව), සහ K8s නිෂ්පාදනයේදී එය ධාවනය කිරීමට භාවිතා කරනු ඇත (මේ ගැන වැඩි විස්තර 2017 වසර).

Kubernetes හි බෙදාහැරීම පෙනෙන්නේ කෙසේද?

• එය ගොඩනැගීම සඳහා කේතය සහ උපදෙස් සහිත Git ගබඩාවක් ඇත. යෙදුම Docker රූපයක් තුළට ගොඩනගා ඇති අතර Docker Registry හි ප්‍රකාශයට පත් කර ඇත.
• යෙදුම යෙදවීමට සහ ක්‍රියාත්මක කරන්නේ කෙසේද යන්න පිළිබඳ උපදෙස් ද එම ගබඩාවේ අඩංගු වේ. යෙදවීමේ අදියරේදී, මෙම උපදෙස් කුබර්නෙටස් වෙත යවනු ලබන අතර, එය රෙජිස්ට්‍රියෙන් අපේක්ෂිත රූපය ලබාගෙන එය දියත් කරයි.
• ඊට අමතරව, සාමාන්යයෙන් පරීක්ෂණ තිබේ. මේවායින් සමහරක් පින්තූරයක් ප්‍රකාශයට පත් කිරීමේදී කළ හැකිය. ඔබට (එකම උපදෙස් අනුගමනය කරමින්) යෙදුමේ පිටපතක් (වෙනම K8s නාම අවකාශයක හෝ වෙනම පොකුරක) යෙදවිය හැකි අතර එහි පරීක්ෂණ ක්‍රියාත්මක කරන්න.
• අවසාන වශයෙන්, ඔබට Git (හෝ බොත්තම් ක්ලික් කිරීම්) වෙතින් සිදුවීම් ලබා ගන්නා CI පද්ධතියක් අවශ්‍ය වන අතර සියලුම නම් කරන ලද අදියරයන් අමතන්න: ගොඩනැගීම, ප්‍රකාශ කිරීම, යෙදවීම, පරීක්ෂා කිරීම.

මෙහි වැදගත් සටහන් කිහිපයක් තිබේ:

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

අපි Kubernetes හි ඉහත බෙදාහැරීමේ යෝජනා ක්‍රමය වෙත ආපසු යමු: එය අප විසින් පමණක් නොව, මෙම ගැටලුව සමඟ කටයුතු කළ සෑම කෙනෙකුම විසින් සොයා ගන්නා ලදී. ඇත්ත වශයෙන්ම, මෙම රටාව දැන් GitOps ලෙස හැඳින්වේ (මෙම යෙදුම සහ එය පිටුපස ඇති අදහස් ගැන ඔබට වැඩිදුර කියවිය හැකිය මෙහි). යෝජනා ක්රමයේ අදියර දෙස බලමු.

වේදිකාව ගොඩනඟන්න

Dockerfiles ලිවීමට සහ ධාවනය කරන්නේ කෙසේදැයි සියලු දෙනා දන්නා විට, 2019 දී Docker images ගොඩනැගීම ගැන ඔබට කතා කළ හැකි බව පෙනේ. docker build?.. මෙන්න මම අවධානය යොමු කිරීමට කැමති සූක්ෂ්ම කරුණු:

1. රූපයේ බර වැදගත්, එබැවින් භාවිතා කරන්න බහු-අදියරමෙහෙයුම සඳහා සැබවින්ම අවශ්‍ය යෙදුම පමණක් රූපයේ තැබීමට.
2. ස්ථර ගණන දම්වැල් ඒකාබද්ධ කිරීමෙන් අවම කළ යුතුය RUN- අර්ථය අනුව විධාන.
3. කෙසේ වෙතත්, මෙය ගැටළු එකතු කරයි නිදොස් කිරීම, මොකද එකලස් කිරීම කඩා වැටෙන විට, ගැටලුව ඇති වූ දාමයෙන් ඔබට නිවැරදි විධානය සොයාගත යුතුය.
4. එකලස් කිරීමේ වේගය වැදගත් වන්නේ අපට ඉක්මනින් වෙනස්කම් සිදු කර ප්‍රතිඵල දැකීමට අවශ්‍ය බැවිනි. උදාහරණයක් ලෙස, ඔබ යෙදුමක් ගොඩනඟන සෑම අවස්ථාවකදීම භාෂා පුස්තකාලවල පරායත්තතා නැවත ගොඩනැගීමට ඔබට අවශ්‍ය නැත.
5. බොහෝ විට ඔබට අවශ්‍ය එක් Git ගබඩාවකින් බොහෝ පින්තූර, එය Dockerfiles කට්ටලයක් (හෝ එක් ගොනුවක නම් කරන ලද අදියර) සහ ඒවායේ අනුක්‍රමික එකලස් කිරීම සහිත Bash ස්ක්‍රිප්ට් එකකින් විසඳිය හැක.

මෙය සෑම කෙනෙකුම මුහුණ දෙන අයිස් කන්දේ කෙළවරක් පමණි. නමුත් වෙනත් ගැටළු තිබේ, විශේෂයෙන්:

1. බොහෝ විට එකලස් කිරීමේ වේදිකාවේදී අපට යමක් අවශ්ය වේ කන්ද (උදාහරණයක් ලෙස, තුන්වන පාර්ශ්ව නාමාවලියක apt වැනි විධානයක ප්‍රතිඵලය හැඹිලි කරන්න).
2. අපට අවශ්යයි පිළිතුරු shell එකේ ලියනවා වෙනුවට.
3. අපට අවශ්යයි Docker නොමැතිව ගොඩනඟන්න (අපට දැනටමත් බහාලුම් ක්‍රියාත්මක කළ හැකි Kubernetes පොකුරක් ඇති විට, අපට මේ සඳහා සියල්ල වින්‍යාස කිරීමට අවශ්‍ය අමතර අතථ්‍ය යන්ත්‍රයක් අවශ්‍ය වන්නේ ඇයි?).
4. සමාන්තර එකලස් කිරීම, විවිධ ආකාරවලින් තේරුම් ගත හැකි: Dockerfile වෙතින් විවිධ විධාන (බහු-අදියර භාවිතා කරන්නේ නම්), එකම ගබඩාවේ කැපවීම් කිහිපයක්, Dockerfiles කිහිපයක්.
5. බෙදා හරින ලද එකලස් කිරීම: අපට "අකාලික" නිසා කරල් වල දේවල් එකතු කිරීමට අවශ්‍යයි ඔවුන්ගේ හැඹිලිය අතුරුදහන් වේ, එයින් අදහස් කරන්නේ එය වෙනම තැනක ගබඩා කළ යුතු බවයි.
6. අන්තිමට මම ආශාවන්ගේ මුදුන් මල්කඩ නම් කළා ස්වයංක්‍රීය: නිධිය වෙත ගොස් යම් විධානයක් ටයිප් කර නිවැරැදිව කළ යුත්තේ කෙසේද සහ කුමක් ද යන්න පිළිබඳ අවබෝධයක් ඇතිව සකස් කළ රූපයක් ලබා ගැනීම වඩාත් සුදුසුය. කෙසේ වෙතත්, සියලු සූක්ෂ්මතා මේ ආකාරයෙන් පුරෝකථනය කළ හැකි බව මට පෞද්ගලිකව විශ්වාස නැත.

සහ ව්‍යාපෘති මෙන්න:

• moby/buildkit - මෙම සියලු ගැටලු විසඳීමට උත්සාහ කරන Docker Inc (දැනටමත් Docker හි වත්මන් අනුවාදවලට ඒකාබද්ධ කර ඇත) වෙතින් ගොඩනගන්නෙක්;
• කනිකෝ - Docker නොමැතිව ගොඩ නැගීමට ඔබට ඉඩ සලසන Google වෙතින් ගොඩනගන්නෙක්;
• Buildpacks.io - CNCF හි ස්වයංක්‍රීය මැජික් සෑදීමට උත්සාහ කිරීම සහ, විශේෂයෙන්, ස්ථර සඳහා නැවත සකස් කිරීම සමඟ සිත්ගන්නා විසඳුමක්;
• සහ වැනි වෙනත් උපයෝගිතා පොකුරක් බිල්ඩා, genuinetools/img...

සහ GitHub මත ඔවුන්ට තරු කීයක් තිබේදැයි බලන්න. එනම්, එක් අතකින්, docker build පවතින අතර යමක් කළ හැකිය, නමුත් යථාර්ථයේ දී ප්රශ්නය සම්පූර්ණයෙන්ම විසඳා නැත - මෙය සනාථ කිරීම විකල්ප එකතුකරන්නන්ගේ සමාන්තර සංවර්ධනයයි, ඒ සෑම එකක්ම ගැටළු වලින් කොටසක් විසඳයි.

වර්ෆ් හි එකලස් කිරීම

ඉතින් අපිට සිද්ධ වුණා werf (පෙර ප්රසිද්ධ ඩප් වගේ) - අපි වසර ගණනාවක් තිස්සේ සාදන ලද Flant සමාගමෙන් විවෘත මූලාශ්‍ර උපයෝගීතාවයක්. ඒ සියල්ල ආරම්භ වූයේ මීට වසර 5 කට පෙර ඩොකර්ෆයිල්ස් එකලස් කිරීම ප්‍රශස්ත කළ Bash ස්ක්‍රිප්ට් සමඟ වන අතර පසුගිය වසර 3 තුළ පූර්ණ සංවර්ධනයක් එහිම Git ගබඩාවක් සහිත එක් ව්‍යාපෘතියක රාමුව තුළ සිදු කර ඇත. (පළමුව රූබි, සහ පසුව නැවත ලියා ඇත යාමට, සහ ඒ සමඟම නැවත නම් කරන ලදී). werf හි විසඳන එකලස් කිරීමේ ගැටළු මොනවාද?

නිල් පාටින් සෙවන ලද ගැටළු දැනටමත් ක්රියාත්මක කර ඇත, සමාන්තර ගොඩනැගීම එකම ධාරකය තුළ සිදු කර ඇති අතර, කහ පැහැයෙන් ඉස්මතු කර ඇති ගැටළු ගිම්හානය අවසන් වන විට අවසන් කිරීමට සැලසුම් කර ඇත.

ලේඛනයේ ප්‍රකාශන අදියර (ප්‍රකාශනය)

අපි ඩයල් කළා docker push... - රෙජිස්ට්රි වෙත රූපයක් උඩුගත කිරීමේදී අපහසු විය හැක්කේ කුමක් ද? එවිට ප්රශ්නය පැනනගින්නේ: "මම රූපය මත තැබිය යුතු ටැගය කුමක්ද?" එය අපට ඇති හේතුව නිසා ඇතිවේ Gitflow (හෝ වෙනත් Git උපාය මාර්ගයක්) සහ Kubernetes, සහ කර්මාන්තය උත්සාහ කරන්නේ Kubernetes හි සිදුවන දේ Git හි සිදුවන දේ අනුගමනය කරන බව සහතික කිරීමට ය. ඇත්ත වශයෙන්ම, Git අපගේ එකම සත්‍ය මූලාශ්‍රයයි.

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

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

ටැග් කිරීමේ උපාය මාර්ග

පළමු එක සරලයි git ටැගය. ලෙස ටැග් කර ඇති රූපයක් සහිත රෙජිස්ට්‍රියක් අප සතුව ඇත 1.0. Kubernetes මෙම රූපය උඩුගත කරන ලද වේදිකාව සහ නිෂ්පාදනය ඇත. Git වලදී අපි කැපවීම් කරන අතර යම් අවස්ථාවක අපි ටැග් කරමු 2.0. ගබඩාවෙන් ලැබෙන උපදෙස් අනුව අපි එය එකතු කර ටැග් සමඟ රෙජිස්ට්‍රියේ තබමු 2.0. අපි එය වේදිකාවට පෙරළා, සියල්ල හොඳින් නම්, නිෂ්පාදනයට.

මෙම ප්‍රවේශයේ ඇති ගැටළුව නම් අපි මුලින්ම ටැගය තැබූ අතර පසුව එය පරීක්ෂා කර පෙරළීමයි. ඇයි? පළමුව, එය හුදෙක් තාර්කික නොවේ: අපි තවමත් පරීක්‍ෂා කර නොමැති මෘදුකාංග අනුවාදයක් නිකුත් කරන්නෙමු (අපට වෙනත් ආකාරයකින් කළ නොහැක, මන්ද පරීක්ෂා කිරීම සඳහා අපට ටැගයක් තැබිය යුතුය). දෙවනුව, මෙම මාර්ගය Gitflow සමඟ නොගැලපේ.

දෙවන විකල්පය නම් git commit + tag. ප්‍රධාන ශාඛාවට ටැග් එකක් ඇත 1.0; රෙජිස්ට්රි තුළ එය සඳහා - නිෂ්පාදනය සඳහා යොදවා ඇති රූපයක්. මීට අමතරව, Kubernetes පොකුරට පෙරදසුන් සහ වේදිකා සමෝච්ඡයන් ඇත. ඊළඟට අපි Gitflow අනුගමනය කරමු: සංවර්ධනය සඳහා ප්‍රධාන ශාඛාවේ (develop) අපි නව විශේෂාංග සාදන්නෙමු, එහි ප්‍රතිඵලයක් ලෙස හැඳුනුම්කාරකය සමඟ බැඳීමක් ඇති වේ #c1. අපි එය එකතු කර මෙම හැඳුනුම්කාරකය භාවිතයෙන් එය රෙජිස්ට්‍රියේ ප්‍රකාශයට පත් කරමු (#c1) එකම හැඳුනුම්කාරකය සමඟ අපි පෙරදසුන් කිරීමට පෙරළන්නෙමු. අපි කැපවීම් සමඟත් එසේ කරන්නෙමු #c2 и #c3.

ප්රමාණවත් තරම් විශේෂාංග ඇති බව අප තේරුම් ගත් විට, අපි සියල්ල ස්ථාවර කිරීමට පටන් ගනිමු. Git හි ශාඛාවක් සාදන්න release_1.1 (පාදම මත #c3 සිට develop) මෙම නිකුතුව එකතු කිරීමට අවශ්‍ය නැත, මන්ද... මෙය පෙර පියවරේදී සිදු කරන ලදී. එමනිසා, අපට එය සරලව වේදිකාගත කළ හැකිය. අපි දෝෂ නිවැරදි කරමු #c4 සහ ඒ හා සමානව වේදිකාගත කිරීමට පෙරළන්න. ඒ අතරම, සංවර්ධනය වෙමින් පවතී develop, වෙනස්කම් වරින් වර ලබා ගන්නා තැන release_1.1. යම් අවස්ථාවක දී, අපට කැපවීමක් සම්පාදනය කර වේදිකාගත කිරීමට උඩුගත කරනු ලැබේ, එය අප සතුටු වේ (#c25).

එවිට අපි මුදා හැරීමේ ශාඛාව (වේගයෙන් ඉදිරියට) ඒකාබද්ධ කරන්නෙමු (release_1.1) මාස්ටර් තුළ. අපි මෙම කැපවීම මත නව අනුවාදය සමඟ ටැගයක් තැබුවෙමු (1.1) නමුත් මෙම පින්තූරය දැනටමත් රෙජිස්ට්‍රියේ එකතු කර ඇත, එබැවින් එය නැවත එකතු නොකිරීමට, අපි දැනට පවතින රූපයට දෙවන ටැගයක් එක් කරන්නෙමු (දැන් එයට රෙජිස්ට්‍රියේ ටැග් ඇත. #c25 и 1.1) ඊට පස්සේ, අපි එය නිෂ්පාදනයට පෙරළන්නෙමු.

වේදිකාගත කිරීම සඳහා එක් පින්තූරයක් පමණක් උඩුගත කිරීම අඩුපාඩුවක් ඇත (#c25), සහ නිෂ්පාදනයේදී එය යම් ආකාරයක වෙනස් (1.1), නමුත් "භෞතිකව" මේවා රෙජිස්ට්රි වෙතින් එකම රූපය බව අපි දනිමු.

සැබෑ අවාසිය නම් ඒකාබද්ධ කිරීම් සඳහා කිසිදු සහායක් නොමැති වීමයි, ඔබ වේගයෙන් ඉදිරියට යා යුතුය.

අපට තවත් ඉදිරියට ගොස් උපක්‍රමයක් කළ හැකිය... අපි සරල Dockerfile එකක උදාහරණයක් බලමු:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

පහත සඳහන් මූලධර්මය අනුව අපි එයින් ගොනුවක් ගොඩනඟමු:

• SHA256 භාවිතා කරන ලද පින්තූර හඳුනාගැනීම් වලින් (ruby:2.3 и nginx:alpine), ඒවායේ අන්තර්ගතයේ චෙක්සම්;
• සියලුම කණ්ඩායම් (RUN, CMD සහ යනාදි.);
• SHA256 එකතු කරන ලද ගොනු වලින්.

... සහ එවැනි ගොනුවකින් චෙක්සම් (නැවත SHA256) ගන්න. මෙය අත්සන ඩොකර් රූපයේ අන්තර්ගතය නිර්වචනය කරන සෑම දෙයක්ම.

අපි නැවතත් රූප සටහන වෙත යමු සහ කැපවීම් වෙනුවට අපි එවැනි අත්සන් භාවිතා කරමු, i.e. අත්සන් සහිත පින්තූර ටැග් කරන්න.

දැන්, අවශ්‍ය වූ විට, උදාහරණයක් ලෙස, නිකුතුවක සිට ප්‍රධාන දක්වා වෙනස්කම් ඒකාබද්ධ කිරීමට, අපට සැබෑ ඒකාබද්ධ කිරීමේ කැපවීමක් කළ හැකිය: එයට වෙනස් හඳුනාගැනීමක් ඇත, නමුත් එකම අත්සන ඇත. එකම හැඳුනුම්කාරකය සමඟ අපි රූපය නිෂ්පාදනයට පෙරළන්නෙමු.

අවාසිය නම්, නිෂ්පාදනයට තල්ලු කළේ කුමන ආකාරයේ කැපවීමක්ද යන්න දැන් තීරණය කිරීමට නොහැකි වනු ඇත - චෙක්සම් වැඩ කරන්නේ එක් දිශාවකට පමණි. මෙම ගැටළුව පාර-දත්ත සමඟ අතිරේක ස්ථරයකින් විසඳනු ලැබේ - මම ඔබට පසුව කියන්නම්.

werf හි ටැග් කිරීම

werf එකේ අපි ඊටත් එහා ගිහින් එක මැෂින් එකක ගබඩා නොවෙන කෑෂ් එකකින් ඩිස්ට්‍රිස්ට් රිඩ් බිල්ඩ් එකක් කරන්න ලෑස්ති ​​වෙනවා... ඉතින් අපි ඩොකර් ඉමේජ් වර්ග දෙකක් හදනවා, අපි ඒවාට කියන්නේ. අදියර и රූප.

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

මෙයින් පසු යෙදුම් කේතය පමණක් වෙනස් කර ඇති නව කැපවීමක් දිස්වේ යැයි සිතමු. කුමක් සිදුවේවිද? කේත වෙනස් කිරීම් සඳහා, පැච් එකක් සාදනු ලබන අතර නව වේදිකා රූපයක් සකස් කරනු ලැබේ. එහි අත්සන පැරණි වේදිකා රූපයේ සහ නව පැච් එකේ චෙක්සම් ලෙස තීරණය කරනු ලැබේ. මෙම රූපයෙන් නව අවසාන රූපයක් සාදනු ඇත. වෙනත් අදියරවල වෙනස්කම් සමඟ සමාන හැසිරීම් සිදුවනු ඇත.

මේ අනුව, අදියර රූප යනු බෙදාහැරීමේ ගබඩා කළ හැකි හැඹිලියක් වන අතර, එයින් දැනටමත් නිර්මාණය කර ඇති පින්තූර Docker Registry වෙත උඩුගත කරනු ලැබේ.

රෙජිස්ට්රි පිරිසිදු කිරීම

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

පිරිසිදු කිරීමේ උපාය මාර්ග මොනවාද?

1. ඔබට කිසිවක් කළ නොහැක පිරිසිදු නොකරන්න. සමහර විට විශාල ටැග් පටලැවිල්ලක් ලිහා ගැනීමට වඩා අමතර ඉඩක් සඳහා ටිකක් ගෙවීම ඇත්තෙන්ම පහසුය. නමුත් මෙය ක්‍රියාත්මක වන්නේ යම්කිසි කරුණක් දක්වා පමණි.
2. සම්පූර්ණ යළි පිහිටුවීම. ඔබ සියලුම පින්තූර මකා දමා CI පද්ධතියේ පවතින ඒවා පමණක් නැවත ගොඩනඟන්නේ නම්, ගැටළුවක් ඇතිවිය හැකිය. නිෂ්පාදනයේදී කන්ටේනරය නැවත ආරම්භ කළහොත්, ඒ සඳහා නව රූපයක් පටවනු ලැබේ - කිසිවෙකු විසින් තවමත් පරීක්ෂා කර නොමැති එකක්. මෙය වෙනස් කළ නොහැකි යටිතල පහසුකම් පිළිබඳ අදහස විනාශ කරයි.
3. නිල් කොල. එක් රෙජිස්ට්‍රියක් පිටාර ගැලීමට පටන් ගත්තේය - අපි පින්තූර තවත් එකකට උඩුගත කරමු. පෙර ක්‍රමයේ ඇති එකම ගැටළුව: පිටාර ගැලීමට පටන් ගෙන ඇති රෙජිස්ට්‍රිය ඉවත් කළ හැක්කේ කුමන අවස්ථාවේදීද?
4. කාලය විසින්. මාස 1කට වඩා පැරණි සියලුම පින්තූර මකන්නද? හැබැයි මාසයක් යනකන් අප්ඩේට් නොකරපු සර්විස් එකක් අනිවා එනවා...
5. අතින් දැනටමත් මකා දැමිය හැකි දේ තීරණය කරන්න.

සැබවින්ම ශක්‍ය විකල්ප දෙකක් තිබේ: පිරිසිදු නොකරන්න හෝ නිල්-කොළ + අතින් සංයෝජනයක්. අවසාන අවස්ථාවේ දී, අපි පහත සඳහන් දේ ගැන කතා කරමු: රෙජිස්ට්රි පිරිසිදු කිරීමට කාලය පැමිණ ඇති බව ඔබ තේරුම් ගත් විට, ඔබ නව එකක් සාදා, උදාහරණයක් ලෙස, මාසයක් පුරාවට සියලු නව පින්තූර එකතු කරන්න. මාසයකට පසු, කුබර්නෙටේස් හි කුමන කරල් තවමත් පැරණි රෙජිස්ට්‍රිය භාවිතා කරන්නේ දැයි බලන්න, ඒවාද නව රෙජිස්ට්‍රියට මාරු කරන්න.

අපි මොනවද ආවේ werf? අපි එකතු කරන්නේ:

1. Git head: සියලුම ටැග්, සියලුම ශාඛා - පින්තූරවල Git හි ටැග් කර ඇති සියල්ල අපට අවශ්‍ය යැයි උපකල්පනය කරමින් (සහ එසේ නොවේ නම්, අපි එය Git තුළම මකා දැමිය යුතුය);
2. දැනට Kubernetes වෙත පොම්ප කරන සියලුම කරල්;
3. පැරණි ReplicaSets (මෑතකදී නිකුත් කරන ලද දේ), තවද අපි Helm නිකුතු පරිලෝකනය කර එහි නවතම පින්තූර තෝරා ගැනීමටද සැලසුම් කරමු.

... සහ මෙම කට්ටලයෙන් සුදු ලැයිස්තුවක් සාදන්න - අපි මකා නොදමනු ලබන පින්තූර ලැයිස්තුවක්. අපි අනෙක් සියල්ල පිරිසිදු කර, පසුව අපි අනාථ වේදිකා රූප සොයාගෙන ඒවා මකා දමමු.

අදියර යෙදවීම

විශ්වසනීය ප්රකාශනය

යෙදවීමේදී මා අවධානය යොමු කිරීමට කැමති පළමු කරුණ නම් ප්‍රකාශනාත්මකව ප්‍රකාශ කරන ලද යාවත්කාලීන කළ සම්පත් වින්‍යාසය පෙරළීමයි. Kubernetes සම්පත් විස්තර කරන මුල් YAML ලේඛනය සෑම විටම පොකුරේ ක්‍රියාත්මක වන ප්‍රතිඵලයට වඩා බෙහෙවින් වෙනස් ය. Kubernetes වින්‍යාසයට එකතු කරන නිසා:

1. හඳුනාගැනීම්;
2. සේවා තොරතුරු;
3. බොහෝ පෙරනිමි අගයන්;
4. වත්මන් තත්ත්වය සහිත කොටස;
5. ඇතුළත් කිරීමේ webhook හි කොටසක් ලෙස සිදු කරන ලද වෙනස්කම්;
6. විවිධ පාලකයන්ගේ (සහ කාලසටහන්කරුගේ) කාර්යයේ ප්රතිඵලය.

එබැවින්, නව සම්පත් වින්‍යාසයක් දිස්වන විට (අළුත්), අපට එය සමඟ වත්මන්, “සජීවී” වින්‍යාසය ගෙන නැවත ලිවිය නොහැක (සජීවි) මෙය සිදු කිරීම සඳහා අපට සංසන්දනය කිරීමට සිදුවනු ඇත අළුත් අවසන් වරට යෙදූ වින්‍යාසය සමඟ (අවසන් වරට යෙදූ) සහ පෙරළන්න සජීවි පැච් ලැබුණා.

මෙම ප්රවේශය ලෙස හැඳින්වේ 2-මාර්ග ඒකාබද්ධ කිරීම. එය උදාහරණයක් ලෙස, හෙල්ම් හි භාවිතා වේ.

ද ඇත 3-මාර්ග ඒකාබද්ධ කිරීම, එය වෙනස් වේ:

• සංසන්දනය කිරීම අවසන් වරට යෙදූ и අළුත්, අපි මකා දැමූ දේ දෙස බලමු;
• සංසන්දනය කිරීම අළුත් и සජීවි, අපි එකතු කර ඇති හෝ වෙනස් කර ඇති දේ දෙස බලමු;
• සාරාංශගත පැච් එක යොදනු ලැබේ සජීවි.

අපි හෙල්ම් සමඟ යෙදුම් 1000+ යොදවන්නෙමු, එබැවින් අපි ඇත්ත වශයෙන්ම 2-මාර්ග ඒකාබද්ධ කිරීම සමඟ ජීවත් වෙමු. කෙසේ වෙතත්, එය අපගේ පැච් සමඟ විසඳා ඇති ගැටළු ගණනාවක් ඇත, එය සාමාන්‍යයෙන් ක්‍රියා කිරීමට Helm හට උපකාරී වේ.

සැබෑ පෙරළීමේ තත්ත්වය

අපගේ CI පද්ධතිය ඊළඟ සිදුවීම මත පදනම්ව Kubernetes සඳහා නව වින්‍යාසයක් ජනනය කළ පසු, එය භාවිතය සඳහා එය සම්ප්‍රේෂණය කරයි (අයදුම් කරන්න) පොකුරකට - හෙල්ම් භාවිතා කිරීම හෝ kubectl apply. ඊළඟට, දැනටමත් විස්තර කර ඇති N-way ඒකාබද්ධ කිරීම සිදු වේ, Kubernetes API CI පද්ධතියට සහ එහි පරිශීලකයාට අනුමත ලෙස ප්‍රතිචාර දක්වයි.

කෙසේ වෙතත්, විශාල ගැටළුවක් තිබේ: සියල්ලට පසු සාර්ථක යෙදුම යනු සාර්ථක ප්‍රවාහයක් අදහස් නොවේ. Kubernetes කුමන වෙනස්කම් යෙදිය යුතුද යන්න තේරුම් ගෙන එය යෙදුවහොත්, එහි ප්‍රතිඵලය කුමක්දැයි අපි තවමත් නොදනිමු. උදාහරණයක් ලෙස, පෙර අන්තයේ පොඩ් යාවත්කාලීන කිරීම සහ නැවත ආරම්භ කිරීම සාර්ථක විය හැකි නමුත් පසු අන්තයේ නොවේ, සහ ධාවනය වන යෙදුම් රූපවල විවිධ අනුවාද අපට ලැබෙනු ඇත.

සෑම දෙයක්ම නිවැරදිව කිරීමට, මෙම යෝජනා ක්‍රමයට අමතර සබැඳියක් අවශ්‍ය වේ - විශේෂ ට්‍රැකර් එකක් වන අතර එය Kubernetes API වෙතින් තත්ව තොරතුරු ලබා ගන්නා අතර දේවල්වල සැබෑ තත්වය පිළිබඳ වැඩිදුර විශ්ලේෂණය සඳහා එය සම්ප්‍රේෂණය කරයි. අපි Go හි විවෘත මූලාශ්‍ර පුස්තකාලයක් නිර්මාණය කළෙමු - cubedog (එහි නිවේදනය බලන්න මෙහි), මෙම ගැටළුව විසඳන අතර එය werf බවට ගොඩනගා ඇත.

වර්ෆ් මට්ටමේ මෙම ට්රැකර්ගේ හැසිරීම Deployments හෝ StatefulSets මත තබා ඇති අනුසටහන් භාවිතයෙන් වින්‍යාස කර ඇත. ප්‍රධාන විවරණ - fail-mode - පහත අර්ථයන් තේරුම් ගනී:

• IgnoreAndContinueDeployProcess - අපි මෙම සංරචකය පෙරළීමේ ගැටළු නොසලකා හැර, යෙදවීම දිගටම කරගෙන යන්නෙමු;
• FailWholeDeployProcessImmediately - මෙම සංරචකයේ දෝෂයක් යෙදවීමේ ක්රියාවලිය නතර කරයි;
• HopeUntilEndOfDeployProcess — මෙම සංරචකය යෙදවීම අවසන් වන විට වැඩ කරනු ඇතැයි අපි බලාපොරොත්තු වෙමු.

උදාහරණයක් ලෙස, සම්පත් සහ විවරණ අගයන්හි මෙම සංයෝජනය fail-mode:

අපි පළමු වරට යොදවන විට, දත්ත සමුදාය (MongoDB) තවම සූදානම් නොවිය හැකිය - යෙදවීම් අසාර්ථක වනු ඇත. නමුත් එය ආරම්භ වන මොහොත සඳහා ඔබට බලා සිටිය හැක, සහ යෙදවීම තවමත් සිදුවනු ඇත.

werf හි kubedog සඳහා තවත් විවරණ දෙකක් තිබේ:

• failures-allowed-per-replica - එක් එක් අනුරුව සඳහා අවසර ලත් වැටීම් ගණන;
• show-logs-until - සියලු රෝල් කරන ලද කරල් වලින් වර්ෆ් (stdout හි) ලඝු-සටහන් පෙන්වන මොහොත නියාමනය කරයි. පෙරනිමිය වේ PodIsReady (පොඩ් එකට ගමනාගමනය ආරම්භ වූ විට අපට අවශ්‍ය නොවන පණිවිඩ නොසලකා හැරීමට), නමුත් අගයන් ද වලංගු වේ: ControllerIsReady и EndOfDeploy.

යෙදවීමෙන් අපට අවශ්‍ය තවත් මොනවාද?

දැනටමත් විස්තර කර ඇති කරුණු දෙකට අමතරව, අපි කැමතියි:

• බලන්න සටහන් - සහ අවශ්‍ය ඒවා පමණක් වන අතර පේළියේ ඇති සියල්ල නොවේ;
• ධාවන පථය ප්‍රගතිය, කාර්යය මිනිත්තු කිහිපයක් සඳහා "නිහඬව" එල්ලී ඇත්නම්, එහි සිදුවන්නේ කුමක්ද යන්න තේරුම් ගැනීම වැදගත් වන බැවිනි;
• විය යුතුය ස්වයංක්රීය ආපසු හැරීම යම් දෙයක් වැරදී ගියහොත් (එබැවින් යෙදවීමේ සැබෑ තත්ත්වය දැන ගැනීම ඉතා වැදගත් වේ). පෙරළීම පරමාණුක විය යුතුය: එක්කෝ එය අවසානය දක්වා ගමන් කරයි, නැතහොත් සියල්ල එහි පෙර තත්වයට පැමිණේ.

ප්රතිඵල

සමාගමක් ලෙස අපට, බෙදා හැරීමේ විවිධ අවස්ථා වලදී විස්තර කර ඇති සියලුම සූක්ෂ්මතා ක්‍රියාත්මක කිරීමට (ඉදිකිරීම, ප්‍රකාශනය, යෙදවීම), CI පද්ධතියක් සහ උපයෝගීතාව ප්‍රමාණවත් වේ. werf.

නිගමනය වෙනුවට:

වර්ෆ්ගේ සහාය ඇතිව, අපි DevOps ඉංජිනේරුවන් සඳහා ගැටලු විශාල ප්‍රමාණයක් විසඳීමේ හොඳ ප්‍රගතියක් ලබා ඇති අතර පුළුල් ප්‍රජාව අවම වශයෙන් මෙම උපයෝගීතාව ක්‍රියාවෙන් උත්සාහ කළේ නම් සතුටු වනු ඇත. එකට හොඳ ප්රතිඵලයක් ලබා ගැනීමට පහසු වනු ඇත.

වීඩියෝ සහ විනිවිදක

කාර්ය සාධනයෙන් වීඩියෝව (මිනිත්තු 47):

වාර්තාව ඉදිරිපත් කිරීම:

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

අපගේ බ්ලොග් අඩවියේ Kubernetes පිළිබඳ වෙනත් වාර්තා:

• «Kubernetes හි ස්වයං පරිමාණය සහ සම්පත් කළමනාකරණය» (Dmitry Stolyarov; අප්රේල් 27, 2019 "වර්ජන" මත);
• «Kubernetes දිගු කිරීම සහ සම්පූර්ණ කිරීම» (Andrey Polovov; 8 අප්‍රේල් 2019 Saint HighLoad++ හි);
• «දත්ත සමුදායන් සහ Kubernetes» (Dmitry Stolyarov; නොවැම්බර් 8, 2018 HighLoad++ මත);
• «අධීක්ෂණය සහ කුබර්නෙටස්» (Dmitry Stolyarov; මැයි 28, 2018 RootConf හිදී);
• «Kubernetes සහ GitLab සමඟ CI/CD හොඳම භාවිතයන්» (Dmitry Stolyarov; නොවැම්බර් 7, 2017 HighLoad++ මත);
• «කුඩා ව්යාපෘති වල Kubernetes සමඟ අපගේ අත්දැකීම්» (Dmitry Stolyarov; ජූනි 6, 2017 RootConf හිදී).

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