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

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

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ GitOps tool အကြောင်းကို တစ်ကြိမ်ထက်ပို၍ ပြောထားပြီးဖြစ်သည်။ werfဒီတစ်ခါမှာတော့ ပရောဂျက်ကိုယ်တိုင်က စာရွက်စာတမ်းတွေနဲ့ ဝဘ်ဆိုဒ်တစ်ခုကို စုစည်းမှုအတွေ့အကြုံကို မျှဝေလိုပါတယ်။ werf.io (၎င်း၏ရုရှားဗားရှင်းဖြစ်သည်။ ru.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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

werf vs git clone နှင့် artifacts

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

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

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

werf.yaml ရေးသည်။

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

werf သည်သင့်အားအသုံးပြုရန်ခွင့်ပြုသည်။ ပုံစံများကို သွားပါ။ သင်၏ဖွဲ့စည်းပုံဖိုင်တွင် (werf.yaml) ၊ ဒါက ဖြစ်နိုင်တယ်။ config "on the fly" ကိုထုတ်လုပ်ပါ ပြင်ပဒေတာပေါ် မူတည်၍ (ကျွန်ုပ်တို့လိုအပ်သည်!) ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ပြင်ပဒေတာသည် ကျွန်ုပ်တို့လိုအပ်သော ရှေးဟောင်းပစ္စည်းအရေအတွက်ကို စုဆောင်းပြီး ရလဒ်အဖြစ် ပုံနှစ်ပုံရရှိသည့်အပေါ် အခြေခံ၍ ဗားရှင်းများနှင့် ထုတ်ဝေမှုများအကြောင်း အချက်အလက်ဖြစ်သည်။ 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-contour အတွက် ဗားရှင်း အပါအဝင်) နှင့် တူညီပါသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ၎င်းကို လုပ်ဆောင်ချက်ကို အသုံးပြု၍ သီးခြား ပိတ်ဆို့ခြင်းသို့ ယူပါမည်။ 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 }}

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

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

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

၎င်းကို အခြေအနေအလိုက် အော်ပရေတာကို အသုံးပြု၍ လုပ်ဆောင်သည်။ if ပုံစံများကို သွား၍ တည်ဆောက်ပါ။ {{ $Root.Files.Get "releases.yml" | sha256sum }} စင်ပေါ်မှာ အဆင့်များ. ၎င်းသည် root ဗားရှင်းအတွက် artifact (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 -}}

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

အလားတူ၊ သို့သော် စက်ဝန်းမရှိဘဲ၊ ကျွန်ုပ်တို့သည် "အထူးကိစ္စများ" အတွက် ရှေးဟောင်းပစ္စည်း နမူနာပုံစံကို ခေါ်သည်- 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 နှင့် ရှေးဟောင်းပစ္စည်းများမှ statics များ။ ဆိုက်၏ root ဗားရှင်း၏ လက်ရာအပြင်၊ ကျွန်ုပ်တို့သည် ကိန်းရှင်ဖြင့် သံသရာကို ပြန်လုပ်ရန် လိုအပ်သည်။ .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-ဆားကစ်ပေါ်တွင်လွှင့်တင်ထားသည့်နောက်ထပ်ရုပ်ပုံတွင်၊ ဆိုက်၏ဗားရှင်းနှစ်မျိုးသာပါဝင်သည်- ပြန်လည်သုံးသပ်ချက်ကွန်မန့်မှဗားရှင်းနှင့် ဆိုက်၏အမြစ်ဗားရှင်း (၎င်းတွင် ဘုံပိုင်ဆိုင်မှုများပါရှိပြီး သင်မှတ်မိပါက၊ ဒေတာထုတ်လွှတ်ပါ)။ ထို့ကြောင့်၊ အပိုပုံသည် တင်သွင်းမှုအပိုင်းတွင်သာ အဓိကပုံနှင့် ကွဲပြားလိမ့်မည် (ဟုတ်ပါတယ်၊ အမည်မှာ)။

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 ကို လုပ်ဆောင်သည့်အခါမှသာ ထုတ်ပေးမည်ဖြစ်သည်။ 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 တွက်ချက်သော အဆင့်လက်မှတ်များနှင့် ဥပမာအားဖြင့် ဖြန့်ကျက်ခြင်းတို့သည် ကွဲပြားလိမ့်မည်။ ဖြန့်ကျက်မှုအတွက် လိုအပ်သောပုံသည် ပျောက်ဆုံးသွားသည့်အတွက် ၎င်းသည် အသုံးချမှု အမှားအယွင်းတစ်ခုဆီသို့ ဦးတည်သွားမည်ဖြစ်သည်။

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

မျိုးဆက်ရှိရင် 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

Artifact တွင် ပြင်ပဒေတာကို ပြုပြင်ပြီးပါက 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) နှင့် contour environment variable များကို သတ်မှတ်ခြင်း (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. ကက်ရှ်ကို အများဆုံးအတိုင်းအတာအထိ အသုံးပြုထားသောကြောင့် ၎င်းသည် လျင်မြန်စွာ အလုပ်လုပ်နိုင်သောကြောင့် - werf ဗားရှင်းအသစ်ကို ထုတ်ပြန်လိုက်သည့်အခါ သို့မဟုတ် GitHub ချိတ်ကို ပြန်လည်သုံးသပ်မှုပြုလုပ်ရန်အတွက် တောင်းဆိုလိုက်သောအခါ၊ ပြောင်းလဲထားသော ဗားရှင်းနှင့် သက်ဆိုင်သည့် ရှေးဟောင်းပစ္စည်းကိုသာ ပြန်လည်တည်ဆောက်ထားသည်။
  5. အသုံးမပြုသောပုံများကို ဖျက်ခြင်းအတွက် စိတ်ပူစရာမလိုပါ- werf policy-based cleanup သည် သင်၏ Docker Registry ကို သပ်ရပ်နေစေမည်ဖြစ်ပါသည်။

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

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

PS

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

source: www.habr.com

DDoS ကာကွယ်ရေး၊ VPS VDS ဆာဗာများပါသည့် ဆိုက်များအတွက် ယုံကြည်စိတ်ချရသော hosting ကို ဝယ်ယူပါ။ 🔥 DDoS ကာကွယ်မှု၊ VPS VDS ဆာဗာများပါရှိသော ယုံကြည်စိတ်ချရသော ဝဘ်ဆိုက် hosting ကို ဝယ်ယူပါ | ProHoster