Application & Softwares Guide Knowledge Tutorials Ubuntu ubuntumm

Actions Runner Controller အကြောင်း တစေ့တစောင်း

yehbonemyat
yehbonemyat
07/07/2022 · 5 minutes
329
0

GitHub Action အကြောင်း နဲ့ ဘာလို့ ARC သုံးဖြစ်သွားလဲ? 

ကျနော့် အလုပ်မှာ လိုအပ်လို့ လိုက်ရှာရင်း သုံးဖြစ်တဲ့ GitHub Action  Runner Controller (ARC) ဆိုတဲ့ open source project အကြောင်းလေး ပြန်မျှဝေချင်ပါတယ်။ ဒါက project ရဲ့ link ပါ။

GitHub Action ဆိုတာ software development process မှာ ရေးပြီးသား code တွေ test ဖို့ software release တွေ automate လုပ်ဖို့တို့ container image တွေ သုံးတဲ့ organization တွေဆိုရင် software release လုပ်ပြီးတာနဲ့ တပြိုင်နက် container image တွေ build လုပ် ပြီး private container registry တွေပို့ဖို့  အစသဖြင့်တို့ကို workflow တွေ တည်ဆောက်ပြီး အလိုအလျှောက် ခိုင်းစေနိုင်တဲ့ GitHub က feature တစ်ခုဖြစ်ပါတယ်။ အဲလို workflow တွေ ရေးပြီး ခိုင်းစေနိုင်တာကို CI (continuous integration) လို ခေါ်ကြပါတယ်။ GitHub Action က software development automation မှာ တော်တော် အသုံးဝင်တဲ့ feature တစ်ခုဖြစ်ပါတယ်။

အဲဒီ  action workflow တင် run နိုင်ဖို့ based os (operating system) တွေ လိုလာပါတယ်။ အဲ os တွေကို runner လို့လဲ ခေါ်ကြတယ်။ အများအားဖြင့် GitHub က runners တွေကိုယူသုံးလို့ရပါတယ်။

ကဲပြဿနာကခုမှစပါပြီ။ GitHub က runners တွေယူသုံးတာက တစ်ယောက်တည်း စမ်းရုံ သုံးရုံ လောက်ဆိုအဆင်ပြေပါတယ်။ Organization အလိုက် ဆိုရင်တော့ running time ပေါ်မူတည်ပြီး bill ဖြတ်တဲ့အတွက် GitHub က custom runner တွေ အသုံးပြုလို့ရအောင် ခွင့်ပြုထားတဲ့ self-hosted runner နည်းကို သုံးမှ ပိုသင့်တော်ပါလိမ့်မယ်။

ကျနော်မျှဝေမဲ့ ARC project ကဘာလုပ်ပေးလဲဆိုတော့ အဲဒီ self-hosted runner တွေကို Kubernetes cluster ပေါ် မှာ တင် run ပေးပြီး တဲ့အပြင် workload အပေါ်မူတည်ပြီး အဲ runner တွေကို auto scale ပါလုပ်ပေးပါတယ်။ auto scaling လုပ်ဆောင် ချက် ပါတဲ့ အတွက် ကိုယ့်ရဲ့ cluster resources တွေ ကို လိုအပ်တဲ့အချိန်မှ လိုအပ်သလို အသုံးပြုတဲ့အပြင် GitHub ဖြတ်မယ့် bill လည်း ‌သက်သာနိုင်မှာဖြစ်ပါတယ်။

Authentication Options နဲ့ Levels တွေ

ကျနော်တို့ Kubernetes Cluster နဲ့ GitHub ကို ချိတ်ဆက်ဆောင်ရွက်နိုင်ဖို့အတွက် authentication လိုလာပါတယ်။ ARC က support လုပ်တဲ့ authentication types တွေကတော့အောက်ပါအတိုင်းဖြစ်ပါတယ်။

၁။  GitHub App နဲ့

၂။ Personal Access Token  တို့ဖြစ်ပါတယ်။

အဲနှစ်မျိုးထဲက နှစ်သက်ရာသုံးနိုင်ပါတယ်။ ကျနော်တော့ PAT ကို recommend လုပ်ပါတယ်။တခြားတော့မဟုတ်ပါဘူး။ setup လုပ်ရတာ အသုံးပြုရတာ ပိုရိုးရှင်းတဲ့အတွက်ပါ။ Authentication မှာမှ GitHub Account type အပေါ်မူတည်ပြီးကွဲသွားပါတယ်။ ကျနော်ကတော့ organization ထဲက repo တွေမှာ self hosted runner တွေသုံးချင်တဲ့ အတွက် original level access ရှိတဲ့ PAT token ကိုသုံးရပါတယ်။ တခြား   GitHub Enterprise သုံးချင်ရင် သူ့ရဲ့ tokenကိုသုံးရပါမယ် အစသဖြင့်ပေါ့။

Auth token ဘယ်လိုယူရမလဲ?

၁။ GitHub Auth App တည်ဆောက်ပြီး လိုအပ်တဲ့ token ယူနည်း ကို ဒီမှာ ကြည့်နိုင်ပါတယ်။

၂။ Personal Access Token ယူနည်း ကို ဒီမှာ ကြည့်နိုင်ပါတယ်။

မှတ်ချက်။​ ။မိမိအသုံးပြုမယ့် access level ကို မှန်ကန်အောင် ရွေးပေးဖို့လိုပါမယ်။

Prerequisites က ဘာလိုလဲ?

အဲတော့ ကျနော်တို့ ARC ကို Kubernetes Cluster မှာ တည်ဆောက်ကြပါမယ်။ အဲမတိုင်ခင် ARC က certificate manager သုံးတဲ့အတွက် cluster ပေါ်အရင် သွင်းပေးရပါမယ်။

ပုံမှန် တစ်ခုချင်းစီ install ရင် အချိန်ပိုကြာနိုင်တဲ့အတွက် official site က cert-manager file ကိုသုံးပြီး အောက်ပါအတိုင်း install လုပ်ပါ့မယ်။

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.2/cert-manager.yaml

Installation success ဖြစ်မဖြစ် အောက်ပါအတိုင်း check နိုင်ပါတယ်။

cert manager api ကို ready ဖြစ်မဖြစ် အောက်ပါအတိုင်း check နိုင်ပါတယ်။

 

Cluster ပေါ်မှာ ARC ဘယ်လို install မလဲ?

ကဲလိုအပ်တာတွေ ရပြီဆိုတော့ ARC ကို install ကြပါမယ်။ ကျနော်တို့ helm package manager နဲ့ ARC ကို install လုပ်ကြပါမယ်။

ပထမဆုံး action namespace တစ်ခု တည်ဆောက်ပါမယ်။ တစ်ခြား application တွေနဲ့ သီးခြားဖြစ်သွားအောင်လို့ပါ။

kubectl create ns actions

ARC အတွက်လိုအပ်တဲ့ secret တစ်ခုတည်ဆောက်ရပါမယ်။ helm default template က controller-manager ဆို တဲ့ name နဲ့ secret ကို ယူသုံးတဲ့အတွက်ကြောင့် controller-manager ဆိုတဲ့ name ကိုသုံးပြီး secret တစ်ခုတည်ဆောက်ပါမယ်။

ဒီနေရာမှာ ကျနော်တို့ secret name ကို ကြိုက်တာပေးလို့ရပါတယ်။ ပေးတဲ့ name ကို helm chart ကို download လုပ်းပြီးပြင်‌‌ နေရမှာဆိုတော့ မပြင်ချင်လို့ default ပါတဲ့ secret name ကို သုံးလိုက်တာပါ။

kubectl create secret generic controller-manager \
-n actions-runner-system \
--from-literal=github_token=${GITHUB_TOKEN}

secret တည်ဆောက်တာ success ဖြစ်မဖြစ် check ပါ။

secret ရပြီဆိုတာနဲ့ ARC helm repo သွင်းရပါမယ်။ အောက်ပါအတိုင်းသွင်းနိုင်ပါတယ်။

$ helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller
$ helm repo update
$ helm search repo actions

helm repo သွင်းပြီးပြီဆိုတော့ ARC သွင်းမယ့် namespace ကို ခုနက တည်ဆောက်ခဲ့တဲ့ actions namespace ကို option အနေနဲ့ ပေးပြီး အောက်ပါအတိုင်းသွင်းနိုင်ပါတယ်။ ပြီးတော့ version က helm chart version ပါ။ syncPeriod က ကြိုက်သလိုပေးနိုင်ပါတယ်။ ခုတော့ 1 minute ပေးထားပါတယ်။

helm install runner actions-runner-controller/actions-runner-controller \
--namespace actions \
--version 0.18.0 \
--set syncPeriod=1m

ARC install ပြီးရင် status check ပါ။

This image has an empty alt attribute; its file name is Screen-Shot-2022-07-05-at-12.57.39-PM.png

Pod run မ run check ပါ။

Runner Controller Pod run နေရင် ARC သွင်းတာ အဆင်ပြေပါပြီ။

Runner Deployment Custom Resource Definition ရေးပုံရေးနည်း နဲ့ တည်ဆောက်ပုံ

Runner Deployment ရေးပုံကတော့ ရိုးရှင်းပါတယ်။ ပုံမှန် deployment file လိုပါဘဲ။
တစ်ခုသတိထားစရာတော့ရှိပါတယ်။ repository နေရာမှာ ကိုယ်သုံးမယ့် repo name ကို မှန်အောင်ရေးပေးရပါမယ်။ organization runner ဆိုရင် organization, enterprise runner ဆိုရင် enterprise မှန်အောင်သတ်မှတ်ပြီးမှ runner တည်ဆောက်ပါ။ အကျယ်ချဲ့ကတော့ ဒီ မှာကြည့်ပါ။

# runnerdeployment.yaml
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: example-runner-deployment
spec:
  template:
    spec:
      repository: ye-hbonemyat/test-check

ရေးထားတဲ့ yaml file ကို kubectl apply လုပ်ပါ။

kubectl apply လုပ်ပြီးရင် အောက်ပါအတိုင်း check လုပ်နိုင်ပါတယ်။

ဒါကတော့ runner deployment level check တာပါ။

ဒါကတော့ pod level check တာပါ။

ကဲအခုကျနော်တို့ single runner လေးတစ်လုံးရပါပြီ။

Horizontal Runner Deployment Autoscaler Custom Resource Definition ရေးပုံရေးနည်း နဲ့ တည်ဆောက်ပုံ

Kubernetes nature ကိုသုံးပြီး ကျနော်တို့ single runner ကို load အပေါ်မူတည်ပြီး horizontal autoscaling လုပ်နိုင်ပါတယ်။ သူ့အတွက် လိုအပ်တဲ့ CRD တွေကို ARC template က လုပ်ဆောင်ပေးပြီးသား ဖြစ်တဲ့အတွက် အောက်ပါအတိုင်း yaml file လေးရေးပြီး apply လုပ်ရုံပါဘဲ။ Horizontal autoscaling လုပ်ဖို့အတွက် ARC support ပေးတဲ့ နည်းလမ်းတွေက အများကြီးပါဘဲ။ ကိုယ်လိုသလို အဆင်ပြေသလို သုံးနိုင်ပါတယ်။ ကျနော်ကတော့ အရိုးရှင်းဆုံး တစ်ခုကို ဥပမာ ပြထားပါတယ်။ အကျယ်ချဲ့ ကို ဒီ မှာကြည့်ပါ။

# hra.yaml
apiVersion: actions.summerwind.dev/v1alpha1
kind: HorizontalRunnerAutoscaler
metadata:
  name: example-runner-deployment-autoscaler
spec:
  scaleTargetRef:
    name: example-runner-deployment
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: TotalNumberOfQueuedAndInProgressWorkflowRuns
      repositoryNames:
        - ye-hbonemyat/test-check

ရေးထားတဲ့ yaml file ကို kubectl apply လုပ်ပါ။

HRA လို့ဘဲ အတိုကောက်ခေါ်ပါတော့မယ်။
HRA apply လုပ်ပြီးရင် အောက်ပါအတိုင်း check နိုင်ပါတယ်။

ပြီးတော့ runner deployment ကိုပြန်ကြည့်ပါ။ Desired က နှစ်ခုတိုးသွားပါလိမ့်မယ်။ အကြောင်းက HRA မှာ minimum runners ကို 2 ပေးလိုက်လို့ပါ။

runners check ကြည့်တဲ့အခါ runner နှစ်ခုဖြစ်သွားတာတွေ့ရပါမယ်။

pod level check ပါ။

ကဲအကုန်ပြီးပြီဆိုတော့ repo ထဲသွားပြီး တစ်ချက် ကြည့်ပါ။ runner တွေ idle ဖြစ်နေတာတွေ့ရပါမယ်။

အဲဒါဆိုရင် ARC setup က အဆင်ပြေသွားပါပြီ။

မူရင်း image ကိုသုံးပြီး လိုအပ် သော package တွေ သွင်းခြင်း

ကဲ နောက်ဆုံးအနေနဲ့ runner တွေရဲ့ based image က အကုန်လုံးအတွက်လိုအပ်တဲ့ package တွေ အကုန်ပါဖို့က မဖြစ်နိုင်ပါဘူး။ တော်တော်များများပါပေမဲ့ ကိုယ့် organization မှာသုံးနေတဲ့ package တွေ မပါခဲ့သည်ရှိသော် အောက်ပါအတိုင်း docker image ပြန် build ပြီး သုံးနိုင်ပါတယ်။

FROM summerwind/actions-runner:latest

RUN sudo apt update -y \
&& sudo apt install YOUR_PACKAGE
&& sudo rm -rf /var/lib/apt/lists/*

ဒါကတော့ runner deployment file မှာ custom image သုံးပုံသုံးနည်း ပါ။

apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: example-runnerdeployment
spec:
  template:
    spec:
      repository: yehbone-myat/test-check
      image: YOUR_CUSTOM_DOCKER_IMAGE

ကဲ ARC အကြောင်းကတော့ ကျနော်သိသလောက် ဒါပါဘဲ။ အဆင်ပြေကြပါစေ။ ။

Leave a Reply