ProHoster > Blog > Administratioun > Ewechzehuelen eng verännert Featurezweig an engem Kubernetes Cluster

Ewechzehuelen eng verännert Featurezweig an engem Kubernetes Cluster

Ewechzehuelen eng verännert Featurezweig an engem Kubernetes Cluster

Hallo! Feature Branche (alias Deploy Preview, Review App) - dëst ass wann net nëmmen d'Master Branche ofgesat gëtt, awer och all Pull Ufro op eng eenzegaarteg URL. Dir kënnt iwwerpréiwen ob de Code an engem Produktiounsëmfeld funktionnéiert kann d'Feature fir aner Programméierer oder Produktspezialisten gewise ginn. Wärend Dir an enger Pull-Ufro schafft, gëtt all nei Verpflichtung aktuell Deploy fir den ale Code geläscht, an den neien Deploy fir den neie Code gëtt ausgerullt. Froen kënnen optrieden wann Dir eng Pull-Ufro an d'Meeschtesch Branche fusionéiert hutt. Dir braucht net méi d'Feature Branche, awer d'Kubernetes Ressourcen sinn nach ëmmer am Cluster.

Méi iwwer Feature Filialen

Eng Approche fir Feature Filialen a Kubernetes ze maachen ass Nummraim ze benotzen. Kuerz gesot, d'Produktiounskonfiguratioun gesäit esou aus:

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

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

Fir eng Feature-Branche gëtt en Nummraum erstallt mat sengem Identifizéierer (zum Beispill, der Pull-Ufro-Nummer) an enger Aart vu Präfix / Postfix (zum Beispill, -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
...

Am Allgemengen hunn ech geschriwwen Kubernetes Bedreiwer (eng Applikatioun déi Zougang zu Clusterressourcen huet), Link zum Projet op Github. Et läscht Nummraim déi zu alen Featurezweige gehéieren. A Kubernetes, wann Dir e Nummraum läscht, ginn aner Ressourcen an deem Nummraum och automatesch geläscht.

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

Dir kënnt liesen wéi Dir Feature Filialen an e Cluster implementéiert hei и hei.

Motivatioun

Loosst eis en typesche Pull Ufro Liewenszyklus mat kontinuéierlecher Integratioun kucken (continuous integration):

  1. Mir drécken en neit Engagement fir d'Branche.
  2. Op der Build, linters an / oder Tester lafen.
  3. Kubernetes Pull Ufro Konfiguratiounen ginn op der Flucht generéiert (zum Beispill, seng Zuel gëtt an de fäerdege Schabloun agebaut).
  4. Mat kubectl applizéiert ginn Konfiguratiounen an de Cluster bäigefüügt (deploy).
  5. Pull Ufro ass an d'Meeschtesch Branche fusionéiert.

Wärend Dir an enger Pull-Ufro schafft, gëtt all nei Verpflichtung aktuell Deploy fir den ale Code geläscht, an den neien Deploy fir den neie Code gëtt ausgerullt. Awer wann eng Pull-Ufro an d'Meeschterzweig fusionéiert gëtt, gëtt nëmmen d'Meeschterzweig gebaut. Als Resultat stellt et eraus datt mir d'Pull-Ufro scho vergiess hunn, a seng Kubernetes Ressourcen sinn nach ëmmer am Cluster.

Wéi benotzen

Installéiert de Projet mam Kommando hei ënnen:

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

Erstellt eng Datei mat dem folgenden Inhalt an installéiert via kubectl apply -f:

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

Parameter NummraumSubstring néideg fir Nummraim fir Pull-Ufroe vun aneren Nummraim ze filteren. Zum Beispill, wann de Cluster déi folgend Nummraim huet: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, da wäerten d'Kandidate fir d'Läsche sinn habr-back-end-pr-17, habr-back-end-pr-33.

Parameter afterDaysWithoutDeploy néideg fir al Nummraim ze läschen. Zum Beispill, wann Nummraum erstallt gëtt 3 дня 1 час zréck, an de Parameter weist 3 дня, gëtt dësen Nummraum geläscht. Et funktionnéiert och an der Géigendeel Richtung wann den Nummraum erstallt gëtt 2 дня 23 часа zréck, an de Parameter weist 3 дня, gëtt dësen Nummraum net geläscht.

Et gëtt nach ee Parameter, et ass verantwortlech fir wéi dacks all Nummraim ze scannen a fir Deeg ouni Deployment ze kontrolléieren - checkEveryMinutes. Par défaut ass et gläich 30 минутам.

Wéi heescht dat Aarbecht

An der Praxis braucht Dir:

  1. Docker fir an engem isoléierten Ëmfeld ze schaffen.
  2. Minikube wäert e Kubernetes Stärekoup lokal erhéijen.
  3. kubectl - Kommando Linn Interface fir Cluster Gestioun.

Mir erhéijen e Kubernetes Cluster lokal:

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

Mir uginn kubectl benotzt lokal Cluster als Standard:

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

Download Konfiguratiounen fir d'Produktiounsëmfeld:

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

Well d'Produktiounskonfiguratioune konfiguréiert sinn fir al Nummraim z'iwwerpréiwen, an eise nei opgehuewe Cluster se net huet, ersetzen mir d'Ëmfeldvariabel IS_DEBUG op true. Mat dësem Wäert de Parameter afterDaysWithoutDeploy gëtt net berücksichtegt an Nummraim ginn net fir Deeg iwwerpréift ouni Deploy, nëmme fir d'Optriede vun der Ënnerstring (-pr-).

Wann Dir op Linux:

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

Wann Dir op macOS:

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

Installatioun vum Projet:

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

Iwwerpréift datt eng Ressource am Cluster opgetaucht ass StaleFeatureBranch:

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

Mir kontrolléieren ob e Bedreiwer am Cluster opgetaucht ass:

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

Wann Dir op seng Logbicher kuckt, ass et prett Ressourcen ze veraarbecht 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}

Mir installéieren prett gemaach fixtures (fäerdeg Konfiguratioune fir Modelléiere vu Clusterressourcen) fir eng Ressource StaleFeatureBranch:

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

D'Konfiguratioune weisen op fir no Nummraim mat enger Ënnerstring ze sichen -pr- eemol all 1 минуту.:

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

De Bedreiwer huet geäntwert an ass prett fir Nummraim ze kontrolléieren:

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

Installéieren fixtures, mat zwee Nummraim (project-pr-1, project-pr-2) an hinnen deployments, services, ingress, a sou weider:

$ 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

Mir kontrolléieren ob all d'Ressourcen hei uewen erfollegräich erstallt goufen:

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

Zënter mir abegraff debug, Nummraim project-pr-1 и project-pr-2, dofir mussen all aner Ressourcen direkt geläscht ginn ouni de Parameter ze berücksichtegen afterDaysWithoutDeploy. Dëst kann an de Bedreiwer Logbicher gesi ginn:

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

Wann Dir d'Disponibilitéit vu Ressourcen iwwerpréift, wäerte se am Status sinn Terminating (Läschprozess) oder scho geläscht (Kommandoausgang ass eidel).

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

Dir kënnt de Kreatiounsprozess widderhuelen fixtures e puer Mol a gitt sécher datt se bannent enger Minutt ewechgeholl ginn.

Alternativen

Wat kann amplaz vun engem Bedreiwer gemaach ginn, deen an engem Cluster schafft? Et gi verschidde Approchen, all si onvollstänneg (an hir Mängel sinn subjektiv), a jidderee entscheet fir sech selwer wat am Beschten fir e bestëmmte Projet ass:

  1. Läschen Feature Branche wärend der kontinuéierlecher Integratiounsbau vun der Master Branche.

    • Fir dëst ze maachen, musst Dir wësse wéi eng Pull-Ufro op den Engagement bezitt deen gebaut gëtt. Zënter der Feature Branche Nummraum enthält den Pull Ufro Identifizéierer - seng Nummer, oder den Numm vun der Branche, muss den Identifizéierer ëmmer an der Verpflichtung spezifizéiert ginn.
    • Master Branche baut versoen. Zum Beispill hutt Dir déi folgend Etappen: de Projet eroflueden, Tester ausféieren, de Projet bauen, eng Verëffentlechung maachen, Notifikatiounen schécken, d'Featurezweige vun der leschter Pull-Ufro läschen. Wann de Build feelt wann Dir eng Notifikatioun schéckt, musst Dir all Ressourcen am Cluster manuell läschen.
    • Ouni richtege Kontext ass d'Läsche vun Featurezweige am Masterbuild net offensichtlech.

  2. Benotzt Webhooks (Beispill).

    • Dëst ass vläicht net Är Approche. Zum Beispill, an Jenkins, nëmmen eng Zort Pipeline ënnerstëtzt d'Fäegkeet fir seng Konfiguratiounen am Quellcode ze späicheren. Wann Dir Webhooks benotzt, musst Dir Ären eegene Skript schreiwen fir se ze veraarbecht. Dëst Skript muss an der Jenkins Interface gesat ginn, wat schwéier ze erhalen ass.

  3. Schreif Cronjob a füügt e Kubernetes-Cluster derbäi.

    • Zäit fir Schreiwen an Ënnerstëtzung ze verbréngen.
    • De Bedreiwer schafft schonn an engem ähnlechen Stil, ass dokumentéiert an ënnerstëtzt.

Merci fir Är Opmierksamkeet op den Artikel. Link zum Projet op Github.

Source: will.com

Setzt e Commentaire