ProHoster > بلاګ > اداره > په Kubernetes کلستر کې د زوړ فیچر څانګې لرې کول

په Kubernetes کلستر کې د زوړ فیچر څانګې لرې کول

په Kubernetes کلستر کې د زوړ فیچر څانګې لرې کول

سلام! د فیچر څانګه (aka deploy preview, review app) - دا هغه وخت دی چې نه یوازې د ماسټر څانګه ګمارل کیږي، بلکې د هر یو ځانګړي URL ته د پلولو غوښتنه هم کوي. تاسو کولی شئ وګورئ چې ایا کوډ د تولید چاپیریال کې کار کوي؛ فیچر نورو پروګرام کونکو یا د محصول متخصصینو ته ښودل کیدی شي. پداسې حال کې چې تاسو د پل په غوښتنه کې کار کوئ ، د زاړه کوډ لپاره هر نوی ژمن اوسنی ګمارل حذف کیږي ، او د نوي کوډ لپاره نوی ځای پرځای شوی. پوښتنې راپورته کیدی شي کله چې تاسو په ماسټر څانګه کې د پلټ غوښتنه ضمیمه کړئ. تاسو نور د فیچر څانګې ته اړتیا نلرئ، مګر د کوبرنیټس سرچینې لاهم په کلستر کې دي.

د فیچر څانګو په اړه نور

په Kubernetes کې د ځانګړتیاو څانګو جوړولو لپاره یوه لاره د نوم ځایونو کارول دي. په لنډه توګه، د تولید ترتیب داسې ښکاري:

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

د فیچر څانګې لپاره، د نوم ځای د خپل پیژندونکي (د مثال په توګه، د پلټ غوښتنې شمیره) او یو ډول مخکینۍ / پوسټ فکس (د مثال په توګه، -pr-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

په عمومي توګه، ما لیکلي کوبرنیټس آپریټر (یو غوښتنلیک چې کلستر سرچینو ته لاسرسی لري) په ګیتوب کې پروژې سره اړیکه ونیسئ. دا د نوم ځایونه لرې کوي چې د پخوانیو ځانګړتیاو څانګو پورې اړه لري. په Kubernetes کې، که تاسو د نوم ځای ړنګ کړئ، په دې نوم ځای کې نورې سرچینې هم په اتوماتيک ډول حذف کیږي.

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

تاسو کولی شئ په کلستر کې د ځانګړتیاو څانګو پلي کولو څرنګوالي په اړه ولولئ دلته и دلته.

انګیزه

راځئ چې د دوامداره ادغام سره د ځانګړي پل غوښتنې ژوند دورې ته وګورو (continuous integration):

  1. موږ څانګې ته نوې ژمنې فشار راوړو.
  2. په جوړیدو کې، لینټرې او/یا ازموینې پرمخ وړل کیږي.
  3. د کوبرنیټس پل غوښتنې تشکیلات په الوتنه کې رامینځته کیږي (د مثال په توګه ، د هغې شمیره په بشپړ شوي ټیمپلیټ کې داخلیږي).
  4. د kubectl اپلیکیشن په کارولو سره ، تشکیلات په کلستر کې اضافه کیږي (ځای پرځای کول).
  5. د پل غوښتنه په ماسټر څانګه کې یوځای کیږي.

پداسې حال کې چې تاسو د پل په غوښتنه کې کار کوئ ، د زاړه کوډ لپاره هر نوی ژمن اوسنی ګمارل حذف کیږي ، او د نوي کوډ لپاره نوی ځای پرځای شوی. مګر کله چې د پل غوښتنه په ماسټر څانګه کې ضمیمه شي، یوازې ماسټر څانګه به جوړه شي. د پایلې په توګه، دا معلومه شوه چې موږ لا دمخه د پلولو غوښتنې په اړه هیر کړی، او د دې د کوبرنیټس سرچینې لاهم په کلستر کې دي.

څنګه کارول کیږي

پروژه د لاندې کمانډ سره نصب کړئ:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

د لاندې مینځپانګې سره فایل جوړ کړئ او له لارې یې نصب کړئ kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

پارسيم namespaceSubstring د نورو نوم ځایونو څخه د غوښتنې غوښتنې لپاره د نوم ځایونو فلټر کولو ته اړتیا ده. د مثال په توګه، که کلستر لاندې نوم ځایونه ولري: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33، بیا به د حذف لپاره نوماندان وي habr-back-end-pr-17, habr-back-end-pr-33.

پارسيم afterDaysWithoutDeploy د زړو نوم ځایونو ړنګولو ته اړتیا ده. د مثال په توګه، که د نوم ځای جوړ شي 3 дня 1 час بیرته، او پیرامیټر په ګوته کوي 3 дня، دا نوم ځای به ړنګ شي. دا په مخالف لوري کې هم کار کوي که چیرې نوم ځای رامینځته شي 2 дня 23 часа بیرته، او پیرامیټر په ګوته کوي 3 дня, دا نوم ځای به ړنګ نه شي.

یو بل پیرامیټر شتون لري، دا د دې مسولیت دی چې څومره ځله ټول نوم ځایونه سکین کړئ او د ځای پرځای کولو پرته د ورځو لپاره وګورئ - هره دقیقه چیک کړئ. په ډیفالټ کې دا مساوي دی 30 минутам.

دا څنګه کار کوي؟

په عمل کې، تاسو به اړتیا ولرئ:

  1. ډاکر په یو جلا چاپیریال کې د کار کولو لپاره.
  2. مینیکیوب په سیمه ایزه توګه د Kubernetes کلستر به لوړ کړي.
  3. kubectl - د کلستر مدیریت لپاره د کمانډ لاین انٹرفیس.

موږ په سیمه ایزه توګه د Kubernetes کلستر پورته کوو:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

موږ اشاره کوو kubectl د ډیفالټ لخوا محلي کلستر وکاروئ:

$ kubectl config use-context minikube
Switched to context "minikube".

د تولید چاپیریال لپاره تشکیلات ډاونلوډ کړئ:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

څرنګه چې د تولید ترتیبات د زاړه نوم ځایونو چک کولو لپاره ترتیب شوي، او زموږ نوي پورته شوي کلستر دوی نلري، موږ به د چاپیریال تغیر بدل کړو. IS_DEBUG په true. د دې ارزښت سره پیرامیټر afterDaysWithoutDeploy په پام کې نه نیول کیږي او د نوم ځایونه د ځای پرځای کولو پرته د ورځو لپاره نه چک کیږي، یوازې د سبسټرینګ پیښې لپاره (-pr-).

که تاسو روان یاست Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

که تاسو روان یاست macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

د پروژې نصب کول:

$ kubectl apply -f stale-feature-branch-production-configs.yml

چک کول چې یوه سرچینه په کلستر کې ښکاره شوې StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

موږ ګورو چې یو آپریټر په کلستر کې څرګند شوی دی:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

که تاسو د دې لاګونو ته وګورئ، دا د سرچینو پروسس کولو لپاره چمتو دی StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

موږ چمتو شوي نصب کوو fixtures (د کلستر سرچینو ماډل کولو لپاره چمتو شوي ترتیبونه) ​​د سرچینې لپاره StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

تشکیلات د فرعي سټینګ سره د نوم ځایونو لټون ته اشاره کوي -pr- یو ځل دننه 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

آپریټر ځواب ورکړ او د نوم ځایونو چک کولو لپاره چمتو دی:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

ولګوه fixturesدوه نوم ځایونه لري (project-pr-1, project-pr-2) او دوی deployments, services, ingress، او همداسی پسی:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

موږ ګورو چې پورته ټولې سرچینې په بریالیتوب سره رامینځته شوي:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

ځکه چې موږ پکې شامل شو debugد نوم ځایونه project-pr-1 и project-pr-2له همدې امله ټولې نورې سرچینې باید سمدلاسه حذف شي پرته لدې چې پیرامیټر په پام کې ونیول شي afterDaysWithoutDeploy. دا د آپریټر لاګونو کې لیدل کیدی شي:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

که تاسو د سرچینو شتون وګورئ، دوی به په وضعیت کې وي Terminating (د حذف کولو پروسه) یا دمخه حذف شوی (د قوماندې محصول خالي دی).

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

تاسو کولی شئ د جوړولو پروسه تکرار کړئ fixtures څو ځله او ډاډ ترلاسه کړئ چې دوی په یوه دقیقه کې لرې شوي.

بدیلونه

د یو آپریټر پرځای چې په کلستر کې کار کوي څه شی کیدی شي؟ ډیری طریقې شتون لري، ټول یې نیمګړتیاوې دي (او د دوی نیمګړتیاوې موضوعي دي)، او هرڅوک د ځان لپاره پریکړه کوي چې د یوې ځانګړې پروژې لپاره غوره وي:

  1. د ماسټر برانچ د دوامداره ادغام جوړولو پرمهال د فیچر څانګه حذف کړئ.

    • د دې کولو لپاره، تاسو اړتیا لرئ پوه شئ چې کوم پل غوښتنه د هغه ژمنې سره تړاو لري چې جوړیږي. څنګه چې د فیچر څانګې نوم ځای د پل غوښتنې پیژندونکی لري - د هغې شمیره ، یا د څانګې نوم ، پیژندونکی باید تل په ژمنې کې مشخص شي.
    • د ماسټر څانګې جوړول ناکام دي. د مثال په توګه ، تاسو لاندې مرحلې لرئ: پروژه ډاونلوډ کړئ ، ازموینې پرمخ وړئ ، پروژه رامینځته کړئ ، خوشې کړئ ، خبرتیاوې واستوئ ، د وروستي پل غوښتنې فیچر څانګه پاک کړئ. که چیرې د خبرتیا لیږلو په وخت کې جوړونه ناکامه شي، نو تاسو باید په کلستر کې ټولې سرچینې په لاسي ډول حذف کړئ.
    • د مناسب شرایطو پرته، په ماسټر جوړ کې د ځانګړتیاو څانګو حذف کول ښکاره ندي.

  2. د ویب هکونو کارول (مثال).

    • دا ممکن ستاسو چلند نه وي. د مثال په توګه، په جینکنز، یوازې یو ډول پایپ لاین د سرچینې کوډ کې د دې تشکیلاتو خوندي کولو وړتیا ملاتړ کوي. کله چې ویب هکس کاروئ، تاسو اړتیا لرئ چې خپل سکریپټ ولیکئ ترڅو دوی پروسس کړي. دا سکریپټ باید د جینکنز انٹرفیس کې ځای په ځای شي، کوم چې ساتل یې ستونزمن دي.

  3. د لیکلو لپاره کرونجوب او د Kubernetes کلستر اضافه کړئ.

    • په لیکلو او ملاتړ کې وخت لګول.
    • آپریټر دمخه په ورته سټایل کې کار کوي ، مستند او ملاتړ شوی.

مقالې ته ستاسو د پاملرنې لپاره مننه. په ګیتوب کې پروژې ته لینک.

سرچینه: www.habr.com

Add a comment