ProHoster > Blog > administratie > Het verwijderen van een verouderde feature branch in een Kubernetes-cluster

Het verwijderen van een verouderde feature branch in een Kubernetes-cluster

Het verwijderen van een verouderde feature branch in een Kubernetes-cluster

Hey there! Functietak (ook wel implementatievoorbeeld, beoordelingsapp genoemd) β€” hierbij wordt niet alleen de masterbranch geΓ―mplementeerd, maar ook elke pull-aanvraag naar een unieke URL. U kunt controleren of de code werkt in een productieomgeving en de functionaliteit kunt u aan andere programmeurs of productmanagers laten zien. Terwijl u aan een pull-aanvraag werkt, verwijdert elke nieuwe commit de huidige implementatie voor de oude code en rolt een nieuwe implementatie voor de nieuwe code uit. Er kunnen vragen ontstaan ​​wanneer u een pull request samenvoegt met de master branch. Je hebt de feature branch niet meer nodig, maar de Kubernetes-resources bevinden zich nog steeds in het cluster.

Meer over feature branches

EΓ©n aanpak voor het maken van feature branches in Kubernetes is het gebruik van naamruimten. Kort gezegd ziet de productieconfiguratie er als volgt uit:

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

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

Voor een feature branch wordt een naamruimte gemaakt met de bijbehorende identificatie (bijvoorbeeld het pull request-nummer) en een voorvoegsel/achtervoegsel (bijvoorbeeld -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
...

Hoe dan ook, ik schreef Kubernetes-operator (een applicatie die toegang heeft tot clusterbronnen), link naar het project op Github. Hiermee worden naamruimten verwijderd die verwijzen naar oude feature branches. Als u in Kubernetes een naamruimte verwijdert, worden andere resources in die naamruimte ook automatisch verwijderd.

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

U kunt lezen hoe u feature branches in een cluster implementeert hier ΠΈ hier.

Motivatie

Laten we eens kijken naar de typische levenscyclus van een pull-aanvraag met continue integratie (continuous integration):

  1. Push een nieuwe commit naar de branch.
  2. Tijdens de build worden linters en/of tests uitgevoerd.
  3. Configuraties voor pull-aanvragen in Kubernetes worden direct gegenereerd (het nummer wordt bijvoorbeeld vervangen door een kant-en-klare sjabloon).
  4. Met behulp van kubectl apply worden configuraties naar het cluster geΓ―mplementeerd.
  5. De pull-aanvraag wordt samengevoegd in de master-branch.

Terwijl u aan een pull-aanvraag werkt, verwijdert elke nieuwe commit de huidige implementatie voor de oude code en rolt een nieuwe implementatie voor de nieuwe code uit. Maar wanneer een pull request wordt samengevoegd in de master branch, wordt alleen de master branch gebouwd. Het blijkt dat we de pull request alweer vergeten zijn en dat de Kubernetes-resources zich nog steeds in het cluster bevinden.

Hoe te gebruiken

Installeer het project met de onderstaande opdracht:

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

Maak een bestand met de volgende inhoud en installeer via kubectl apply -f:

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

Parameter naamruimteSubstring nodig om naamruimten te filteren voor pull-aanvragen van andere naamruimten. Als een cluster bijvoorbeeld de volgende naamruimten heeft: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, dan zullen de kandidaten voor verwijdering zijn habr-back-end-pr-17, habr-back-end-pr-33.

Parameter naDagenZonderImplementatie nodig om oude naamruimten te verwijderen. Als er bijvoorbeeld een naamruimte wordt aangemaakt 3 дня 1 час terug, en de parameter geeft aan 3 дня, wordt deze naamruimte verwijderd. Het werkt ook andersom, als de naamruimte wordt aangemaakt 2 дня 23 часа terug, en de parameter geeft aan 3 дня, wordt deze naamruimte niet verwijderd.

Er is nog een parameter die verantwoordelijk is voor hoe vaak alle naamruimten moeten worden gescand en er moet worden gecontroleerd op dagen zonder implementatie. controleerElkeMinuten. Standaard is dit gelijk aan 30 ΠΌΠΈΠ½ΡƒΡ‚Π°ΠΌ.

Hoe werkt dit

In de praktijk heeft u het volgende nodig:

  1. havenarbeider voor werk in een geΓ―soleerde omgeving.
  2. Minikubus zal lokaal een Kubernetes-cluster opzetten.
  3. kubectl β€” opdrachtregelinterface voor clusterbeheer.

We zetten lokaal een Kubernetes-cluster op:

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

Specificeer kubectl Standaard lokaal cluster gebruiken:

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

Configuraties downloaden voor de productieomgeving:

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

Omdat de productieconfiguraties zijn ingesteld om oude naamruimten te controleren en ons nieuw opgerichte cluster deze niet heeft, zullen we de omgevingsvariabele IS_DEBUG op true. Met deze waarde wordt de parameter afterDaysWithoutDeploy wordt niet in aanmerking genomen en naamruimten worden niet gecontroleerd op dagen zonder implementatie, alleen op het voorkomen van een subtekenreeks (-pr-).

Als je aan bent Linux:

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

Als je aan bent macOS:

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

Installeer het project:

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

We controleren of de bron in het cluster is verschenen StaleFeatureBranch:

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

We controleren of de operator in het cluster voorkomt:

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

Als u de logs bekijkt, is het programma klaar om bronnen te verwerken. 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}

Wij installeren kant-en-klare fixtures (kant-en-klare configuraties voor het modelleren van clusterbronnen) voor de bron StaleFeatureBranch:

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

De configuraties specificeren dat er gezocht moet worden naar naamruimten met een subtekenreeks -pr- eens een 1 ΠΌΠΈΠ½ΡƒΡ‚Ρƒ.:

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

De operator heeft gereageerd en is klaar om de naamruimten te controleren:

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

Ingesteld fixtures, met twee naamruimten (project-pr-1, project-pr-2) en hun deployments, services, ingress, enzovoort:

$ 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

Laten we controleren of alle bovenstaande bronnen succesvol zijn aangemaakt:

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

Aangezien we hebben opgenomen debug, naamruimten project-pr-1 ΠΈ project-pr-2, daarom zullen alle andere bronnen onmiddellijk moeten worden verwijderd zonder rekening te houden met de parameter afterDaysWithoutDeploy. Dit is te zien in de operatorlogboeken:

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

Als u controleert op de beschikbaarheid van bronnen, zullen deze de status hebben Terminating (verwijderingsproces) of al verwijderd (opdrachtuitvoer is leeg).

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

Je kunt het creatieproces herhalen fixtures meerdere keren en zorg ervoor dat ze binnen een minuut verwijderd zijn.

alternatieven

Wat kan er gedaan worden in plaats van de operator die in het cluster werkt? Er zijn verschillende benaderingen, die niet allemaal ideaal zijn (en hun tekortkomingen zijn subjectief) en iedereen beslist voor zichzelf wat het beste past bij een specifiek project:

  1. Verwijder de feature branch tijdens de continue integratie-build van de master branch.

    • Om dit te doen, moet je weten welke pull request hoort bij de commit die wordt gebouwd. Omdat de feature branch-naamruimte de pull-request-ID bevat (het nummer of de branchnaam) moet de ID altijd in de commit worden opgegeven.
    • Het bouwen van de masterbranch mislukt. U heeft bijvoorbeeld de volgende stappen: het project downloaden, tests uitvoeren, het project bouwen, een release maken, meldingen verzenden en de featurebranch van de laatste pull-aanvraag opschonen. Als de build mislukt wanneer u een melding verzendt, moet u alle bronnen in het cluster handmatig verwijderen.
    • Zonder de juiste context is het verwijderen van een feature branch in een master build niet vanzelfsprekend.

  2. Webhooks gebruiken (voorbeeld).

    • Dit is misschien niet uw aanpak. Bijvoorbeeld in Jenkins, slechts één type pijplijn ondersteunt de mogelijkheid om configuraties in de broncode op te slaan. Wanneer u webhooks gebruikt, moet u een eigen script schrijven om deze te verwerken. Dit script zou gehost moeten worden in de Jenkins-interface, die moeilijk te onderhouden is.

  3. Schrijven cronjob en voeg een Kubernetes-cluster toe.

    • Tijd besteed aan schrijven en ondersteuning.
    • De operator werkt al op een vergelijkbare manier, is gedocumenteerd en ondersteund.

Dank u voor uw aandacht voor het artikel. Link naar het project op Github.

Bron: www.habr.com

Koop betrouwbare hosting voor sites met DDoS-bescherming, VPS VDS-servers πŸ”₯ Koop betrouwbare websitehosting met DDoS-bescherming, VPS- en VDS-servers | ProHoster