werf စုဆောင်းသူတွင် အကြောင်းအရာ-အခြေခံတဂ်လုပ်ခြင်း- အဘယ်ကြောင့်နှင့် မည်သို့အလုပ်လုပ်သနည်း။

werf Kubernetes ထံ အက်ပ်များကို တည်ဆောက်ခြင်းနှင့် ပေးပို့ခြင်းအတွက် ကျွန်ုပ်တို့၏ open source GitOps CLI utility ဖြစ်သည်။ IN v1.1 ကိုထုတ်သည်။ ရုပ်ပုံစုဆောင်းသူတွင် အင်္ဂါရပ်အသစ်ကို မိတ်ဆက်ခဲ့သည်- ရုပ်ပုံများကို အကြောင်းအရာအလိုက် သို့မဟုတ် တဂ်လုပ်ခြင်း။ အကြောင်းအရာအခြေခံတဂ်လုပ်ခြင်း။. ယခုအချိန်အထိ၊ werf ရှိ ပုံမှန်တဂ်လုပ်ခြင်းအစီအစဉ်တွင် Git tag၊ Git ဌာနခွဲ သို့မဟုတ် Git commit ဖြင့် Docker ပုံများကို တဂ်ထိုးခြင်းပါ၀င်သည်။ သို့သော် ဤအစီအစဥ်များအားလုံးတွင် tagging နည်းဗျူဟာအသစ်ဖြင့် လုံးဝဖြေရှင်းနိုင်သော အားနည်းချက်များရှိသည်။ ဒီအကြောင်းအသေးစိတ်နဲ့ ဘာကြောင့် ဒီလောက်ကောင်းလဲဆိုတာကို အောက်မှာ ဖော်ပြပေးလိုက်ပါတယ်။

Git repository တစ်ခုမှ microservices အစုံကို ထုတ်လွှတ်ခြင်း။

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

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

သို့သော်လည်း လက်တွေ့တွင်၊ developer များသည် application တစ်ခုတည်းကို microservices အများအပြားအဖြစ် ပိုင်းခြားလေ့ရှိသော်လည်း တစ်ခုစီအတွက် သီးခြား repository နှင့် project တစ်ခုကို ဖန်တီးခြင်းသည် ရှင်းရှင်းလင်းလင်း ကျော်လွန်သွားပါသည်။ ဆက်လက်ဆွေးနွေးမည့် ဤအခြေအနေမှာ- ဤကဲ့သို့သော မိုက်ခရိုဝန်ဆောင်မှုအများအပြားကို ပရောဂျက်သိုလှောင်ရုံတစ်ခုတွင် တည်ရှိပြီး CI/CD တွင် လုပ်ငန်းစဉ်တစ်ခုတည်းဖြင့် ထုတ်ဝေမှုများ ဖြစ်ပေါ်ပါသည်။

Git အကိုင်းအခက်နှင့် Git tag ဖြင့်တဂ်ခြင်း။

အသုံးအများဆုံး tagging နည်းဗျူဟာကို အသုံးပြုသည် ဆိုကြပါစို့။ tag-or-ကိုင်း. Git အကိုင်းအခက်များအတွက်၊ ပုံများကို ဌာနခွဲအမည်ဖြင့် တဂ်လုပ်ထားပါသည်၊ တစ်ချိန်တည်းတွင် ဌာနခွဲတစ်ခုအတွက် ထိုဌာနခွဲ၏အမည်ဖြင့် ထုတ်ဝေထားသော ပုံတစ်ပုံသာရှိသည်။ Git တဂ်များအတွက်၊ တဂ်အမည်အရ ပုံများကို တဂ်ထားသည်။

Git တဂ်အသစ်ကို ဖန်တီးသည့်အခါ—ဥပမာ၊ ဗားရှင်းအသစ်တစ်ခု ထွက်ရှိလာသောအခါ— Docker တဂ်အသစ်သည် Docker Registry ရှိ ပရောဂျက်ပုံများအားလုံးအတွက် ဖန်တီးလိမ့်မည်-

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 ဖွဲ့စည်းမှုပုံစံသို့ ပေးပို့ပါသည်။ command ဖြင့် deployment စတင်သောအခါ werf deploy အကွက်ကို အပ်ဒိတ်လုပ်နေပါသည်။ image Kubernetes အရင်းအမြစ်တွင် ဖော်ပြပြီး ပြောင်းလဲထားသော ပုံအမည်ကြောင့် သက်ဆိုင်ရာ အရင်းအမြစ်များကို ပြန်လည်စတင်သည်။

ပြဿနာ: အမှန်မှာ၊ ယခင်ထွက်ရှိထားသော (Git tag) ကတည်းက ပုံ၏အကြောင်းအရာများသည် မပြောင်းလဲသေးသော်လည်း ၎င်း၏ Docker tag သာဖြစ်သည့်အခါ၊ ပိုလျှံ ဤအပလီကေးရှင်းကို ပြန်လည်စတင်ခြင်းဖြင့် အချို့သော စက်ရပ်ချိန်ဖြစ်နိုင်သည်။ ဤပြန်လည်စတင်ရန် အမှန်တကယ်အကြောင်းပြချက်မရှိသော်လည်း၊

ရလဒ်အနေဖြင့်၊ လက်ရှိ tagging အစီအစဉ်ဖြင့် သီးခြား Git repositories အများအပြားကို ကာရံထားရန် လိုအပ်ပြီး အဆိုပါ repositories အများအပြားကို ဖြန့်ကျက်စီစဉ်ရာတွင် ပြဿနာပေါ်ပေါက်လာပါသည်။ ယေဘူယျအားဖြင့်၊ ထိုသို့သောအစီအစဥ်သည် ဝန်ပို၍ ရှုပ်ထွေးနေပါသည်။ ဝန်ဆောင်မှုများစွာကို သိုလှောင်ရုံတစ်ခုတည်းတွင် ပေါင်းစပ်ပြီး မလိုအပ်ဘဲ ပြန်လည်စတင်ခြင်းများ မရှိစေရန် Docker tags များကို ဖန်တီးခြင်းသည် ပိုကောင်းပါသည်။

Git commit ဖြင့် တဂ်ခြင်း။

werf တွင် Git commits နှင့်ဆက်စပ်သော tagging နည်းဗျူဟာလည်းရှိသည်။

Git-commit သည် Git repository ၏ အကြောင်းအရာများအတွက် identifier တစ်ခုဖြစ်ပြီး Git repository ရှိ ဖိုင်များ၏ တည်းဖြတ်မှုမှတ်တမ်းအပေါ် မူတည်သောကြောင့် Docker Registry တွင် ပုံများကို တဂ်လုပ်ရန်အတွက် ၎င်းကို အသုံးပြုခြင်းသည် ယုတ္တိရှိပုံရသည်။

သို့သော်၊ Git commit မှ တဂ်ခြင်းသည် Git အကိုင်းအခက်များ သို့မဟုတ် Git tags များဖြင့် တဂ်ခြင်းကဲ့သို့ အားနည်းချက်များရှိသည်။

မည်သည့်ဖိုင်ကိုမှ မပြောင်းလဲသည့် ဗလာ commit တစ်ခုကို ဖန်တီးနိုင်သော်လည်း ပုံ၏ Docker tag ကို ပြောင်းလဲသွားပါမည်။
ဖိုင်များကို မပြောင်းလဲသော ပေါင်းစည်းမှုတစ်ခု ဖန်တီးနိုင်သော်လည်း ပုံ၏ Docker တဂ်ကို ပြောင်းလဲသွားပါမည်။
ပုံထဲသို့ မတင်သွင်းထားသော Git အတွင်းရှိ အဆိုပါဖိုင်များကို ပြောင်းလဲနိုင်ပြီး ပုံ၏ Docker တဂ်ကို ထပ်မံပြောင်းလဲပါမည်။

Git ဌာနခွဲအမည်ကို တဂ်လုပ်ခြင်းသည် ပုံဗားရှင်းနှင့် မကိုက်ညီပါ။

Git အကိုင်းအခက်များအတွက် တဂ်လုပ်ခြင်းဗျူဟာနှင့် ဆက်စပ်သည့် နောက်ထပ်ပြဿနာတစ်ခုရှိပါသည်။

ထိုဌာနခွဲတွင် ကတိကဝတ်များကို အချိန်နှင့် တပြေးညီ စုဆောင်းထားသရွေ့ ဌာနခွဲအမည်ဖြင့် တဂ်လုပ်ခြင်း လုပ်ဆောင်ပါသည်။

လက်ရှိအစီအစဥ်တွင် အသုံးပြုသူသည် အချို့သောဌာနခွဲတစ်ခုနှင့်ဆက်စပ်သော commit အဟောင်းကို ပြန်လည်တည်ဆောက်မည်ဆိုပါက၊ werf သည် commit အဟောင်းအတွက် အသစ်တည်ဆောက်ထားသော ပုံ၏ဗားရှင်းအသစ်တစ်ခုနှင့် သက်ဆိုင်ရာ Docker tag ကို အသုံးပြု၍ ပုံကို ပြန်လည်ရေးသားမည်ဖြစ်သည်။ ကျွန်ုပ်တို့၏ အပလီကေးရှင်းသည် CI စနစ်နှင့် ချိတ်ဆက်မှု ပြတ်တောက်ပြီး ကွဲထွက်သွားသည့် ရလဒ်အနေဖြင့် pods များကို ပြန်လည်စတင်သောအခါတွင် ဤတက်ဂ်ကို အသုံးပြု၍ ဖြန့်ကျက်မှုများသည် အခြားဗားရှင်းတစ်ခုကို ဆွဲထုတ်နိုင်သည့် အန္တရာယ်ရှိသည်။

ထို့အပြင်၊ ၎င်းတို့ကြားရှိ အချိန်တိုအတွင်း အကိုင်းအခက်တစ်ခုသို့ ဆက်တိုက်တွန်းပို့ခြင်းဖြင့်၊ ကတိကဝတ်ဟောင်းသည် အသစ်ထက်နောက်ကျ၍ စုစည်းနိုင်သည်- ပုံ၏ဗားရှင်းဟောင်းသည် Git အကိုင်းအခက်တက်ဂ်ကို အသုံးပြု၍ အသစ်ကို ထပ်ရေးပါမည်။ ထိုသို့သောပြဿနာများကို CI/CD စနစ်ဖြင့် ဖြေရှင်းနိုင်သည် (ဥပမာ၊ GitLab CI တွင် နောက်ပိုင်းတွင် ပိုက်လိုင်းသည် commits အများအပြားအတွက် စတင်သည်)။ သို့သော်၊ စနစ်အားလုံးက ၎င်းကို ပံ့ပိုးပေးသည်မဟုတ်ပေ၊ ထိုကဲ့သို့သော အခြေခံပြဿနာကို ကာကွယ်ရန် ပိုမိုယုံကြည်စိတ်ချရသော နည်းလမ်းတစ်ခု ရှိရပါမည်။

အကြောင်းအရာအခြေခံ တဂ်ဂ်ဆိုတာ ဘာလဲ။

ဒီတော့ content-based tagging ဆိုတာ ဘာလဲ - အကြောင်းအရာအလိုက် ပုံများကို တဂ်ခြင်း။

Docker တဂ်များဖန်တီးရန်၊ ၎င်းသည် အသုံးပြုသည့် Git primitives (Git ဌာနခွဲ၊ Git tag...) မဟုတ်ဘဲ၊ နှင့်ဆက်စပ်သော checksum တစ်ခုဖြစ်သည်။

ပုံ၏အကြောင်းအရာများ. ပုံ ID တဂ်သည် ၎င်း၏ အကြောင်းအရာကို ရောင်ပြန်ဟပ်သည်။ ဗားရှင်းအသစ်ကို တည်ဆောက်သည့်အခါ၊ ပုံရှိဖိုင်များ မပြောင်းလဲပါက ဤသတ်မှတ်စနစ်သည် ပြောင်းလဲမည်မဟုတ်ပါ။
ဤပုံကို Git တွင်ဖန်တီးခြင်း၏သမိုင်း. မတူညီသော Git အကိုင်းအခက်များနှင့် ဆက်စပ်နေသည့် ပုံများနှင့် werf မှတစ်ဆင့် မတူညီသော တည်ဆောက်မှုမှတ်တမ်းများတွင် မတူညီသော ID တဂ်များ ရှိပါမည်။

ထိုသို့သော အမှတ်အသားကို အမှတ်အသားဟု ခေါ်သည်။ ရုပ်ပုံစင်မြင့်လက်မှတ်.

ပုံတစ်ပုံချင်းစီတွင် အဆင့်များပါဝင်သည်- from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch စသည်တို့ အဆင့်တစ်ခုစီတွင် ၎င်း၏အကြောင်းအရာများကို ထင်ဟပ်စေသည့် identifier တစ်ခုရှိသည်။ စင်မြင့်လက်မှတ် (စင်မြင့်လက်မှတ်).

ဤအဆင့်များပါ ၀ င်သောနောက်ဆုံးပုံသည်ဤအဆင့်များ၏အစု၏လက်မှတ်ဟုခေါ်သည် - အဆင့်လက်မှတ်, - ပုံ၏ အဆင့်အားလုံးအတွက် ယေဘူယျ ဖြစ်သည့်။

ပုံတစ်ပုံချင်းစီအတွက် configuration မှ werf.yaml ယေဘူယျအားဖြင့်၊ ၎င်း၏ကိုယ်ပိုင်လက်မှတ်ရှိမည်ဖြစ်ပြီး၊ ထို့ကြောင့် Docker တဂ်တစ်ခုရှိလိမ့်မည်။

အဆင့်လက်မှတ်သည် ဤပြဿနာအားလုံးကို ဖြေရှင်းပေးသည်-

Git သည် အချည်းနှီးဖြစ်ခြင်းကို ခံနိုင်ရည်ရှိသည်။
Git ကို ခံနိုင်ရည်ရှိခြင်းသည် ပုံနှင့် မသက်ဆိုင်သော ဖိုင်များကို ပြောင်းလဲပေးပါသည်။
ဌာနခွဲတစ်ခု၏ Git အဟောင်းအတွက် တည်ဆောက်မှုများကို ပြန်လည်စတင်သောအခါတွင် ပုံ၏လက်ရှိဗားရှင်းကို ပြုပြင်မွမ်းမံခြင်းပြဿနာကို မဖြစ်ပေါ်စေပါ။

၎င်းသည် ယခုအခါ အကြံပြုထားသော တဂ်လုပ်နည်းဗျူဟာဖြစ်ပြီး CI စနစ်အားလုံးအတွက် werf တွင် မူရင်းဖြစ်သည်။

werf တွင်မည်သို့ဖွင့်ပြီးအသုံးပြုရမည်နည်း။

ယခု command တွင် သက်ဆိုင်ရာ ရွေးချယ်ခွင့်တစ်ခု ရှိသည်။ werf publish: --tag-by-stages-signature=true|false

CI စနစ်တွင် tagging နည်းဗျူဟာကို command ဖြင့်သတ်မှတ်သည်။ werf ci-env. ယခင်က ၎င်းအတွက် ကန့်သတ်ချက်များ သတ်မှတ်ခဲ့သည်။ werf ci-env --tagging-strategy=tag-or-branch. အခု သတ်မှတ်ပေးရင်တော့ werf ci-env --tagging-strategy=stages-signature သို့မဟုတ် ဤရွေးချယ်မှုကို မသတ်မှတ်ပါနှင့်၊ werf သည် မူရင်းအတိုင်း တဂ်ခြင်းဗျူဟာကို အသုံးပြုပါမည်။ stages-signature. အသင်းအဖွဲ့ werf ci-env command အတွက် လိုအပ်သော အလံများကို အလိုအလျောက် သတ်မှတ်ပေးပါမည်။ werf build-and-publish (သို့မဟုတ် werf publish) ထို့ကြောင့် ဤအမိန့်စာများအတွက် နောက်ထပ်ရွေးချယ်စရာများကို သတ်မှတ်ရန်မလိုအပ်ပါ။

ဥပမာအားဖြင့်၊ command

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 အတွက် tagging ရွေးစရာများကို အသုံးပြုခဲ့လျှင် (WERF_TAG_GIT_COMMIT သို့မဟုတ် ရွေးချယ်မှု werf publish --tag-git-commit COMMIT) ထို့နောက် tagging နည်းဗျူဟာသို့ ပြောင်းရန် သေချာပါစေ။ အဆင့်များ-လက်မှတ်.
ပရောဂျက်အသစ်များကို တဂ်ခြင်းအစီအစဉ်အသစ်သို့ ချက်ချင်းပြောင်းခြင်းသည် ပိုကောင်းသည်။
werf 1.1 သို့လွှဲပြောင်းသည့်အခါ၊ ပရောဂျက်ဟောင်းများကို tagging အစီအစဉ်အသစ်သို့ ပြောင်းရန် အကြံပြုလိုသော်လည်း အဟောင်း၊ tag-or-ကိုင်း ထောက်ခံနေဆဲဖြစ်သည်။

အကြောင်းအရာအခြေခံတဂ်လုပ်ခြင်းသည် ဆောင်းပါးတွင်ပါရှိသော ပြဿနာအားလုံးကို ဖြေရှင်းပေးသည်-

Git အချည်းနှီးဖြစ်စေရန်အတွက် Docker တဂ်အမည်ကို ခံနိုင်ရည်ရှိသည်။
Git သို့ Docker တဂ်အမည်၏ ခံနိုင်ရည်ရှိမှုသည် ပုံနှင့်မသက်ဆိုင်သော ဖိုင်များကို ပြောင်းလဲပေးသည်။
Git အကိုင်းအခက်များအတွက် Git commits အဟောင်းများအတွက် တည်ဆောက်မှုများကို ပြန်လည်စတင်သောအခါတွင် ပုံ၏ လက်ရှိဗားရှင်းကို ပြုပြင်မွမ်းမံခြင်းပြဿနာကို မဖြစ်ပေါ်စေပါ။

သုံးပါ။ ပြီးတော့ ကျွန်တော်တို့ကို လာလည်ဖို့ မမေ့ပါနဲ့။ GitHubပြဿနာတစ်ခုဖန်တီးရန် သို့မဟုတ် ရှိပြီးသားတစ်ခုကိုရှာရန်၊ အပေါင်းတစ်ခုထည့်ပါ၊ PR တစ်ခုဖန်တီးပါ သို့မဟုတ် ပရောဂျက်၏ဖွံ့ဖြိုးတိုးတက်မှုကို ရိုးရိုးရှင်းရှင်းကြည့်ရှုပါ။

PS

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

source: www.habr.com