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