ProHoster > ဘလော့ > အုပ်ချုပ်ရေး > ဗားရှင်းဖော်ထားသော စာရွက်စာတမ်းဆိုက်၏နမူနာကို အသုံးပြု၍ werf ဖြင့် Docker ရုပ်ပုံများ တပ်ဆင်ခြင်းနှင့် အသုံးပြုခြင်း

ဗားရှင်းဖော်ထားသော စာရွက်စာတမ်းဆိုက်၏နမူနာကို အသုံးပြု၍ werf ဖြင့် Docker ရုပ်ပုံများ တပ်ဆင်ခြင်းနှင့် အသုံးပြုခြင်း

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ GitOps tool အကြောင်းကို တစ်ကြိမ်ထက်ပို၍ ပြောထားပြီးဖြစ်သည်။ werfဒီတစ်ခါမှာတော့ ပရောဂျက်ကိုယ်တိုင်က စာရွက်စာတမ်းတွေနဲ့ ဆိုက်ကို စုစည်းရာမှာ အတွေ့အကြုံကို မျှဝေလိုပါတယ်။ werf.io (၎င်း၏ရုရှားဗားရှင်းဖြစ်သည်။ en.werf.io) ၎င်းသည် သာမာန်အငြိမ်ဆိုက်တစ်ခုဖြစ်သော်လည်း၊ ၎င်းသည် ရွေ့လျားနေသော ရှေးဟောင်းပစ္စည်းအရေအတွက်ကို အသုံးပြု၍ တည်ဆောက်ထားသောကြောင့် ၎င်း၏စုဝေးမှုမှာ စိတ်ဝင်စားစရာဖြစ်သည်။

ဗားရှင်းဖော်ထားသော စာရွက်စာတမ်းဆိုက်၏နမူနာကို အသုံးပြု၍ werf ဖြင့် Docker ရုပ်ပုံများ တပ်ဆင်ခြင်းနှင့် အသုံးပြုခြင်း

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

နိဒါန်း- ဆိုက်က ဘယ်လိုအလုပ်လုပ်လဲ။

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

  • စာတမ်းပြုစုခြင်းကို မွမ်းမံခြင်းမရှိဘဲ werf လုပ်ဆောင်ချက်အသစ်များကို ထုတ်လွှတ်ခြင်းမပြုသင့်ဘဲ၊ အပြန်အလှန်အားဖြင့်၊ စာရွက်စာတမ်းတွင် မည်သည့်ပြောင်းလဲမှုမဆို werf ဗားရှင်းအသစ်ကို ထုတ်ဝေခြင်းကို ဆိုလိုပါသည်။
  • ပရောဂျက်တွင် အတော်လေး အကြိတ်အနယ် ဖြစ်ထွန်းနေသည်- ဗားရှင်းအသစ်များကို တစ်နေ့လျှင် အကြိမ်ပေါင်းများစွာ ထုတ်ဝေနိုင်သည်၊
  • စာရွက်စာတမ်းဗားရှင်းအသစ်ပါရှိသော ဆိုက်တစ်ခုအား ဖြန့်ကျက်ရန် လက်ဖြင့်လုပ်ဆောင်မှုမှန်သမျှသည် အနည်းဆုံး ပျင်းစရာကောင်းပါသည်။
  • ပရောဂျက်သည် သဘောတရားရေးရာ ချဉ်းကပ်မှုကို လက်ခံသည်။ မူကွဲတည်ငြိမ်မှုချန်နယ် 5 ခုပါရှိသည်။ ဖြန့်ချိမှုလုပ်ငန်းစဉ်တွင် တည်ငြိမ်မှုတိုးလာစေရန်အတွက် လမ်းကြောင်းများမှတစ်ဆင့် ဗားရှင်းများ ဆက်တိုက်ပါဝင်သည်- alpha မှ rock-solid အထိ၊
  • ဝဘ်ဆိုက်တွင် အဓိက (ဆိုလိုသည်မှာ အင်္ဂလိပ်ဘာသာ) ဗားရှင်းနှင့် အပြိုင် "အသက်ရှင်ပြီး ဖွံ့ဖြိုးတိုးတက်သည်" (ဆိုလိုသည်မှာ အပ်ဒိတ်လုပ်ထားသော အကြောင်းအရာ) ရှိသည့် ရုရှားဘာသာစကားဗားရှင်းတစ်ခု ရှိသည်။

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

ဝဘ်ဆိုက်ရှိ ဗားရှင်းရွေးချယ်မှုမီနူးတွင်၊ ချန်နယ်တစ်ခုစီတွင် werf ၏ နောက်ဆုံးဗားရှင်းများကို ရရှိနိုင်သည်။ မူရင်းအားဖြင့်၊ လိပ်စာအားဖြင့် werf.io/documentation နောက်ဆုံးထွက်ရှိမှုအတွက် အတည်ငြိမ်ဆုံးချန်နယ်ဗားရှင်းကို ဖွင့်ထားသည် - ၎င်းကို ရှာဖွေရေးအင်ဂျင်များမှလည်း အညွှန်းပေးထားသည်။ ချန်နယ်အတွက် စာရွက်စာတမ်းများကို သီးခြားလိပ်စာများတွင် ရနိုင်သည် (ဥပမာ၊ werf.io/v1.0-beta/documentation beta release 1.0 အတွက်)။

စုစုပေါင်း၊ ဤဆိုက်တွင် ရရှိနိုင်သော အောက်ပါဗားရှင်းများရှိသည်။

  1. root (မူလအားဖြင့်ဖွင့်သည်)၊
  2. ထုတ်ဝေမှုတစ်ခုစီ၏ အသက်ဝင်သော အပ်ဒိတ်ချန်နယ်တစ်ခုစီအတွက် (ဥပမာ၊ werf.io/v1.0-beta).

ဆိုက်တစ်ခု၏ သီးခြားဗားရှင်းတစ်ခုကို ထုတ်လုပ်ရန်၊ ယေဘုယျအားဖြင့် ၎င်းကို အသုံးပြု၍ စုစည်းရန် လုံလောက်ပါသည်။ Jekylldirectory တွင် run ခြင်းဖြင့် /docs werf repository သက်ဆိုင်ရာ command (jekyll build) လိုအပ်သောဗားရှင်း၏ Git tag သို့ပြောင်းပြီးနောက်။

အဲဒါကို ထပ်ထည့်ဖို့ပဲ ကျန်တော့တယ်။

  • utility ကိုယ်တိုင် (werf) ကို စုဝေးရာတွင် အသုံးပြုသည်။
  • CI/CD လုပ်ငန်းစဉ်များကို GitLab CI ၏အခြေခံပေါ်တွင်တည်ဆောက်ထားသည်။
  • ဤအရာအားလုံးသည် Kubernetes တွင်အလုပ်လုပ်သည်။

တာဝန်များကို

ယခု ဖော်ပြထားသော အသေးစိတ်အချက်များအားလုံးကို ထည့်သွင်းစဉ်းစားရမည့် အလုပ်များကို ပုံဖော်ကြပါစို့။

  1. အပ်ဒိတ်ချန်နယ်ရှိ werf ဗားရှင်းကို ပြောင်းလဲပြီးနောက် ဆိုက်ရှိစာရွက်စာတမ်းများကို အလိုအလျောက် အပ်ဒိတ်လုပ်သင့်သည်။.
  2. ဖွံ့ဖြိုးတိုးတက်ဖို့အတွက် တခါတရံ လုပ်နိုင်ရမယ်။ ဆိုက်၏ အကြိုကြည့်ရှုမှုဗားရှင်းများကို ကြည့်ရှုပါ။.

သက်ဆိုင်ရာ Git တဂ်များမှ မည်သည့်ချန်နယ်တွင်မဆို ဗားရှင်းဗားရှင်းကို ပြောင်းလဲပြီးနောက် ဆိုက်အား ပြန်လည်စုစည်းရမည်ဖြစ်ပြီး၊ သို့သော် ပုံတည်ဆောက်ခြင်းလုပ်ငန်းစဉ်တွင် ကျွန်ုပ်တို့သည် အောက်ပါအင်္ဂါရပ်များကို ရရှိပါမည်-

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

ထိုသို့ထွက်လှည့် စည်းဝေးပွဲသည် ပြင်ပဒေတာပြောင်းလဲခြင်းအပေါ် မူတည်သည်။.

အကောင်အထည်ဖော်မှု

ချဉ်းကပ်မှုတစ်ခုရွေးချယ်ခြင်း။

တစ်နည်းအားဖြင့် Kubernetes တွင် သီးခြား pod တစ်ခုအဖြစ် လိုအပ်သော ဗားရှင်းတစ်ခုစီကို သင်သုံးနိုင်သည်။ ဤရွေးချယ်မှုသည် တည်ငြိမ်သော werf ထုတ်ဝေမှုအရေအတွက် တိုးလာသည်နှင့်အမျှ အစုအဝေးအတွင်းရှိ အရာဝတ္ထုအရေအတွက် ပိုများလာမှုကို ရည်ညွှန်းသည်။ ထို့အပြင် ၎င်းသည် ပိုမိုရှုပ်ထွေးသော ပြုပြင်ထိန်းသိမ်းမှုကို ဖော်ညွှန်းသည်- ဗားရှင်းတစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် HTTP ဆာဗာရှိပြီး သေးငယ်သော ဝန်ဖြင့် ပါဝင်သည်။ ဟုတ်ပါတယ်၊ ဒါကလည်း အရင်းအမြစ်ကုန်ကျစရိတ် ပိုကြီးပါတယ်။

တူညီတဲ့လမ်းကို လျှောက်ခဲ့ကြတယ်။ လိုအပ်သောဗားရှင်းအားလုံးကို ပုံတစ်ပုံတည်းတွင် စုစည်းပါ။. ဝဘ်ဆိုက်၏ ဗားရှင်းအားလုံး၏ စုစည်းထားသော statics များသည် NGINX ပါသည့် ကွန်တိန်နာတစ်ခုတွင် တည်ရှိပြီး သက်ဆိုင်ရာ ဖြန့်ကျက်ခြင်းသို့ လမ်းကြောင်းသည် NGINX Ingress မှတဆင့် ရောက်ရှိလာပါသည်။ ရိုးရှင်းသောဖွဲ့စည်းပုံ - နိုင်ငံမဲ့အက်ပလီကေးရှင်းတစ်ခု - Kubernetes ကိုယ်တိုင်ကို အသုံးပြု၍ ဖြန့်ကျက်မှု (ဝန်ပေါ် မူတည်၍) ကို အလွယ်တကူ အတိုင်းအတာဖြင့် လုပ်ဆောင်နိုင်စေပါသည်။

ပိုမိုတိကျစေရန်အတွက်၊ ကျွန်ုပ်တို့သည် ထုတ်လုပ်မှုပတ်လမ်းအတွက် ပုံနှစ်ပုံ၊ ဒုတိယပုံသည် dev circuit အတွက် နောက်ထပ်ပုံတစ်ပုံဖြစ်သည်။ အပိုပုံအား ပင်မစက်ဖြင့် dev circuit တွင်သာ (ဖွင့်ထားသည်) ကို အသုံးပြုထားပြီး ပြန်လည်သုံးသပ်မှုကော်မတီမှ ဆိုက်၏ဗားရှင်းပါရှိသည်၊ ၎င်းတို့ကြားလမ်းကြောင်းကို Ingress ရင်းမြစ်များကို အသုံးပြု၍ လုပ်ဆောင်သည်။

werf vs git clone နှင့် artifacts

ဖော်ပြထားပြီးဖြစ်သည့်အတိုင်း၊ စာရွက်စာတမ်း၏ သီးခြားဗားရှင်းတစ်ခုအတွက် site statics ကိုဖန်တီးရန်အတွက် သင့်လျော်သော repository tag သို့ပြောင်းခြင်းဖြင့် တည်ဆောက်ရန်လိုအပ်ပါသည်။ သင်တည်ဆောက်ပြီးတိုင်း repository ကိုပွားခြင်းဖြင့်၊ စာရင်းတစ်ခုမှသင့်လျော်သော tags များကိုရွေးချယ်ခြင်းဖြင့်၎င်းကိုသင်လုပ်ဆောင်နိုင်သည်။ သို့သော်၊ ၎င်းသည် အရင်းအမြစ်-အလေးပေးလုပ်ဆောင်မှုဖြစ်ပြီး၊ ထို့အပြင်၊ အသေးအဖွဲမဟုတ်သော ညွှန်ကြားချက်များကို ရေးသားရန် လိုအပ်သည်... နောက်ထပ်ဆိုးရွားသောအားနည်းချက်မှာ စည်းဝေးပွဲအတွင်း တစ်စုံတစ်ခုကို ကက်ရှ်လုပ်ရန် ဤနည်းလမ်းဖြင့် နည်းလမ်းမရှိပေ။

ဤတွင် werf utility ကိုယ်တိုင်ကကျွန်ုပ်တို့၏အကူအညီကိုအကောင်အထည်ဖော်ရန်ရောက်လာသည်။ smart caching အသုံးပြုခွင့်ပေးသည်။ ပြင်ပသိုလှောင်မှုများ. repository မှကုဒ်ထည့်ရန် werf ကိုအသုံးပြုခြင်းသည် build ကိုသိသိသာသာအရှိန်မြှင့်ပေးသောကြောင့်ဖြစ်သည်။ werf သည် အခြေခံအားဖြင့် repository ကို တစ်ကြိမ် clones လုပ်ပြီး execute လုပ်သည်။ သာ fetch လိုအပ်ခဲ့လျှင်။ ထို့အပြင်၊ repository မှဒေတာကိုထည့်သောအခါ၊ ကျွန်ုပ်တို့သည် လိုအပ်သောလမ်းညွှန်များကိုသာ ရွေးချယ်နိုင်သည် (ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ဤသည်မှာ directory ဖြစ်သည်။ docs) ထည့်သွင်းထားသော ဒေတာပမာဏကို သိသိသာသာ လျှော့ချပေးမည်ဖြစ်ပါသည်။

Jekyll သည် static data များကို စုစည်းရန် ဒီဇိုင်းထုတ်ထားသည့် tool တစ်ခုဖြစ်ပြီး နောက်ဆုံးပုံတွင် မလိုအပ်သောကြောင့် compile လုပ်ခြင်းသည် ယုတ္တိရှိပေလိမ့်မည်။ werf ရှေးဟောင်းပစ္စည်းနှင့်နောက်ဆုံးပုံသို့ စုစည်းမှုရလဒ်ကိုသာတင်သွင်းပါ။.

werf.yaml ရေးသည်။

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

werf သည်သင့်အားအသုံးပြုရန်ခွင့်ပြုသည်။ ပုံစံများကို သွားပါ။ သင့် configuration file တွင် (werf.yaml) ၊ ဒါက ဖြစ်နိုင်တယ်။ ပျံသန်းမှုတွင် config ကိုဖန်တီးပါ။ ပြင်ပဒေတာပေါ် မူတည်. (သင်လိုအပ်သည်!) ကျွန်ုပ်တို့၏ကိစ္စရပ်တွင် ပြင်ပဒေတာသည် ကျွန်ုပ်တို့လိုအပ်သော ရှေးဟောင်းပစ္စည်းအရေအတွက်ကို အခြေခံ၍ ဗားရှင်းများနှင့် ထုတ်ဝေမှုများအကြောင်း အချက်အလက်များကို စုဆောင်းပြီး ရလဒ်အနေဖြင့် ရုပ်ပုံနှစ်ခုကို ရရှိသည်- werf-doc и werf-dev မတူညီသော circuit များပေါ်တွင်လည်ပတ်ရန်။

ပြင်ပဒေတာကို ပတ်၀န်းကျင် ကိန်းရှင်များမှတဆင့် ဖြတ်သန်းပါသည်။ ဤတွင် ၎င်းတို့၏ ဖွဲ့စည်းမှု။

  • RELEASES — ထုတ်ဝေမှုများစာရင်းနှင့် werf ၏သက်ဆိုင်ရာလက်ရှိဗားရှင်းပါသော စာကြောင်းတစ်ကြောင်း၊ ဖော်မတ်ရှိ နေရာလွတ်ခြားထားသော တန်ဖိုးများစာရင်းပုံစံ၊ <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. ဥပမာ- 1.0%v1.0.4-beta.20
  • CHANNELS — လိုင်းများစာရင်းတစ်ခုနှင့် werf ၏သက်ဆိုင်ရာလက်ရှိဗားရှင်းပါရှိသော မျဉ်းတစ်ကြောင်း၊ ဖော်မတ်ရှိ နေရာလွတ်ခြားထားသော တန်ဖိုးများစာရင်းပုံစံ၊ <КАНАЛ>%<НОМЕР_ВЕРСИИ>. ဥပမာ- 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
  • ROOT_VERSION — ဆိုက်ပေါ်တွင် ပုံသေဖြင့်ပြသမည့် werf ဗားရှင်းဗားရှင်း (အမြင့်ဆုံးထုတ်လွှတ်မှုနံပါတ်ဖြင့် စာရွက်စာတမ်းများကို အမြဲတမ်းပြသရန် မလိုအပ်ပါ)။ ဥပမာ- v1.0.4-beta.20
  • REVIEW_SHA — စမ်းသပ်ကွင်းအတွက် ဗားရှင်းကို သင်တည်ဆောက်ရန်လိုအပ်သည့် ပြန်လည်သုံးသပ်မှု၏ hash ရှိသည်။

ဤကိန်းရှင်များကို GitLab CI ပိုက်လိုင်းတွင် ဖြည့်သွင်းမည်ဖြစ်ပြီး အတိအကျကို အောက်တွင် ရေးထားသည်။

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

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

site ၏ static ဗားရှင်းကို စုစည်းရန်အတွက် artifact ၏ ဖော်ပြချက်သည် ယေဘူယျအားဖြင့် ကျွန်ုပ်တို့လိုအပ်သော ကိစ္စအားလုံးအတွက် ( root ဗားရှင်းနှင့် dev circuit အတွက် ဗားရှင်း အပါအဝင်) နှင့် တူညီပါသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ၎င်းကို လုပ်ဆောင်ချက်ကို အသုံးပြု၍ သီးခြားဘလောက်တစ်ခုသို့ ရွှေ့ပါမည်။ define - နောက်ဆက်တွဲအနေနဲ့ ပြန်သုံးဘို့ include. ကျွန်ုပ်တို့သည် အောက်ပါ အကြောင်းပြချက်များကို နမူနာပုံစံသို့ ကျော်ဖြတ်ပါမည်-

  • Version - ထုတ်လုပ်ထားသောဗားရှင်း (တက်ဂ်အမည်);
  • Channel — ရှေးဟောင်းပစ္စည်းကိုထုတ်ပေးသည့် အပ်ဒိတ်ချန်နယ်၏အမည်၊
  • Commit - ပြန်လည်သုံးသပ်မှုတစ်ခုအတွက် ရှေးဟောင်းပစ္စည်းကို ထုတ်လုပ်ပါက hash ကို ကျူးလွန်ပါ။
  • စကားစပ်။

Artifact Template ဖော်ပြချက်

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

ရှေးဟောင်းပစ္စည်းအမည်သည် ထူးခြားရပါမည်။ ဥပမာအားဖြင့်၊ ချန်နယ်အမည် (variable ၏တန်ဖိုး .Channel) ရှေးဟောင်းပစ္စည်းအမည်၏ နောက်ဆက်တွဲအဖြစ်- artifact: doc-{{ .Channel }}. သို့သော် ရှေးဟောင်းပစ္စည်းများမှ တင်သွင်းသည့်အခါ တူညီသောအမည်များကို ရည်ညွှန်းရန် လိုအပ်ကြောင်း နားလည်ထားရန် လိုအပ်သည်။

ရှေးဟောင်းပစ္စည်းတစ်ခုကို ဖော်ပြသောအခါ၊ အောက်ပါ werf အင်္ဂါရပ်ကို အသုံးပြုသည်- တပ်ဆင်ခြင်း။. ဝန်ဆောင်မှုလမ်းညွှန်ကို ညွှန်ပြနေပါသည်။ build_dir ပိုက်လိုင်းလည်ပတ်မှုကြားတွင် Jekyll ကက်ရှ်ကို သိမ်းဆည်းနိုင်စေပါသည်။ ပြန်လည်စုစည်းမှုကို သိသိသာသာ မြန်ဆန်စေသည်။.

ဖိုင်အသုံးပြုမှုကိုလည်း သင်သတိပြုမိပေမည်။ releases.yml ထံမှ တောင်းဆိုထားသော ထုတ်ပြန်ချက်ဒေတာပါရှိသော YAML ဖိုင်တစ်ခုဖြစ်သည်။ github.com (ပိုက်လိုင်းကို အကောင်အထည်ဖော်ရာတွင် ရရှိသော ပစ္စည်းတစ်ခု)။ ဆိုက်ကို ပြုစုရာတွင် လိုအပ်သော်လည်း ဆောင်းပါး၏ အခြေအနေတွင် ၎င်းသည် ၎င်း၏ အခြေအနေအပေါ် မူတည်သောကြောင့် ကျွန်ုပ်တို့အတွက် စိတ်ဝင်စားစရာ ကောင်းပါသည်။ တစ်ခုတည်းသော ရှေးဟောင်းပစ္စည်းကို ပြန်လည်စုစည်းပါ။ - ဆိုက်၏ root ဗားရှင်း၏ ရှေးဟောင်းပစ္စည်း (အခြားအရာများတွင် မလိုအပ်ပါ)။

၎င်းကို conditional statement ကို အသုံးပြု၍ အကောင်အထည်ဖော်သည်။ if ပုံစံများနှင့် ဒီဇိုင်းများကို သွားပါ။ {{ $Root.Files.Get "releases.yml" | sha256sum }} စင်ပေါ်မှာ အဆင့်များ. ၎င်းသည် အောက်ပါအတိုင်း အလုပ်လုပ်သည်- root ဗားရှင်းအတွက် (variable .Channel ဖြစ် root) ဖိုင် hash releases.yml ၎င်းသည် Ansible လုပ်ငန်းအမည် (ပါရာမီတာ) ၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သောကြောင့် စတိတ်တစ်ခုလုံး၏ လက်မှတ်ကို အကျိုးသက်ရောက်စေသည်။ name) ဒါကြောင့် ပြောင်းလဲလိုက်တာ အကြောင်းအရာ ဖိုင် releases.yml သက်ဆိုင်ရာ ရှေးဟောင်းပစ္စည်းကို ပြန်လည်စုစည်းပါမည်။

ပြင်ပ repository တစ်ခုနှင့် အလုပ်လုပ်ရန်လည်း အာရုံစိုက်ပါ။ ပုံသဏ္ဌာန်အားဖြင့် ရှေးဟောင်းပစ္စည်းတစ်ခုထံမှ သိရသည်။ werf သိုလှောင်မှုလမ်းညွှန်ကိုသာ ထည့်သွင်းထားသည်။ /docsနှင့် ကျော်လွန်သွားသော ကန့်သတ်ဘောင်များပေါ် မူတည်၍ လိုအပ်သော တဂ် သို့မဟုတ် သုံးသပ်ချက် ကွန်မန့်၏ ဒေတာကို ချက်ချင်း ပေါင်းထည့်သည်။

ချန်နယ်များနှင့် ထုတ်ဝေမှုများ၏ လွှဲပြောင်းထားသော ဗားရှင်းများနှင့် ထုတ်ဝေမှုများ၏ ရှေးဟောင်းပစ္စည်းအကြောင်း ဖော်ပြချက်ကို ဖန်တီးရန် ရှေးဟောင်းပုံစံပုံစံကို အသုံးပြုရန်၊ ကျွန်ုပ်တို့သည် ကိန်းရှင်ပေါ်တွင် ကွင်းဆက်တစ်ခုကို စုစည်းထားသည်။ .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

ဘာဖြစ်လို့လဲဆိုတော့ ကွင်းသည် များစွာသော ရှေးဟောင်းပစ္စည်းများကို ထုတ်ပေးလိမ့်မည် (ကျွန်ုပ်တို့မျှော်လင့်ထားသည်)၊ ၎င်းတို့အကြား ခြားနားချက်ကို ထည့်သွင်းစဉ်းစားရန် လိုအပ်သည် - ဆင့်ပွား --- (Configuration file syntax ဆိုင်ရာ နောက်ထပ်အချက်အလက်များအတွက်၊ ကြည့်ပါ။ စာရွက်စာတမ်း) အစောပိုင်းတွင် သတ်မှတ်ထားသည့်အတိုင်း၊ စက်ဝိုင်းတစ်ခုတွင် ပုံစံပလိတ်တစ်ခုကို ခေါ်သောအခါ၊ ကျွန်ုပ်တို့သည် ဗားရှင်း ကန့်သတ်ချက်များ၊ URL နှင့် root အကြောင်းအရာများကို ဖြတ်သန်းပါသည်။

အလားတူဘဲ၊ ကွင်းဆက်မပါဘဲ၊ ကျွန်ုပ်တို့သည် "အထူးကိစ္စများ" အတွက် ရှေးဟောင်းပစ္စည်းပုံစံကို ခေါ်သည်- အမြစ်ဗားရှင်းနှင့် ပြန်လည်သုံးသပ်မှု ကွန်မန့်မှ ဗားရှင်းကို-

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

ကိန်းရှင်သတ်မှတ်ထားမှသာ ပြန်လည်သုံးသပ်မှုကော်မတီအတွက် အဆောက်အအုံကို တည်ဆောက်မည်ဖြစ်ကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ။ .WerfReviewCommit.

ရှေးဟောင်းပစ္စည်းများ အဆင်သင့်ဖြစ်ပါပြီ - စတင်တင်သွင်းရန် အချိန်တန်ပါပြီ။

Kubernetes တွင်လည်ပတ်ရန် ဒီဇိုင်းထုတ်ထားသည့် နောက်ဆုံးပုံသည် ပုံမှန် NGINX ဖြစ်ပြီး ဆာဗာဖွဲ့စည်းမှုပုံစံဖိုင်တစ်ခုထည့်သွင်းထားသည်။ nginx.conf နှင့် ရှေးဟောင်းပစ္စည်းများမှ ငြိမ်သည်။ ဝဘ်ဆိုက်၏ အမြစ်ဗားရှင်း၏ အတုအယောင်အပြင်၊ ကျွန်ုပ်တို့သည် ကိန်းရှင်ပေါ်ရှိ ကွင်းဆက်ကို ပြန်လုပ်ရန် လိုအပ်သည်။ .WerfVersions ချန်နယ်၏ ရှေးဟောင်းပစ္စည်းများကို တင်သွင်းရန်နှင့် ဗားရှင်းများထုတ်ရန် + အစောပိုင်းက ကျွန်ုပ်တို့ချမှတ်ခဲ့သည့် ရှေးဟောင်းပစ္စည်းအမည်ပေးခြင်း စည်းမျဉ်းကို လိုက်နာပါ။ ပစ္စည်းတစ်ခုစီသည် ဘာသာစကားနှစ်မျိုးအတွက် ဝဘ်ဆိုက်၏ဗားရှင်းများကို သိမ်းဆည်းထားသောကြောင့်၊ ၎င်းတို့ကို ဖွဲ့စည်းမှုပုံစံဖြင့် ပံ့ပိုးပေးထားသည့်နေရာများသို့ တင်သွင်းပါသည်။

နောက်ဆုံးပုံ werf-doc ၏ ရှင်းလင်းချက်

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

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

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

အထက်တွင်ဖော်ပြထားသည့်အတိုင်း၊ ပြန်လည်သုံးသပ်မှုကော်မတီအတွက် ပစ္စည်းများသည် သတ်မှတ်ပတ်၀န်းကျင် variable ကို run သည့်အခါမှသာ ထုတ်ပေးမည်ဖြစ်ပါသည်။ REVIEW_SHA. ပတ်၀န်းကျင် ပြောင်းလဲနိုင်သော ကိန်းရှင်မရှိပါက werf-dev ပုံကို လုံးဝမထုတ်လုပ်နိုင်ပါ။ REVIEW_SHAဒါပေမယ် မူဝါဒများဖြင့် ရှင်းလင်းခြင်း။ werf ရှိ Docker ပုံများသည် werf-dev ပုံအတွက် အလုပ်လုပ်သည်၊၊ ပိုက်လိုင်းတည်ဆောက်ပုံကို ရိုးရှင်းစေရန်အတွက် ၎င်းကို root version artifact (မည်သို့ပင်ဖြစ်စေ တည်ဆောက်ထားပြီးဖြစ်သည်) ဖြင့်သာ တည်ဆောက်ထားပါမည်။

ပရိသတ် အဆင်သင့်ဖြစ်ပါပြီ။ CI/CD နှင့် အရေးကြီးသော ကွဲပြားချက်များသို့ ဆက်သွားကြပါစို့။

GitLab CI ရှိ Pipeline နှင့် dynamic build ၏အင်္ဂါရပ်များ

build ကို run သောအခါတွင်အသုံးပြုသောပတ်ဝန်းကျင် variable များကိုသတ်မှတ်ရန်လိုအပ်သည်။ werf.yaml. ၎င်းသည် GitHub ချိတ်မှ ပိုက်လိုင်းကို ခေါ်ဆိုသည့်အခါ သတ်မှတ်ပေးမည့် REVIEW_SHA ကိန်းရှင်နှင့် မသက်ဆိုင်ပါ။

ကျွန်ုပ်တို့သည် Bash script တစ်ခုတွင် လိုအပ်သော ပြင်ပဒေတာကို ထုတ်လုပ်ပေးပါမည်။ generate_artifactsGitLab ပိုက်လိုင်း ရှေးဟောင်းပစ္စည်း နှစ်ခုကို ထုတ်လုပ်ပေးမည့်၊

  • ဖိုင် releases.yml ထုတ်ပြန်ချက်အချက်အလက်နှင့်အတူ၊
  • ဖိုင် common_envs.shတင်ပို့မည့် ပတ်ဝန်းကျင် ကိန်းရှင်များ ပါဝင်သော၊

ဖိုင်အကြောင်းအရာများ generate_artifacts ငါတို့မှာတွေ့လိမ့်မယ်။ နမူနာများဖြင့် သိုလှောင်မှုများ. ဒေတာကို လက်ခံရယူခြင်းသည် ဆောင်းပါး၏အကြောင်းအရာမဟုတ်သော်လည်း ဖိုင်ဖြစ်သည်။ common_envs.sh အဘယ်ကြောင့်ဆိုသော် ကျွန်ုပ်တို့အတွက် အရေးကြီးပါသည်။ werf ၏အလုပ်သည်၎င်းပေါ်တွင်မူတည်သည်။ ၎င်း၏ အကြောင်းအရာ ဥပမာ

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

ဥပမာ Bash လုပ်ဆောင်ချက်ကို အသုံးပြု၍ ထိုကဲ့သို့သော script ၏ output ကို သင်သုံးနိုင်သည်။ source.

ကဲ ပျော်စရာအပိုင်းလေး လာပါပြီ။ အက်ပလီကေးရှင်းကို တည်ဆောက်ခြင်းနှင့် ဖြန့်ကျက်ခြင်း နှစ်ခုစလုံး မှန်ကန်စွာ လုပ်ဆောင်နိုင်စေရန်အတွက် ၎င်းကို သေချာစေရန် လိုအပ်ပါသည်။ werf.yaml ဒါဟာခဲ့ အတူတူ အနည်းဆုံးတော့ ပိုက်လိုင်းတစ်ခုအတွင်း. ဤအခြေအနေနှင့် မကိုက်ညီပါက၊ စည်းဝေးပွဲအတွင်း werf တွက်ချက်သည့် အဆင့်များနှင့် ဥပမာအားဖြင့် ဖြန့်ကျက်ခြင်းများသည် ကွဲပြားသွားပါမည်။ ဒါက deployment error ဖြစ်သွားပါလိမ့်မယ်... ဖြန့်ကျက်မှုအတွက် လိုအပ်သောပုံ ပျောက်ဆုံးနေပါမည်။

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

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

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

ဇာတ်ခုံအကြောင်းအရာ ကြိုတင်တည်ဆောက်ပါ။ ဖိုင် .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

ပစ္စည်းရှိ ပြင်ပဒေတာကို ဖမ်းယူပြီးနောက်၊ စံ GitLab CI ပိုက်လိုင်းအဆင့်များ- တည်ဆောက်ခြင်းနှင့် ဖြန့်ကျက်ခြင်းတို့ကို အသုံးပြု၍ တည်ဆောက်ပြီး အသုံးချနိုင်သည်။ werf GitHub repository (ဆိုလိုသည်မှာ GitHub repository တွင် အပြောင်းအလဲများရှိလာသောအခါ) မှ ချိတ်များကို အသုံးပြု၍ ပိုက်လိုင်းကို ကျွန်ုပ်တို့ကိုယ်တိုင် စတင်လုပ်ဆောင်ပါသည်။ ၎င်းတို့အတွက် ဒေတာကို ကဏ္ဍရှိ GitLab ပရောဂျက်ဂုဏ်သတ္တိများတွင် တွေ့ရှိနိုင်သည်။ CI/CD ဆက်တင်များ -> ပိုက်လိုင်း အစပျိုးမှုများပြီးမှ GitHub တွင် သက်ဆိုင်ရာ Webhook ကို ဖန်တီးပါ (ဆက်တင်များ -> Webhooks).

တည်ဆောက်ပုံ အဆင့်သည် ဤကဲ့သို့ ဖြစ်လိမ့်မည် ။

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

GitLab သည် စင်မြင့်မှ တည်ဆောက်သည့် အဆင့်သို့ ရှေးဟောင်းပစ္စည်း နှစ်ခုကို ပေါင်းထည့်မည်ဖြစ်သည်။ ကြိုတင်တည်ဆောက်ပါ။ထို့ကြောင့် ကျွန်ုပ်တို့သည် တည်ဆောက်မှုကို အသုံးပြု၍ ပြင်ဆင်ထည့်သွင်းသည့်ဒေတာဖြင့် ကိန်းရှင်များကို တင်ပို့ပါသည်။ source common_envs.sh. အချိန်ဇယားအတိုင်း ပိုက်လိုင်းစတင်ခြင်းမှလွဲ၍ ကိစ္စအားလုံးတွင် ကျွန်ုပ်တို့သည် တည်ဆောက်မှုအဆင့်ကို စတင်ပါသည်။ အချိန်ဇယားအရ ကျွန်ုပ်တို့သည် သန့်ရှင်းရေးအတွက် ပိုက်လိုင်းတစ်ခုကို လည်ပတ်ပါမည် - ဤကိစ္စတွင် စည်းဝေးပွဲလုပ်ဆောင်ရန် မလိုအပ်ပါ။

ဖြန့်ကျက်ခြင်းအဆင့်တွင်၊ YAML ပုံစံပလိတ်ကို အသုံးပြု၍ ထုတ်လုပ်ခြင်းနှင့် dev ဆားကစ်များဆီသို့ ဖြန့်ကျက်ခြင်းအတွက် သီးခြားလုပ်ဆောင်စရာနှစ်ခုကို ဖော်ပြပါမည်။

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

အလုပ်များသည် werf ကို ဖြန့်ကျက်လုပ်ဆောင်သင့်သည့် အစုအဝေးအကြောင်းအရာကို ညွှန်ပြရာတွင်သာ အဓိကအားဖြင့် ကွဲပြားသည် (WERF_KUBE_CONTEXT) နှင့် ကွင်းဆက်ပတ်ဝန်းကျင် ကိန်းရှင်များကို သတ်မှတ်ခြင်း (environment.name и environment.url) ထို့နောက် Helm chart templates များတွင် အသုံးပြုကြသည်။ တမ်းပလိတ်များ၏ အကြောင်းအရာများကို ကျွန်ုပ်တို့ ပေးမည်မဟုတ်သောကြောင့် ... အဲဒီမေးခွန်းအတွက် စိတ်ဝင်စားစရာ ဘာမှမရှိဘူး၊ ဒါပေမယ့် အဲဒါတွေကို တွေ့နိုင်တယ်။ ဆောင်းပါးအတွက် သိုလှောင်နေရာများ.

နောက်ဆုံးထိ

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

အကောင်အထည်ဖော်ရန် သင်လိုအပ်လိမ့်မည်-

  • သန့်ရှင်းရေးအဆင့်ကို ထည့်ပါ။ .gitlab-ci.yml;
  • သန့်ရှင်းရေးလုပ်ငန်းကို အချိန်အပိုင်းအခြားအလိုက် လုပ်ဆောင်မှုကို ထည့်ပါ။
  • ရေးရန်ဝင်ရောက်ခွင့် တိုကင်တစ်ခုဖြင့် ပတ်၀န်းကျင် ပြောင်းလဲနိုင်သော ကိန်းရှင်တစ်ခုကို စနစ်ထည့်သွင်းပါ။

သန့်ရှင်းရေးအဆင့်ကို ပေါင်းထည့်သည်။ .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

ဤအရာအားလုံးကို ကျွန်ုပ်တို့နီးပါးမြင်ပြီးဖြစ်သည် - ၎င်းကိုရှင်းလင်းရန်အတွက်သာ Docker Registry တွင်ပုံများကိုဖျက်ပိုင်ခွင့်ရှိသောတိုကင်တစ်ခုဖြင့် ဦးစွာဝင်ရောက်ရန်လိုအပ်သည် (အလိုအလျောက်ထုတ်ပေးသည့် GitLab CI လုပ်ဆောင်စရာတိုကင်မပါရှိပါ။ ဒီလိုအခွင့်အရေးတွေ ရှိတယ်။) တိုကင်ကို GitLab တွင် ကြိုတင်ဖန်တီးထားရမည်ဖြစ်ပြီး ၎င်း၏တန်ဖိုးကို Environment variable တွင် သတ်မှတ်ထားရပါမည်။ WERF_IMAGES_CLEANUP_PASSWORD စီမံကိန်း (CI/CD ဆက်တင်များ -> Variables).

လိုအပ်သောအချိန်ဇယားဖြင့် သန့်ရှင်းရေးလုပ်ငန်းကို ပေါင်းထည့်ခြင်း ပြီးပါပြီ။ CI/CD ->
အချိန်ဇယား.

ဒါပါပဲ- Docker Registry ရှိ ပရောဂျက်တစ်ခုသည် အသုံးမပြုသော ပုံများမှ အဆက်မပြတ် ကြီးထွားလာမည်မဟုတ်ပါ။

လက်တွေ့ကျတဲ့အပိုင်းရဲ့ အဆုံးမှာတော့ ဆောင်းပါးထဲက စာရင်းအပြည့်အစုံကို မှာလို့ရနိုင်တယ်ဆိုတာကို သတိပေးပါရစေ git:

ရလဒ်

  1. ကျွန်ုပ်တို့သည် ယုတ္တိတန်သော စုဖွဲ့မှုဖွဲ့စည်းပုံကို လက်ခံရရှိခဲ့သည်- ဗားရှင်းတစ်ခုလျှင် ရှေးဟောင်းပစ္စည်းတစ်ခု။
  2. စည်းဝေးပွဲသည် universal ဖြစ်ပြီး werf ဗားရှင်းအသစ်များ ထွက်ရှိလာသောအခါတွင် ကိုယ်တိုင်ပြောင်းလဲမှုများ မလိုအပ်ပါ- ဝဘ်ဆိုက်ရှိ စာရွက်စာတမ်းများကို အလိုအလျောက် အပ်ဒိတ်လုပ်ပါသည်။
  3. ပုံနှစ်ပုံကို မတူညီသောပုံစံများအတွက် စုစည်းထားသည်။
  4. ဘာကြောင့်လဲဆိုတော့ မြန်မြန်ဆန်ဆန် အလုပ်လုပ်တယ်။ Caching ကို တတ်နိုင်သမျှ အသုံးပြုသည် - werf ဗားရှင်းအသစ်ကို ထုတ်ပေးသည့်အခါ သို့မဟုတ် GitHub ချိတ်ကို ပြန်လည်သုံးသပ်မှုပြုလုပ်ရန် တောင်းဆိုသောအခါ၊ ပြောင်းလဲထားသော ဗားရှင်းနှင့် သက်ဆိုင်သည့် ပစ္စည်းများကိုသာ ပြန်လည်တည်ဆောက်ပါသည်။
  5. အသုံးမပြုသော ပုံများကို ဖျက်ရန် စဉ်းစားနေရန် မလိုအပ်ပါ- werf မူဝါဒများအတိုင်း သန့်ရှင်းရေးလုပ်ခြင်းသည် Docker Registry ကို စနစ်တကျ ထိန်းသိမ်းထားမည်ဖြစ်သည်။

တွေ့ရှိချက်များ

  • werf ကိုအသုံးပြုခြင်းဖြင့် စည်းဝေးပွဲအား တပ်ဆင်မှုကိုယ်တိုင် ကက်ရှ်လုပ်ခြင်းနှင့် ပြင်ပသိုလှောင်ခန်းများနှင့် အလုပ်လုပ်သောအခါတွင် ကက်ရှ်လုပ်ခြင်းများကြောင့် စည်းဝေးပွဲကို လျင်မြန်စွာလုပ်ဆောင်နိုင်စေပါသည်။
  • ပြင်ပ Git repositories နှင့် အလုပ်လုပ်ခြင်းသည် အချိန်တိုင်း repository တစ်ခုလုံးကို clone လုပ်ရန် လိုအပ်ခြင်း သို့မဟုတ် ဆန်းကျယ်သော optimization logic ဖြင့် wheel ကို ပြန်လည်တီထွင်ရန် လိုအပ်ပါသည်။ werf သည် cache ကိုအသုံးပြုပြီး တစ်ကြိမ်သာ cloning ပြုလုပ်ပြီးနောက် အသုံးပြုသည်။ fetch လိုအပ်သောအခါမှသာ။
  • build configuration file တွင် Go templates ကိုသုံးနိုင်သည်။ werf.yaml ပြင်ပဒေတာပေါ်တွင်မူတည်သည့် ရလဒ်ကို စည်းဝေးပွဲတစ်ခုအား သင်ဖော်ပြခွင့်ပြုသည်။
  • werf တွင် mount ကိုအသုံးပြုခြင်းသည် ပိုက်လိုင်းအားလုံးတွင်ဖြစ်လေ့ရှိသော cache ကြောင့် ရှေးဟောင်းပစ္စည်းများစုဆောင်းမှုကို သိသိသာသာမြန်ဆန်စေသည်။
  • werf သည် ဒိုင်းနမစ်နည်းဖြင့် တည်ဆောက်သည့်အခါ အထူးအရေးကြီးသည့် သန့်ရှင်းရေးကို configure လုပ်ရန် လွယ်ကူစေသည်။

PS

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

source: www.habr.com

မှတ်ချက် Add