{"id":86902,"date":"2020-07-01T07:42:28","date_gmt":"2020-07-01T05:42:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere"},"modified":"2020-07-01T07:42:28","modified_gmt":"2020-07-01T05:42:28","slug":"udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Verwijder de verouderde feature branch in het Kubernetes-cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Verwijder<\/p>\n

Hallo! Feature branch<\/b> (aka deploy preview, review app) \u2014 dit is wanneer niet alleen de master branch wordt gedeployed, maar ook elke pull request naar een unieke URL. Je kunt controleren of de code werkt in een productieomgeving, en de functie kan aan andere programmeurs of productontwikkelaars worden getoond. Terwijl je aan de pull request werkt, wordt elke nieuwe commit de huidige deploy voor de oude code verwijderd, en een nieuwe deploy voor de nieuwe code uitgerold. Vraagstukken kunnen ontstaan als je de pull request in de master branch hebt samengevoegd. De feature branch is dan niet meer nodig, maar de Kubernetes-resources blijven nog steeds in de cluster.<\/p>\n

<\/a><\/noindex><\/p>\n

Meer over feature branches<\/h2>\n

<\/p>\n

Een van de benaderingen om feature branches in Kubernetes te maken, is door gebruik te maken van namespaces. In het kort ziet de productieconfiguratie er zo uit:<\/p>\n

<\/p>\n

kind: Namespace\napiVersion: v1\nmetadata:\n  name: habr-back-end\n...\n\nkind: Deployment\napiVersion: apps\/v1\nmetadata:\n  namespace: habr-back-end\nspec:\n  replicas: 3\n...<\/code><\/pre>\n
<\/p>\n
Voor feature branches wordt een namespace aangemaakt met haar identificatie (bijvoorbeeld het nummer van de pull request) en een of andere prefix\/suffix (bijvoorbeeld, -pr-<\/b>):<\/p>\n
<\/p>\n
kind: Namespace\napiVersion: v1\nmetadata:\n  name: habr-back-end-pr-17\n...\n\nkind: Deployment\napiVersion: apps\/v1\nmetadata:\n  namespace: habr-back-end-pr-17\nspec:\n  replicas: 1\n...<\/code><\/pre>\n
<\/p>\n
Over het algemeen, ik schreef Kubernetes Operator<\/b> (een applicatie die toegang heeft tot de clusterresources), link naar het project op Github<\/a><\/noindex>). Het verwijdert namespaces die betrekking hebben op oude feature branches. In Kubernetes, als een namespace wordt verwijderd, worden andere resources in die namespace ook automatisch verwijderd.<\/p>\n
<\/p>\n
$ kubectl get pods --all-namespaces | grep -e \"-pr-\"\nNAMESPACE            ... AGE\nhabr-back-end-pr-264 ... 4d8h\nhabr-back-end-pr-265 ... 5d7h<\/code><\/pre>\n
<\/p>\n
Over hoe je feature branches in de cluster kunt implementeren, kun je lezen here<\/a><\/noindex> en here<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motivatie<\/h2>\n
<\/p>\n
Laten we eens kijken naar de typische levenscyclus van een pull request met continue integratie (continue integratie<\/code>):<\/p>\n
<\/p>\n
    \n
  1. We pushen een nieuwe commit naar de branch.<\/li>\n
  2. Bij de build worden linter- en\/of tests uitgevoerd.<\/li>\n
  3. De configuraties van de Kubernetes pull request worden on-the-fly gegenereerd (bijvoorbeeld, zijn nummer wordt ingebracht in een kant-en-klaar sjabloon).<\/li>\n
  4. Met behulp van kubectl apply komen de configuraties in het cluster (deploy).<\/li>\n
  5. De pull request wordt samengevoegd met de master branch.<\/li>\n<\/ol>\n
    <\/p>\n
    Terwijl je aan de pull request werkt, wordt elke nieuwe commit de huidige deploy voor de oude code verwijderd en een nieuwe deploy voor de nieuwe code uitgerold. Maar wanneer de pull request in de master branch wordt samengevoegd, wordt er alleen voor de master branch gebouwd. Hierdoor vergeten we de pull request, terwijl zijn Kubernetes-resources nog steeds in de cluster aanwezig zijn.<\/p>\n
    <\/p>\n
    Hoe te gebruiken<\/h2>\n
    <\/p>\n
    Installeer het project met de onderstaande opdracht:<\/p>\n
    <\/p>\n
    $ kubectl apply -f https:\/\/raw.githubusercontent.com\/dmytrostriletskyi\/stale-feature-branch-operator\/master\/configs\/production.yml<\/code><\/pre>\n
    <\/p>\n
    Maak een bestand met de volgende inhoud en installeer het via kubectl apply -f<\/code>:<\/p>\n
    <\/p>\n
    apiVersion: feature-branch.dmytrostriletskyi.com\/v1\nkind: StaleFeatureBranch\nmetadata:\n  name: stale-feature-branch\nspec:\n  namespaceSubstring: -pr-\n  afterDaysWithoutDeploy: 3<\/code><\/pre>\n
    <\/p>\n
    Parameter namespaceSubstring<\/b> is nodig om namespaces voor pull requests van andere namespaces te filteren. Bijvoorbeeld, als de cluster de volgende namespaces heeft: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, dan zullen de kandidaten voor verwijdering zijn habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Parameter afterDaysWithoutDeploy<\/b> is nodig om oude namespaces te verwijderen. Bijvoorbeeld, als een namespace is aangemaakt 3 dagen 1 uur<\/code> geleden, en de parameter is ingesteld op 3 dagen<\/code>, dan zal deze namespace worden verwijderd. Het werkt ook omgekeerd, als de namespace is aangemaakt 2 dagen 23 uur<\/code> geleden, en de parameter is ingesteld op 3 dagen<\/code>, dan zal deze namespace niet worden verwijderd.<\/p>\n
    <\/p>\n
    Er is nog een andere parameter, die bepaalt hoe vaak alle namespaces moeten worden gescand en gecontroleerd op dagen zonder deploy \u2014 checkEveryMinutes<\/b>. Standaard is deze ingesteld op 30 minuten<\/code>.<\/p>\n
    <\/p>\n
    Hoe het werkt<\/h2>\n
    <\/p>\n
    In de praktijk heeft men nodig:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> voor gebruik in een ge\u00efsoleerde omgeving.<\/li>\n
    2. Minikube<\/a><\/noindex> zal de Kubernetes cluster lokaal opzetten.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 de commandoregelinterface voor het beheren van de cluster.<\/li>\n<\/ol>\n
      <\/p>\n
      We zetten de Kubernetes cluster lokaal op:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 op Darwin 10.15.5\nGebruik de docker-driver op basis van het bestaande profiel.\nStart de beheersnode minikube in cluster minikube.<\/code><\/pre>\n
      <\/p>\n
      Geef op kubectl<\/code> gebruik de lokale cluster als standaard:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nSwitched to context \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      We downloaden de configuraties voor de productieomgeving:<\/p>\n
      <\/p>\n
      $ curl https:\/\/raw.githubusercontent.com\/dmytrostriletskyi\/stale-feature-branch-operator\/master\/configs\/production.yml > stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Omdat productieconfiguraties zijn ingesteld om oude namespaces te controleren, en in onze nieuw opgerichte cluster zijn ze er niet, zullen we de omgevingsvariabele vervangen. IS_DEBUG<\/code> en een werkende opdracht krijgen. true<\/code>. Met deze waarde wordt de parameter afterDaysWithoutDeploy<\/code> wordt niet meegenomen en namespaces worden niet gecontroleerd op dagen zonder deploy, alleen op de aanwezigheid van een substring (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Als je in Linux<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Als je in macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      We installeren het project:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      We controleren of de resource StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nNAAM                 ... APIGROUP                             ... TYPE\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      We controleren of de operator in de cluster aanwezig is:<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nNAAM                                           ... STATUS  ... LEVENSJAREN\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... Draait ... 38s<\/code><\/pre>\n
      <\/p>\n
      Als je in de logs kijkt, is hij klaar om resources te verwerken StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Operator Version: 0.0.1\"}\n...\n... \"msg\":\"Starting EventSource\", ... , \"source\":\"kind source: \/, Kind=\"}\n... \"msg\":\"Starting Controller\", ...}\n... \"msg\":\"Starting workers\", ..., \"worker count\":1}<\/code><\/pre>\n
      <\/p>\n
      Voorgeconfigureerde fixtures<\/code> (voorgeconfigureerde instellingen voor het modelleren van clusterbronnen) voor de hulpbron StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl apply -f https:\/\/raw.githubusercontent.com\/dmytrostriletskyi\/stale-feature-branch-operator\/master\/fixtures\/stale-feature-branch.yml<\/code><\/pre>\n
      <\/p>\n
      In de configuraties is aangegeven om naar namespaces te zoeken met een substring -pr-<\/code> eens in 1 minuut<\/code>.:<\/p>\n
      <\/p>\n
      apiVersion: feature-branch.dmytrostriletskyi.com\/v1\nkind: StaleFeatureBranch\nmetadata:\n  naam: stale-feature-branch\nspec:\n  namespaceSubstring: -pr-\n  afterDaysWithoutDeploy: 1 \n  checkEveryMinutes: 1<\/code><\/pre>\n
      <\/p>\n
      De operator heeft gereageerd en is klaar om namespaces te controleren:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Stale feature branch is being processing.\",\"namespaceSubstring\":\"-pr-\",\"afterDaysWithoutDeploy\":1,\"checkEveryMinutes\":1,\"isDebug\":\"true\"}<\/code><\/pre>\n
      <\/p>\n
      Instellen fixtures<\/code>, die twee namespaces bevatten (project-pr-1<\/code>, project-pr-2<\/code>) en hun deployments<\/code>, services<\/code>, ingress<\/code>, enzovoort:<\/p>\n
      <\/p>\n
      $ 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\n...\nnamespace\/project-pr-1 gecre\u00eberd\ndeployment.apps\/project-pr-1 gecre\u00eberd\nservice\/project-pr-1 gecre\u00eberd\nhorizontalpodautoscaler.autoscaling\/project-pr-1 gecre\u00eberd\nsecret\/project-pr-1 gecre\u00eberd\nconfigmap\/project-pr-1 gecre\u00eberd\ningress.extensions\/project-pr-1 gecre\u00eberd\nnamespace\/project-pr-2 gecre\u00eberd\ndeployment.apps\/project-pr-2 gecre\u00eberd\nservice\/project-pr-2 gecre\u00eberd\nhorizontalpodautoscaler.autoscaling\/project-pr-2 gecre\u00eberd\nsecret\/project-pr-2 gecre\u00eberd\nconfigmap\/project-pr-2 gecre\u00eberd\ningress.extensions\/project-pr-2 gecre\u00eberd<\/code><\/pre>\n
      <\/p>\n
      We controleren of alle bovenstaande resources succesvol zijn aangemaakt:<\/p>\n
      <\/p>\n
      $ 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\n...\nNAAM                              ... KLAAR ... STATUS  ... LEVENSDUUR\npod\/project-pr-1-848d5fdff6-rpmzw ... 1\/1   ... Actief ... 67s\n\nNAAM                         ... KLAAR ... BESCHIKBAAR ... LEVENSDUUR\ndeployment.apps\/project-pr-1 ... 1\/1   ... 1         ... 67s\n...<\/code><\/pre>\n
      <\/p>\n
      Aangezien we debug<\/code>, namespaces project-pr-1<\/code> en project-pr-2<\/code>, en alle andere resources, moeten direct worden verwijderd ongeacht de parameter afterDaysWithoutDeploy<\/code>. Dit is zichtbaar in de logs van de operator:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Namespace should be deleted due to debug mode is enabled.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Namespace is being processing.\",\"namespaceName\":\"project-pr-1\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace has been deleted.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Namespace should be deleted due to debug mode is enabled.\",\"namespaceName\":\"project-pr-2\"}\n... \"msg\":\"Namespace is being processing.\",\"namespaceName\":\"project-pr-2\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace has been deleted.\",\"namespaceName\":\"project-pr-2\"}<\/code><\/pre>\n
      <\/p>\n
      Als we de resources controleren, zullen ze in status zijn Terminating<\/code> (verwijderingsproces) of al verwijderd zijn (de uitvoer van het commando is leeg).<\/p>\n
      <\/p>\n
      $ 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\n...<\/code><\/pre>\n
      <\/p>\n
      U kunt het proces om te maken herhalen fixtures<\/code> en bevestigen dat ze binnen een minuut worden verwijderd.<\/p>\n
      <\/p>\n
      Alternatieven<\/h2>\n
      <\/p>\n
      Wat kan men doen in plaats van de operator die in het cluster werkt? Er zijn verschillende benaderingen, allemaal zijn ze niet perfect (en hun nadelen zijn subjectief), en iedereen moet zelf beslissen welke het beste past bij het specifieke project:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Verwijder de feature branch tijdens de build van de master branch voor continue integratie.<\/p>\n
        <\/p>\n