🥇Töröljük a régi feature branch-t a Kubernetes klaszterben

Helló! Jellemző ág (más néven telepítési előnézet, áttekintő alkalmazás) — ez az, amikor nemcsak a master ágat telepítjük, hanem minden egyes pull request-et is egyedi URL-re. Ellenőrizni lehet, hogy a kód működik-e a gyártási környezetben, és a funkciót bemutathatjuk más programozóknak vagy termékfejlesztőknek. Amíg a pull request-ben dolgozol, minden új commit esetén a jelenlegi telepítés az előző kódra törlődik, míg egy új telepítés a friss kódra kerül ki. Kérdések merülhetnek fel, amikor a pull request-et a master ágba olvasztottad. A jellemző ágra már nincs szükséged, de a Kubernetes erőforrások még mindig a klaszterben maradnak.

További információ a jellemző ágakról

Az egyik megközelítés a jellemző ágak létrehozásához a Kubernetes-ben a namespace-ek használata. Röviden, a gyártási konfiguráció a következőképpen néz ki:

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

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

A jellemző ág számára egy namespace-t hozunk létre a hozzá tartozó azonosítóval (például a pull request számával) és valamilyen előtaggal/utótaggal (például, -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
...

Összességében írtam Kubernetes Operator (alkalmazás, amely hozzáfér a klaszter erőforrásaihoz), link a projekthez a Github-on. Az eltávolítja a régi jellemző ágakhoz tartozó namespace-eket. A Kubernetes-ben, ha eltávolítod a namespace-t, a többi erőforrás, amely abban a namespace-ben található, automatikusan törlődik.

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

A jellemző ágak klaszterbe történő bevezetéséről olvashatsz itt és itt.

Motiváció

Nézzük meg egy tipikus pull request életciklusát folyamatos integrációval (continuous integration):

Új commitot toltunk az ágba.
A build során linters és/vagy tesztek futnak.
A pull request Kubernetes konfigurációi dinamikusan generálódnak (például a megfelelő sablonba beillesztve a számát).
A kubectl apply segítségével a konfigurációk a klaszterbe kerülnek (telepítve).
A pull request összevonása a master ággal.

Amíg a pull request-ben dolgozol, minden új commit esetén a jelenlegi telepítés az előző kódra törlődik, míg egy új telepítés a friss kódra kerül ki. De amikor a pull request összevonásra kerül a master ágba, akkor csak a master ág épül fel. Ennek eredményeként úgy tűnik, hogy a pull request-re már elfeledkeztünk, míg a Kubernetes erőforrásai még mindig a klaszterben vannak.

Hogyan használjuk

Telepítsd a projektet az alábbi parancs segítségével:

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

Hozz létre egy fájlt a következő tartalommal, és telepítsd a következők segítségével: kubectl apply -f:

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

A parameter namespaceSubstring szükséges a namespace-ek szűréséhez a más namespace-ek pull request-jeihez. Például, ha a klaszterben a következő namespace-ek vannak: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, akkor a törlésre jelöltek habr-back-end-pr-17, habr-back-end-pr-33.

A parameter afterDaysWithoutDeploy azért szükséges, hogy törölje a régi namespace-eket. Például, ha a namespace létrehozva 3 nappal 1 órával ezelőtt, és a paraméter azt mondja 3 nap, ez a namespace törölve lesz. Fordított esetben is működik, ha a namespace létrehozva 2 nappal 23 órával ezelőtt, és a paraméter azt mondja 3 nap, ez a namespace nem lesz törölve.

Van egy másik paraméter is, amely meghatározza, hogy milyen gyakran ellenőrizzük az összes namespace-t a deploy nélküli napok miatt — checkEveryMinutes. Alapértelmezés szerint ez 30 perc.

Hogyan működik ez

Gyakorlatban szükséges:

Docker izolált környezetben való működéshez.
Minikube lokálisan emeli fel a Kubernetes klasztert.
kubectl — parancssori felület a klaszter kezelésére.

Lokálisan emeljük fel a Kubernetes klasztert:

$ minikube start --vm-driver=docker
minikube v1.11.0 Darwin 10.15.5 rendszeren
A docker drivert használja a meglévő profil alapján.
Kezdjük a vezérlő sík csomópontot a minikube klaszterben.

Megadjuk kubectl alapértelmezés szerint a helyi klasztert használja:

$ kubectl config use-context minikube
Átkapcsoltunk a "minikube" kontextusra.

Letöltjük a konfigurációkat a production környezethez:

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

Mivel a production konfigurációk be vannak állítva az öreg namespace-ek ellenőrzésére, és az újonnan emelt klaszterünkben nincsenek, megváltoztatjuk a környezeti változót IS_DEBUG Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata igaz. Ezzel az értékkel a paraméter afterDaysWithoutDeploy nem kerül figyelembevételre, és a namespace-eket nem ellenőrzik a deploy nélküli napok miatt, csak a substring belépésére (-pr-).

Ha Ön a Linux:

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

Ha Ön a macOS:

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

Telepítjük a projektet:

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

Ellenőrizzük, hogy a klaszterben megjelent az erőforrás StaleFeatureBranch:

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

Ellenőrizzük, hogy a klaszterben megjelent az operátor:

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

Ha belenézünk a naplójába, készen áll az erőforrások feldolgozására StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operátor Verzió: 0.0.1"}
...
... "msg":"Eseményforrás indítása", ... , "source":"kind source: \/, Kind="}
... "msg":"Vezérlő indítása", ...}
... "msg":"Munkások indítása", ..., "worker count":1}

Telepítjük a kész fixtures (kész konfigurációk a klaszter erőforrásainak modellezéséhez) az erőforráshoz StaleFeatureBranch:

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

A konfigurációkban meg van adva, hogy a namespace-eket a következő alsubstring alapján keresse: -pr- minden 1 percben.:

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

Az operátor reagált, és készen áll a namespace-ek ellenőrzésére:

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

Telepítünk fixtures, amely két namespace-t tartalmaz (project-pr-1, project-pr-2) és azok telepítések, szolgáltatásai, ingress, stb.:

$ 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

Ellenőrizzük, hogy az összes fent említett erőforrás sikeresen létrejött:

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

Mivel aktiváltuk debug, a namespace-ek project-pr-1 és project-pr-2, ezért az összes többi erőforrásnak is azonnal el kell tűnnie, figyelmen kívül hagyva a paramétert afterDaysWithoutDeploy. Ez az operátor naplóiban látható:

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

Ha ellenőrizzük az erőforrások meglétét, akkor azok Terminating (törlési folyamat) állapotban lesznek, vagy már törölve vannak (a parancs kimenete üres).

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

Ismételheti a létrehozási folyamatot fixtures többször is, és megvizsgálhatja, hogy a törlés egy percen belül megtörténik.

Alternatívák

Mit lehet tenni a clusterben működő operátor helyett? Számos megközelítés létezik, mindegyik nem tökéletes (és azok hátrányai szubjektívak), és mindenki maga dönti el, mi a legjobb a konkrét projekthez:

A feature branch törlése a master branch folyamatos integrációs buildje alatt.
- Ehhez tudni kell, melyik pull request tartozik ahhoz a commit-hoz, ami éppen be van építve. Mivel a feature branch namespace tartalmazza a pull request azonosítóját – annak számát vagy a branch nevét, az azonosítót mindig fel kell tüntetni a commitban.
- A master branch buildjei meghiúsulnak. Például az alábbi lépések vannak: letölteni a projektet, futtatni a teszteket, összerakni a projektet, kiadni, értesítéseket küldeni, törölni a legutóbbi pull request feature branch-ét. Ha a build meghiúsul az értesítések küldésénél, manuálisan kell törölni az összes erőforrást a clustereben.
- Megfelelő kontextus nélkül a feature branch törlése a master buildben nem nyilvánvaló.
Webhook-ok használata (példám).
- Lehetséges, hogy ez nem a te megközelítésed. Például a Jenkins, csak egyfajta pipeline támogatja a konfigurációk forrákódba történő mentését. Webhook-ok használatakor saját scriptet kell írni a feldolgozásukhoz. Ezt a scriptet a Jenkins felületén kell elhelyezni, ami nehezen karbantartható.
Írj egy Cronjob-ot és add hozzá a Kubernetes klasztert.
- Időráfordítás az írásra és a karbantartásra.
- Az operátor már hasonló stílusban működik, dokumentált és karbantartott.