ProHoster > Blog > Rêveberî > Di komek Kubernetes de şaxek taybetmendiya kevnare rakirin

Di komek Kubernetes de şaxek taybetmendiya kevnare rakirin

Di komek Kubernetes de şaxek taybetmendiya kevnare rakirin

Hello! Şaxa taybetmendiyê (aka pêşdîtina danînê, sepana vekolînê) - ev gava ku ne tenê şaxê sereke tê bicîh kirin, lê di heman demê de her daxwazek bikişîne ser URLek yekta jî. Hûn dikarin kontrol bikin ka kod di hawîrdorek hilberînê de dixebite an na, taybetmendî dikare ji bernamenûsên din an pisporên hilberê re were destnîşan kirin. Dema ku hûn li ser daxwazek kişandinê dixebitin, her commitek nû, bicîhkirina heyî ya ji bo koda kevn tê jêbirin, û bicîhkirina nû ji bo koda nû tê derxistin. Dema ku we daxwaznameyek kişandinê di şaxê masterê de girêdide dibe ku pirs derkevin holê. Hûn êdî ne hewceyê şaxê taybetmendiyê ne, lê çavkaniyên Kubernetes hîn jî di komê de ne.

Zêdetir li ser şaxên taybetmendiyê

Yek nêzîkatiya çêkirina şaxên taybetmendiyê li Kubernetes ev e ku meriv cîhên navan bikar bîne. Bi kurtasî, veavakirina hilberînê wiha xuya dike:

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

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

Ji bo şaxek taybetmendiyê, cîhek navek bi nasnavê xwe (mînak, hejmara daxwaza kişandinê) û cûreyek pêşgir/postfix (mînak, -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
...

Bi gelemperî, min nivîsand Operatorê Kubernetes (serlêdanek ku xwedan çavkaniyên komê ye), girêdana projeyê li ser Github. Ew cîhên navên ku girêdayî şaxên taybetmendiya kevn in jê dike. Di Kubernetes de, heke hûn cîhek navekî jêbikin, çavkaniyên din ên di wê navan de jî bixweber têne jêbirin.

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

Hûn dikarin bixwînin ka meriv çawa şaxên taybetmendiyê di komekê de bicîh dike vir и vir.

Motivation

Ka em li çerxa jiyanê ya daxwaziya kişandinê ya tîpîk bi entegrasyona domdar (continuous integration):

  1. Em ji bo şaxê komîteyek nû derdixin.
  2. Li ser çêkirinê, linter û / an ceribandin têne meşandin.
  3. Veavakirinên daxwaza kişandina Kubernetes bi lez têne çêkirin (mînakek, hejmara wê di şablona qediyayî de tê danîn).
  4. Bi karanîna kubectl sepanê, veavakirin li komê têne zêdekirin (deploy).
  5. Daxwaza kişandinê di şaxê sereke de tê yek kirin.

Dema ku hûn di daxwaznameyek kişandinê de dixebitin, her bicîhkirina heyî ya nû ya ji bo koda kevn tê jêbirin, û bicîhkirina nû ya ji bo koda nû tê derxistin. Lê gava ku daxwazek kişandinê di şaxê masterê de were yek kirin, tenê şaxê sereke dê were çêkirin. Wekî encamek, derdikeve holê ku me jixwe daxwaza kişandinê ji bîr kiriye, û çavkaniyên wê yên Kubernetes hîn jî di nav komê de ne.

Çawa bikar bînin

Projeyê bi fermana jêrîn saz bikin:

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

Pelek bi naveroka jêrîn biafirînin û bi rê ve saz bikin kubectl apply -f:

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

Parîsê namespaceSubstring pêdivî ye ku cîhên navan ji bo daxwazên kişandina navên din fîlter bikin. Mînakî, heke cluster navên jêrîn hebin: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, wê demê namzetên jêbirinê dê bibin habr-back-end-pr-17, habr-back-end-pr-33.

Parîsê afterDaysWithoutDeploy ji bo jêbirina navên kevn pêwîst e. Mînakî, heke cîhê navan were afirandin 3 дня 1 час paşde, û parametre nîşan dide 3 дня, ev navnav dê were jêbirin. Di heman demê de ger cîhê navan çêbibe ew berevajî kar dike 2 дня 23 часа paşde, û parametre nîşan dide 3 дня, ev navnav nayê jêbirin.

Parametreyek din jî heye, ew berpirsiyar e ku meriv çend caran hemî cîhên navan bişopîne û bi rojan bêyî bicîhkirinê kontrol bike - checkEveryMinutes. Bi xwerû ew wekhev e 30 минутам.

Çawa ev karê

Di pratîkê de, hûn ê hewce bibin:

  1. Docker ji bo xebatê di hawîrdorek veqetandî de.
  2. Minikube dê komikek Kubernetes li herêmî bilind bike.
  3. kubectl - Navbera rêza fermanê ji bo rêveberiya komê.

Em komikek Kubernetes bi herêmî bilind dikin:

$ 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.

Diyar bike kubectl ji hêla xwerû ve komek herêmî bikar bînin:

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

Veavakirinên ji bo hawîrdora hilberînê dakêşin:

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

Ji ber ku mîhengên hilberînê têne mîheng kirin ku cîhên navên kevn kontrol bikin, û koma meya nû hatî hilberandin wan tune, em ê guhêrbara jîngehê biguhezînin. IS_DEBUG li ser true. Bi vê nirxê parametre afterDaysWithoutDeploy nayê hesibandin û cîhên navan bi rojan bêyî ku werin danîn nayên kontrol kirin, tenê ji bo peydabûna xêzikê (-pr-).

Heke hûn li ser in Linux:

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

Heke hûn li ser in macOS:

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

Sazkirina projeyê:

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

Kontrol kirin ku çavkaniyek di komê de xuya bûye StaleFeatureBranch:

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

Em kontrol dikin ku operatorek di komê de xuya bûye:

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

Ger hûn li têketinên wê binêrin, ew amade ye ku çavkaniyan pêvajoyê bike 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}

Em amade saz dikin fixtures ( veavakirinên amade ji bo modelkirina çavkaniyên komê) ji bo çavkaniyek StaleFeatureBranch:

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

Veavakirin ji bo lêgerîna cîhên navan ên bi xêzekê destnîşan dikin -pr- her carekê 1 минуту.:

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

Operator bersiv da û amade ye ku cîhên navan kontrol bike:

$ 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"}

Lêkirin fixtures, du cîhên navan dihewîne (project-pr-1, project-pr-2) û wan deployments, services, ingress, wate ya vê çîye:

$ 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

Em kontrol dikin ku hemî çavkaniyên jorîn bi serfirazî hatine afirandin:

$ 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
...

Ji ber ku em tê de debug, navan project-pr-1 и project-pr-2, ji ber vê yekê pêdivî ye ku hemî çavkaniyên din bêyî girtina pîvanê tavilê werin jêbirin afterDaysWithoutDeploy. Ev dikare di têketinên operatorê de were dîtin:

$ 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"}

Ger hûn hebûna çavkaniyan kontrol bikin, ew ê di statûyê de bin Terminating (pêvajoya jêbirinê) an jixwe hatî jêbirin (derketina fermanê vala ye).

$ 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
...

Hûn dikarin pêvajoya afirandinê dubare bikin fixtures çend caran û piştrast bikin ku ew di nav deqîqeyek de têne rakirin.

Alternatîfên

Li şûna operatorek ku di komekê de dixebite çi dikare were kirin? Gelek nêzîkatî hene, hemî jî bêkêmasî ne (û kêmasiyên wan subjektîf in), û her kes bi xwe biryar dide ka ji bo projeyek taybetî çi çêtirîn e:

  1. Di dema avakirina entegrasyona domdar a şaxê master de şaxê taybetmendiyê jêbirin.

    • Ji bo kirina vê yekê, hûn hewce ne ku zanibin ka kîjan daxwaza kişandinê bi peymana ku tê çêkirin ve girêdayî ye. Ji ber ku cîhê navê şaxê taybetmendiyê nasnavê daxwaziya kişandinê dihewîne - hejmara wê, an navê şaxê, pêdivî ye ku nasname her gav di commit de were diyar kirin.
    • Avakirina şaxên master têk diçin. Mînakî, hûn qonaxên jêrîn hene: Projeyê dakêşin, ceribandinan bimeşînin, projeyê ava bikin, berdanek çêbikin, agahdariyan bişînin, şaxê taybetmendiyê ya daxwaza kişandina paşîn paqij bikin. Heke avahî di şandina agahiyekê de têk neçe, hûn neçar in ku hemî çavkaniyên di komê de bi destan jêbirin.
    • Bêyî çarçoveyek rast, jêbirina şaxên taybetmendiyê di avakirina masterê de ne diyar e.

  2. Bikaranîna webhooks (nimûne).

    • Dibe ku ev nêzîkatiya we nebe. Ji bo nimûne, di Jenkins, tenê celebek lûleyê şiyana hilanîna veavakirinên xwe di koda çavkaniyê de piştgirî dike. Dema ku webhooks bikar tînin, hûn hewce ne ku skrîpta xwe binivîsin da ku wan pêvajoyê bikin. Pêdivî ye ku ev skrîpt di navbeyna Jenkins de were danîn, ku domandina wê dijwar e.

  3. Ku binivîsin Cronjob û komek Kubernetes lê zêde bike.

    • Wextê xwe li ser nivîsandin û piştgirîyê derbas dikin.
    • Operator jixwe bi şêwazek wekhev dixebite, tê belgekirin û piştgirî kirin.

Spas dikim ji bo bala we li ser gotara. Girêdana projeyê li ser Github.

Source: www.habr.com

Add a comment