ProHoster > Blog > Administrim > Hoqim marramendësit e vjetruar të feature branch në klasterin Kubernetes

Hoqim marramendësit e vjetruar të feature branch në klasterin Kubernetes

Hoqim marramendësit e vjetruar të feature branch në klasterin Kubernetes

đŸ„‡Si tĂ« arrish nĂ« qiell dhe tĂ« bĂ«hesh pilot | ProHoster Devi nĂ« veçori (po ashtu preview implementimi, aplikacioni i rishikimit) — kjo Ă«shtĂ« kur implementohet jo vetĂ«m dega master, por gjithashtu çdo kĂ«rkesĂ« tĂ«rheqjeje nĂ« njĂ« URL unike. Mund tĂ« kontrolloni nĂ«se kodi punon nĂ« ambientin e prodhimit, veçorinĂ« mund ta tregoni programuesve tĂ« tjerĂ« ose produktologĂ«ve. NdĂ«rsa punoni nĂ« kĂ«rkesĂ«n tuaj, çdo commit i ri heq implementimin aktual pĂ«r kodin e vjetĂ«r, dhe njĂ« implementim i ri pĂ«r kodin e ri del jashtĂ«. Pyetje mund tĂ« lindin atĂ«herĂ« kur keni bashkuar kĂ«rkesĂ«n tuaj tĂ«rheqĂ«se nĂ« degĂ«n master. Dega e veçorisĂ« mĂ« nuk ju nevojitet, por burimet e Kubernetes janĂ« ende nĂ« klaster.

Më shumë për degët e veçorisë

NjĂ« nga qasjet pĂ«r tĂ« bĂ«rĂ« degĂ« tĂ« veçorisĂ« nĂ« Kubernetes — Ă«shtĂ« pĂ«rdorimi i namespace-ve. NĂ«se shkurtojmĂ«, konfigurimet e prodhimit duken kĂ«shtu:

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

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

Për degën e veçorisë krijohet një namespace me identifikuesin e saj (p.sh., numri i kërkesës së tërheqjes) dhe ndonjë prefiks/postfix (p.sh., -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
...

Në përgjithësi, unë shkrova Kubernetes Operator (një aplikacion që ka qasje në burimet e klasterit), linku për projektin në Github. Ai fshin namespace-t që përkasin në degët e veçorisë të vjetra. Në Kubernetes, nëse fshini një namespace, burimet e tjera në këtë namespace gjithashtu fshihen automatikisht.

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

Për mënyrën sesi të implementoni degët e veçorisë në klaster, mund të lexoni këtu dhe këtu.

Motivimi

Le të shohim një cikël tipik të jetës së kërkesës së tërheqjes me integrim të vazhdueshëm (integrim i vazhdueshëm):

  1. Dërgojmë një commit të ri në degë.
  2. Në ndërtim, lançohet linterat dhe/ose testet.
  3. Në flakë formohen konfigurimet e Kubernetes për kërkesën e tërheqjes (p.sh., numri i saj futet në një shabllon gati).
  4. Me ndihmën e kubectl apply, konfigurimet shkojnë në klaster (implementohet).
  5. Kërkesa e tërheqjes bashkohet në degën master.

Ndërsa punoni në kërkesën tuaj të tërheqjes, çdo commit i ri heq implementimin aktual për kodin e vjetër, dhe një implementim i ri për kodin e ri del jashtë. Por kur kërkesa e tërheqjes bashkohet në degën master, do të ndërtohet vetëm dega master. Në fund rezulton se për kërkesën e tërheqjes tashmë e kemi harruar, por burimet e saj Kubernetes janë ende në klaster.

Si të përdorni

Instaloni projektin me komandën e mëposhtme:

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

Krijoni një skedë me përmbajtjen e mëposhtme dhe instaloni përmes kubectl apply -f:

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

Parametri namespaceSubstring nevohet për të filtruar namespace-t për pull request-et nga namespace të tjera. Për shembull, nëse në kluster ka këto namespace: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, atëherë kandidatët për fshirje do të jenë habr-back-end-pr-17, habr-back-end-pr-33.

Parametri afterDaysWithoutDeploy nevohet për të fshirë namespace-t e vjetra. Për shembull, nëse namespace është krijuar 3 ditë 1 orë mbrapa, dhe në parametrin është e përcaktuar 3 ditë, ky namespace do të fshihet. Funksionon edhe në anën tjetër, nëse namespace është krijuar 2 ditë 23 orë mbrapa, dhe në parametrin është e përcaktuar 3 ditë, ky namespace nuk do të fshihet.

Ka një parameter tjetër, ai e menaxhon sa shpesh të skanohet të gjithë namespace-t dhe të kontrollohet për ditët pa deploy - checkEveryMinutes. Në mënyrë default, ai është baras 30 minutave.

Si funksionon kjo

Në praktikë, do të nevojitet:

  1. Docker për të punuar në një ambient të izoluar.
  2. Minikube do të ngrejë klusterin Kubernetes lokal.
  3. kubectl — ndĂ«rfaqe komandash pĂ«r menaxhimin e klusterit.

Ngremë klusterin Kubernetes lokal:

$ minikube start --vm-driver=docker
minikube v1.11.0 në Darwin 10.15.5
Duke përdorur drejtuesin docker duke u bazuar në profilin ekzistues.
Duke nisur pikën e kontrollit minikube në klusterin minikube.

Specifikoni kubectl përdor klusterin lokal si default:

$ kubectl config use-context minikube
Kaluan në kontekstin "minikube".

Shkarkojmë konfigurimet për mjedisin e production-it:

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

Duke qenë se konfigurimet e production-it janë të vendosura të kontrollojnë namespace-t e vjetra, dhe në klusterin tonë të sapo ngritur nuk ka, do të zëvendësojmë variablën e ambientit IS_DEBUG në true. Me këtë vlerë, parametri afterDaysWithoutDeploy nuk merret parasysh dhe namespace-t nuk kontrollohen për ditë pa deploy, vetëm për përputhjen me substring (-pr-).

Nëse jeni në Linux:

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

Nëse jeni në macOS:

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

Instalojmë projektin:

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

Kontrollojmë që në kluster është shfaqur burimi StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
EMRI                 ... GRUPI I API-së                             ... LLOJI
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

Kontrollojmë që në kluster është shfaqur operatori:

$ kubectl get pods --namespace stale-feature-branch-operator
EMRI                                           ... STATUS  ... MOSHË
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Duke punuar ... 38s

Nëse shohim në logjet e tij, ai është gati për të procesuar burimet StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Versioni i Operatorit: 0.0.1"}
...
... "msg":"Duke nisur EventSource", ... , "source":"kind source: \/, Kind="}
... "msg":"Duke nisur Kontrolluesin", ...}
... "msg":"Duke nisur punonjësit", ..., "numri i punonjësve":1}

Instalojmë fixtures-në aparatet (konfigurata të gatshme për modelimin e burimeve të klasterit) për burimin StaleFeatureBranch:

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

Në konfigurata tregohet të kërkohen namespace'ët me nënstring -pr- një herë në 1 minutë.:

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

Operatori ka reaguar dhe është gati të kontrollojë namespace'ët:

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

Instalojmë aparatet, përfshirë dy namespace'ë (project-pr-1, project-pr-2) dhe të tyre deployed, shërbimet, ingress, etj.:

$ 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

Po kontrollojmë që të gjitha burimet e mësipërme janë krijuar me sukses:

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

Pasi kemi aktivizuar debug, namespace'ët project-pr-1 dhe project-pr-2, pra edhe të gjitha burimet e tjera, do të duhet të fshihen menjëherë pa marrë parasysh parametrin afterDaysWithoutDeploy. Në logët e operatorit kjo është e dukshme:

$ 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 processed.","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 processed.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

Nëse kontrolloni praninë e burimeve, ato do të jenë në statusin Terminating (procesi i fshirjes) ose tashmë të fshira (dalja e komandës është e zbrazët).

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

Mund të përsërisni procesin e krijimit aparatet disa herë dhe të siguroheni që ato do të fshihen brenda një minute.

Alternativat

ÇfarĂ« mund tĂ« bĂ«ni nĂ« vend tĂ« operatorit qĂ« funksionon nĂ« klaster? Ka disa qasje, tĂ« gjitha janĂ« tĂ« pafund dhe tĂ« metat e tyre janĂ« subjektive, dhe secili vendos se cila Ă«shtĂ« mĂ« e pĂ«rshtatshme pĂ«r projektin e tij:

  1. Të fshihen branch-at e veçorive gjatë ndërtimit të branch-it master të integrimit të vazhdueshëm.

    • PĂ«r kĂ«tĂ«, duhet tĂ« dini se cili pull request i pĂ«rket commit-it qĂ« Ă«shtĂ« duke u ndĂ«rtuar. Duke qenĂ« se namespace-i i branch-it tĂ« veçorive pĂ«rmban identifikuesin e pull request-it - numrin e tij ose emrin e branch-it, identifikuesi gjithmonĂ« do tĂ« duhet tĂ« tregojĂ« nĂ« commit.
    • NdĂ«rtimet e branch-eve master kanĂ« dĂ«shtuar. Shembuj, keni kĂ«to hapa: shkarkoni projektin, krijoni testet, ndihmoni projektin, krijoni lĂ«shimin, dĂ«rgoni njoftimet, pastroni branch-in e veçorive tĂ« pull request-it tĂ« fundit. NĂ«se ndĂ«rtimi dĂ«shton nĂ« dĂ«rgimin e njoftimit, do t'ju duhet tĂ« fshini tĂ« gjitha burimet nĂ« klaster manuelisht.
    • Pa kontekstin e duhur, fshirja e branch-it tĂ« veçorive nĂ« ndĂ«rtimin e masterit nuk Ă«shtĂ« e qartĂ«.

  2. PĂ«rdorimi i webhook’ave (Ă«shtĂ«).

    • Mund tĂ« mos jetĂ« qasja juaj. PĂ«r shembull, nĂ« Jenkins, vetĂ«m njĂ« lloj pipeline mbĂ«shtet mundĂ«sinĂ« e ruajtjes sĂ« konfigurimeve tĂ« tij nĂ« kodin burimor. Kur pĂ«rdorni webhook’ë, duhet tĂ« shkruani skriptin tuaj pĂ«r t'i trajtuar ato. Ky skript do tĂ« duhet tĂ« vendoset nĂ« ndĂ«rfaqen e Jenkins, qĂ« Ă«shtĂ« e vĂ«shtirĂ« pĂ«r t'u mbajtur.

  3. Shkruani Cronjob dhe shtoni klasterin Kubernetes.

    • Koha e shpenzuar pĂ«r shkruarjen dhe mbĂ«shtetje.
    • Operatori tashmĂ« funksionon nĂ« njĂ« stil tĂ« ngjashĂ«m, Ă«shtĂ« dokumentuar dhe mbĂ«shtetet.

Faleminderit për vëmendjen ndaj artikullit. Shqyrtimi i projektit në Github.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster