ProHoster > Blogi > Haldamine > Kustutame vananenud feature branch'i Kubernetes klastris

Kustutame vananenud feature branch'i Kubernetes klastris

Kustutame vananenud feature branch'i Kubernetes klastris

Tere! Funktsioonide haru (aka juurutamise eelvaade, ĂŒlevaate rakendus) — see juurutab mitte ainult master haru, vaid ka iga pull request unikaalsel URL-il. Sa saad kontrollida, kas kood töötab tootmisĂŒmbers, ning funktsiooni saab nĂ€idata teistele programmeerijatele vĂ”i tootearendajatele. Kui töötad pull request'is, siis iga uus commit eemaldab praeguse juurdepÀÀsu vana koodiga ja valmis uus juurutus uue koodiga. KĂŒsimused vĂ”ivad tekkida siis, kui oled sulandanud pull request'i master harusse. Funktsioonide haru ei ole enam vajalik, kuid Kubernetes'e ressursid on endiselt klastris.

Veel funktsioonide harudest

Üks lĂ€henemisviis funktsioonide harude tegemiseks Kuberneteses on kasutada nimekaide. LĂŒhidalt öeldes nĂ€eb tootmiskonfiguratsioon vĂ€lja jĂ€rgmine:

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 nimekaid koos selle identifikaatoriga (nÀiteks pull request'i number) ja mingi prefiksiga/postfiksiga (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
...

Üldiselt, olen kirjutanud Kubernetes Operator (rakendus, mis pÀÀseb ligi klastrite ressurssidele), link projekti kohta Githubis. See eemaldab nimekaid, mis kuuluvad vanadele funktsioonide harudele. Kuberneteses, kui eemaldada nimekiri, eemaldatakse automaatselt ka kĂ”ik teised ressursid selles nimekaidis.

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

Funktsioonide harude rakendamise kohta klastris saab lugeda siit ja siit.

Motivatsioon

Vaatame tĂŒĂŒpilist pull request'i elutsĂŒklit pideva integreerimisega (continuous integration):

  1. Pusime uue commit'i harusse.
  2. Build'i ajal kÀivitatakse lintimise ja/vÔi testimise protsessid.
  3. Kubernetes pull request'i konfiguratsioonid genereeritakse reaalajas (nÀiteks selle numbri paigutamine valmis ƥablooni).
  4. Konfiguratsioonide juurutamine klastrisse toimub kubectl apply abil (deploy).
  5. Pull request sulandub master harusse.

Kui töötad pull request'is, siis iga uus commit eemaldab praeguse juurutuse vana koodiga ja valmis uus juurutus uue koodiga. Kuid kui pull request sulandub master harusse, ehitatakse ainult master haru. Tulemuseks on see, et pull request unustatakse, kuid selle Kubernetes'e ressursid on endiselt klastris.

Kuidas kasutada

Paigaldage projekt jÀrgmisel kÀsul:

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

Looge fail jÀrgmise sisuga ja paigaldage 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, mis kuuluvad teistele pull request'idele. NÀiteks, kui kluster sisaldab jÀrgmisi namespace'e: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, siis kaotsitavaks 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 parameetriks on mÀÀratud 3 pÀeva, siis see namespace kustutatakse. See töötab ka vastupidiselt, kui namespace on loodud 2 pÀeva 23 tundi tagasi, ja parameetriks on mÀÀratud 3 pÀeva, siis see namespace ei kustutata.

On veel ĂŒks parameeter, mis vastutab selle eest, kui sageli kontrollida kĂ”iki namespace'e ja kontrollida pĂ€evade puudumist deploy'ide osas — checkEveryMinutes. Vaikimisi on see mÀÀratud 30 minutiks.

Kuidas see töötab

Praktikas on vajalik:

  1. Docker töötamiseks isoleeritud keskkonnas.
  2. Minikube ĂŒles tĂ”sta Kubernetes kluster kohalikult.
  3. kubectl — kĂ€surealiides klustere haldamiseks.

TÔstame Kubernetes klustrit kohalikult:

$ minikube start --vm-driver=docker
minikube v1.11.0 Darwin 10.15.5 peal
Kasutades docker draiverit olemasoleva profiili pÔhjal.
KÀivitame kontrollplaani sÔlme minikube klustrites minikube.

MÀÀrame kubectl kasutame kohalikku klustrit vaikimisi:

$ kubectl config use-context minikube
Vahetatud konteksti "minikube".

Laadime alla produktsioonikeskkonna konfiguratsioonid:

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

Kuna produktsioonikonfiguratsioonid on seadistatud kontrollima vanu namespace'e, ja meie Àsja loodud klusteris neid ei ole, muudame keskkonna muutujat IS_DEBUG . Tundub, et true. Sellise vÀÀrtuse puhul ei arvestata parameetrit ja namespace'e ei kontrollita pÀevade puudumise tÔttu deploy'ide osas, vaid ainult alamtÀhe sisaldumise pÔhjal ( afterDaysWithoutDeploy Kui oled-pr-).

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

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

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

Paigaldame projekti:

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

Kontrollime, et klusteris on ilmunud ressurss

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

Kontrollime, et klusteris on ilmunud operaator:

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

Kui vaatame tema logisid, on ta valmis töötlema ressursse

$ 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} $ kubectl api-resources | grep stalefeaturebranches NAME ... APIGROUP ... KIND stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch:

Paigaldame valmis

fixtures kinnitusvahendid (valmis konfiguratsioon klastrite ressursi mudeldamiseks) ressursi jaoks $ kubectl api-resources | grep stalefeaturebranches NAME ... APIGROUP ... KIND stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... 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, mis sisaldavad alamsÔne -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 kinnitusvahendid, mis sisaldavad kahte namespace'i (project-pr-1, project-pr-2) ja nende deployments, teenused, ingress, ja nii edasi:

$ 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
...
NIMI                              ... VALMIS ... SEISUND  ... VANUS
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Jookseb ... 67s

NIMI                            ... VALMIS ... SAADAV ... VANUS
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

Kuna oleme lĂŒlitanud debug, namespace'id project-pr-1 ja project-pr-2, seega peavad ka kĂ”ik teised ressursid kohe kustutama, arvestamata parameetrit afterDaysWithoutDeploy. Operaatori logides on see nĂ€htav:

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

Kui kontrollida ressursside olemasolu, on need olekus Termineeritud (kustutusprotsess) vĂ”i on juba kustutatud (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
...

Saate protsessi loomist uuesti korrata kinnitusvahendid kontrollige mitu korda ja veenduge, et need eemaldatakse minuti jooksul.

Alternatiivid

Mida teha, kui klastris töötavat operaatori asemel? LĂ€henemisviise on mitu, kĂ”ik ei ole ideaalsed (ja nende puudused on subjektiivsed), ning igaĂŒks peab ise otsustama, mis sobib kĂ”ige paremini konkreetsele projektile:

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

    • Selleks peab teadma, milline pull request kuulub ehitatavale commit'ile. Kuna feature branch nimekiri sisaldab pull request’i identifikaatorit — selle numbrit vĂ”i haru nime, tuleb identifikaator alati commit'is mĂ€rkida.
    • Master haru ehitused ebaĂ”nnestuvad. NĂ€iteks, teil on jĂ€rgmised etapid: projekti allalaadimine, testide kĂ€itamine, projekti koostamine, vĂ€ljaanne, teavituste saatmine, viimase pull request’i feature branch'i puhastamine. Kui ehitus ebaĂ”nnestub teavituste saatmisel, peate kĂ”ik klastrisse kuuluvad ressursid kĂ€sitsi eemaldama.
    • Ilma korraliku kontekstita ei ole feature branch’i eemaldamine master ehituses ilmne.

  2. Webhook'ide kasutamine (nÀide).

    • VĂ”ib-olla ei ole see teie lĂ€henemine. NĂ€iteks, Jenkinsile, ainult ĂŒks juba olemasolev torujuhe toetab oma konfiguratsiooni salvestamist lĂ€hdekoodis. Webhook'ide kasutamisel peate kirjutama oma skripti nende töötlemiseks. See skript tuleb paigaldada Jenkins'i liidesesse, mis on keeruline hooldada.

  3. Kirjutage Cronjob ja lisage Kubernetes klaster.

    • Aja kulu skripti kirjutamiseks ja hooldamiseks.
    • Operaator töötab juba sarnasel stilil, on dokumenteeritud ja toetatud.

AitÀh artikli eest. Projektiga seotud link Github'is.

Allikas: habr.com

Osta usaldusvÀÀrne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid đŸ”„ Osta usaldusvÀÀrne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid | ProHoster