ProHoster > Bloc > Administració > Eliminació d'una branca de funció obsoleta en un clúster de Kubernetes

Eliminació d'una branca de funció obsoleta en un clúster de Kubernetes

Eliminació d'una branca de funció obsoleta en un clúster de Kubernetes

Hi! Branca de característiques (també conegut com a vista prèvia de desplegament, aplicació de revisió): és quan no només es desplega la branca mestra, sinó també cada sol·licitud d'extracció a un URL únic. Podeu comprovar si el codi funciona en un entorn de producció; la funció es pot mostrar a altres programadors o especialistes en productes. Mentre esteu treballant en una sol·licitud d'extracció, s'elimina cada nova confirmació, el desplegament actual del codi antic i es desplega el nou desplegament del codi nou. Poden sorgir preguntes quan fusioneu una sol·licitud d'extracció a la branca mestra. Ja no necessiteu la branca de funcions, però els recursos de Kubernetes encara es troben al clúster.

Més informació sobre les branques de característiques

Un enfocament per fer branques de característiques a Kubernetes és utilitzar espais de noms. En resum, la configuració de producció és així:

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

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

Per a una branca de característiques, es crea un espai de noms amb el seu identificador (per exemple, el número de sol·licitud d'extracció) i algun tipus de prefix/postfix (per exemple, -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
...

En general, vaig escriure Operador Kubernetes (una aplicació que té accés als recursos del clúster), enllaç al projecte a Github. Elimina els espais de noms que pertanyen a branques de funcions antigues. A Kubernetes, si suprimiu un espai de noms, altres recursos d'aquest espai de noms també se suprimiran automàticament.

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

Podeu llegir sobre com implementar branques de característiques en un clúster aquí и aquí.

RњRѕS, ReRІR ° C † ReSЏ

Vegem un cicle de vida típic de sol·licituds d'extracció amb integració contínua (continuous integration):

  1. Impulsem un nou compromís amb la sucursal.
  2. A la construcció, s'executen linters i/o proves.
  3. Les configuracions de sol·licitud d'extracció de Kubernetes es generen sobre la marxa (per exemple, el seu número s'insereix a la plantilla acabada).
  4. Mitjançant kubectl apply, s'afegeixen configuracions al clúster (desplegament).
  5. La sol·licitud d'extracció es fusiona amb la branca mestra.

Mentre esteu treballant en una sol·licitud d'extracció, cada nova confirmació, el desplegament actual del codi antic s'elimina i el nou desplegament del codi nou es desplega. Però quan una sol·licitud d'extracció es fusiona a la branca mestra, només es construirà la branca mestra. Com a resultat, resulta que ja ens hem oblidat de la sol·licitud d'extracció i els seus recursos de Kubernetes encara es troben al clúster.

Com s'utilitza

Instal·leu el projecte amb l'ordre següent:

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

Creeu un fitxer amb el contingut següent i instal·leu-lo mitjançant kubectl apply -f:

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

Paràmetre namespaceSubcadena necessari per filtrar espais de noms per a sol·licituds d'extracció d'altres espais de noms. Per exemple, si el clúster té els següents espais de noms: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, llavors els candidats a supressió seran habr-back-end-pr-17, habr-back-end-pr-33.

Paràmetre afterDaysWithoutDeploy necessari per esborrar espais de noms antics. Per exemple, si es crea un espai de noms 3 дня 1 час enrere i el paràmetre indica 3 дня, aquest espai de noms se suprimirà. També funciona en sentit contrari si es crea l'espai de noms 2 дня 23 часа enrere i el paràmetre indica 3 дня, aquest espai de noms no se suprimirà.

Hi ha un paràmetre més, és responsable de la freqüència amb què escanejar tots els espais de noms i comprovar durant dies sense desplegament: checkEveryMinutes. Per defecte és igual 30 минутам.

Com funciona això

A la pràctica, necessitareu:

  1. estibador per treballar en un entorn aïllat.
  2. Minikube generarà un clúster de Kubernetes localment.
  3. kubectl — Interfície de línia d'ordres per a la gestió de clúster.

Creem un clúster de Kubernetes localment:

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

Ho indiquem kubectl utilitzar el clúster local per defecte:

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

Baixeu les configuracions per a l'entorn de producció:

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

Com que les configuracions de producció estan configurades per comprovar els espais de noms antics i el nostre clúster recentment creat no en té, substituirem la variable d'entorn IS_DEBUG en true. Amb aquest valor el paràmetre afterDaysWithoutDeploy no es té en compte i els espais de noms no es comproven durant dies sense desplegament, només per a l'aparició de la subcadena (-pr-).

Si estàs activat Linux:

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

Si estàs activat macOS:

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

Instal·lació del projecte:

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

Comprovació que un recurs ha aparegut al clúster StaleFeatureBranch:

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

Comprovem que ha aparegut un operador al clúster:

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

Si mireu els seus registres, està preparat per processar recursos 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}

Instal·lem ja fets fixtures (configuracions preparades per modelar recursos de clúster) per a un recurs StaleFeatureBranch:

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

Les configuracions indiquen cercar espais de noms amb una subcadena -pr- una vegada cada 1 минуту.:

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

L'operador ha respost i està preparat per comprovar els espais de noms:

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

Establir fixtures, que conté dos espais de noms (project-pr-1, project-pr-2) i ells deployments, services, ingress, etcètera:

$ 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

Comprovem que tots els recursos anteriors s'han creat correctament:

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

Des que vam incloure debug, espais de noms project-pr-1 и project-pr-2, per tant, tots els altres recursos s'hauran de suprimir immediatament sense tenir en compte el paràmetre afterDaysWithoutDeploy. Això es pot veure als registres de l'operador:

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

Si comproveu la disponibilitat de recursos, estaran en estat Terminating (procés de supressió) o ja s'ha suprimit (la sortida de l'ordre està buida).

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

Podeu repetir el procés de creació fixtures diverses vegades i assegureu-vos que s'eliminen en un minut.

Alternatives

Què es pot fer en lloc d'un operador que treballa en un clúster? Hi ha diversos enfocaments, tots són imperfectes (i les seves mancances són subjectives) i cadascú decideix per si mateix què és el millor per a un projecte concret:

  1. Suprimeix la branca de funcions durant la creació d'integració contínua de la branca mestra.

    • Per fer-ho, heu de saber quina sol·licitud d'extracció es relaciona amb la confirmació que s'està creant. Com que l'espai de noms de la branca de funcions conté l'identificador de la sol·licitud d'extracció: el seu número o el nom de la branca, l'identificador sempre s'haurà d'especificar a la confirmació.
    • Les compilacions de la branca mestra fallen. Per exemple, teniu les etapes següents: descarregar el projecte, executar proves, crear el projecte, fer un llançament, enviar notificacions, esborrar la branca de funcions de l'última sol·licitud d'extracció. Si la compilació falla quan envieu una notificació, haureu de suprimir tots els recursos del clúster manualment.
    • Sense un context adequat, la supressió de branques de característiques a la compilació mestra no és obvi.

  2. Ús de webhooks (exemple).

    • Aquest pot no ser el vostre enfocament. Per exemple, en Jenkins, només un tipus de canalització admet la possibilitat de desar les seves configuracions al codi font. Quan utilitzeu webhooks, heu d'escriure el vostre propi script per processar-los. Aquest script s'haurà de col·locar a la interfície de Jenkins, que és difícil de mantenir.

  3. Per escriure Cronjob i afegiu un clúster de Kubernetes.

    • Dedicar temps a escriure i donar suport.
    • L'operador ja treballa amb un estil similar, està documentat i recolzat.

Gràcies per la vostra atenció a l'article. Enllaç al projecte a Github.

Font: www.habr.com

Afegeix comentari