{"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\/sv\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Tar bort den gamla funktionningsgrenen i Kubernetes-klustret","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Tar<\/p>\n

Hej! Funktionsgren<\/b> (aka deploy preview, review app) \u2014 detta n\u00e4r inte bara master-grenen deployas, utan \u00e4ven varje pull request till en unik URL. Du kan kontrollera om koden fungerar i produktionsmilj\u00f6n, och funktionen kan visas f\u00f6r andra programmerare eller produkt\u00e4gare. Medan du arbetar i pull request'en tas varje ny commit bort fr\u00e5n den aktuella deployen f\u00f6r den gamla koden, och en ny deploy f\u00f6r den nya koden implementeras. Fr\u00e5gor kan uppst\u00e5 n\u00e4r du har merget pull request'en till master-grenen. Feature-grenen beh\u00f6vs inte l\u00e4ngre, men resurserna i Kubernetes finns fortfarande kvar i klustret.<\/p>\n

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

Mer om feature-grenar<\/h2>\n

<\/p>\n

Ett av s\u00e4tten att skapa feature-grenar i Kubernetes \u00e4r att anv\u00e4nda namespaces. Sammanfattningsvis ser produktionskonfigurationerna ut s\u00e5 h\u00e4r:<\/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
F\u00f6r feature-grenen skapas ett namespace med dess identifierare (till exempel, numret p\u00e5 pull request'en) och n\u00e5got prefix\/suffix (till exempel, -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
Sammanfattningsvis, jag skrev Kubernetes Operator<\/b> (en applikation som har \u00e5tkomst till klustrets resurser), l\u00e4nk till projektet p\u00e5 Github<\/a><\/noindex>. Det tar bort namespaces som tillh\u00f6r gamla feature-grenar. I Kubernetes, n\u00e4r ett namespace tas bort, tas andra resurser i detta namespace ocks\u00e5 bort automatiskt.<\/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 hur man implementerar feature-grenar i klustret kan du l\u00e4sa ). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex> och ). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motivation<\/h2>\n
<\/p>\n
L\u00e5t oss titta p\u00e5 en typisk livscykel f\u00f6r en pull request med kontinuerlig integration (kontinuerlig integration<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Vi pushar en ny commit till grenen.<\/li>\n
  2. Vid bygget k\u00f6rs linters och\/eller tester.<\/li>\n
  3. Kubernetes-konfigurationer f\u00f6r pull request'en genereras i realtid (till exempel, numret s\u00e4tts in i en f\u00e4rdig mall).<\/li>\n
  4. Med hj\u00e4lp av kubectl apply kommer konfigurationerna att \u00f6verf\u00f6ras till klustret (distribuera).<\/li>\n
  5. Pull requesten sl\u00e5s samman med master-grenen.<\/li>\n<\/ol>\n
    <\/p>\n
    Medan du arbetar i pull request'en tas varje ny commit bort fr\u00e5n den aktuella deployen f\u00f6r den gamla koden, och en ny deploy f\u00f6r den nya koden implementeras. Men n\u00e4r pull request'en sl\u00e5s ihop med master-grenen kommer endast master-grenen att byggas. Resultatet blir att vi redan har gl\u00f6mt pull request'en, men dess Kubernetes-resurser finns fortfarande kvar i klustret.<\/p>\n
    <\/p>\n
    Hur man anv\u00e4nder<\/h2>\n
    <\/p>\n
    Installera projektet med kommandot nedan:<\/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
    Skapa en fil med f\u00f6ljande inneh\u00e5ll och installera genom 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> Beh\u00f6vs f\u00f6r att filtrera namespaces f\u00f6r pull requests fr\u00e5n andra namespaces. Till exempel, om klustret har f\u00f6ljande namespaces: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, d\u00e5 kommer kandidaterna f\u00f6r borttagning att vara habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Parameter afterDaysWithoutDeploy<\/b> Beh\u00f6vs f\u00f6r att ta bort gamla namespaces. Till exempel, om namespace har skapats 3 dagar 1 timme<\/code> sedan, och parametern anges som 3 dagar<\/code>, kommer detta namespace att tas bort. Det fungerar ocks\u00e5 tv\u00e4rtom; om namespace skapades 2 dagar 23 timmar<\/code> sedan, och parametern anges som 3 dagar<\/code>, kommer detta namespace inte att tas bort.<\/p>\n
    <\/p>\n
    Det finns ytterligare en parameter, som ansvarar f\u00f6r hur ofta alla namespaces ska skannas och kontrolleras f\u00f6r dagar utan deploy \u2014 checkEveryMinutes<\/b>. Som standard \u00e4r den inst\u00e4lld p\u00e5 30 minuter<\/code>.<\/p>\n
    <\/p>\n
    Hur det fungerar<\/h2>\n
    <\/p>\n
    I praktiken kommer det att beh\u00f6vas:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> f\u00f6r att arbeta i en isolerad milj\u00f6.<\/li>\n
    2. Minikube<\/a><\/noindex> startar Kubernetes-klustret lokalt.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 kommandoradsgr\u00e4nssnitt f\u00f6r att hantera klustret.<\/li>\n<\/ol>\n
      <\/p>\n
      Startar Kubernetes-klustret lokalt:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 p\u00e5 Darwin 10.15.5\nAnv\u00e4nder docker-drivrutinen baserat p\u00e5 befintlig profil.\nStartar kontrollplanet nod minikube i klustret minikube.<\/code><\/pre>\n
      <\/p>\n
      Ange kubectl<\/code> anv\u00e4nda det lokala klustret som standard:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nBytte till kontext \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Laddar ner konfigurationerna f\u00f6r produktionsmilj\u00f6n:<\/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
      Eftersom produktionskonfigurationerna \u00e4r inst\u00e4llda f\u00f6r att kontrollera gamla namespaces, och i v\u00e5rt nyuppr\u00e4ttade kluster finns det inga, ska vi \u00e4ndra milj\u00f6variabeln IS_DEBUG<\/code> till true<\/code>. N\u00e4r detta v\u00e4rde \u00e4r inst\u00e4llt beaktas inte parametern och namespace kontrolleras inte f\u00f6r dagar utan deploy, endast f\u00f6r f\u00f6rekomsten av delstr\u00e4ngen ( afterDaysWithoutDeploy<\/code> ing\u00e5 och namespaces kontrolleras inte f\u00f6r dagar utan deploy, endast f\u00f6r att hitta delstr\u00e4ngar (-pr-<\/code>).<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml Linux<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/p>\n
      <\/p>\n
      Kontrollerar att resursen har dykt upp i klustret<\/code><\/pre>\n
      <\/p>\n
      StaleFeatureBranch $ kubectl api-resources | grep stalefeaturebranches\nNAMN                 ... APIGROUP                             ... TYP\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      Kontrollerar att operat\u00f6ren har dykt upp i klustret:<\/code><\/pre>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nNAMN                                           ... STATUS  ... \u00c5LDER\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... K\u00f6r ... 38s<\/p>\n
      <\/p>\n
      Om man kollar loggarna f\u00f6r det, \u00e4r det redo att hantera resurser<\/code><\/pre>\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} $ kubectl api-resources | grep stalefeaturebranches\nNAMN                 ... APIGROUP                             ... TYP\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... 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
      fixtures armaturer<\/code> (f\u00e4rdiga konfigurationer f\u00f6r resurskluster) f\u00f6r resursen $ kubectl api-resources | grep stalefeaturebranches\nNAMN                 ... APIGROUP                             ... TYP\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... 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
      I konfigurationerna anges att s\u00f6ka efter namespace med delstr\u00e4ngar -pr-<\/code> varje 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
      Operat\u00f6ren har reagerat och \u00e4r redo att kontrollera namespace:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Stale feature branch bearbetas.\",\"namespaceSubstring\":\"-pr-\",\"afterDaysWithoutDeploy\":1,\"checkEveryMinutes\":1,\"isDebug\":\"true\"}<\/code><\/pre>\n
      <\/p>\n
      Installera armaturer<\/code>, som inneh\u00e5ller tv\u00e5 namespace (project-pr-1<\/code>, project-pr-2<\/code>) och deras deployment<\/code>, tj\u00e4nster<\/code>, ingress<\/code>, och s\u00e5 vidare:<\/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\n-ingress.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\n-ingress.extensions\/project-pr-2 created<\/code><\/pre>\n
      <\/p>\n
      Vi kontrollerar att alla resurser ovan har skapats framg\u00e5ngsrikt:<\/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
      Eftersom vi har aktiverat debug<\/code>, namespace project-pr-1<\/code> och project-pr-2<\/code>, m\u00e5ste d\u00e4rf\u00f6r alla andra resurser avl\u00e4gsnas omedelbart oavsett parametern afterDaysWithoutDeploy<\/code>. Detta kan ses i operat\u00f6rens loggar:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Namespace b\u00f6r raderas eftersom debug-l\u00e4get \u00e4r aktiverat.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Namespace bearbetas.\",\"namespaceName\":\"project-pr-1\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace har raderats.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Namespace b\u00f6r raderas eftersom debug-l\u00e4get \u00e4r aktiverat.\",\"namespaceName\":\"project-pr-2\"}\n... \"msg\":\"Namespace bearbetas.\",\"namespaceName\":\"project-pr-2\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace har raderats.\",\"namespaceName\":\"project-pr-2\"}<\/code><\/pre>\n
      <\/p>\n
      Om du kontrollerar tillg\u00e5ngen till resurser kommer de att vara i status Terminating<\/code> (borttagningsprocess) eller redan borttagna (kommandoutdata \u00e4r 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 upprepa skapelseprocessen armaturer<\/code> flera g\u00e5nger och se till att de tas bort inom en minut.<\/p>\n
      <\/p>\n
      Alternativ<\/h2>\n
      <\/p>\n
      Vad kan man g\u00f6ra ist\u00e4llet f\u00f6r en operator som arbetar i en kluster? Det finns flera tillv\u00e4gag\u00e5ngss\u00e4tt, alla \u00e4r inte perfekta (och deras nackdelar \u00e4r subjektiva), och varje person m\u00e5ste avg\u00f6ra vad som passar b\u00e4st f\u00f6r just sitt projekt:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Att ta bort feature branch under bygget av master-grenen f\u00f6r kontinuerlig integration.<\/p>\n
        <\/p>\n