ProHoster > Blogi > Haldamine > Eemaldame aegunud feature branch'i Kubernetes klastris

Eemaldame aegunud feature branch'i Kubernetes klastris

Eemaldame aegunud feature branch'i Kubernetes klastris

Tere! Funktsioonide haru (kaasa arvatud juurutamise eelvaade, ĂŒlevaate rakendus) — see on olukord, kus juurutatakse mitte ainult master haru, vaid ka iga pull request unikaalses URL-is. Sa saad kontrollida, kas kood töötab produktsioonikeskkonnas, funktsiooni saab teistele programmeerijatele vĂ”i tootearendajatele nĂ€idata. Kuni töötad pull request'is, eemaldatakse iga uus commit vana koodi jaoks praegune juurutamine ja uus juurutamine uue koodi jaoks kĂ€ivitatakse. KĂŒsimused vĂ”ivad tekkida siis, kui oled pull request'i master haru sisse sulgenud. Funktsioonide haru pole enam vajalik, kuid Kubernetes'i ressursid jÀÀvad ikkagi klastrisse.

Veel funktsioonide harudest

Üks lĂ€henemine funktsioonide harude tegemiseks Kubernetes'is on nimede ruumide kasutamine. LĂŒhidalt öeldes, produktsioonikonfiguratsioon nĂ€eb vĂ€lja nii:

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

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

Funktsioonide haru jaoks luuakse nimede ruum tema identifikaatoriga (nÀiteks pull request'i number) ja mingi prefiksi/postfiksi kasutamisega (nÀiteks, -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
...

LĂŒhidalt, ma kirjutasin Kubernetes Operator (rakendus, mis pÀÀseb ligi klastrite ressurssidele), link projekti kohta Githubis. See eemaldab namespace'id, mis kuuluvad vanade feature branch'ide juurde. Kuberneteses, kui namespace eemaldatakse, kustutatakse automaatselt ka kĂ”ik teised ressursid, mis selle namespace'i all on.

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

Feature branch'ide klastrisse juurutamise kohta saab lugeda siin ja siin.

Motivatsioon

Vaadakem, kuidas nĂ€eb vĂ€lja tĂŒĂŒpiline pull request’i elutsĂŒkkel koos pideva integreerimisega (continuous integration):

  1. Pusime uue commit'i harusse.
  2. Build'i ajal kÀivitatakse lintijad ja/vÔi testid.
  3. Kubernetes pull request'i konfiguratsioonid genereeritakse jooksvalt (nÀiteks tÀiendatakse valmisse ƥablooni selle numbriga).
  4. Kubectl apply abil jÔuavad konfiguratsioonid klastrisse (deploy).
  5. Pull request liidetakse master haruga.

Kuni töötate pull request'is, eemaldatakse iga uus commit vana koodi jaoks praegune deploy, ja uue koodi jaoks tehakse uus deploy. Kuid kui pull request liidetakse master haruga, ehitatakse ainult master haru. Tulemuseks on, et pull request'i kohta oleme juba unustanud, ent selle Kubernetes'i ressursid on klastris endiselt olemas.

Kasutamine

Installige projekt alloleva kÀsuga:

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

Looge fail jÀrgmise sisuga ja installige see kaudu kubectl apply -f:

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

Parameeter namespaceSubstring on vajalik, et filtreerida namespace'id teistest namespace'idest tulevate pull request'ide jaoks. NÀiteks, kui klastris on jÀrgmised namespace'id: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, siis kustutamise kandidaatideks on habr-back-end-pr-17, habr-back-end-pr-33.

Parameeter afterDaysWithoutDeploy on vajalik, et kustutada vanad namespace'id. NÀiteks, kui namespace on loodud 3 pÀeva 1 tund tagasi, ja parameetris on mÀrgitud 3 pÀeva, siis see namespace eemaldatakse. See toimib ka vastupidi, kui namespace on loodud 2 pÀeva 23 tundi tagasi, ja parameetris on mÀrgitud 3 pÀeva, siis see namespace ei eemaldata.

On veel ĂŒks parameeter, mis vastutab selle eest, kui tihti kontrollida kĂ”iki namespace'e ja jĂ€lgida pĂ€eva, mil ei ole deploy'd — checkEveryMinutes. Vaikimisi on see seadistatud 30 minutiks.

Kuidas see toimib

Praktiliselt on vajalik:

  1. Docker töötada isoleeritud keskkonnas.
  2. Minikube kÀivitab Kubernetes klastrit kohapeal.
  3. kubectl — kĂ€surealiides klastriga haldamiseks.

KĂ€ivitame Kubernetes klastrit kohapeal:

$ minikube start --vm-driver=docker
minikube v1.11.0 macOS 10.15.5
Kasutades docker-driverit olemasoleva profiili pÔhjal.
Alustades juhtimispunkte minikube klastris minikube.

MÀÀrake kubectl kasutada kohapealset klastrit vaikevalikuna:

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

Laadime alla konfigureerimise production keskkonnale:

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

Kuna production konfigureerimine on seadistatud kontrollima vanu namespace'e, ja meie uuesti loodud klastri puhul neid ei ole, muudame keskkonnamuutuja IS_DEBUG jÀrgnevaga true. Sellise vÀÀrtusega parameetrit afterDaysWithoutDeploy ei arvestata ning namespace'e ei kontrollita pÀrast deploy'd, vaid ainult alamstringi esinemise jÀrgi (-pr-).

Kui te olete Linux:

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

Kui te olete macOS:

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

Paigaldame projekti:

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

Kontrollime, et klastri ressursid on jooksnud StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NIMI               ... APIGROUP                             ... TÜÜP
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

Kontrollime, et klastri sees on operaator:

$ kubectl get pods --namespace stale-feature-branch-operator
NIMI                                         ... STAATUS ... VANUS
stale-feature-branch-operator-6bfbfd4df8-m7sch ... KĂ€ib ... 38s

Kui vaadata selle logisid, on see valmis ressursse töötlema 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}

Paigaldame valmis moodulid (valmis konfiguratsioon klastrite ressursside simuleerimiseks) ressursi jaoks StaleFeatureBranch:

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

Konfiguratsioonides on mÀÀratud otsida namespace'e, millel on alamstring -pr- iga 1 minut.:

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

Operaator reageeris ja on valmis kontrollima namespace'e:

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

Paigaldame moodulid, sisaldades kahte namespace'i (project-pr-1, project-pr-2) ja nende deployments, teenused, ingress, jne:

$ 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

Kontrollime, et kĂ”ik ĂŒlaltoodud ressursid on edukalt loodud:

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

Kuna me oleme sisse lĂŒlitanud debug, namespace’id project-pr-1 ja project-pr-2, peab ka kĂ”ik ĂŒlejÀÀnud ressursid kohe kustuma, arvestamata parameetrit afterDaysWithoutDeploy. See on nĂ€htav operaatori logides:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Nimi ruum peab olema kustutatud, kuna silumise reĆŸiim on lubatud.","namespaceName":"project-pr-1"}
... "msg":"Ruum on töötlemisel.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Ruum on kustutatud.","namespaceName":"project-pr-1"}
... "msg":"Nimi ruum peab olema kustutatud, kuna silumise reĆŸiim on lubatud.","namespaceName":"project-pr-2"}
... "msg":"Ruum on töötlemisel.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Ruum on kustutatud.","namespaceName":"project-pr-2"}

Kui kontrollite ressursside olemasolu, on need olekus Terminating (kustutamisprotsess) vĂ”i on juba eemaldatud (kĂ€skluse vĂ€ljund on tĂŒhi).

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

VÔite protsessi loomist korrata moodulid mitu korda ja veenduda, et need eemaldatakse minutite jooksul.

Alternatiivid

Mida saab teha, et asendada operaator, mis töötab klastri sees? On mitmeid lĂ€henemisviise, kĂ”ik ei ole ideaalsed (ja nende puudused on subjektiivsed), igaĂŒks peab ise otsustama, mis sobib kĂ”ige paremini konkreetsele projektile:

  1. Kustutada feature branch pideva integratsiooni master haru ehitamise ajal.

    • Selleks tuleb teada, milline pull request seondub commit'iga, mis ehitatakse. Kuna feature branch'i nimede ruum sisaldab pull request'i identifikaatorit - selle numbrit vĂ”i haru nime, tuleb identifikaator alati commit'is mĂ€rkida.
    • Master harude ehitused ebaĂ”nnestuvad. NĂ€iteks, teil on jĂ€rgmised etapid: projekt alla laadida, testid kĂ€ivitada, projekt kokku panna, vĂ€ljaanne luua, teavitused saata, viimane pull request'i feature branch puhastada. Kui ehitus ebaĂ”nnestub teavituste saatmisel, peate kĂ”ik klastrisse kuuluvad ressursid kĂ€sitsi kustutama.
    • Ilma nĂ”uetekohase kontekstita ei ole feature branch'i eemaldamine master ehitusest ilmselge.

  2. Webhook'ide kasutamine (an example).

    • VĂ”ib-olla ei ole see teie lĂ€henemine. NĂ€iteks, Jenkins, ainult ĂŒks pipeline'i tĂŒĂŒp toetab vĂ”imalust sĂ€ilitada selle konfiguratsioonid lĂ€htekoodis. Webhook'ide kasutamisel on vaja kirjutada oma skript nende töötlemiseks. See skript tuleb paigutada Jenkins'i liidesesse, mis on raske hallata.

  3. Kirjuta Cronjob ja lisa Kubernetes klaster.

    • Aja raiskamine skripti kirjutamisele ja hooldamisele.
    • Operaator töötab juba sarnases stiilis, on dokumenteeritud ja toetatud.

AitÀh tÀhelepanu eest artiklile. Link projekti kohta GitHubis.

Allikas: habr.com

Osta usaldusvÀÀrne veebihosting DDoS kaitsega, VPS VDS serverid đŸ”„ Osta usaldusvÀÀrne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster