werf - Kubernetes ရှိ CI/CD အတွက် ကျွန်ုပ်တို့၏ကိရိယာ (ခြုံငုံသုံးသပ်ချက်နှင့် ဗီဒီယိုအစီရင်ခံစာ)

မေလ 27 ရက်နေ့တွင် ပွဲတော်၏တစ်စိတ်တစ်ပိုင်းအဖြစ် ကျင်းပသည့် DevOpsConf 2019 ညီလာခံ၊ RIT++ 2019"စဉ်ဆက်မပြတ် ပေးပို့ခြင်း" ကဏ္ဍ၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့်၊ Kubernetes ရှိ "werf - ကျွန်ုပ်တို့၏ CI/CD အတွက် ကျွန်ုပ်တို့၏ကိရိယာ" အစီရင်ခံစာကို ပေးအပ်ခဲ့ပါသည်။ အဲဒါတွေအကြောင်းပြောနေတာ Kubernetes ကို အသုံးပြုရာတွင် လူတိုင်းကြုံတွေ့ရသော ပြဿနာများနှင့် စိန်ခေါ်မှုများချက်ခြင်းသိသာထင်ရှားနိုင်မည်မဟုတ်သော ကွဲပြားမှုများအပြင်၊ ဖြစ်နိုင်ချေရှိသော ဖြေရှင်းချက်များကို ခွဲခြမ်းစိတ်ဖြာခြင်းဖြင့် ၎င်းကို Open Source တူးလ်တစ်ခုတွင် မည်သို့လုပ်ဆောင်ကြောင်း ပြသပါသည်။ werf.

တင်ပြချိန်မှစ၍၊ ကျွန်ုပ်တို့၏ အသုံးဝင်မှု (ယခင် dapp ဟုခေါ်သည်) သည် သမိုင်းဝင်မှတ်တိုင်တစ်ခုသို့ ရောက်ရှိသွားပြီဖြစ်သည်။ GitHub တွင် ကြယ် ၁၀၀၀ — DevOps အင်ဂျင်နီယာများစွာအတွက် ၎င်း၏ ကြီးထွားလာနေသော သုံးစွဲသူအသိုင်းအဝိုင်းသည် ဘဝကို ပိုမိုလွယ်ကူလာစေရန် ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။

ဒီတော့ မိတ်ဆက်ပေးပါရစေ အစီရင်ခံစာဗီဒီယို (~47 မိနစ်၊ ဆောင်းပါးထက် များစွာပို၍ အချက်အလက်များ) နှင့် ၎င်းမှ အဓိက ထုတ်နုတ်ချက်ကို စာသားပုံစံဖြင့် ထုတ်ယူပါ။ သွား!

ကုဒ်ကို Kubernetes သို့ ပေးပို့ခြင်း။

ဟောပြောချက်သည် werf အကြောင်းမဟုတ်တော့ဘဲ Kubernetes ရှိ CI/CD အကြောင်း၊ ကျွန်ုပ်တို့၏ဆော့ဖ်ဝဲလ်ကို Docker ကွန်တိန်နာများတွင် ထုပ်ပိုးထားကြောင်း ဆိုလိုသည် (ဒီအကြောင်းကို ကျွန်တော်ပြောခဲ့တယ်။ 2016 အစီရင်ခံစာ)နှင့် K8s တို့ကို ထုတ်လုပ်မှုတွင် အသုံးပြုမည်ဖြစ်သည်။ (ဒီအကြောင်း နောက်ထပ် 2017 တစ်နှစ်).

Kubernetes တွင် ပေးပို့မှုပုံစံက မည်သို့ရှိသနည်း။

• ၎င်းကိုတည်ဆောက်ရန်အတွက်ကုဒ်နှင့်လမ်းညွှန်ချက်များပါရှိသော Git repository တစ်ခုရှိသည်။ အပလီကေးရှင်းကို Docker ပုံတွင်တည်ဆောက်ထားပြီး Docker Registry တွင်ထုတ်ဝေထားသည်။
• အလားတူ သိုလှောင်ရုံတွင် အပလီကေးရှင်းကို အသုံးချပုံနှင့် လည်ပတ်ပုံဆိုင်ရာ ညွှန်ကြားချက်များလည်း ပါရှိသည်။ အသုံးချမှုအဆင့်တွင်၊ ဤညွှန်ကြားချက်များကို မှတ်ပုံတင်ခြင်းမှ အလိုရှိသောပုံကို လက်ခံရရှိပြီး ၎င်းကို စတင်သည့် Kubernetes သို့ ပေးပို့ပါသည်။
• ထို့အပြင်၊ များသောအားဖြင့်စမ်းသပ်မှုများရှိသည်။ ပုံတစ်ပုံကို လွှင့်တင်သည့်အခါ အချို့က လုပ်ဆောင်နိုင်သည်။ သင်သည် (တူညီသောညွှန်ကြားချက်များအတိုင်း) အပလီကေးရှင်း၏မိတ္တူကို (သီးခြား K8s namespace သို့မဟုတ် သီးခြားအစုအဝေးတစ်ခုတွင်) အသုံးချပြီး ထိုနေရာတွင် စမ်းသပ်မှုများကို လုပ်ဆောင်နိုင်သည်။
• နောက်ဆုံးတွင်၊ သင်သည် Git (သို့မဟုတ် ခလုတ်နှိပ်ခြင်း) မှ အဖြစ်အပျက်များကို လက်ခံရရှိပြီး သတ်မှတ်ထားသော အဆင့်အားလုံးကို ခေါ်သည်- တည်ဆောက်ခြင်း၊ ထုတ်ဝေခြင်း၊ ဖြန့်ကျက်ခြင်း၊ စမ်းသပ်ခြင်းတို့ကို ခေါ်ဆိုသော CI စနစ်တစ်ခု လိုအပ်ပါသည်။

ဤနေရာတွင် အရေးကြီးသော မှတ်ချက်အချို့ရှိပါသည်။

1. ဘာကြောင့်လဲဆိုတော့ ကျွန်တော်တို့မှာ မပြောင်းလဲနိုင်တဲ့ အခြေခံအဆောက်အအုံတွေ ရှိတယ်။ (မပြောင်းလဲနိုင်သော အခြေခံအဆောက်အဦ)အဆင့်အားလုံးတွင် အသုံးပြုသည့် အပလီကေးရှင်းပုံ (ဇာတ်ညွှန်း၊ ထုတ်လုပ်ရေး စသည်)၊ တစ်ခုရှိရမည်။. ဒီအကြောင်းတွေကို အသေးစိတ်နဲ့ ဥပမာတွေနဲ့ ပြောပြခဲ့တယ်။ ဒီမှာ.
2. ဘာကြောင့်လဲဆိုတော့ ကျွန်တော်တို့က အခြေခံအဆောက်အအုံကို ကုဒ်ချဉ်းကပ်မှုအတိုင်း လိုက်နာတယ်။ (IaC)အပလီကေးရှင်းကုဒ်၊ တပ်ဆင်ခြင်းနှင့် စတင်ခြင်းအတွက် ညွှန်ကြားချက်များ ဖြစ်သင့်သည်။ repository တစ်ခုထဲမှာ အတိအကျ. ဤအကြောင်းပိုမိုသိရှိလိုပါက ကြည့်ပါ။ တူညီသောအစီရင်ခံစာ.
3. Delivery chain (ပို့ဆောင်မှု) ကျွန်ုပ်တို့ ဤကဲ့သို့ မြင်လေ့ရှိသည်- လျှောက်လွှာကို စုစည်းပြီး စမ်းသပ်၊ ထုတ်ဝေခဲ့သည်။ (လွှတ်​​တော်​အဆင့်​) ဒါပါပဲ - ပေးပို့မှု ဖြစ်ပေါ်လာပါပြီ။ ဒါပေမယ့် လက်တွေ့မှာတော့ သုံးစွဲသူက သင်ထုတ်လိုက်တဲ့အရာကို ရရှိပြီး၊ မဟုတ် အဲဒါကို ထုတ်လုပ်ရေးဆီ အပ်လိုက်တဲ့အခါ၊ သူက အဲဒီကို သွားပြီးတော့ ဒီထုတ်လုပ်မှုက အလုပ်ဖြစ်သွားတယ်။ ဒါကြောင့် ပို့ဆောင်ရေးကွင်းဆက် ပြီးဆုံးမယ်လို့ ယုံကြည်ပါတယ်။ လည်ပတ်မှုအဆင့်တွင်သာ (ပြေး)ကုဒ်ကို ထုတ်လုပ်ခြင်းမှ ဖယ်ရှားလိုက်သည့်အချိန်တွင်ပင် (၎င်းကို အသစ်တစ်ခုဖြင့် အစားထိုးခြင်း) သို့မဟုတ် ထို့ထက်ပို၍ အတိအကျပင်။

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

စင်မြင့်တည်ဆောက်ပါ။

Dockerfiles ကိုမည်ကဲ့သို့ရေးပြီး run ရမည်ကိုလူတိုင်းသိသောအခါ 2019 ခုနှစ်တွင် Docker ပုံများတည်ဆောက်ခြင်းအကြောင်းပြောနိုင်ပုံရသည်။ docker build?.. ဤတွင် ကျွန်ုပ်အာရုံစိုက်လိုသော ကွဲပြားချက်များမှာ-

1. ပုံအလေးချိန် အရေးကြီးတာမို့ သုံးပါ။ multi-stageလုပ်ဆောင်ချက်အတွက် အမှန်တကယ်လိုအပ်သော အက်ပလီကေးရှင်းကိုသာ ပုံတွင်ထားခဲ့ပါ။
2. အလွှာအရေအတွက် ကွင်းဆက်များ၏ပေါင်းစပ်ခြင်းဖြင့် minimize လုပ်ရပါမည်။ RUN- အဓိပ္ပါယ်အရ အမိန့်ပေးသည်။
3. သို့သော်၊ ဤအရာသည်ပြဿနာများကိုထပ်လောင်းသည်။ အမှားရှာခြင်း။အဘယ်ကြောင့်ဆိုသော် စည်းဝေးပွဲပျက်သွားသောအခါ ပြဿနာဖြစ်စေသော ကွင်းဆက်မှ မှန်ကန်သောအမိန့်ကို သင်ရှာဖွေရမည်ဖြစ်သည်။
4. စုဝေးမှုအရှိန် အပြောင်းအလဲများကို အမြန်ထုတ်ပြီး ရလဒ်များကို မြင်လိုသောကြောင့် အရေးကြီးပါသည်။ ဥပမာအားဖြင့်၊ သင်သည် အပလီကေးရှင်းတစ်ခုတည်ဆောက်သည့်အခါတိုင်း ဘာသာစကားစာကြည့်တိုက်များတွင် မှီခိုမှုကို ပြန်လည်တည်ဆောက်လိုခြင်းမရှိပါ။
5. သင်လိုအပ်သော Git repository တစ်ခုမှမကြာခဏ ပုံများစွာDockerfiles အစုအဝေး (သို့မဟုတ် ဖိုင်တစ်ခုတွင် အဆင့်များဟု အမည်ပေးထားသည့်) နှင့် ၎င်းတို့၏ ဆင့်ကဲ စုဝေးမှုနှင့်အတူ Bash script ဖြင့် ဖြေရှင်းနိုင်သည်။

ဤသည်မှာ လူတိုင်းရင်ဆိုင်ရမည့် ရေခဲတောင်၏အစွန်အဖျားဖြစ်သည်။ ဒါပေမယ့် အထူးသဖြင့် တခြားပြဿနာတွေ ရှိပါသေးတယ်။

1. ပရိသတ်စင်မြင့်မှာ တစ်ခုခုလိုအပ်နေတတ်တယ်။ တောင်ပေါ် (ဥပမာ၊ apt ကဲ့သို့ command ၏ရလဒ်ကို third-party directory တွင် cache)။
2. လိုချင်တယ်။ မြင်မရဘူး shell မှာရေးမယ့်အစား
3. လိုချင်တယ်။ Docker မပါဘဲတည်ဆောက်ပါ။ (ကျွန်ုပ်တို့သည် ကွန်တိန်နာများကို အသုံးပြုနိုင်သည့် Kubernetes အစုအဝေးတစ်ခု ရှိနှင့်ပြီးသောအခါ၊ ၎င်းအတွက် အရာအားလုံးကို စီစဉ်သတ်မှတ်ရန် လိုအပ်သည့် နောက်ထပ် virtual machine တစ်ခု လိုအပ်သနည်း။)
4. ပြိုင်တူ စုဝေးမတူညီသောနည်းလမ်းများဖြင့် နားလည်နိုင်သည်- Dockerfile မှ မတူညီသော command များ (အဆင့်များစွာကိုအသုံးပြုပါက)၊ တူညီသော repository ၏ commits များစွာ၊ Dockerfiles များစွာ။
5. ဖြန့်ချီရေး: "တဒင်္ဂ" ဖြစ်သောကြောင့် ကျွန်ုပ်တို့သည် အရာဝတ္ထုများကို စုဆောင်းလိုပါသည်။ ၎င်းတို့၏ cache ပျောက်သွားသည်၊ ဆိုလိုသည်မှာ ၎င်းကို သီးခြားတစ်နေရာတွင် သိမ်းဆည်းထားရန် လိုအပ်သည်။
6. နောက်ဆုံးတော့ လိုအင်ဆန္ဒရဲ့ အထွတ်အထိပ်လို့ ခေါ်တယ်။ အော်တိုမက်တစ်: repository ကိုသွားပြီး၊ command တစ်ချို့ကိုရိုက်ပြီး အဆင်သင့်လုပ်ထားတဲ့ပုံကိုရယူပါ၊ ဘယ်လိုလုပ်ရမယ်ဆိုတာကို မှန်ကန်စွာနားလည်သဘောပေါက်အောင် စုစည်းထားတာ အကောင်းဆုံးပါပဲ။ သို့သော်၊ ကွဲပြားချက်များအားလုံးကို ဤနည်းဖြင့် ကြိုမြင်နိုင်သည်ဟု ကျွန်ုပ်ကိုယ်တိုင်ပင် မသေချာပါ။

ဤသည်မှာ ပရောဂျက်များဖြစ်သည်-

• moby/buildkit — Docker Inc မှ တည်ဆောက်သူ (Docker ၏ လက်ရှိဗားရှင်းများသို့ ပေါင်းစပ်ထားပြီး) မှ ဤပြဿနာအားလုံးကို ဖြေရှင်းရန် ကြိုးစားနေပါသည်။
• ကာနီကို — Docker မပါဘဲ တည်ဆောက်ခွင့်ပြုသော Google မှ တည်ဆောက်သူ။
• Buildpacks.io — CNCF ၏ အလိုအလျောက် မှော်ပညာကို ဖန်တီးရန် ကြိုးပမ်းမှု နှင့် အထူးသဖြင့် အလွှာများအတွက် ပြန်လည် အခြေစိုက်ခြင်း ပါ၀င်သော စိတ်ဝင်စားဖွယ် ဖြေရှင်းချက် ၊
• နှင့် အခြားသော အသုံးအဆောင်များဖြစ်သော၊ ။, စစ်မှန်သောတူးလ်များ/img...

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

werf တွင်စည်းဝေးပွဲ

ဒီတော့ ကျွန်တော်တို့ ရခဲ့ပါတယ်။ werf (ယခင် နာမည်ကြီး dapp ကဲ့သို့) - ကျွန်ုပ်တို့နှစ်ပေါင်းများစွာပြုလုပ်ခဲ့သည့် Flant ကုမ္ပဏီမှ open source utility တစ်ခု။ ၎င်းသည် Dockerfiles စည်းဝေးပွဲကို အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်သော Bash scripts များဖြင့် လွန်ခဲ့သော 5 နှစ်က စတင်ခဲ့ပြီး ပြီးခဲ့သော 3 နှစ်တွင် ၎င်း၏ကိုယ်ပိုင် Git repository ဖြင့် ပရောဂျက်တစ်ခု၏ ဘောင်အတွင်း၌ ပြည့်စုံသောဖွံ့ဖြိုးတိုးတက်မှုကို လုပ်ဆောင်ခဲ့သည်။ (ပထမဆုံး Ruby ၊ ပြီးတော့ ပြန်ရေးသည်။ သွားရန်၊ တစ်ချိန်တည်းတွင် အမည်ပြောင်း). werf တွင် မည်သည့်စုဝေးမှုပြဿနာများကို ဖြေရှင်းနိုင်သနည်း။

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

မှတ်ပုံတင်ခြင်းတွင် ထုတ်ဝေခြင်းအဆင့် (ထုတ်ဝေခြင်း)

ငါတို့ဖုန်းခေါ်တယ်။ docker push... - Registry တွင် ပုံတစ်ပုံကို အပ်လုဒ်တင်ခြင်းအတွက် ဘာအခက်အခဲရှိနိုင်မလဲ။ ထို့နောက် မေးခွန်းပေါ်လာသည်– “ပုံပေါ်တွင် ဘာ tag ထားရမည်နည်း။ အဲဒါက ငါတို့မှာ ရှိလို့ ဖြစ်ပေါ်လာတာ။ Gitflow (သို့မဟုတ် အခြား Git နည်းဗျူဟာ) နှင့် Kubernetes နှင့် Kubernetes တွင် ဖြစ်ပျက်နေသည့်အရာများသည် Git တွင်ဖြစ်ပျက်နေသည့်အရာများကို လိုက်နာကြောင်း သေချာစေရန် စက်မှုလုပ်ငန်းက ကြိုးစားနေပါသည်။ နောက်ဆုံးတွင်၊ Git သည် ကျွန်ုပ်တို့၏တစ်ခုတည်းသောအမှန်တရားအရင်းအမြစ်ဖြစ်သည်။

ဒီအတွက် ဘာအခက်အခဲရှိလို့လဲ။ မျိုးပွားနိုင်စွမ်းသေချာပါစေ။: သဘာဝတွင် မပြောင်းလဲနိုင်သော Git ရှိ ကတိတစ်ခုမှ (မပြောင်းလဲနိုင်သော)အတူတူထားသင့်သည့် Docker ပုံတစ်ခုသို့။

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

Tagging Strategies

ပထမတစ်ခုက ရိုးရှင်းပါတယ်။ git tag. ကျွန်ုပ်တို့တွင် အမှတ်အသားပြုထားသည့် ပုံတစ်ခုပါသည့် မှတ်ပုံတင်တစ်ခုရှိသည်။ 1.0. Kubernetes တွင် ဤပုံကို အပ်လုဒ်လုပ်ထားသည့် အဆင့်နှင့် ထုတ်လုပ်ရေး ရှိသည်။ Git တွင် ကျွန်ုပ်တို့သည် ကတိကဝတ်များ ပြုလုပ်ကြပြီး တစ်ချိန်ချိန်တွင် ကျွန်ုပ်တို့သည် tag လုပ်ကြသည်။ 2.0. repository မှ ညွှန်ကြားချက်များအတိုင်း ၎င်းကို စုဆောင်းပြီး tag ဖြင့် registry တွင် ထားရှိပါ။ 2.0. အဲဒါကို စင်ပေါ်တင်ပြီး အားလုံးအဆင်ပြေရင် ထုတ်လုပ်ရေးအထိပေါ့။

ဤချဉ်းကပ်မှု၏ပြဿနာမှာ ကျွန်ုပ်တို့သည် tag ကိုပထမဆုံးတင်ကာ စမ်းသပ်ပြီးမှသာ ထုတ်ယူနိုင်ခြင်းဖြစ်သည်။ အဘယ်ကြောင့်? ပထမဦးစွာ၊ ၎င်းသည် ရိုးရိုးရှင်းရှင်း ယုတ္တိမတန်ပါ- ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့ မစမ်းသပ်ရသေးသော ဆော့ဖ်ဝဲဗားရှင်းကို ထုတ်ပေးနေသည် (စစ်ဆေးရန်အတွက်၊ ကျွန်ုပ်တို့သည် tag တစ်ခုထည့်ထားရန် လိုအပ်သောကြောင့် အခြားနည်းဖြင့် မလုပ်နိုင်ပါ)။ ဒုတိယအချက်မှာ၊ ဤလမ်းကြောင်းသည် Gitflow နှင့်သဟဇာတမဖြစ်ပါ။

ဒုတိယ option ကို - git commit + tag. မာစတာအကိုင်းအခက်တွင် tag တစ်ခုရှိသည်။ 1.0; ၎င်းအတွက် registry တွင် - ထုတ်လုပ်မှုတွင် ဖြန့်ကျက်ထားသော ပုံတစ်ခု။ ထို့အပြင်၊ Kubernetes အစုအဝေးတွင် အကြိုကြည့်ရှုခြင်းနှင့် အဆင့်သတ်မှတ်ခြင်းပုံစံများ ပါရှိသည်။ ဆက်လက်၍ ကျွန်ုပ်တို့သည် Gitflow ကို လိုက်နာသည်- ဖွံ့ဖြိုးတိုးတက်မှုအတွက် အဓိကဌာနခွဲ (develop) ကျွန်ုပ်တို့သည် အင်္ဂါရပ်အသစ်များကို ပြုလုပ်ပြီး identifier နှင့် ကတိကဝတ်ပြုပါသည်။ #c1. ကျွန်ုပ်တို့ ၎င်းကို စုဆောင်းပြီး ဤသတ်မှတ်စနစ်ကို အသုံးပြု၍ မှတ်ပုံတင်ခြင်းတွင် ထုတ်ဝေခြင်း (#c1) တူညီသော identifier ဖြင့် အစမ်းကြည့်ရှုရန် ထုတ်ပေးပါသည်။ ကျွန်ုပ်တို့သည် ကတိကဝတ်များနှင့် အတူတူပင်ဖြစ်သည်။ #c2 и #c3.

လုံလောက်သောအင်္ဂါရပ်များရှိကြောင်း ကျွန်ုပ်တို့သိရှိလာသောအခါ၊ ကျွန်ုပ်တို့သည် အရာအားလုံးကို တည်ငြိမ်စပြုလာသည်။ Git တွင် ဌာနခွဲတစ်ခုဖန်တီးပါ။ release_1.1 (အခြေခံပေါ်မှာ #c3 မှ develop) ဒီထုတ်လွှတ်မှုကို စုဆောင်းဖို့ မလိုအပ်ဘူးဆိုတော့... ၎င်းကို ယခင်အဆင့်တွင် ပြုလုပ်ခဲ့သည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ၎င်းကို ဇာတ်ကြောင်းသို့ ရိုးရှင်းစွာ ဖြန့်ချနိုင်သည်။ ကျွန်ုပ်တို့သည် bug များကိုပြင်သည်။ #c4 အလားတူ ဇာတ်ခုံသို့ လွှင့်တင်ပါ။ တစ်ချိန်တည်းမှာပင် ဖွံ့ဖြိုးတိုးတက်ရေးကို ဆောင်ရွက်လျက်ရှိပါသည်။ developအပြောင်းအလဲများကို အခါအားလျော်စွာ ယူဆောင်လာပါသည်။ release_1.1. တစ်ချိန်ချိန်တွင်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့ ကျေနပ်နှစ်သက်သော ကတိပြုချက်ကို စုစည်းပြီး ဇာတ်ခုံသို့ အပ်လုဒ်လုပ်ရမည်၊#c25).

ထို့နောက် ကျွန်ုပ်တို့သည် လွတ်မြောက်ရေးဌာနခွဲ (ရှေ့သို့ အမြန်) နှင့် ပေါင်းစည်းလိုက်ပါသည်။release_1.1) ဆရာကြီး။ ကျွန်ုပ်တို့သည် ဤ commit တွင် ဗားရှင်းအသစ်ဖြင့် tag တစ်ခုတင်ထားသည် (1.1) ဒါပေမယ့် ဒီပုံကို registry မှာ စုဆောင်းထားပြီးဖြစ်လို့ အဲဒါကို ထပ်မစုဆောင်းဖို့အတွက်၊ ရှိပြီးသားပုံထဲကို ဒုတိယတဂ်တစ်ခု ထပ်ထည့်လိုက်ရုံပါပဲ (အခုတော့ registry ထဲမှာ tags တွေရှိနေပါပြီ။ #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။

... ပြီးလျှင်ထိုကဲ့သို့သောဖိုင်မှ checksum (SHA256 တစ်ဖန်) ကိုယူပါ။ ဒီ လက်မှတ် Docker ပုံ၏ အကြောင်းအရာများကို သတ်မှတ်ပေးသည့် အရာအားလုံး။

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

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

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

werf တွင် တဂ်လုပ်ခြင်း။

werf တွင်ကျွန်ုပ်တို့ပို၍သွားခဲ့ပြီးစက်တစ်ခုတည်းတွင်သိမ်းဆည်းခြင်းမရှိသော cache ဖြင့်ဖြန့်ဝေတည်ဆောက်ရန်ပြင်ဆင်နေသည်... ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် Docker ပုံများကို အမျိုးအစားနှစ်မျိုးဖြင့်တည်ဆောက်နေသည်၊ စင် и ပုံရိပ်.

werf Git repository သည် build ၏ မတူညီသော အဆင့်များကို ဖော်ပြသော build-specific ညွှန်ကြားချက်များကို သိမ်းဆည်းသည် (မတပ်ဆင်မီ, install, မတပ်ဆင်မီ, တည်ဆောက်သည်) ပထမအဆင့်၏ checksum အဖြစ် သတ်မှတ်ထားသော လက်မှတ်ဖြင့် ပထမအဆင့် ရုပ်ပုံကို စုဆောင်းပါသည်။ ထို့နောက် စင်မြင့်ပုံအသစ်အတွက် ၎င်း၏ checksum ကို ကျွန်ုပ်တို့ တွက်ချက်သည်... ဤလုပ်ဆောင်ချက်များကို အဆင့်အားလုံးအတွက် ထပ်ခါတလဲလဲ လုပ်ဆောင်သည်၊ ရလဒ်အနေဖြင့် စတိတ်ပုံများ အစုအဝေးကို ရရှိပါသည်။ ထို့နောက် ၎င်း၏မူလအစနှင့်ပတ်သက်သည့် မက်တာဒေတာပါ၀င်သည့် နောက်ဆုံးပုံကို ပြုလုပ်သည်။ ကျွန်ုပ်တို့သည် ဤပုံကို မတူညီသောနည်းလမ်းများဖြင့် tag (နောက်မှအသေးစိတ်ဖော်ပြသည်)။

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

ထို့ကြောင့်၊ စင်မြင့်ပုံများသည် ဖြန့်ဝေသိမ်းဆည်းနိုင်သည့် ကက်ရှ်တစ်ခုဖြစ်ပြီး ၎င်းမှဖန်တီးပြီးသားပုံများကို Docker Registry သို့ အပ်လုဒ်လုပ်ထားသည်။

မှတ်ပုံတင်ကို သန့်ရှင်းရေးလုပ်ပါ။

ဖျက်လိုက်သည့် tags များနောက်တွင် တွဲနေသော အလွှာများကို ဖျက်ခြင်းအကြောင်း ကျွန်ုပ်တို့ပြောနေခြင်းမဟုတ်ပါ - ၎င်းသည် Docker Registry ကိုယ်တိုင်၏ စံသတ်မှတ်ချက်တစ်ခုဖြစ်သည်။ Docker tag အများအပြားစုပုံနေချိန်တွင် ကျွန်ုပ်တို့သည် ၎င်းတို့အချို့ကို မလိုအပ်တော့ကြောင်း ကျွန်ုပ်တို့နားလည်သော်လည်း ၎င်းတို့သည် နေရာယူသည် (နှင့်/သို့မဟုတ် ကျွန်ုပ်တို့ ပေးဆောင်သည်)။

သန့်ရှင်းရေးဗျူဟာတွေက ဘာတွေလဲ။

1. မင်း ဘာမှလုပ်လို့မရဘူး မသန့်ရှင်းပါနှင့်. တခါတရံတွင် ကြီးမားသော အရှုပ်အထွေးများကို ရှင်းထုတ်ရန်ထက် အပိုနေရာအတွက် အနည်းငယ် ပေးချေခြင်းသည် အမှန်တကယ်ပင် လွယ်ကူပါသည်။ ဒါပေမယ့် ဒါက အတိုင်းအတာတစ်ခုအထိသာ အလုပ်လုပ်ပါတယ်။
2. အပြည့်အဝ ပြန်လည်သတ်မှတ်ပါ။. ပုံများအားလုံးကို ဖျက်ပြီး CI စနစ်ရှိ လက်ရှိပုံများကိုသာ ပြန်လည်တည်ဆောက်ပါက ပြဿနာတစ်ခု ဖြစ်လာနိုင်သည်။ ကွန်တိန်နာကို ထုတ်လုပ်မှုတွင် ပြန်လည်စတင်ပါက၊ မည်သူ့ကိုမျှ မစမ်းသပ်ရသေးသော ပုံအသစ်တစ်ခုကို တင်ပါမည်။ ယင်းသည် မပြောင်းလဲနိုင်သော အခြေခံအဆောက်အအုံ အယူအဆကို သတ်ပစ်သည်။
3. စိမ်းပြာ. မှတ်ပုံတင်တစ်ခုသည် ပြည့်လျှံလာသည် - ကျွန်ုပ်တို့သည် ပုံများကို အခြားသို့ အပ်လုဒ်လုပ်ပါသည်။ ယခင်နည်းလမ်းတွင်ကဲ့သို့ တူညီသောပြဿနာ- ပြည့်လျှံနေသည့် registry ကို မည်သည့်အချက်တွင် သင်ရှင်းလင်းနိုင်မည်နည်း။
4. အချိန်အားဖြင့်. 1 လထက်ကြီးသော ပုံအားလုံးကို ဖျက်မလား။ ဒါပေမယ့် တစ်လလောက် မွမ်းမံမွမ်းမံထားတဲ့ ဝန်ဆောင်မှုတစ်ခုတော့ ရှိမှာ သေချာပါတယ်...
5. လက်ဖြင့် ဖျက်လို့ရပြီလားဆိုတာကို ဆုံးဖြတ်ပါ။

အမှန်တကယ် အကျုံးဝင်သော ရွေးချယ်စရာ နှစ်ခုရှိသည်- မသန့်ရှင်းပါ သို့မဟုတ် စိမ်းပြာရောင် + လက်ဖြင့် ပေါင်းစပ်ပါ။ နောက်ဆုံးအခြေအနေတွင်၊ ကျွန်ုပ်တို့သည် အောက်ပါအကြောင်းများကို ပြောနေသည်- registry ကို ရှင်းရန် အချိန်တန်ပြီဟု နားလည်သောအခါ၊ သင်သည် အသစ်တစ်ခုဖန်တီးပြီး ဥပမာအားဖြင့် တစ်လတာကာလအတွင်း ၎င်းတွင် ပုံအသစ်များအားလုံးကို ထည့်ပါ။ တစ်လအကြာတွင်၊ Kubernetes ရှိ မည်သည့် pods များသည် မှတ်ပုံတင်ခြင်းအဟောင်းကို ဆက်လက်အသုံးပြုနေသေးသည်ကို ကြည့်ရှုပြီး ၎င်းတို့ကိုလည်း မှတ်ပုံတင်အသစ်သို့ လွှဲပြောင်းပါ။

ငါတို့ဘာတွေရောက်လာတာလဲ။ werf? ကျွန်ုပ်တို့စုဆောင်းသည်-

1. Git head - ပုံများတွင် Git တွင်တဂ်ထားသောအရာအားလုံးကိုလိုအပ်သည်ဟုယူဆပါက tags အားလုံး၊ အကိုင်းအခက်များအားလုံး (ထို့ကြောင့်၎င်းကို Git ကိုယ်တိုင်ဖျက်ရန်လိုအပ်သည်)
2. လက်ရှိ Kubernetes သို့ စုပ်ထုတ်နေသည့် pods အားလုံးကို၊
3. ReplicaSets အဟောင်းများ (မကြာသေးမီက ထွက်ရှိခဲ့သော) နှင့် Helm ထုတ်ဝေမှုများကို စကင်န်ဖတ်ပြီး ထိုနေရာတွင် နောက်ဆုံးပုံများကို ရွေးချယ်ရန်လည်း စီစဉ်ထားပါသည်။

... ပြီးလျှင် ဤအစုမှ အဖြူရောင်စာရင်းတစ်ခု ပြုလုပ်ပါ - ကျွန်ုပ်တို့ ဖျက်မည်မဟုတ်သော ပုံများစာရင်း။ ကျွန်ုပ်တို့သည် အခြားအရာအားလုံးကို ရှင်းထုတ်ပြီးနောက် မိဘမဲ့ဇာတ်ခုံရုပ်ပုံများကို တွေ့ရှိပြီး ၎င်းတို့ကိုလည်း ဖျက်ပစ်ပါသည်။

စင်ပေါ်ချထားပါ။

ယုံကြည်စိတ်ချရသောကြေငြာချက်

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

1. ခွဲခြားသတ်မှတ်မှုများ၊
2. ဝန်ဆောင်မှုသတင်းအချက်အလက်;
3. ပုံသေတန်ဖိုးများစွာ၊
4. လက်ရှိအခြေအနေနှင့်အပိုင်း၊
5. ဝင်ခွင့် webhook ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် ပြောင်းလဲမှုများ၊
6. အမျိုးမျိုးသော controllers (နှင့်အချိန်ဇယားဆွဲ) ၏အလုပ်၏ရလဒ်။

ထို့ကြောင့်၊ အရင်းအမြစ်ဖွဲ့စည်းပုံအသစ်တစ်ခုပေါ်လာသောအခါ (အသစ်) ကျွန်ုပ်တို့သည် ၎င်းနှင့်အတူ လက်ရှိ၊ "တိုက်ရိုက်" ဖွဲ့စည်းမှုပုံစံကို ယူ၍ ရေးချရုံမျှမက (အသက်ရှင်သော) ဒီလိုလုပ်ဖို့ နှိုင်းရပါလိမ့်မယ်။ အသစ် နောက်ဆုံးအသုံးပြုထားသော ဖွဲ့စည်းမှုပုံစံ (နောက်ဆုံးသုံးထားသည်။) အပေါ်ကို လူးပေးပါ။ အသက်ရှင်သော patch ကိုလက်ခံရရှိခဲ့သည်။

ဤချဉ်းကပ်နည်းဟုခေါ်သည်။ 2-လမ်းပေါင်းစည်း. ဥပမာအားဖြင့် Helm တွင်အသုံးပြုသည်။

လည်းရှိတယ်။ 3-လမ်းပေါင်းစည်း၊ ကွဲပြားသောအရာ၊

• နှိုင်းယှဉ် နောက်ဆုံးသုံးထားသည်။ и အသစ်ဖျက်ပစ်ခဲ့တာကို ကြည့်ပါ။
• နှိုင်းယှဉ် အသစ် и အသက်ရှင်သောထပ်ထည့်ထားသည် သို့မဟုတ် ပြောင်းလဲထားသည်ကို ကျွန်ုပ်တို့ကြည့်ရှုပါ။
• summed patch ကို အသုံးပြုသည်။ အသက်ရှင်သော.

Helm ဖြင့် အပလီကေးရှင်းပေါင်း 1000+ ကို အသုံးပြုထားသောကြောင့် ကျွန်ုပ်တို့သည် 2-way ပေါင်းစည်းခြင်းဖြင့် အမှန်တကယ် အသက်ရှင်နေပါသည်။ သို့သော်၊ ၎င်းတွင် Helm ပုံမှန်အလုပ်လုပ်ရန် ကူညီပေးသည့် ကျွန်ုပ်တို့၏ ဖာထေးမှုများဖြင့် ကျွန်ုပ်တို့ဖြေရှင်းခဲ့သည့် ပြဿနာများစွာရှိသည်။

ထုတ်လွှင့်မှုအခြေအနေအမှန်

ကျွန်ုပ်တို့၏ CI စနစ်သည် လာမည့်ဖြစ်ရပ်အပေါ် အခြေခံ၍ Kubernetes အတွက် ဖွဲ့စည်းမှုအသစ်ကို ထုတ်ပေးပြီးနောက်၊ ၎င်းကို အသုံးပြုရန်အတွက် ထုတ်လွှင့်သည် (လျှောက်ထား) to a cluster - Helm ကိုအသုံးပြုခြင်း သို့မဟုတ် kubectl apply. ထို့နောက်တွင် ဖော်ပြထားပြီးဖြစ်သော N-way ပေါင်းစည်းမှုသည် Kubernetes API သည် CI စနစ်နှင့် ၎င်းကို အသုံးပြုသူအား အတည်ပြုချက်ဖြင့် တုံ့ပြန်သည်။

သို့သော်၊ ကြီးမားသောပြဿနာတစ်ခုရှိသည်။ အောင်မြင်သော အပလီကေးရှင်းသည် အောင်မြင်စွာ ဖြန့်ချိခြင်းကို မဆိုလိုပါ။. အကယ်၍ Kubernetes သည် မည်သည့်ပြောင်းလဲမှုများကို အသုံးချရမည်ကို နားလည်ပြီး ၎င်းကို အသုံးချပါက ရလဒ်သည် မည်သို့ဖြစ်မည်ကို ကျွန်ုပ်တို့ မသိနိုင်ပါ။ ဥပမာအားဖြင့်၊ ရှေ့တန်းတွင် ပေါ့ဒ်များကို အပ်ဒိတ်လုပ်ခြင်းနှင့် ပြန်လည်စတင်ခြင်းတို့သည် အောင်မြင်နိုင်သော်လည်း နောက်ခံတွင် မဟုတ်ဘဲ၊ လည်ပတ်နေသည့် အပလီကေးရှင်းပုံများ၏ ဗားရှင်းအမျိုးမျိုးကို ကျွန်ုပ်တို့ ရရှိပါမည်။

အရာအားလုံးကို မှန်ကန်စွာလုပ်ဆောင်ရန်၊ ဤအစီအစဥ်သည် Kubernetes API မှ အခြေအနေအချက်အလက်များကို လက်ခံရရှိပြီး အရာများ၏ တကယ့်အခြေအနေမှန်ကို ထပ်မံခွဲခြမ်းစိတ်ဖြာရန်အတွက် ပို့လွှတ်မည့် အထူးခြေရာခံလင့်ခ်တစ်ခု လိုအပ်ပါသည်။ Go တွင် Open Source စာကြည့်တိုက်တစ်ခုကို ကျွန်ုပ်တို့ ဖန်တီးခဲ့သည်- ခွေးကလေး (၎င်း၏ကြေငြာချက်ကိုကြည့်ပါ။ ဒီမှာ)ဤပြဿနာကိုဖြေရှင်းပေးပြီး werf အဖြစ်တည်ဆောက်ထားသည်။

werf အဆင့်ရှိ ဤခြေရာခံကိရိယာ၏ အပြုအမူကို Deployments သို့မဟုတ် StatefulSets တွင် ထည့်ထားသည့် မှတ်စာများကို အသုံးပြု၍ စီစဉ်သတ်မှတ်ထားသည်။ အဓိက မှတ်ချက်- fail-mode - အောက်ပါ အဓိပ္ပါယ်များကို နားလည်သည်။

• IgnoreAndContinueDeployProcess — ကျွန်ုပ်တို့သည် ဤအစိတ်အပိုင်းကို ထုတ်ပစ်ခြင်း၏ ပြဿနာများကို လျစ်လျူရှုပြီး ဖြန့်ကျက်မှုကို ဆက်လက်လုပ်ဆောင်ပါသည်။
• FailWholeDeployProcessImmediately - ဤအစိတ်အပိုင်းရှိ အမှားတစ်ခုသည် ဖြန့်ကျက်ခြင်းလုပ်ငန်းစဉ်ကို ရပ်တန့်စေသည်။
• HopeUntilEndOfDeployProcess — ဖြန့်ကျက်မှုအပြီးတွင် ဤအစိတ်အပိုင်းသည် အလုပ်လုပ်နိုင်မည်ဟု ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။

ဥပမာအားဖြင့်၊ ဤအရင်းအမြစ်များနှင့် မှတ်ချက်တန်ဖိုးများကို ပေါင်းစပ်ထားသည်။ fail-mode:

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

werf တွင် kubedog အတွက် နောက်ထပ် မှတ်စု နှစ်ခု ရှိပါသည်-

• failures-allowed-per-replica - ပုံစံတူတစ်ခုစီအတွက် ခွင့်ပြုထားသော ကြွေကျအရေအတွက်၊
• show-logs-until — လှိမ့်ထားသော pods များအားလုံးမှ werf (stdout) မှတ်တမ်းများပြသသည့်အခိုက်အတန့်ကို ထိန်းညှိပါ။ ပုံသေကား PodIsReady (ယာဉ်အသွားအလာစတင်သည့်အချိန်တွင် ကျွန်ုပ်တို့မလိုလားသည့်စာများကို လျစ်လျူရှုရန်)၊ သို့သော် တန်ဖိုးများသည်လည်း အကျုံးဝင်သည်- ControllerIsReady и EndOfDeploy.

ဖြန့်ကျက်မှုကနေ နောက်ထပ် ဘာလိုချင်သေးလဲ။

ဖော်ပြပြီးသား အချက်နှစ်ချက်အပြင်၊

• မြင် သစ်လုံးများ - လိုအပ်သောသူများကိုသာ ဆက်တိုက်လုပ်ပါ။
• တစ်ပုဒ် တိုးတက်ခြင်းအဘယ်ကြောင့်ဆိုသော် အလုပ်သည် မိနစ်အတော်ကြာ "တိတ်ဆိတ်စွာ" ချိတ်ထားမည်ဆိုပါက ထိုနေရာတွင် ဖြစ်ပျက်နေသည်များကို နားလည်ရန် အရေးကြီးပါသည်။
• иметь အလိုအလျောက်ပြန်လှည့်ခြင်း။ တစ်ခုခု မှားယွင်းသွားပါက (ထို့ကြောင့် ဖြန့်ကျက်မှု၏ အခြေအနေမှန်ကို သိရန် အရေးကြီးသည်)။ လွှတ်တင်မှုသည် အဏုမြူဗုံးဖြစ်ရမည်- အဆုံးအထိသွားသည်ဖြစ်စေ၊ အားလုံးသည် ၎င်း၏ ယခင်အခြေအနေသို့ ပြန်သွားမည်ဖြစ်သည်။

ရလဒ်များကို

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

နိဂုံးချုပ်ရာ၌

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

ဗီဒီယိုများနှင့် ဆလိုက်များ

ဖျော်ဖြေပွဲမှ ဗီဒီယို (~47 မိနစ်)

အစီရင်ခံစာတင်ပြချက်-

PS

ကျွန်ုပ်တို့၏ဘလော့ဂ်ရှိ Kubernetes အကြောင်း အခြားအစီရင်ခံစာများ-

• «Kubernetes ရှိ အော်တိုစကေးချဲ့ခြင်းနှင့် အရင်းအမြစ်စီမံခန့်ခွဲမှု» (Dmitry Stolyarov; ဧပြီလ 27 ရက်၊ 2019 “Strike” တွင်);
• «Kubernetes ကို တိုးချဲ့ခြင်းနှင့် ဖြည့်စွက်ခြင်း။» (Andrey Polovov; ဧပြီ 8၊ 2019 တွင် Saint HighLoad++);
• «ဒေတာဘေ့စ်များနှင့် Kubernetes» (Dmitry Stolyarov; နိုဝင်ဘာ 8၊ 2018 တွင် HighLoad++);
• «စောင့်ကြည့်ခြင်းနှင့် Kubernetes» (Dmitry Stolyarov; မေလ 28 ရက်၊ 2018 တွင် RootConf);
• «Kubernetes နှင့် GitLab ဖြင့် အကောင်းဆုံး အလေ့အကျင့်များ CI/CD» (Dmitry Stolyarov; နိုဝင်ဘာ 7၊ 2017 တွင် HighLoad++);
• «ပရောဂျက်ငယ်များတွင် Kubernetes နှင့် ကျွန်ုပ်တို့၏အတွေ့အကြုံ» (Dmitry Stolyarov; ဇွန်လ 6၊ 2017 တွင် RootConf).

source: www.habr.com