မင်္ဂလာပါ! မကြာသေးမီက၊ Docker ပုံများတည်ဆောက်ခြင်းနှင့် Kubernetes တွင် ဖြန့်ကျက်ခြင်းအတွက် အလန်းစား အော်တိုမက်ထစ်ကိရိယာများစွာကို ဖြန့်ချိခဲ့သည်။ ဤကိစ္စနှင့် ပတ်သက်၍ ကျွန်ုပ်သည် GitLab ဖြင့် ကစားရန် ဆုံးဖြတ်ခဲ့ပြီး ၎င်း၏ စွမ်းဆောင်ရည်များကို သေချာလေ့လာပြီး ပိုက်လိုင်းကို ထူထောင်ရန် ဆုံးဖြတ်ခဲ့သည်။

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

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

ဆောင်းပါးတွင် ဤကဲ့သို့သော ကိရိယာများကို ဆွေးနွေးပါမည်။
ဟူဂို, qbec, ကာနီကို, git-crypt и GitLab CI တက်ကြွသောပတ်ဝန်းကျင်များဖန်တီးမှုနှင့်အတူ။

အကြောင်းအရာ

1. Hugo နှင့်တွေ့ဆုံပါ။
2. Dockerfile ကိုပြင်ဆင်ခြင်း။
3. ကာနီကိုအကြောင်း သိလာရတယ်။
4. qbec အကြောင်းသိလာခြင်း။
5. Kubernetes-executor ဖြင့် Gitlab-runner ကိုကြိုးစားနေပါသည်။
6. qbec ဖြင့် Helm ဇယားများကို ဖြန့်ကျက်ခြင်း။
7. git-crypt ကို မိတ်ဆက်ခြင်း။
8. ကိရိယာပုံးပုံ ဖန်တီးခြင်း။
9. ကျွန်ုပ်တို့၏ ပထမဆုံး ပိုက်လိုင်းနှင့် တဂ်များဖြင့် ပုံများ စုစည်းမှု
10. ဖြန့်ကျက် အလိုအလျောက်စနစ်
11. အရေးပေး တွန်းအားပေး လုပ်တဲ့ ပရိသတ်
12. တက်ကြွသောပတ်ဝန်းကျင်များ
13. အက်ပ်များကို ပြန်လည်သုံးသပ်ပါ။

1. Hugo ကို သိလာခြင်း

ကျွန်ုပ်တို့၏ပရောဂျက်၏ဥပမာတစ်ခုအနေဖြင့်၊ Hugo တွင်တည်ဆောက်ထားသောစာရွက်စာတမ်းထုတ်ဝေခြင်းဆိုက်ကိုဖန်တီးရန်ကြိုးစားပါမည်။ Hugo သည် static content generator တစ်ခုဖြစ်သည်။

static generator နဲ့ မရင်းနှီးတဲ့သူတွေအတွက်၊ အဲဒါတွေအကြောင်း နည်းနည်းပြောပြမယ်။ သမားရိုးကျ ဒေတာဘေ့စ်တစ်ခုနှင့် အချို့သော PHP ပါသည့် သမားရိုးကျ ဝဘ်ဆိုဒ်အင်ဂျင်များနှင့် မတူဘဲ၊ အသုံးပြုသူတစ်ဦးမှ တောင်းဆိုသောအခါတွင် စာမျက်နှာများ ပျံဝဲကာ ထုတ်ပေးသည့် static ဂျင်နရေတာများသည် အနည်းငယ်ကွဲပြားစွာ ဒီဇိုင်းထုတ်ထားသည်။ ၎င်းတို့သည် သင့်အား Markdown markup နှင့် theme templates တွင် ဖိုင်အစုံအလင်ဖြင့် အရင်းအမြစ်များကို ယူခွင့်ပြုပြီးနောက် ၎င်းတို့ကို ပြီးပြည့်စုံသော ဝဘ်ဆိုက်တစ်ခုအဖြစ် စုစည်းနိုင်သည်။

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

Hugo ကို စက်တွင်းတွင် ထည့်သွင်းနိုင်ပြီး စမ်းသုံးကြည့်နိုင်သည်-

ဆိုက်အသစ်တစ်ခုကို စတင်နေသည်-

hugo new site docs.example.org

တစ်ချိန်တည်းမှာပင် git repository သည်-

cd docs.example.org
git init

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

ဆောင်ပုဒ်အတွက် ကျွန်ုပ်တို့ အသုံးပြုပါမည်။ သင်ကြားကျွန်ုပ်၏အမြင်အရ၊ စာတမ်းပြုစုသည့်ဆိုဒ်အတွက် လုံးဝသင့်လျော်ပါသည်။

ကျွန်ုပ်တို့၏ပရောဂျက်သိုလှောင်ခန်းတွင် ဆောင်ပုဒ်ဖိုင်များကို သိမ်းဆည်းရန်မလိုအပ်ကြောင်းကို အထူးဂရုပြုလိုပါသည်၊ ၎င်းအစား ၎င်းကို ရိုးရိုးရှင်းရှင်းဖြင့် ချိတ်ဆက်နိုင်သည် git submodule:

git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn

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

config ကိုပြင်ကြရအောင် config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "My Docs Site"
theme = "learn"

ဤအဆင့်တွင် သင်လုပ်ဆောင်နိုင်သည်-

hugo server

လိပ်စာမှာ http://localhost:1313/ ကျွန်ုပ်တို့၏အသစ်ဖန်တီးထားသောဝဘ်ဆိုဒ်ကိုစစ်ဆေးပါ၊ လမ်းညွှန်တွင်ပြုလုပ်ထားသောပြောင်းလဲမှုများအားလုံး browser ရှိဖွင့်ထားသောစာမျက်နှာကိုအလိုအလျောက် update လုပ်ပါ၊ အလွန်အဆင်ပြေပါသည်။

မျက်နှာဖုံးစာမျက်နှာကို ဖန်တီးကြည့်ရအောင် အကြောင်းအရာ/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

အသစ်ဖန်တီးထားသော စာမျက်နှာ၏ ဖန်သားပြင်ဓာတ်ပုံ

ဆိုက်တစ်ခုဖန်တီးရန်၊ ပြေးလိုက်ရုံဖြင့်-

hugo

လမ်းညွှန်အကြောင်းအရာများ အများသူငှာ/ သင်၏ website ဖြစ်လိမ့်မည်။
ဟုတ်တယ်၊ စကားမစပ်၊ အဲဒါကို ချက်ချင်းထည့်လိုက်ရအောင် .gitignore:

echo /public > .gitignore

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

git add .
git commit -m "New site created"

2. Dockerfile ကိုပြင်ဆင်ခြင်း။

ကျွန်ုပ်တို့၏ repository ၏ဖွဲ့စည်းပုံကိုသတ်မှတ်ရန်အချိန်ရောက်ပြီ။ ကျွန်ုပ်သည် အများအားဖြင့်၊

.
├── deploy
│   ├── app1
│   └── app2
└── dockerfiles
    ├── image1
    └── image2

• dockerfiles/ — Dockerfiles ပါရှိသော လမ်းညွှန်များနှင့် ကျွန်ုပ်တို့၏ Docker ပုံများကို တည်ဆောက်ရန်အတွက် လိုအပ်သော အရာအားလုံး ပါဝင်ပါသည်။
• ဖြန့်ကျက်/ — ကျွန်ုပ်တို့၏ အပလီကေးရှင်းများကို Kubernetes သို့ အသုံးချရန်အတွက် လမ်းညွှန်များ ပါရှိသည်။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် လမ်းကြောင်းတစ်လျှောက်တွင် ကျွန်ုပ်တို့၏ ပထမဆုံး Dockerfile ကို ဖန်တီးပါမည်။ dockerfiles/website/Dockerfile

FROM alpine:3.11 as builder
ARG HUGO_VERSION=0.62.0
RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin
ADD . /src
RUN hugo -s /src

FROM alpine:3.11
RUN apk add --no-cache darkhttpd
COPY --from=builder /src/public /var/www
ENTRYPOINT [ "/usr/bin/darkhttpd" ]
CMD [ "/var/www" ]

သင်တွေ့မြင်ရသည့်အတိုင်း Dockerfile တွင် နှစ်ခုပါရှိသည်။ FROM မှဤအခွင့်အရေးဟုခေါ်သည်။ multi-stage တည်ဆောက်မှု နှင့် နောက်ဆုံး docker ပုံမှ မလိုအပ်သောအရာအားလုံးကို ဖယ်ထုတ်နိုင်စေပါသည်။
ထို့ကြောင့် နောက်ဆုံးပုံတွင်သာ ပါဝင်မည်ဖြစ်သည်။ darkhttpd (ပေါ့ပါးသော HTTP ဆာဗာ) နှင့် အများသူငှာ/ — ကျွန်ုပ်တို့၏ တည်ငြိမ်စွာ ထုတ်လုပ်ထားသော ဝဘ်ဆိုက်၏ အကြောင်းအရာ။

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

git add dockerfiles/website
git commit -m "Add Dockerfile for website"

3. kaniko သိလာခြင်း။

docker image builder တစ်ယောက်အနေနဲ့ ကျွန်တော်သုံးဖို့ ဆုံးဖြတ်လိုက်တယ်။ ကာနီကို၎င်း၏လုပ်ဆောင်ချက်သည် docker daemon မလိုအပ်သောကြောင့်၊ ၎င်းကိုယ်တိုင်တည်ဆောက်မှုကို မည်သည့်စက်တွင်မဆို လုပ်ဆောင်နိုင်ပြီး cache ကို registry တွင် တိုက်ရိုက်သိမ်းဆည်းနိုင်သောကြောင့်၊ ပြည့်စုံသောအမြဲတမ်းသိုလှောင်မှုတစ်ခုရှိရန် လိုအပ်မှုကို ဖယ်ရှားပေးပါသည်။

ပုံတည်ဆောက်ရန်၊ ကွန်တိန်နာကို run လိုက်ပါ။ kaniko စီမံအုပ်ချုပ်သူ ၎င်းကို လက်ရှိတည်ဆောက်မှုအကြောင်းအရာကို ကျော်ဖြတ်ပါ၊ ၎င်းကို docker မှတစ်ဆင့် စက်တွင်း၌လည်း လုပ်ဆောင်နိုင်သည်-

docker run -ti --rm 
  -v $PWD:/workspace 
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro 
  gcr.io/kaniko-project/executor:v0.15.0 
  --cache 
  --dockerfile=dockerfiles/website/Dockerfile 
  --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1

ဘယ်မှာ registry.gitlab.com/kvaps/docs.example.org/website — သင်၏ docker ပုံ၏အမည်၊ တည်ဆောက်ပြီးနောက်၊ ၎င်းသည် docker မှတ်ပုံတင်ခြင်းသို့ အလိုအလျောက်စတင်မည်ဖြစ်သည်။

parameter သည် -- ကက်ရှ် docker registry တွင် ကက်ရှ်အလွှာများကို သင့်အား ခွင့်ပြုသည်၊ ဥပမာပေးထားသည့်အတွက်၊ ၎င်းတို့ကို သိမ်းဆည်းမည်ဖြစ်သည်။ registry.gitlab.com/kvaps/docs.example.org/website/cacheသို့သော် သင်သည် ကန့်သတ်ဘောင်ကို အသုံးပြု၍ အခြားလမ်းကြောင်းကို သတ်မှတ်နိုင်သည်။ --cache-repo.

docker-registry ၏ဖန်သားပြင်ဓာတ်ပုံ

4. qbec ကို သိလာခြင်း

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

ကွဲပြားသောဘောင်များရှိသည့် အစုအဝေးများစွာတွင် အက်ပ်လီကေးရှင်းတစ်ခုကို အသုံးချရန် လိုအပ်ပြီး Git တွင် ၎င်းတို့ကို ရှင်းရှင်းလင်းလင်း ဖော်ပြလိုသည့်ကိစ္စများတွင် ၎င်းသည် အထူးသဖြင့် မှန်နိုင်သည်။

Qbec သည် သင့်အား လိုအပ်သော ကန့်သတ်ဘောင်များကိုဖြတ်ကာ ၎င်းတို့အား အမျိုးမျိုးသော ဗီဇပြောင်းလဲမှုများကို အသုံးချနိုင်သည် အပါအဝင် ပုံမှန် manifests များအတိုင်း လုပ်ဆောင်ခြင်းဖြင့် Helm ဇယားများကို တင်ဆက်နိုင်စေပြီး၊ ၎င်းသည် လိုအပ်ချက်များကို ဖယ်ရှားနိုင်စေပါသည်။ ChartMuseum ကိုသုံးပါ။ ဆိုလိုသည်မှာ၊ ၎င်းတို့ပိုင်ဆိုင်သည့် git မှဇယားကွက်များကို သင်သိမ်းဆည်းပြီး တိုက်ရိုက်တင်ဆက်နိုင်သည်။

စောစောကပြောခဲ့သလိုပဲ၊ ဖြန့်ကျက်မှုအားလုံးကို လမ်းညွှန်ထဲမှာ သိမ်းထားမယ်။ ဖြန့်ကျက်/:

mkdir deploy
cd deploy

ကျွန်ုပ်တို့၏ပထမဆုံးလျှောက်လွှာကို စတင်ကြပါစို့။

qbec init website
cd website

ယခုကျွန်ုပ်တို့၏ application ၏ဖွဲ့စည်းပုံသည်ဤကဲ့သို့ဖြစ်သည်-

.
├── components
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
└── qbec.yaml

ဖိုင်ကိုကြည့်ရအောင် qbec.yaml:

apiVersion: qbec.io/v1alpha1
kind: App
metadata:
  name: website
spec:
  environments:
    default:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443
  vars: {}

ဒီနေရာမှာ ကျွန်တော်တို့ အဓိက စိတ်ဝင်စားပါတယ်။ spec.ပတ်ဝန်းကျင်များ၊ qbec သည် ကျွန်ုပ်တို့အတွက် ပုံသေပတ်ဝန်းကျင်တစ်ခုကို ဖန်တီးထားပြီး ဆာဗာလိပ်စာအပြင် ကျွန်ုပ်တို့၏လက်ရှိ kubeconfig မှ namespace ကိုလည်း ယူထားသည်။
အခု တပ်ဖြန့်လိုက်တာ ပျက်ကွက် ပတ်ဝန်းကျင်၊ qbec သည် သတ်မှတ်ထားသော Kubernetes အစုအဝေးသို့သာ အမြဲတမ်း ဖြန့်ကျက်ထားမည်ဖြစ်ပြီး၊ ဆိုလိုသည်မှာ၊ ဖြန့်ကျက်လုပ်ဆောင်ရန်အတွက် သင်သည် ဆက်စပ်အကြောင်းအရာများနှင့် namespaces များကြားတွင် ပြောင်းလဲရန် မလိုအပ်တော့ပါ။
လိုအပ်ပါက သင်သည် ဤဖိုင်ရှိ ဆက်တင်များကို အမြဲတမ်း အပ်ဒိတ်လုပ်နိုင်ပါသည်။

သင့်ပတ်ဝန်းကျင်အားလုံးကို ဖော်ပြထားပါသည်။ qbec.yaml, ဖိုင်ထဲမှာ params.libsonnetသူတို့အတွက် parameters တွေကို ဘယ်မှာရရမယ်ဆိုတာ ပြောထားတယ်။

နောက်တစ်ခုက လမ်းညွှန်နှစ်ခုကို တွေ့ရတယ်။

• အစိတ်အပိုင်းများ/ — ကျွန်ုပ်တို့၏ အပလီကေးရှင်းအတွက် ဖော်ပြချက်အားလုံးကို ဤနေရာတွင် သိမ်းဆည်းထားမည်ဖြစ်ပြီး၊ ၎င်းတို့ကို jsonnet နှင့် ပုံမှန် yaml ဖိုင်များတွင် ဖော်ပြနိုင်သည်။
• ပတ်ဝန်းကျင်/ — ဤနေရာတွင် ကျွန်ုပ်တို့၏ပတ်ဝန်းကျင်အတွက် ပြောင်းလဲနိုင်သော (ပါရာမီတာများ) အားလုံးကို ဖော်ပြပါမည်။

မူရင်းအားဖြင့် ကျွန်ုပ်တို့တွင် ဖိုင်နှစ်ခုရှိသည်-

• ပတ်ဝန်းကျင်များ/base.libsonnet - ၎င်းတွင် ပတ်ဝန်းကျင်အားလုံးအတွက် ဘုံဘောင်များပါရှိသည်။
• environments/default.libsonnet — ပတ်ဝန်းကျင်အတွက် လွှမ်းမိုးထားသော ကန့်သတ်ချက်များ ပါရှိသည်။ ပျက်ကွက်

ဖွင့်ကြည့်ရအောင် ပတ်ဝန်းကျင်များ/base.libsonnet ပြီးလျှင် ကျွန်ုပ်တို့၏ပထမအစိတ်အပိုင်းအတွက် ကန့်သတ်ချက်များထည့်ပါ။

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1',
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

ကျွန်ုပ်တို့၏ ပထမဆုံးအစိတ်အပိုင်းကိုလည်း ဖန်တီးကြပါစို့ အစိတ်အပိုင်းများ/website.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.website;

[
  {
    apiVersion: 'apps/v1',
    kind: 'Deployment',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      replicas: params.replicas,
      selector: {
        matchLabels: {
          app: params.name,
        },
      },
      template: {
        metadata: {
          labels: { app: params.name },
        },
        spec: {
          containers: [
            {
              name: 'darkhttpd',
              image: params.image,
              ports: [
                {
                  containerPort: params.containerPort,
                },
              ],
            },
          ],
          nodeSelector: params.nodeSelector,
          tolerations: params.tolerations,
          imagePullSecrets: [{ name: 'regsecret' }],
        },
      },
    },
  },
  {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      selector: {
        app: params.name,
      },
      ports: [
        {
          port: params.servicePort,
          targetPort: params.containerPort,
        },
      ],
    },
  },
  {
    apiVersion: 'extensions/v1beta1',
    kind: 'Ingress',
    metadata: {
      annotations: {
        'kubernetes.io/ingress.class': params.ingressClass,
      },
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      rules: [
        {
          host: params.domain,
          http: {
            paths: [
              {
                backend: {
                  serviceName: params.name,
                  servicePort: params.servicePort,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

ဤဖိုင်တွင် Kubernetes entities သုံးခုကို တစ်ပြိုင်နက် ဖော်ပြခဲ့ပြီး၊ ၎င်းတို့မှာ- ဖြန့်ကျက်, ဝန်ဆောင်မှု и Ingress. ကျွန်ုပ်တို့အလိုရှိပါက ၎င်းတို့ကို မတူညီသော အစိတ်အပိုင်းများအဖြစ် ထည့်သွင်းနိုင်သော်လည်း ဤအဆင့်တွင် ကျွန်ုပ်တို့အတွက် လုံလောက်မည်ဖြစ်သည်။

syntax jsonnet ပုံမှန် json နှင့် အလွန်ဆင်တူသည်၊ နိယာမအားဖြင့်၊ ပုံမှန် json သည် တရားဝင် jsonnet ဖြစ်သည်၊ ထို့ကြောင့် အစပိုင်းတွင် သင်ကဲ့သို့ အွန်လိုင်းဝန်ဆောင်မှုများကို အသုံးပြုရန် ပိုမိုလွယ်ကူပေမည်။ yaml2json သင်၏ပုံမှန် yaml ကို json သို့ပြောင်းရန် သို့မဟုတ် သင့်အစိတ်အပိုင်းများတွင် ကိန်းရှင်များမပါဝင်ပါက ၎င်းတို့ကို ပုံမှန် yaml ပုံစံဖြင့် ဖော်ပြနိုင်ပါသည်။

အတူအလုပ်လုပ်တဲ့အခါ jsonnet သင်၏တည်းဖြတ်သူအတွက် ပလပ်အင်တစ်ခု ထည့်သွင်းရန် အထူးအကြံပြုလိုပါသည်။

ဥပမာ၊ vim အတွက် plugin တစ်ခုရှိတယ်။ vim-jsonnetsyntax highlighting ကိုဖွင့်ပြီး အလိုအလျောက် execute လုပ်သည်။ jsonnet fmt သင်သိမ်းဆည်းသည့်အချိန်တိုင်း (jsonnet ထည့်သွင်းရန် လိုအပ်သည်)။

အားလုံးအဆင်သင့်ဖြစ်ပါပြီ၊ ယခု ကျွန်ုပ်တို့ စတင်အသုံးပြုနိုင်ပါပြီ-

ငါတို့ဘာတွေရလဲဆိုတာကြည့်ရအောင်၊

qbec show default

အထွက်တွင်၊ ပုံသေအစုအဝေးသို့ အသုံးချမည့် rendered yaml manifests ကို သင်တွေ့ရပါမည်။

ကောင်းပြီ၊ ယခုလျှောက်ထားပါ-

qbec apply default

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

ကျွန်ုပ်တို့၏ အပလီကေးရှင်းသည် အဆင်သင့်ဖြစ်ပြီး အသုံးပြုနိုင်ပါပြီ။

အပြောင်းအလဲများပြုလုပ်ပါက၊ သင်အမြဲလုပ်နိုင်သည်-

qbec diff default

ဤပြောင်းလဲမှုများသည် လက်ရှိအသုံးပြုမှုကို မည်သို့အကျိုးသက်ရောက်မည်ကို ကြည့်ရှုရန်

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

cd ../..
git add deploy/website
git commit -m "Add deploy for website"

5. Kubernetes-executor ဖြင့် Gitlab-runner ကို စမ်းသုံးကြည့်ပါ။

မကြာသေးခင်အထိတော့ ပုံမှန်ပဲသုံးတယ်။ gitlab-အပြေးသမား shell သို့မဟုတ် docker-executor ပါရှိသော ကြိုတင်ပြင်ဆင်ထားသောစက် (LXC container) ပေါ်တွင်။ ကနဦးတွင်၊ ကျွန်ုပ်တို့တွင် ကျွန်ုပ်တို့၏ gitlab တွင် ကမ္ဘာအနှံ့သတ်မှတ်ထားသော ထိုကဲ့သို့သောအပြေးသမားများစွာရှိသည်။ ပရောဂျက်အားလုံးအတွက် docker ပုံများကို စုဆောင်းခဲ့ကြသည်။

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

ကံကောင်းထောက်မစွာ၊ ဤသည်မှာ ပြဿနာမဟုတ်ပါ၊ ယခုကတည်းက ကျွန်ုပ်တို့ ဖြန့်ကျက်လိုက်ပါမည်။ gitlab-အပြေးသမား Kubernetes ရှိ ကျွန်ုပ်တို့၏ ပရောဂျက်၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် တိုက်ရိုက်။

Gitlab သည် Kubernetes သို့ gitlab-runner ကိုအသုံးပြုရန်အတွက် အဆင်သင့်လုပ်ထားသည့် ဦးထုပ်ဇယားကို ပံ့ပိုးပေးပါသည်။ ဒါကြောင့် သင်လုပ်ရမှာက သိအောင်လုပ်ပါ။ မှတ်ပုံတင်ခြင်းလက္ခဏာသက်သေ ကျွန်ုပ်တို့၏ပရောဂျက်အတွက် ဆက်တင်များ -> CI / CD -> ပြေးသူများ ပဲ့စင်သို့ လွှဲ၍၊

helm repo add gitlab https://charts.gitlab.io

helm install gitlab-runner 
  --set gitlabUrl=https://gitlab.com 
  --set runnerRegistrationToken=yga8y-jdCusVDn_t4Wxc 
  --set rbac.create=true 
  gitlab/gitlab-runner

ဘယ်မှာ:

• https://gitlab.com — သင့် Gitlab ဆာဗာ၏လိပ်စာ။
• yga8y-jdCusVDn_t4Wxc - သင့်ပရောဂျက်အတွက် မှတ်ပုံတင်အမှတ်အသား။
• rbac.create=အမှန် - kubernetes-executor ကိုအသုံးပြု၍ ကျွန်ုပ်တို့၏တာဝန်များကိုလုပ်ဆောင်ရန်အတွက် pods များဖန်တီးနိုင်စေရန်အတွက် လိုအပ်သောအခွင့်ထူးများကို အပြေးသမားအား ပံ့ပိုးပေးပါသည်။

အားလုံးမှန်ကန်စွာလုပ်ဆောင်ပါက၊ ကဏ္ဍတွင်စာရင်းသွင်းထားသောအပြေးသမားကိုတွေ့ရပါမည်။ အပြေးသမားသင့်ပရောဂျက်ဆက်တင်များတွင်။

ထည့်ထားသော အပြေးသမား၏ ဖန်သားပြင်ဓာတ်ပုံ

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

6. QBEC ဖြင့် Helm ဇယားများကို အသုံးချပါ။

စဉ်းစားဆုံးဖြတ်ပြီးကတည်းက gitlab-အပြေးသမား ကျွန်ုပ်တို့၏ပရောဂျက်၏တစ်စိတ်တစ်ပိုင်း၊ ကျွန်ုပ်တို့၏ Git repository တွင် ၎င်းကိုဖော်ပြရန်အချိန်ရောက်ပြီ။

၎င်းကို သီးခြားအစိတ်အပိုင်းတစ်ခုအဖြစ် ကျွန်ုပ်တို့ဖော်ပြနိုင်သည်။ က်ဘ်ဆိုက်ဒါပေမယ့် အနာဂတ်မှာ မတူညီတဲ့ ကော်ပီတွေကို ဖြန့်ကျက်ဖို့ စီစဉ်နေပါတယ်။ က်ဘ်ဆိုက် အလွန်မကြာခဏ, မတူပါ။ gitlab-အပြေးသမားKubernetes အစုအဝေးတစ်ခုလျှင် တစ်ကြိမ်သာ အသုံးပြုပါမည်။ ထို့ကြောင့် ၎င်းအတွက် သီးခြားအက်ပ်တစ်ခုကို စတင်ကြပါစို့။

cd deploy
qbec init gitlab-runner
cd gitlab-runner

ယခုတစ်ကြိမ်တွင် Kubernetes entities များကို ကိုယ်တိုင်ဖော်ပြမည်မဟုတ်သော်လည်း အဆင်သင့်လုပ်ထားသော Helm ဇယားကို ယူပါမည်။ qbec ၏အားသာချက်များထဲမှတစ်ခုမှာ Helm ဇယားများကို Git repository မှတိုက်ရိုက်တင်ဆက်နိုင်ခြင်းဖြစ်သည်။

git submodule သုံးပြီး ချိတ်ဆက်ကြည့်ရအောင်။

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner

အခုလမ်းညွှန် ရောင်းချသူ/gitlab-runner ကျွန်ုပ်တို့တွင် gitlab-runner အတွက်ဇယားတစ်ခုပါရှိသည်။

အလားတူနည်းအားဖြင့် သင်သည် အခြားသိုလှောင်ရာနေရာများကို ချိတ်ဆက်နိုင်သည်၊ ဥပမာအားဖြင့်၊ သိုလှောင်မှုတစ်ခုလုံးကို တရားဝင်ဇယားများဖြင့် ချိတ်ဆက်နိုင်သည်။ https://github.com/helm/charts

အစိတ်အပိုင်းကိုဖော်ပြကြပါစို့ အစိတ်အပိုင်းများ/gitlab-runner.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.gitlabRunner;

std.native('expandHelmTemplate')(
  '../vendor/gitlab-runner',
  params.values,
  {
    nameTemplate: params.name,
    namespace: env.namespace,
    thisFile: std.thisFile,
    verbose: true,
  }
)

ပထမဆုံး ဆင်ခြေပေးလိုက်တယ်။ တိုးချဲ့ HelmTemplate ဒါဆို ဇယားကို ဖြတ်သွားမယ်။ params.values ​​များပတ်၀န်းကျင် ဘောင်များမှ ကျွန်ုပ်တို့ယူသော၊ ထို့နောက် အရာဝတ္ထုနှင့်အတူ ပါလာသည်။

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

ယခု ကျွန်ုပ်တို့၏ အစိတ်အပိုင်းအတွက် ဘောင်များကို ဖော်ပြကြပါစို့ ပတ်ဝန်းကျင်များ/base.libsonnet:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
      },
    },
  },
}

ကျေးဇူးပြု. သတိပြုပါ runnerRegistrationToken ကျွန်ုပ်တို့သည် ပြင်ပဖိုင်တစ်ခုမှ ယူသည်။ လျှို့ဝှက်ချက်များ/base.libsonnetဖန်တီးလိုက်ရအောင်-

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

အားလုံးအဆင်ပြေလားဆိုတာ စစ်ဆေးကြည့်ရအောင်။

qbec show default

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

helm uninstall gitlab-runner

၎င်းကို qbec မှတဆင့် ဤနည်းအတိုင်း အသုံးချပါ။

qbec apply default

7. git-crypt နိဒါန်း

Git-crypt သင့်သိုလှောင်ရာအတွက် ပွင့်လင်းမြင်သာသော ကုဒ်ဝှက်စနစ်ကို သတ်မှတ်ခွင့်ပြုသည့် ကိရိယာတစ်ခုဖြစ်သည်။

လောလောဆယ်တွင်၊ gitlab-runner အတွက် ကျွန်ုပ်တို့၏လမ်းညွှန်ဖွဲ့စည်းပုံမှာ ဤကဲ့သို့ဖြစ်သည်-

.
├── components
│   ├── gitlab-runner.jsonnet
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
├── qbec.yaml
├── secrets
│   └── base.libsonnet
└── vendor
    └── gitlab-runner (submodule)

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

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

ထို့အပြင်၊ ဤကိစ္စတွင်၊ ဤကဲ့သို့သော အံ့သြဖွယ်ကောင်းသော ကိရိယာအကြောင်း သင့်အား ငါပြောပြနိုင်မည်မဟုတ်ပေ။ git-crypt.

git-crypt လျှို့ဝှက်သမိုင်းတစ်ခုလုံးကို သိမ်းဆည်းနိုင်သည့်အပြင် Git ကိစ္စတွင် ကျွန်ုပ်တို့လုပ်ဆောင်လေ့ရှိသည့်အတိုင်း ပဋိပက္ခများကို နှိုင်းယှဉ်၊ ပေါင်းစည်းကာ ဖြေရှင်းနိုင်စေသည့်အတွက်လည်း အဆင်ပြေပါသည်။

တပ်ဆင်ပြီးနောက်ပထမအချက် git-crypt ကျွန်ုပ်တို့၏သိုလှောင်မှုအတွက် သော့များထုတ်လုပ်ရန် လိုအပ်သည်-

git crypt init

သင့်တွင် PGP သော့တစ်ခုရှိပါက၊ သင်သည် ဤပရောဂျက်အတွက် ပူးပေါင်းလုပ်ဆောင်သူအဖြစ် သင့်ကိုယ်သင် ချက်ချင်းထည့်နိုင်သည်-

git-crypt add-gpg-user [email protected]

ဤနည်းဖြင့် သင်သည် သင်၏ကိုယ်ပိုင်သော့ကို အသုံးပြု၍ ဤသိုလှောင်မှုအား အမြဲတမ်းစာဝှက်နိုင်ပါသည်။

သင့်တွင် PGP သော့မရှိပါက ၎င်းကို မမျှော်လင့်ထားပါက၊ သင်သည် အခြားတစ်ဘက်သို့သွားကာ ပရောဂျက်ကီးကို ထုတ်ယူနိုင်သည်-

git crypt export-key /path/to/keyfile

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

ကျွန်ုပ်တို့၏ ပထမဆုံးလျှို့ဝှက်ချက်ကို သတ်မှတ်ရန် အချိန်ရောက်ပြီ။
ကျွန်ုပ်တို့သည် လမ်းညွှန်တွင်ရှိနေဆဲဖြစ်ကြောင်း သတိပေးပါရစေ deploy/gitlab-runner/ကျွန်ုပ်တို့တွင် လမ်းညွှန်တစ်ခုရှိသည်။ လျှို့ဝှက်ချက်များ/ဖိုင်များအားလုံးကို ကုဒ်ဝှက်ကြပါစို့၊ ဤအတွက် ကျွန်ုပ်တို့သည် ဖိုင်တစ်ခုကို ဖန်တီးပါမည်။ လျှို့ဝှက်ချက်များ/.gitattributes အောက်ပါအကြောင်းအရာနှင့်အတူ

* filter=git-crypt diff=git-crypt
.gitattributes !filter !diff

အကြောင်းအရာမှ မြင်တွေ့နိုင်သကဲ့သို့၊ ဖိုင်အားလုံးကို ဖုံးအုပ်ထားသည်။ * ဖြတ်သန်းမောင်းနှင်မည်ဖြစ်သည်။ git-cryptအများစုမှလွဲ၍ .gitattributes

၎င်းကို run ခြင်းဖြင့် ကျွန်ုပ်တို့ စစ်ဆေးနိုင်သည်-

git crypt status -e

အထွက်သည် ကုဒ်ဝှက်ခြင်းကို ဖွင့်ထားသည့် သိုလှောင်ခန်းရှိ ဖိုင်အားလုံး၏ စာရင်းတစ်ခု ဖြစ်လိမ့်မည်။

ဒါပါပဲ၊ ယခု ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုံခြုံစွာ ကတိပြုနိုင်ပါပြီ-

cd ../..
git add .
git commit -m "Add deploy for gitlab-runner"

repository ကိုပိတ်ဆို့ရန်၊ run လိုက်ရုံဖြင့်-

git crypt lock

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

git crypt unlock

8. ကိရိယာပုံးပုံ ဖန်တီးပါ။

ကိရိယာပုံးပုံသည် ကျွန်ုပ်တို့၏ပရောဂျက်ကို အသုံးပြုရန် ကျွန်ုပ်တို့အသုံးပြုမည့် ကိရိယာအားလုံးပါသည့် ရုပ်ပုံဖြစ်သည်။ ပုံမှန်အသုံးပြုမှုလုပ်ဆောင်ရန် Gitlab အပြေးသမားက ၎င်းကိုအသုံးပြုမည်ဖြစ်သည်။

အရာအားလုံးက ရိုးရှင်းပါတယ်၊ အသစ်တစ်ခုကို ဖန်တီးလိုက်ကြရအောင် dockerfiles/toolbox/Dockerfile အောက်ပါအကြောင်းအရာနှင့်အတူ

FROM alpine:3.11

RUN apk add --no-cache git git-crypt

RUN QBEC_VER=0.10.3 
 && wget -O- https://github.com/splunk/qbec/releases/download/v${QBEC_VER}/qbec-linux-amd64.tar.gz 
     | tar -C /tmp -xzf - 
 && mv /tmp/qbec /tmp/jsonnet-qbec /usr/local/bin/

RUN KUBECTL_VER=1.17.0 
 && wget -O /usr/local/bin/kubectl 
      https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VER}/bin/linux/amd64/kubectl 
 && chmod +x /usr/local/bin/kubectl

RUN HELM_VER=3.0.2 
 && wget -O- https://get.helm.sh/helm-v${HELM_VER}-linux-amd64.tar.gz 
     | tar -C /tmp -zxf - 
 && mv /tmp/linux-amd64/helm /usr/local/bin/helm

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

ထို့အပြင် Kubernetes နှင့် ဆက်သွယ်ပြီး ၎င်းကို အသုံးချနိုင်ရန်၊ gitlab-runner မှ ထုတ်လုပ်သည့် pods များအတွက် အခန်းကဏ္ဍကို သတ်မှတ်ရန် လိုအပ်ပါသည်။

ဒါကိုလုပ်ဖို့ gitlab-runner နဲ့ directory ကိုသွားကြည့်ရအောင်။

cd deploy/gitlab-runner

အစိတ်အပိုင်းအသစ်တစ်ခုထည့်ပါ။ အစိတ်အပိုင်းများ/rbac.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.rbac;

[
  {
    apiVersion: 'v1',
    kind: 'ServiceAccount',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'Role',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    rules: [
      {
        apiGroups: [
          '*',
        ],
        resources: [
          '*',
        ],
        verbs: [
          '*',
        ],
      },
    ],
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'RoleBinding',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    roleRef: {
      apiGroup: 'rbac.authorization.k8s.io',
      kind: 'Role',
      name: params.name,
    },
    subjects: [
      {
        kind: 'ServiceAccount',
        name: params.name,
        namespace: env.namespace,
      },
    ],
  },
]

ကန့်သတ်ချက်အသစ်များကိုလည်း ဖော်ပြပါမည်။ ပတ်ဝန်းကျင်များ/base.libsonnet၊ ယခုဤပုံသည်-

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
        runners: {
          serviceAccountName: $.components.rbac.name,
          image: 'registry.gitlab.com/kvaps/docs.example.org/toolbox:v0.0.1',
        },
      },
    },
    rbac: {
      name: 'gitlab-runner-deploy',
    },
  },
}

ကျေးဇူးပြု. သတိပြုပါ $.components.rbac.name ရည်ညွှန်းသည်။ နာမတျောကို အစိတ်အပိုင်းအတွက် rbac

ဘာတွေပြောင်းလဲသွားလဲ စစ်ဆေးကြည့်ရအောင်။

qbec diff default

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို Kubernetes တွင်အသုံးပြုပါ-

qbec apply default

ထို့အပြင်၊ ကျွန်ုပ်တို့၏အပြောင်းအလဲများကို git တွင်ထည့်သွင်းရန်မမေ့ပါနှင့်။

cd ../..
git add dockerfiles/toolbox
git commit -m "Add Dockerfile for toolbox"
git add deploy/gitlab-runner
git commit -m "Configure gitlab-runner to use toolbox"

9. ကျွန်ုပ်တို့၏ ပထမဆုံး ပိုက်လိုင်းနှင့် tags များဖြင့် ပုံများ တပ်ဆင်ခြင်း။

ပရောဂျက်ရဲ့ အမြစ်မှာ ငါတို့ ဖန်တီးမယ်။ .gitlab-ci.yml အောက်ပါအကြောင်းအရာနှင့်အတူ

.build_docker_image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug-v0.15.0
    entrypoint: [""]
  before_script:
    - echo "{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}" > /kaniko/.docker/config.json

build_toolbox:
  extends: .build_docker_image
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR/dockerfiles/toolbox --dockerfile $CI_PROJECT_DIR/dockerfiles/toolbox/Dockerfile --destination $CI_REGISTRY_IMAGE/toolbox:$CI_COMMIT_TAG
  only:
    refs:
      - tags

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_TAG
  only:
    refs:
      - tags

ကျွန်ုပ်တို့အသုံးပြုသည်ကို သတိပြုပါ။ GIT_SUBMODULE_STRATEGY- ပုံမှန် သင်မလုပ်ဆောင်မီတွင် submodule များကို အထူးတလည်စတင်ရန်လိုအပ်သည့် ထိုအလုပ်များအတွက်။

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

git add .gitlab-ci.yml
git commit -m "Automate docker build"

ဒါကို ဗားရှင်းအဖြစ် လုံခြုံစွာ ခေါ်နိုင်မယ်လို့ ထင်ပါတယ်။ v0.0.1 နှင့် tag ကိုထည့်ပါ

git tag v0.0.1

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

လုပ်လိုက်ကြရအောင် git push --tagsကျွန်ုပ်တို့၏ ပထမဆုံး ပိုက်လိုင်းကို ကြည့်ကြပါစို့။

ပထမပိုက်လိုင်း၏ ဖန်သားပြင်ဓာတ်ပုံ

tags များဖြင့် တပ်ဆင်ခြင်းသည် docker ပုံများကို တည်ဆောက်ရန်အတွက် သင့်လျော်သော်လည်း Kubernetes အက်ပလီကေးရှင်းကို အသုံးချခြင်းအတွက် မသင့်တော်ကြောင်းကို သင့်အာရုံစိုက်သင့်ပါသည်။ တဂ်အသစ်များကို ကတိကဝတ်ဟောင်းများတွင် တာဝန်ပေးအပ်နိုင်သောကြောင့်၊ ဤအခြေအနေတွင်၊ ၎င်းတို့အတွက် ပိုက်လိုင်းကို အစပြုခြင်းဖြင့် ဗားရှင်းဟောင်းကို ဖြန့်ကျက်ခြင်းသို့ ဦးတည်သွားစေမည်ဖြစ်သည်။

ဤပြဿနာကိုဖြေရှင်းရန်၊ အများအားဖြင့် docker ပုံများတည်ဆောက်ခြင်းကို tags များနှင့်ချိတ်ဆက်ထားပြီး application ကို ဌာနခွဲတစ်ခုသို့ အသုံးချခြင်း မာစတာစုဆောင်းထားသော ပုံများ၏ ဗားရှင်းများတွင် hardcode လုပ်ထားပါသည်။ ဤသည်မှာ ရိုးရှင်းသော ပြန်ပြောင်းမှုဖြင့် rollback ကို စတင်နိုင်သည် မာစတာ- ကိုင်း၊

10. အလိုအလျောက်ဖြန့်ကျက်မှု

Gitlab-runner သည် ကျွန်ုပ်တို့၏လျှို့ဝှက်ချက်များကို ကုဒ်ဝှက်ရန်အတွက်၊ ကျွန်ုပ်တို့သည် repository key ကို ထုတ်ယူပြီး ကျွန်ုပ်တို့၏ CI ပတ်ဝန်းကျင်တွင် ပြောင်းလဲနိုင်သောကိန်းရှင်များသို့ ထည့်ရန် လိုအပ်ပါမည်-

git crypt export-key /tmp/docs-repo.key
base64 -w0 /tmp/docs-repo.key; echo

ကျွန်ုပ်တို့သည် Gitlab တွင် ရရှိလာသော လိုင်းကို သိမ်းဆည်းပါမည်၊ ၎င်းကိုလုပ်ဆောင်ရန်၊ ကျွန်ုပ်တို့၏ ပရောဂျက်ဆက်တင်များသို့ သွားကြပါစို့။
ဆက်တင်များ -> CI / CD -> Variables

ပြီးတော့ variable အသစ်တစ်ခုကို ဖန်တီးကြည့်ရအောင်။

ပုံစံ
သော့
အဘိုး
protected
မျက်နှာဖုံး
scope

File
GITCRYPT_KEY
<your string>
true (သင်တန်းချိန်အတွင်း တတ်နိုင်သည်။ false)
true
All environments

ထည့်ထားသော variable ၏ ဖန်သားပြင်ဓာတ်ပုံ

ယခုကျွန်ုပ်တို့၏ update ကိုကြပါစို့ .gitlab-ci.yml ၎င်းကိုထည့်သည်-

.deploy_qbec_app:
  stage: deploy
  only:
    refs:
      - master

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes

deploy_website:
  extends: .deploy_qbec_app
  script:
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes

ဤနေရာတွင် qbec အတွက် ရွေးချယ်စရာအသစ်များစွာကို ကျွန်ုပ်တို့ ဖွင့်ထားပါသည်-

• --အချို့/အက်ပ်ကို root လုပ်ပါ။ - တိကျသောအပလီကေးရှင်းတစ်ခု၏လမ်းညွှန်ကိုသင်ဆုံးဖြတ်ရန်ခွင့်ပြုသည်။
• --force:k8s-context __incluster__ - ၎င်းသည် gtilab-runner လုပ်ဆောင်နေသည့် တူညီသောအစုအဝေးတွင် ဖြန့်ကျက်မှု ဖြစ်ပေါ်လာမည်ဟု ပြောထားသည့် မှော်ကိန်းရှင်တစ်ခုဖြစ်သည်။ မဟုတ်ပါက qbec သည် သင့် kubeconfig တွင် သင့်လျော်သော Kubernetes ဆာဗာကို ရှာတွေ့ရန် ကြိုးစားမည်ဖြစ်သောကြောင့် ၎င်းသည် လိုအပ်ပါသည်။
• --စောင့် — ၎င်းဖန်တီးထားသောရင်းမြစ်များသည် Ready state သို့ရောက်ရှိသည်အထိစောင့်ဆိုင်းရန် qbec အား တွန်းအားပေးပြီး အောင်မြင်သော exit-code ဖြင့်ထွက်ပါ။
• -ဟုတ် - အပြန်အလှန်တုံ့ပြန်မှု shell ကိုရိုးရှင်းစွာပိတ်ထားပါ။ သေချာလား? တပ်ဖြန့်သောအခါ။

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

git add .gitlab-ci.yml
git commit -m "Automate deploy"

ပြီးမှ git တွန်း ကျွန်ုပ်တို့၏ အပလီကေးရှင်းများကို မည်သို့အသုံးပြုထားသည်ကို ကျွန်ုပ်တို့ မြင်တွေ့ရပါမည်-

ဒုတိယပိုက်လိုင်း၏ ဖန်သားပြင်ဓာတ်ပုံ

11. ကျွမ်းကျင်ဖို့ တွန်းအားပေးတဲ့ အခါမှာ ပစ္စည်းတွေနဲ့ စုဝေးမှုတွေ၊

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

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

ဒီအလုပ်နှစ်ခုကို ငါတို့မှာ အပ်ဒိတ်လုပ်ကြရအောင် .gitlab-ci.yml:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/
  only:
    refs:
      - master
      - tags

deploy_website:
  extends: .deploy_qbec_app
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

ကျေးဇူးပြု၍ ကျွန်ုပ်တို့တွင် စာတွဲတစ်ခုကို ထည့်ထားသည်။ မာစတာ к ကိုးကား အလုပ်များအတွက် build_website ယခုကျွန်ုပ်တို့အသုံးပြုသည်။ $CI_COMMIT_REF_NAME အစား $CI_COMMIT_TAGဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် Git ရှိ tag များနှင့် ချိတ်ဆက်ထားပြီး ယခု ပိုက်လိုင်းကို အစပြုခဲ့သော commit ဌာနခွဲ၏ အမည်ဖြင့် ပုံတစ်ခုကို တွန်းပို့ပါမည်။ ၎င်းသည် docker-registry တွင် သီးခြားဗားရှင်းတစ်ခုပါသည့် ဝဘ်ဆိုက်တစ်ခု၏ လျှပ်တစ်ပြက်ရိုက်ချက်များကို သိမ်းဆည်းနိုင်စေမည့် tags များနှင့်လည်း လုပ်ဆောင်နိုင်သည်ကို သတိပြုသင့်ပါသည်။

ဆိုက်၏ဗားရှင်းအသစ်အတွက် docker tag ၏အမည်ကို မပြောင်းလဲနိုင်ပါက Kubernetes တွင် အပြောင်းအလဲများကို ဖော်ပြရန် လိုအပ်နေသေးသည်၊ သို့မဟုတ်ပါက ၎င်းသည် အပလီကေးရှင်းကို ပုံအသစ်မှ ပြန်လည်အသုံးချမည်မဟုတ်ပါ၊ ဖြန့်ကျက်မှု ထင်ရှားသည်။

ရွေးချယ်စရာ —vm:ext-str digest=”$DIGEST” qbec အတွက် - သင့်အား jsonnet သို့ ပြင်ပကိန်းရှင်တစ်ခုကို ဖြတ်သန်းခွင့်ပြုသည်။ ကျွန်ုပ်တို့၏ အပလီကေးရှင်းထုတ်ပြီးတိုင်း ၎င်းကို အစုအဝေးတွင် ပြန်လည်အသုံးချစေလိုပါသည်။ ကျွန်ုပ်တို့သည် ပုံ၏ သီးခြားဗားရှင်းတစ်ခုနှင့် ချိတ်ဆက်ထားရန် လိုအပ်ပြီး ပြောင်းလဲသည့်အခါတွင် အသုံးပြုမှုကို အစပျိုးရန် လိုအပ်သောကြောင့် ယခုအခါတွင် မပြောင်းလဲနိုင်သော တဂ်အမည်ကို ကျွန်ုပ်တို့ အသုံးမပြုနိုင်တော့ပါ။

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

ကျွန်ုပ်တို့အတွက် ကန့်သတ်ချက်များကို အပ်ဒိတ်လုပ်ကြပါစို့ deploy/website/environments/base.libsonnet ယခုဤကဲ့သို့မြင်ရလိမ့်မည်-

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website@' + std.extVar('digest'),
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

ပြီးပါပြီ၊ တစ်ခုခုကို ကျူးလွန်လိုက်ပါ။ မာစတာ docker image ၏ တည်ဆောက်မှုကို အစပြုသည်။ က်ဘ်ဆိုက်ပြီးနောက် ၎င်းကို Kubernetes သို့ အသုံးချပါ။

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

git add .
git commit -m "Configure dynamic build"

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

မာစတာအတွက် ပိုက်လိုင်း၏ ဖန်သားပြင်ဓာတ်ပုံ

မူအရ၊ ကျွန်ုပ်တို့သည် gitlab-runner ကို push တစ်ခုစီဖြင့်ပြန်လည်အသုံးချရန်မလိုအပ်ပါ၊ ဟုတ်ပါတယ်၊ ၎င်း၏ဖွဲ့စည်းပုံတွင်ဘာမှမပြောင်းလဲပါက၊ ၎င်းကိုပြင်ကြပါစို့။ .gitlab-ci.yml:

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes
  only:
    changes:
      - deploy/gitlab-runner/**/*

အပြောင်းအလဲများ အပြောင်းအလဲများကို စောင့်ကြည့်နိုင်မည်ဖြစ်သည်။ deploy/gitlab-runner/ တစ်ခုခုရှိမှသာလျှင် ကျွန်ုပ်တို့၏အလုပ်ကို စတင်မည်ဖြစ်သည်။

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

git add .gitlab-ci.yml
git commit -m "Reduce gitlab-runner deploy"

git တွန်း, ဒါပိုကောင်းတယ်:

မွမ်းမံထားသော ပိုက်လိုင်း၏ ဖန်သားပြင်ဓာတ်ပုံ

12. တက်ကြွသောပတ်ဝန်းကျင်များ

ကျွန်ုပ်တို့၏ ပိုက်လိုင်းအား တက်ကြွသောပတ်ဝန်းကျင်များဖြင့် ကွဲပြားအောင်ပြုလုပ်ရန် အချိန်တန်ပြီ။

ပထမဆုံး အလုပ်အပ်ဒိတ်လုပ်ကြည့်ရအောင် build_website ငါတို့ရဲ့ .gitlab-ci.ymlဘလောက်ကို ဖယ်ရှားလိုက်ပါ။ သာGitlab သည် မည်သည့်ဌာနခွဲကိုမဆို ကတိကဝတ်ပြုမှုတွင် ၎င်းကို အစပျိုးရန် တွန်းအားပေးလိမ့်မည်-

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/

ထို့နောက် အလုပ်အပ်ဒိတ်လုပ်ပါ။ deploy_websiteအဲဒီမှာ ဘလောက်တစ်ခုထည့်ပါ။ ပတ်ဝန်းကျင်:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

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

အခု နောက်ထပ် အလုပ်နှစ်ခု ထပ်ထည့်ကြည့်ရအောင်။

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

deploy_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.docs.example.org
    on_stop: stop_review
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  only:
    refs:
    - branches
  except:
    refs:
      - master

stop_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  stage: deploy
  before_script:
    - git clone "$CI_REPOSITORY_URL" master
    - cd master
  script:
    - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  variables:
    GIT_STRATEGY: none
  only:
    refs:
    - branches
  except:
    refs:
      - master
  when: manual

မာစတာမှလွဲ၍ မည်သည့်အကိုင်းအခက်ကိုမဆို တွန်းပို့လိုက်သည်နှင့် ၎င်းတို့ကို ဆိုက်၏ အကြိုကြည့်ရှုမှုဗားရှင်းကို အသုံးချမည်ဖြစ်သည်။

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

ဤတွင်ကျွန်ုပ်တို့လည်းအသုံးပြုသည်။ qbec သည် ပြန်လည်သုံးသပ်မှုကို ကျင့်သုံးသည်။, အစား qbec သည် မူရင်းအတိုင်း အသုံးပြုပါသည်။ - ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ပတ်ဝန်းကျင်အတွက် ကွဲပြားမှုများကို ဖော်ပြရန် ကြိုးစားမည့်အချိန်ဖြစ်သည် (ပြန်လည်သုံးသပ်ခြင်းနှင့် မူရင်းအတိုင်းဖြစ်သည်)။

ထည့်ရအောင် ပြန်လည်သုံးသပ် ပတ်ဝန်းကျင် deploy/website/qbec.yaml

spec:
  environments:
    review:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443

အဲဒီအခါမှာ ကျနော်တို့က အဲဒါကို ကြေညာမယ်။ deploy/website/params.libsonnet:

local env = std.extVar('qbec.io/env');
local paramsMap = {
  _: import './environments/base.libsonnet',
  default: import './environments/default.libsonnet',
  review: import './environments/review.libsonnet',
};

if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile

၎င်းအတွက် စိတ်ကြိုက်ဘောင်များကို ချရေးပါ။ deploy/website/environments/review.libsonnet:

// this file has the param overrides for the default environment
local base = import './base.libsonnet';
local slug = std.extVar('qbec.io/tag');
local subdomain = std.extVar('subdomain');

base {
  components+: {
    website+: {
      name: 'example-docs-' + slug,
      domain: subdomain + '.docs.example.org',
    },
  },
}

jobu ကိုလည်း အနီးကပ် လေ့လာကြည့်ရအောင် stop_သုံးသပ်ချက်ဌာနခွဲကို ဖျက်လိုက်သောအခါတွင် ၎င်းကို အစပျိုးပေးမည်ဖြစ်ပြီး gitlab က ၎င်းကို ငွေရှင်းရန် မကြိုးစားဘဲ၊ GIT_STRATEGY- မရှိပါ။၊ နောက်ပိုင်းမှာ ကျွန်တော်တို့ မွေးထုတ်တယ်။ မာစတာ- ကိုင်းဖြတ်ပြီး သုံးသပ်ချက်တွေကို ဖျက်လိုက်ပါ။
နည်းနည်းရှုပ်နေပေမယ့် ပိုလှတဲ့နည်းလမ်းကို ရှာမတွေ့သေးဘူး။
အခြားရွေးချယ်စရာတစ်ခုသည် အမြဲတမ်း လုံးလုံးလျားလျား ဖျက်သိမ်းနိုင်သည့် ဟိုတယ်အမည်နေရာတစ်ခုသို့ ပြန်လည်သုံးသပ်မှုတစ်ခုစီကို အသုံးချရန်ဖြစ်သည်။

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

git add .
git commit -m "Enable automatic review"

git တွန်း, git checkout -b စမ်းသပ်မှု, git push မူရင်းစမ်းသပ်မှုစစ်ဆေးပါ-

Gitlab ရှိ ဖန်တီးထားသော ပတ်ဝန်းကျင်၏ ဖန်သားပြင်ဓာတ်ပုံ

အားလုံး အလုပ်ဖြစ်ပြီလား? - ကောင်းပြီ၊ ကျွန်ုပ်တို့၏စမ်းသပ်မှုဌာနခွဲကိုဖျက်ပါ။ git ကုန်ပစ္စည်းမာစတာ, git push မူရင်း :testပတ်ဝန်းကျင်ကို ဖျက်ခြင်းအလုပ်များသည် အမှားအယွင်းမရှိဘဲ အလုပ်လုပ်ကြောင်း စစ်ဆေးပါသည်။

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

13. အက်ပ်များကို ပြန်လည်သုံးသပ်ပါ။

အက်ပ်များကို ပြန်လည်သုံးသပ်ပါ။ ၎င်းသည် အသုံးပြုထားသော ပတ်ဝန်းကျင်တွင် ၎င်းကို လျင်မြန်စွာကြည့်ရှုနိုင်ရန် repository အတွင်းရှိ ဖိုင်တစ်ခုစီအတွက် ခလုတ်တစ်ခုစီကို ထည့်သွင်းနိုင်စေမည့် GitLab အင်္ဂါရပ်တစ်ခုဖြစ်သည်။

ဤခလုတ်များပေါ်လာစေရန်အတွက် ဖိုင်တစ်ခုဖန်တီးရန် လိုအပ်ပါသည်။ .gitlab/route-map.yml ၎င်းတွင် လမ်းကြောင်းပြောင်းလဲခြင်းအားလုံးကို ဖော်ပြပါ၊ ကျွန်ုပ်တို့၏ကိစ္စတွင် ၎င်းသည် အလွန်ရိုးရှင်းပါမည်-

# Indices
- source: /content/(.+?)_index.(md|html)/ 
  public: '1'

# Pages
- source: /content/(.+?).(md|html)/ 
  public: '1/'

ကျွန်ုပ်တို့၏ပြောင်းလဲမှုများကို လုပ်ဆောင်ရန် မမေ့ပါနှင့်။

git add .gitlab/
git commit -m "Enable review apps"

git တွန်းနှင့် စစ်ဆေးပါ-

Review အက်ပ်ခလုတ်၏ ဖန်သားပြင်ဓာတ်ပုံ

အလုပ်ပြီးပါပြီ။

ပရောဂျက်ရင်းမြစ်များ-

• Gitlab တွင်- https://gitlab.com/kvaps/docs.example.org
• GitHub တွင်- https://github.com/kvaps/docs.example.org

မင်းရဲ့အာရုံစိုက်မှုအတွက်ကျေးဇူးတင်ပါတယ်၊ ငါနှစ်သက်မယ်လို့မျှော်လင့်ပါတယ်။

source: www.habr.com