{"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\/da\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Fjerner for\u00e6ldet feature branch i Kubernetes-klyngen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Fjerner<\/p>\n

Hej! Funktionsgren<\/b> (aka deploy preview, review app) \u2014 det er n\u00e5r der ikke kun deployeres til master-grenen, men hver pull request til en unik URL. Man kan tjekke, om koden fungerer i production-milj\u00f8et, og funktionen kan vises til andre programm\u00f8rer eller produktfolk. Mens du arbejder i pull requesten, slettes den nuv\u00e6rende deployment for gammel kode, hver gang der laves et nyt commit, og en ny deployment for den nye kode k\u00f8res. Sp\u00f8rgsm\u00e5l kan opst\u00e5, n\u00e5r du har merger'et pull requesten ind i master-grenen. Feature-grenen er ikke l\u00e6ngere n\u00f8dvendig, men ressourcerne i Kubernetes er stadig i klyngen.<\/p>\n

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

Mere om feature-grene<\/h2>\n

<\/p>\n

En m\u00e5de at oprette feature-grene i Kubernetes \u2014 er at anvende namespaces. Kort sagt, production-konfigurationerne ser s\u00e5dan ud:<\/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
For feature-grenen oprettes der et namespace med dens identifikator (for eksempel, nummeret p\u00e5 pull requesten) og et eller andet pr\u00e6fiks\/suffiks (for eksempel, -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
Generelt har jeg skrevet Kubernetes Operator<\/b> (applikationen, der har adgang til klyngens ressourcer), link til projektet p\u00e5 Github<\/a><\/noindex>. Det fjerner namespaces, der tilh\u00f8rer gamle feature-grene. I Kubernetes, hvis du sletter et namespace, slettes andre ressourcer i dette namespace ogs\u00e5 automatisk.<\/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
Om hvordan man implementerer feature-grene i klyngen, kan du l\u00e6se her<\/a><\/noindex> og her<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motivation<\/h2>\n
<\/p>\n
Lad os se p\u00e5 en typisk livscyklus for en pull request med kontinuerlig integration (kontinuerlig integration<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Vi push'er en ny commit til grenen.<\/li>\n
  2. Ved bygningene k\u00f8res linters og\/eller tests.<\/li>\n
  3. Kubernetes-konfigurationerne for pull requesten dannes on the fly (for eksempel inds\u00e6ttes dens nummer i en f\u00e6rdig skabelon).<\/li>\n
  4. Med kubectl apply bliver konfigurationerne sendt til klyngen (deploy).<\/li>\n
  5. Pull request'en flettes ind i master-grenen.<\/li>\n<\/ol>\n
    <\/p>\n
    Mens du arbejder i pull requesten, slettes den aktuelle deployment for gammel kode ved hvert nyt commit, og en ny deployment for ny kode k\u00f8res. Men n\u00e5r pull requesten merges ind i master-grenen, vil der kun blive bygget for master-grenen. Resultatet er, at vi har glemt pull requesten, men dens Kubernetes-ressourcer er stadig i klyngen.<\/p>\n
    <\/p>\n
    Hvordan man bruger<\/h2>\n
    <\/p>\n
    Installer projektet med kommandoen nedenfor:<\/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
    Opret en fil med f\u00f8lgende indhold og installer gennem 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> er n\u00f8dvendig for at filtrere namespaces for pull requests fra andre namespaces. For eksempel, hvis der i klyngen er f\u00f8lgende namespaces: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, s\u00e5 vil kandidaterne til sletning v\u00e6re habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Parameter afterDaysWithoutDeploy<\/b> er n\u00f8dvendig for at slette gamle namespaces. For eksempel, hvis namespace er oprettet 3 dage 1 time<\/code> siden, og parameteren angiver 3 dage<\/code>, vil dette namespace blive slettet. Det fungerer ogs\u00e5 i den modsatte retning; hvis et namespace blev oprettet 2 dage 23 timer<\/code> siden, og parameteren angiver 3 dage<\/code>, vil dette namespace ikke blive slettet.<\/p>\n
    <\/p>\n
    Der er ogs\u00e5 en parameter, der angiver hvor ofte der skal scannes i alle namespaces og kontrolleres for dage uden deployment \u2014 checkEveryMinutes<\/b>. Som standard er den sat til 30 minutter<\/code>.<\/p>\n
    <\/p>\n
    Hvordan fungerer det<\/h2>\n
    <\/p>\n
    I praksis vil vi have brug for:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> til drift i et isoleret milj\u00f8.<\/li>\n
    2. Minikube<\/a><\/noindex> vil starte Kubernetes-klyngen lokalt.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 et kommandolinjeinterface til styring af klyngen.<\/li>\n<\/ol>\n
      <\/p>\n
      Starter Kubernetes-klyngen lokalt:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 p\u00e5 Darwin 10.15.5\nBruger docker-driveren baseret p\u00e5 eksisterende profil.\nStarter kontrolplanet node minikube i klyngen minikube.<\/code><\/pre>\n
      <\/p>\n
      Angiv kubectl<\/code> for at bruge den lokale klynge som standard:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nSwitched to context \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Downloader konfigurationerne til produktionsmilj\u00f8et:<\/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
      Da production-konfigurationerne er indstillet til at tjekke gamle namespaces, og der ikke er nogen i vores nyligt oprettede klynge, skal vi \u00e6ndre milj\u00f8variablen IS_DEBUG<\/code> og f\u00e5 en fungerende kommando. true<\/code>. Ved denne v\u00e6rdi vil parameteren afterDaysWithoutDeploy<\/code> overvejes ikke, og namespaces tjekkes ikke for dage uden deployment, kun for tilstedev\u00e6relsen af en substring (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Hvis du er p\u00e5 Linux<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Hvis du er p\u00e5 macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Installerer projektet:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Kontrollerer, at ressourcen er til stede i klyngen StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nNAVN                 ... APIGROUP                             ... TYPE\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      Kontrollerer, at operat\u00f8ren er til stede i klyngen:<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nNAVN                                           ... STATUS  ... AGE\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... K\u00f8rende ... 38s<\/code><\/pre>\n
      <\/p>\n
      Hvis du ser i dens logs, er den klar til at behandle ressourcer 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
      Installerer de f\u00e6rdige fixtures<\/code> (f\u00e6rdige konfigurationer til modellering af clusterressourcer) til ressourcen 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
      Konfigurationerne angiver at s\u00f8ge efter namespaces med substring -pr-<\/code> en gang hvert 1 minut<\/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: 1 \n  checkEveryMinutes: 1<\/code><\/pre>\n
      <\/p>\n
      Operatoren reagerede og er klar til at tjekke namespaces:<\/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
      Installerer fixtures<\/code>, som indeholder to namespaces (project-pr-1<\/code>, project-pr-2<\/code>) og deres deployments<\/code>, services<\/code>, ingress<\/code>, og s\u00e5 videre:<\/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...\nnamespaces\/project-pr-1 created\ndeployment.apps\/project-pr-1 created\nservice\/project-pr-1 created\nhorizontalpodautoscaler.autoscaling\/project-pr-1 created\nsecret\/project-pr-1 created\nconfigmap\/project-pr-1 created\ningress.extensions\/project-pr-1 created\nnamespace\/project-pr-2 created\ndeployment.apps\/project-pr-2 created\nservice\/project-pr-2 created\nhorizontalpodautoscaler.autoscaling\/project-pr-2 created\nsecret\/project-pr-2 created\nconfigmap\/project-pr-2 created\ningress.extensions\/project-pr-2 created<\/code><\/pre>\n
      <\/p>\n
      Vi tjekker, om alle ovenn\u00e6vnte ressourcer er blevet oprettet:<\/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...\nNAME                              ... READY ... STATUS  ... AGE\npod\/project-pr-1-848d5fdff6-rpmzw ... 1\/1   ... Running ... 67s\n\nNAME                         ... READY ... AVAILABLE ... AGE\ndeployment.apps\/project-pr-1 ... 1\/1   ... 1         ... 67s\n...<\/code><\/pre>\n
      <\/p>\n
      Da vi har aktiveret debug<\/code>, namespaces project-pr-1<\/code> og project-pr-2<\/code>, vil alle andre ressourcer ogs\u00e5 straks blive fjernet uanset parameteren afterDaysWithoutDeploy<\/code>. Dette ses i operat\u00f8rens logs:<\/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
      Hvis du tjekker for ressourcer, vil de v\u00e6re i status Terminating<\/code> (sletningsprocess) eller allerede slettet (kommandoens output er tomt).<\/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
      Du kan gentage oprettelsesprocessen fixtures<\/code> flere gange og sikre dig, at de vil blive slettet inden for et minut.<\/p>\n
      <\/p>\n
      Alternativer<\/h2>\n
      <\/p>\n
      Hvad kan man g\u00f8re i stedet for en operator, der arbejder i et cluster? Der er flere tilgange, alle har deres mangler (og disse mangler er subjektive), og hver person m\u00e5 selv vurdere, hvad der passer bedst til det specifikke projekt:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Fjerne feature branch under byggeriet af master-branchens kontinuerlige integration.<\/p>\n
        <\/p>\n