ကွန်တိန်နာပုံများကို "စမတ်" သန့်ရှင်းရေးနှင့် werf တွင်၎င်း၏ဖြေရှင်းချက်

ဆောင်းပါးသည် Kubernetes ထံပေးပို့သော cloud ဇာတိအက်ပ်လီကေးရှင်းများအတွက် ခေတ်မီ CI/CD ပိုက်လိုင်းများ၏ လက်တွေ့ဖြစ်ရပ်များတွင် ကွန်တိန်နာမှတ်ပုံတင်ခြင်း (Docker Registry နှင့် ၎င်း၏ analogues) များတွင် စုပုံနေသောပုံများကို သန့်ရှင်းရေးလုပ်ခြင်းဆိုင်ရာ ပြဿနာများကို ဆွေးနွေးထားသည်။ ရုပ်ပုံများ၏ ဆက်စပ်မှုနှင့် အလိုအလျောက် သန့်ရှင်းရေး၊ နေရာချွေတာခြင်းနှင့် အသင်းများ၏ လိုအပ်ချက်များကို ပြည့်မီခြင်းအတွက် ရရှိလာသော အခက်အခဲများအတွက် အဓိက စံသတ်မှတ်ချက်များကို ပေးထားသည်။ နောက်ဆုံးတွင်၊ သီးခြား Open Source ပရောဂျက်တစ်ခု၏ ဥပမာကို အသုံးပြု၍ ဤအခက်အခဲများကို မည်သို့ကျော်လွှားနိုင်သည်ကို ကျွန်ုပ်တို့ ပြောပြပါမည်။

နိဒါန်း

ကွန်တိန်နာစာရင်းသွင်းမှုတစ်ခုရှိ ပုံအရေအတွက်သည် လျင်မြန်စွာကြီးထွားနိုင်ပြီး သိုလှောင်မှုနေရာပိုယူကာ ၎င်း၏ကုန်ကျစရိတ်ကို သိသိသာသာတိုးစေသည်။ မှတ်ပုံတင်မှုတွင် သိမ်းပိုက်နိုင်သော နေရာများ၏ ကြီးထွားမှုကို ထိန်းချုပ်၊ ကန့်သတ်ရန် သို့မဟုတ် ထိန်းသိမ်းရန်၊ ၎င်းကို လက်ခံသည်-

1. ပုံများအတွက် သတ်မှတ်ထားသော tag အရေအတွက်ကို အသုံးပြုပါ။
2. ပုံများကို တစ်နည်းနည်းဖြင့် သန့်ရှင်းပါ။

ပထမကန့်သတ်ချက်သည် တစ်ခါတစ်ရံတွင် အသင်းငယ်များအတွက် လက်ခံနိုင်သည်။ ဆော့ဖ်ဝဲရေးသားသူများသည် အမြဲတမ်း တဂ်များ လုံလောက်ပါက (latest, main, test, boris စသည်ဖြင့်) registry သည် အရွယ်အစား ကြီးလာမည် မဟုတ်သည့်အပြင် သန့်ရှင်းရေး လုပ်ဖို့ လုံးဝ စဉ်းစားနေစရာ မလိုတော့ဘဲ အချိန်အတော်ကြာအောင် ကြီးထွားနေပါသည်။ နောက်ဆုံးတွင်၊ မသက်ဆိုင်သောပုံများအားလုံးကို ဖျက်ပစ်ပြီး သန့်ရှင်းရေးလုပ်ရန် အလုပ်မကျန်တော့ပါ (အရာရာတိုင်းကို ပုံမှန်အမှိုက်သိမ်းသူမှ လုပ်ဆောင်သည်)။

သို့ရာတွင်၊ ဤချဉ်းကပ်မှုသည် ဖွံ့ဖြိုးတိုးတက်မှုကို များစွာ ကန့်သတ်ထားပြီး ခေတ်မီ CI/CD ပရောဂျက်များနှင့် သက်ဆိုင်ခဲပါသည်။ ဖွံ့ဖြိုးတိုးတက်မှု၏ အရေးပါသော အစိတ်အပိုင်းတစ်ခုဖြစ်ခဲ့သည်။ အလိုအလျောက်၎င်းသည် သုံးစွဲသူများထံ ပိုမိုမြန်ဆန်စွာ စမ်းသပ်ခြင်း၊ အသုံးချခြင်းနှင့် လုပ်ဆောင်ချက်အသစ်များကို ပေးအပ်နိုင်စေပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့၏ ပရောဂျက်အားလုံးတွင် ကတိတစ်ခုစီဖြင့် CI ပိုက်လိုင်းကို အလိုအလျောက် ဖန်တီးပါသည်။ ၎င်းတွင်၊ ရုပ်ပုံအား ပေါင်းစည်းခြင်း၊ စမ်းသပ်ခြင်း၊ အမှားရှာပြင်ခြင်းနှင့် ကျန်စစ်ဆေးမှုများအတွက် Kubernetes ဆားကစ်အမျိုးမျိုးသို့ ထုတ်ပေးပြီး အားလုံးကောင်းပါက အပြောင်းအလဲများသည် သုံးစွဲသူထံရောက်ရှိသွားမည်ဖြစ်သည်။ ဤအရာသည် ဒုံးပျံသိပ္ပံမဟုတ်တော့ဘဲ၊ သင်ဤဆောင်းပါးကိုဖတ်နေသောကြောင့် လူအများအတွက် နေ့စဉ်ဖြစ်ပျက်မှုတစ်ခုဖြစ်သည်။

အမှားအယွင်းများကို ပြုပြင်ခြင်းနှင့် လုပ်ဆောင်ချက်အသစ်များ တီထွင်ခြင်းတို့ကို အပြိုင်လုပ်ဆောင်ပြီး ထုတ်ဝေမှုများကို တစ်နေ့လျှင် အကြိမ်ပေါင်းများစွာ လုပ်ဆောင်နိုင်သောကြောင့် ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်သည် သိသာထင်ရှားသော ကတိက၀တ်များစွာဖြင့် လိုက်ပါသွားသည်မှာ ထင်ရှားပါသည်။ registry တွင် ပုံများစွာရှိသည်။. ရလဒ်အနေဖြင့် မှတ်ပုံတင်ခြင်းအား ထိရောက်စွာ သန့်ရှင်းရေးပြုလုပ်ရန် စည်းရုံးရေးကိစ္စရပ် ပေါ်ပေါက်လာပါသည်။ မသက်ဆိုင်သောပုံများကိုဖယ်ရှားပါ။

ဒါပေမယ့် ပုံတစ်ပုံဟာ ဆက်စပ်မှုရှိမရှိကို သင်ဘယ်လိုဆုံးဖြတ်မလဲ။

ပုံ၏ဆက်စပ်မှုများအတွက် စံသတ်မှတ်ချက်များ

ကိစ္စအများစုတွင်၊ အဓိက စံနှုန်းများမှာ-

1. ပထမဆုံး (အထင်ရှားဆုံးနှင့် အဝေဖန်အခံရဆုံး) သည် ထိုပုံများဖြစ်သည်။ Kubernetes တွင် လက်ရှိအသုံးပြုနေသည်။. ဤပုံများကို ဖယ်ရှားခြင်းသည် သိသာထင်ရှားသော ထုတ်လုပ်မှုရပ်နားချိန် ကုန်ကျစရိတ်ကို ဖြစ်ပေါ်စေသည် (ဥပမာ၊ ပုံများကို ပုံတူကူးရန်အတွက် လိုအပ်နိုင်သည်) သို့မဟုတ် loops တစ်ခုခုရှိ အဖွဲ့မှ အမှားရှာခြင်း၏ အားထုတ်မှုကို ငြင်းပယ်နိုင်သည်။ (ဒီအတွက်ကြောင့်မို့လို့ ထူးထူးခြားခြား လုပ်ခဲ့တာ Prometheus တင်ပို့သူမည်သည့် Kubernetes အစုအဝေးတွင်မဆို ထိုပုံများမရှိခြင်းကို ခြေရာခံသည်။)

2. ဒုတိယ (လူမသိသာသော်လည်း အလွန်အရေးကြီးပြီး အမြတ်ထုတ်ခြင်းနှင့် ထပ်ကာထပ်ကာဆက်စပ်နေသည်) - ထိုပုံများ ကြီးလေးသော ပြဿနာများကို ရှာဖွေတွေ့ရှိပါက ပြန်လှည့်ရန် လိုအပ်သည်။ လက်ရှိဗားရှင်းတွင်။ ဥပမာအားဖြင့်၊ Helm ကိစ္စတွင်၊ ၎င်းတို့သည် ထုတ်ဝေမှု၏ သိမ်းဆည်းထားသော ဗားရှင်းများတွင် အသုံးပြုထားသည့် ပုံများဖြစ်သည်။ (စကားမစပ်၊ Helm တွင် မူရင်းအားဖြင့် ကန့်သတ်ချက်သည် 256 တည်းဖြတ်ခြင်းဖြစ်သည်၊ သို့သော် မည်သူမဆို အမှန်တကယ်ကယ်တင်ရန် လိုအပ်မည်မဟုတ်ပေ။ ဤ ဗားရှင်းအမြောက်အများ?..) အထူးသဖြင့် ကျွန်ုပ်တို့သည် နောက်ပိုင်းတွင် ၎င်းတို့ကိုအသုံးပြုနိုင်စေရန်အတွက် ဗားရှင်းများကို သိမ်းဆည်းထားသည်။ လိုအပ်ပါက သူတို့ကို “ပြန်လှည့်” ပါ။

၃။တတိယ- developer လိုအပ်ချက်: ၎င်းတို့၏ လက်ရှိအလုပ်နှင့် ဆက်စပ်နေသည့် ပုံများအားလုံး။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် PR တစ်ခုကို စဉ်းစားနေပါက၊ နောက်ဆုံး commit နှင့် သက်ဆိုင်သော ပုံတစ်ပုံကို ချန်ထားခဲ့ရပြီး ယခင် commit ဟုဆိုနိုင်သည်- ဤနည်းဖြင့် developer သည် မည်သည့်လုပ်ငန်းကိုမဆို လျင်မြန်စွာ ပြန်သွားပြီး နောက်ဆုံးပြောင်းလဲမှုများနှင့် လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။

4. စတုတ္ထ- ရုပ်ပုံများ ကျွန်ုပ်တို့၏ အပလီကေးရှင်း၏ ဗားရှင်းများနှင့် ကိုက်ညီပါသည်။, i.e. နောက်ဆုံးထုတ်ကုန်များဖြစ်ကြသည်- v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, etc.

NB- ဤနေရာတွင် သတ်မှတ်ထားသော စံနှုန်းများသည် ကုမ္ပဏီများ အသီးသီးမှ ဒါဇင်ပေါင်းများစွာသော ဖွံ့ဖြိုးတိုးတက်ရေး အဖွဲ့များနှင့် အပြန်အလှန် အကျိုးပြုသည့် အတွေ့အကြုံအပေါ် အခြေခံ၍ ပုံဖော်ထားပါသည်။ သို့သော်၊ ဟုတ်ပါတယ်၊ ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်များနှင့် အသုံးပြုသည့် အခြေခံအဆောက်အဦများပေါ် မူတည်၍ (ဥပမာ Kubernetes ကို အသုံးမပြုပါ) ဤစံနှုန်းများ ကွဲပြားနိုင်ပါသည်။

အရည်အချင်းပြည့်မီမှုနှင့် လက်ရှိဖြေရှင်းချက်များ

စည်းကမ်းအတိုင်း ကွန်တိန်နာစာရင်းသွင်းခြင်းဆိုင်ရာ လူကြိုက်များသောဝန်ဆောင်မှုများသည် ၎င်းတို့၏ကိုယ်ပိုင်ရုပ်ပုံရှင်းလင်းရေးမူဝါဒများကို ပေးဆောင်သည်- ၎င်းတို့တွင် တဂ်တစ်ခုကို မှတ်ပုံတင်ခြင်းမှ ဖယ်ရှားသည့်အခြေအနေများကို သင်သတ်မှတ်နိုင်သည်။ သို့သော်၊ ဤအခြေအနေများကို အမည်များ၊ ဖန်တီးချိန်နှင့် တဂ်အရေအတွက်* ကဲ့သို့သော ကန့်သတ်ချက်များဖြင့် ကန့်သတ်ထားသည်။

* သတ်မှတ်ထားသော container registry အကောင်အထည်ဖော်မှုများအပေါ် မူတည်သည်။ အောက်ပါဖြေရှင်းချက်များ၏ဖြစ်နိုင်ချေများကို ကျွန်ုပ်တို့ထည့်သွင်းစဉ်းစားသည်- Azure CR၊ Docker Hub၊ ECR၊ GCR၊ GitHub Packages၊ GitLab Container Registry၊ Harbor Registry၊ JFrog Artifactory၊ Quay.io - စက်တင်ဘာလ '2020 ခုနှစ်အထိ။

ဤကန့်သတ်ချက်များသည် စတုတ္ထစံသတ်မှတ်ချက်ကို ကျေနပ်စေရန် လုံလောက်သည် - ဆိုလိုသည်မှာ ဗားရှင်းများနှင့် ကိုက်ညီသော ပုံများကို ရွေးချယ်ရန်ဖြစ်သည်။ သို့သော်၊ အခြားသတ်မှတ်ချက်များအားလုံးအတွက်၊ မျှော်မှန်းချက်နှင့်ဘဏ္ဍာရေးစွမ်းဆောင်နိုင်မှုအပေါ် မူတည်၍ (ပိုမိုပြင်းထန်သော သို့မဟုတ် အပြန်အလှန်အားဖြင့် ပိုမိုသက်ညှာသောမူဝါဒ) ကို ရွေးချယ်ရမည်ဖြစ်သည်။

ဥပမာအားဖြင့်၊ developer များ၏လိုအပ်ချက်များနှင့်ဆက်စပ်သော တတိယစံသတ်မှတ်ချက် - အဖွဲ့များအတွင်း လုပ်ငန်းစဉ်များကို စုစည်းခြင်းဖြင့် ဖြေရှင်းနိုင်သည်- ရုပ်ပုံများကို သတ်သတ်မှတ်မှတ်အမည်ပေးခြင်း၊ အထူးခွင့်ပြုစာရင်းများနှင့် ဌာနတွင်းသဘောတူညီချက်များကို ထိန်းသိမ်းခြင်း။ ဒါပေမယ့် နောက်ဆုံးမှာတော့ အလိုအလျောက်ဖြစ်ဖို့လိုပါသေးတယ်။ အဆင်သင့်လုပ်ထားသော ဖြေရှင်းချက်များ၏ စွမ်းဆောင်ရည်များ မလုံလောက်ပါက၊ သင်ကိုယ်တိုင် တစ်ခုခုလုပ်ရန် လိုအပ်သည်။

ပထမစံသတ်မှတ်ချက်နှစ်ခုပါသော အခြေအနေသည် ဆင်တူသည်- ပြင်ပစနစ်တစ်ခုမှ ဒေတာကို လက်ခံရရှိခြင်းမရှိဘဲ ၎င်းတို့သည် ကျေနပ်နိုင်မည်မဟုတ်ပေ - အပလီကေးရှင်းများကို ဖြန့်ကျက်ထားသည့် (ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ Kubernetes)။

Git ရှိ အလုပ်အသွားအလာပုံဥပမာ

သင်သည် Git တွင် ဤကဲ့သို့ လုပ်ဆောင်နေသည်ဟု ဆိုကြပါစို့။

ပုံတွင် ခေါင်းတစ်လုံးပါသော အိုင်ကွန်သည် မည်သည့်အသုံးပြုသူများ (အဆုံးအသုံးပြုသူများ၊ စမ်းသပ်သူများ၊ မန်နေဂျာများ စသည်ဖြင့်) သို့မဟုတ် အမှားရှာပြင်ခြင်းနှင့် အလားတူရည်ရွယ်ချက်များအတွက် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများက အသုံးပြုနေသည့် Kubernetes တွင် လက်ရှိအသုံးပြုနေသည့် ကွန်တိန်နာပုံများကို ဖော်ပြသည်။

ရှင်းလင်းရေးမူဝါဒများက ပုံများကိုသာ ထိန်းသိမ်းထားရန် ခွင့်ပြုပါက ဘာဖြစ်မည်နည်း (မဖျက်ပါ) ပေးထားသော tag အမည်များဖြင့်?

ဤကဲ့သို့သော အဖြစ်အပျက်သည် မည်သူတစ်ဦးတစ်ယောက်ကိုမျှ ပျော်ရွှင်စေမည်မဟုတ်ကြောင်း ထင်ရှားသည်။

ရုပ်ပုံများကို မဖျက်ပစ်ရန် မူဝါဒများက ခွင့်ပြုပါက မည်သို့ပြောင်းလဲမည်နည်း။ ပေးထားသော အချိန်ကြားကာလ / နောက်ဆုံး ကတိပြုမှု အရေအတွက်အရ?

ရလဒ်က အများကြီး ပိုကောင်းလာပေမယ့် စံပြနဲ့တော့ ဝေးပါသေးတယ်။ နောက်ဆုံးတွင်၊ အမှားရှာပြင်ရန် registry တွင် ပုံများ (သို့မဟုတ် K8s တွင်ထည့်သွင်းထားသည်) တွင် ပုံများလိုအပ်သော developer များရှိနေသေးသည်...

လက်ရှိစျေးကွက်အခြေအနေကို အကျဉ်းချုပ်ပြောရလျှင်- ကွန်တိန်နာစာရင်းသွင်းခြင်းတွင် ရရှိနိုင်သောလုပ်ဆောင်ချက်များသည် သန့်ရှင်းရေးလုပ်သည့်အခါ လုံလောက်သောပြောင်းလွယ်ပြင်လွယ်မရှိပါ၊ ၎င်းအတွက် အဓိကအကြောင်းရင်းမှာ၊ ပြင်ပကမ္ဘာနှင့် ဆက်ဆံရန် နည်းလမ်းမရှိပါ။. Docker Registry API (သို့မဟုတ် သက်ဆိုင်ရာ အကောင်အထည်ဖော်မှု၏ မူရင်း API) ကို အသုံးပြု၍ ရုပ်ပုံဖျက်ခြင်း "ပြင်ပမှ" ကို လွတ်လပ်စွာ ဖျက်ရန် ဖိအားပေးခံရကြောင်း တွေ့ရှိရပါသည်။

သို့သော်၊ မတူညီသော မှတ်ပုံတင်မှုများကို အသုံးပြု၍ မတူညီသောအဖွဲ့များအတွက် ရုပ်ပုံရှင်းလင်းခြင်းကို အလိုအလျောက်လုပ်ဆောင်ပေးမည့် universal solution တစ်ခုကို ရှာဖွေနေပါသည်...

ကျွန်ုပ်တို့၏ စကြဝဠာပုံသဏ္ဍာန် သန့်ရှင်းရေးဆီသို့

ဒီလိုအပ်ချက်က ဘယ်ကလာတာလဲ။ အမှန်မှာ ကျွန်ုပ်တို့သည် သီးခြား developer အဖွဲ့မဟုတ်သော်လည်း CI/CD ပြဿနာများကို ကျယ်ကျယ်ပြန့်ပြန့်ဖြေရှင်းရန် ကူညီပေးသော ၎င်းတို့ထဲမှ အများအပြားကို တစ်ချိန်တည်းတွင် ဝန်ဆောင်မှုပေးသော အဖွဲ့ဖြစ်သည်။ ၎င်းအတွက် အဓိကနည်းပညာဆိုင်ရာကိရိယာမှာ Open Source utility ဖြစ်သည်။ werf. ၎င်း၏ထူးခြားချက်မှာ ၎င်းသည် လုပ်ဆောင်ချက်တစ်ခုတည်းကို မလုပ်ဆောင်ဘဲ၊ အဆင့်အားလုံးတွင် စဉ်ဆက်မပြတ် ပေးပို့ခြင်းလုပ်ငန်းစဉ်များနှင့်အတူ လိုက်ပါသည်- တပ်ဆင်မှုမှ ဖြန့်ကျက်ခြင်းအထိ။

ပုံများကို registry* သို့ လွှင့်တင်ခြင်း (၎င်းတို့ကို တည်ဆောက်ပြီးနောက် ချက်ခြင်း) သည် ထိုကဲ့သို့သော utility ၏ သိသာထင်ရှားသောလုပ်ဆောင်ချက်တစ်ခုဖြစ်သည်။ ရုပ်ပုံများကို သိမ်းဆည်းရန်အတွက် ထိုနေရာတွင် ထားရှိထားသောကြောင့် - သင်၏ သိုလှောင်မှုသည် အကန့်အသတ်မရှိပါက - ၎င်းတို့၏ နောက်ဆက်တွဲ သန့်ရှင်းရေးအတွက် သင် တာဝန်ယူရန် လိုအပ်ပါသည်။ သတ်မှတ်ထားတဲ့ စံနှုန်းတွေအားလုံးကို ကျေနပ်အောင် ဘယ်လိုအောင်မြင်မှုရခဲ့သလဲ ဆိုတာ ဆက်လက်ဆွေးနွေးပါဦးမယ်။

* မှတ်ပုံတင်ခြင်းများသည် ၎င်းတို့ကိုယ်တိုင် မတူညီနိုင်သော်လည်း (Docker Registry၊ GitLab Container Registry၊ Harbor စသည်ဖြင့်)၊ ၎င်းတို့၏အသုံးပြုသူများသည် တူညီသောပြဿနာများကို ရင်ဆိုင်ရသည်။ ကျွန်ုပ်တို့၏ကိစ္စတွင် universal solution သည် registry ၏အကောင်အထည်ဖော်မှုပေါ်တွင်မူတည်ခြင်းမရှိသောကြောင့်ဖြစ်သည်။ မှတ်ပုံတင်ခြင်း၏ပြင်ပတွင် ၎င်းတို့ကိုယ်တိုင် လုပ်ဆောင်ပြီး လူတိုင်းအတွက် တူညီသောအပြုအမူကို ပေးဆောင်သည်။

werf ကို နမူနာအကောင်အထည်ဖော်မှုအဖြစ် ကျွန်ုပ်တို့အသုံးပြုနေသော်လည်း၊ အလားတူအခက်အခဲများနှင့်ရင်ဆိုင်နေရသော အခြားအသင်းများအတွက် အသုံးပြုသည့်ချဉ်းကပ်မှုများသည် အသုံးဝင်လိမ့်မည်ဟု မျှော်လင့်ပါသည်။

ဒါနဲ့ ငါတို့ အလုပ်ရှုပ်သွားတယ်။ ပြင်ပ ပုံများကို သန့်ရှင်းရေးလုပ်ရန် ယန္တရားတစ်ခုကို အကောင်အထည်ဖော်ခြင်း - ကွန်တိန်နာများအတွက် စာရင်းသွင်းထားပြီးသော စွမ်းရည်များအစား၊ ပထမအဆင့်မှာ တဂ်အရေအတွက်နှင့် ၎င်းတို့၏ဖန်တီးချိန်အတွက် တူညီသော မူလမူဝါဒများကို ဖန်တီးရန် Docker Registry API ကို အသုံးပြုရန်ဖြစ်သည်။ ၎င်းတို့ကို ထည့်ပေးခဲ့သည်။ ဖြန့်ကျက်ထားသော အခြေခံအဆောက်အဦများတွင် အသုံးပြုထားသော ပုံများကို အခြေခံ၍ စာရင်းခွင့်ပြုပါ။, i.e. Kubernetes နောက်ဆုံးတွင်၊ အသုံးပြုထားသည့် အရင်းအမြစ်များအားလုံးမှတဆင့် ထပ်ပြီးဖော်ပြရန်နှင့် တန်ဖိုးစာရင်းတစ်ခုရယူရန် Kubernetes API ကို အသုံးပြုရန် လုံလောက်ပါသည်။ image.

ဤအသေးအဖွဲဖြေရှင်းချက်သည် အလွန်အရေးကြီးသောပြဿနာ (စံသတ်မှတ်ချက်နံပါတ် 1) ကို ဖြေရှင်းပေးခဲ့သော်လည်း သန့်ရှင်းရေးယန္တရားကို မြှင့်တင်ရန် ကျွန်ုပ်တို့၏ခရီးအစသာဖြစ်သည်။ နောက်တစ်ဆင့်က ပိုစိတ်ဝင်စားစရာကောင်းတဲ့ အဆင့်က ဆုံးဖြတ်ချက်ပါပဲ။ Git မှတ်တမ်းနှင့် ထုတ်ဝေထားသော ပုံများကို တွဲဖက်ပါ။.

Tagging အစီအစဉ်များ

စတင်ရန်၊ နောက်ဆုံးပုံသည် သန့်ရှင်းရေးအတွက် လိုအပ်သောအချက်အလက်များကို သိမ်းဆည်းထားသင့်ပြီး tagging အစီအစဉ်များပေါ်တွင် လုပ်ငန်းစဉ်ကို တည်ဆောက်ပေးမည့် ချဉ်းကပ်မှုတစ်ခုကို ကျွန်ုပ်တို့ ရွေးချယ်ခဲ့သည်။ ပုံတစ်ပုံကို လွှင့်တင်သောအခါတွင်၊ အသုံးပြုသူသည် သတ်မှတ်ထားသော tagging ရွေးချယ်မှုတစ်ခုကို ရွေးချယ်ခဲ့သည် (git-branch, git-commit သို့မဟုတ် git-tag) နှင့် သက်ဆိုင်သောတန်ဖိုးကို အသုံးပြုခဲ့သည်။ CI စနစ်များတွင်၊ ဤတန်ဖိုးများကို ပတ်ဝန်းကျင် ကိန်းရှင်များပေါ်တွင် အခြေခံ၍ အလိုအလျောက် သတ်မှတ်ပေးသည်။ တကယ်တော့ နောက်ဆုံးပုံသည် သီးခြား Git primitive နှင့် ဆက်စပ်နေပါသည်။အညွှန်းများတွင် သန့်ရှင်းရေးအတွက် လိုအပ်သောဒေတာကို သိမ်းဆည်းခြင်း။

ဤချဉ်းကပ်မှုသည် Git ကို အမှန်တရား၏ တစ်ခုတည်းသောအရင်းအမြစ်အဖြစ် အသုံးပြုရန် ခွင့်ပြုထားသော မူဝါဒအစုံကို ဖြစ်ပေါ်စေသည်-

• Git ရှိ အကိုင်းအခက်/တက်ဂ်တစ်ခုကို ဖျက်လိုက်သောအခါ၊ မှတ်ပုံတင်ခြင်းရှိ ဆက်စပ်ပုံများကို အလိုအလျောက် ဖျက်ပစ်လိုက်သည်။
• Git တဂ်များနှင့် ကတိပြုမှုများနှင့် ဆက်စပ်နေသည့် ပုံအရေအတွက်ကို ရွေးချယ်ထားသည့် schema တွင် အသုံးပြုသည့် တဂ်အရေအတွက်နှင့် ဆက်စပ် ကတိပြုမှုကို ဖန်တီးသည့်အချိန်ဖြင့် ထိန်းချုပ်နိုင်သည်။

ယေဘုယျအားဖြင့်၊ ရလဒ်အကောင်အထည်ဖော်မှုသည် ကျွန်ုပ်တို့၏လိုအပ်ချက်များကို ဖြည့်ဆည်းပေးသော်လည်း မကြာမီတွင် စိန်ခေါ်မှုအသစ်တစ်ခုက ကျွန်ုပ်တို့ကို စောင့်ကြိုနေပါသည်။ အမှန်မှာ Git primitives များကိုအခြေခံ၍ tagging schemes ကိုအသုံးပြုနေစဉ်တွင် ချို့ယွင်းချက်များစွာကို ကျွန်ုပ်တို့ကြုံတွေ့ခဲ့ရသည်။ (သူတို့၏ဖော်ပြချက်သည် ဤဆောင်းပါး၏ ဘောင်ကိုကျော်လွန်သွားသောကြောင့်၊ လူတိုင်းသည် အသေးစိတ်အချက်အလက်များနှင့် ၎င်းတို့ကို ရင်းနှီးနိုင်သည်။ ဒီမှာ.) ထို့ကြောင့်၊ တဂ်လုပ်ခြင်း (အကြောင်းအရာအခြေခံ တဂ်လုပ်ခြင်း) တွင် ပိုမိုထိရောက်သောချဉ်းကပ်မှုသို့ ပြောင်းရန် ဆုံးဖြတ်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် ရုပ်ပုံရှင်းလင်းခြင်း၏ အကောင်အထည်ဖော်မှုကို ပြန်လည်စဉ်းစားရန် လိုအပ်ပါသည်။

အယ်လဂိုရီသမ်အသစ်

အဘယ်ကြောင့်? အကြောင်းအရာအခြေခံ တဂ်ခြင်းဖြင့်၊ တဂ်တစ်ခုစီသည် Git တွင် ကျူးလွန်မှုများစွာကို ကျေနပ်စေနိုင်သည်။ ရုပ်ပုံများကို သန့်ရှင်းရေးလုပ်သောအခါတွင် သင်သည် မယူဆနိုင်တော့ပါ။ သာ tag အသစ်ကို registry တွင်ထည့်ထားသည့် commit မှ။

သန့်ရှင်းရေးဆိုင်ရာ အယ်လဂိုရီသမ်အသစ်အတွက်၊ တဂ်လုပ်ခြင်းအစီအစဉ်များနှင့် တည်ဆောက်ခြင်းမှ ထွက်ခွာရန် ဆုံးဖြတ်ခဲ့သည်။ meta-image လုပ်ငန်းစဉ်အစုအဝေးတစ်ခုစီကို သိမ်းဆည်းပေးသော၊

• ပုံနှိပ်ထုတ်ဝေခြင်းအား လုပ်ဆောင်ခဲ့သည့် ကတိကဝတ် (ပုံအား ထည့်သွင်းခြင်း၊ ပြောင်းလဲခြင်း သို့မဟုတ် ကွန်တိန်နာစာရင်းသွင်းခြင်းတွင် အတူတူရှိနေသည်ဖြစ်စေ အရေးမကြီးပါ)၊
• နှင့် စုစည်းထားသော ပုံနှင့် သက်ဆိုင်သော ကျွန်ုပ်တို့၏ အတွင်းပိုင်း identifier

တစ်နည်းဆိုရသော် ထောက်ပံ့ပေးခဲ့သည်။ Git ရှိ commits များနှင့် ထုတ်ဝေထားသော tag များကို ချိတ်ဆက်ခြင်း။.

နောက်ဆုံးဖွဲ့စည်းပုံနှင့် အထွေထွေ အယ်လဂိုရီသမ်

သန့်ရှင်းရေးကို စီစဉ်သတ်မှတ်သည့်အခါ၊ အသုံးပြုသူများသည် လက်ရှိပုံများကို ရွေးချယ်သည့် မူဝါဒများကို အသုံးပြုခွင့် ရရှိနေပြီဖြစ်သည်။ ယင်းမူဝါဒတစ်ခုစီကို သတ်မှတ်ထားသည်-

• များစွာသောကိုးကား, i.e. စကင်န်ဖတ်နေစဉ်အသုံးပြုသည့် Git tags သို့မဟုတ် Git အကိုင်းအခက်များ။
• နှင့် set မှ အကိုးအကားတစ်ခုစီအတွက် ရှာဖွေထားသော ပုံများ၏ ကန့်သတ်ချက်။

ဥပမာအနေဖြင့်၊ ဤသည်မှာ မူလမူဝါဒဖွဲ့စည်းပုံပုံစံ စတင်ပုံပေါ်သည်-

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. နောက်ဆုံး 10 Git tags (tag ဖန်တီးသည့်ရက်စွဲဖြင့်) အတွက် ရုပ်ပုံကို သိမ်းဆည်းပါ။
2. ပြီးခဲ့သောအပတ်တွင် လှုပ်ရှားမှုပါသော စာတွဲ 2 ခုထက်မပိုဘဲ ပြီးခဲ့သည့်အပတ်က ထုတ်ပြန်ထားသော ပုံ 10 ပုံထက် မပိုစေဘဲ သိမ်းဆည်းပါ။
3. အကိုင်းအခက်များအတွက် ပုံ ၁၀ ပုံ သိမ်းဆည်းပါ။ main, staging и production.

နောက်ဆုံး algorithm သည် အောက်ပါအဆင့်များအထိ ပြုတ်သွားသည် ။

• ကွန်တိန်နာမှတ်ပုံတင်ခြင်းမှ မန်နီးဖက်စ်များကို ပြန်လည်ရယူခြင်း။
• Kubernetes တွင် အသုံးပြုထားသော ပုံများ မပါဝင်သောကြောင့်၊ K8s API ကို စစ်တမ်းကောက်ယူခြင်းဖြင့် ၎င်းတို့ကို ကြိုတင်ရွေးချယ်ထားပြီးဖြစ်သည်။
• သတ်မှတ်ထားသော မူဝါဒများအပေါ် အခြေခံ၍ Git မှတ်တမ်းကို စကင်န်ဖတ်ခြင်းနှင့် ပုံများကို ဖယ်ထုတ်ခြင်း။
• ကျန်ပုံများကို ဖယ်ရှားခြင်း။

ကျွန်ုပ်တို့၏ပုံဥပမာသို့ပြန်သွားသောအခါ၊ ဤအရာသည် werf နှင့်ဖြစ်ပျက်သည်-

သို့သော် အကယ်၍ သင်သည် werf ကိုအသုံးမပြုသော်လည်း၊ အကောင်အထည်ဖော်မှုတစ်ခု သို့မဟုတ် အခြားတစ်ခုတွင် (ပုံတစ်ပုံတစ်ပုံချင်းချိတ်ခြင်းအတွက် နှစ်သက်သောချဉ်းကပ်မှုအရ) - အခြားစနစ်/အသုံးအဆောင်များတွင် အသုံးပြုနိုင်သည်။ ဒီလိုလုပ်ဖို့၊ ဖြစ်ပေါ်လာတဲ့ပြဿနာတွေကို မှတ်မိပြီး သူတို့ရဲ့ဖြေရှင်းချက်တွေကို တတ်နိုင်သမျှ ချောမွေ့စွာပေါင်းစည်းနိုင်စေမယ့် သင့် stack ထဲမှာ အဲဒီအခွင့်အလမ်းတွေကို ရှာတွေ့ဖို့ လုံလောက်ပါတယ်။ ငါတို့သွားခဲ့တဲ့လမ်းက မင်းရဲ့အသေးစိတ်အချက်အလက်အသစ်တွေနဲ့ အတွေးအမြင်အသစ်တွေနဲ့ မင်းရဲ့ကိစ္စရပ်ကိုကြည့်ရာမှာ အထောက်အကူဖြစ်မယ်လို့ မျှော်လင့်ပါတယ်။

ကောက်ချက်

• များမကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင် အသင်းအများစုသည် registry ပြည့်လျှံမှုပြဿနာကို ကြုံတွေ့ရသည်။
• အဖြေများကိုရှာဖွေသောအခါ၊ ရုပ်ပုံ၏ဆက်စပ်မှုများအတွက် စံသတ်မှတ်ချက်များကို ဦးစွာဆုံးဖြတ်ရန် လိုအပ်ပါသည်။
• လူကြိုက်များသော ကွန်တိန်နာစာရင်းသွင်းခြင်းဝန်ဆောင်မှုများမှ ပေးဆောင်သော ကိရိယာများသည် "ပြင်ပကမ္ဘာ" ကို ထည့်သွင်းစဉ်းစားခြင်းမပြုဘဲ အလွန်ရိုးရှင်းသော ရှင်းလင်းမှုကို စုစည်းနိုင်စေသည်- Kubernetes တွင် အသုံးပြုသည့် ပုံများနှင့် အဖွဲ့၏ လုပ်ငန်းအသွားအလာများ၏ ထူးခြားချက်များ။
• လိုက်လျောညီထွေရှိပြီး ထိရောက်သော အယ်လဂိုရီသမ်တစ်ခုသည် CI/CD လုပ်ငန်းစဉ်များကို နားလည်သဘောပေါက်ပြီး Docker ရုပ်ပုံဒေတာဖြင့်သာမကဘဲ လည်ပတ်နိုင်သည်။

PS

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «werf စုဆောင်းသူတွင် အကြောင်းအရာ-အခြေခံတဂ်လုပ်ခြင်း- အဘယ်ကြောင့်နှင့် မည်သို့အလုပ်လုပ်သနည်း။";
• «werf သို့ 3-လမ်း ပေါင်းစည်းခြင်း- "စတီရွိုက်များပေါ်တွင်" Helm ဖြင့် Kubernetes သို့ ဖြန့်ကျက်ခြင်း";
• «werf တွင် monorepo နှင့် multirepo အတွက် ပံ့ပိုးမှု နှင့် Docker Registry သည် ၎င်းနှင့် သက်ဆိုင်သည်။";
• «werf 1.1 ထုတ်ဝေမှု- ယနေ့ တည်ဆောက်သူအတွက် တိုးတက်မှုများနှင့် အနာဂတ်အတွက် အစီအစဉ်များ"။

source: www.habr.com