{"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\/pl\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Usuwamy przestarza\u0142\u0105 ga\u0142\u0105\u017a funkcji w klastrze Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Usuwamy<\/p>\n

Cze\u015b\u0107! Ga\u0142\u0105\u017a funkcjonalna<\/b> (aka deploy preview, review app) \u2014 to sytuacja, gdy deploy odbywa si\u0119 nie tylko dla ga\u0142\u0119zi master, ale tak\u017ce dla ka\u017cdego pull requestu na unikalnym URL. Mo\u017cna sprawdzi\u0107, czy kod dzia\u0142a w \u015brodowisku produkcyjnym, a funkcj\u0119 mo\u017cna pokaza\u0107 innym programistom lub produktologom. Podczas pracy nad pull requestem, ka\u017cdy nowy commit aktualizuje bie\u017c\u0105cy deploy dla starego kodu, a nowy deploy dla nowego kodu jest wdra\u017cany. Pytania mog\u0105 si\u0119 pojawi\u0107, gdy po\u0142\u0105czysz pull request z ga\u0142\u0119zi\u0105 master. Ga\u0142\u0105\u017a funkcjonalna nie jest ju\u017c potrzebna, ale zasoby Kubernetes wci\u0105\u017c znajduj\u0105 si\u0119 w klastrze.<\/p>\n

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

Jeszcze o ga\u0142\u0119ziach funkcjonalnych<\/h2>\n

<\/p>\n

Jednym ze sposob\u00f3w na tworzenie ga\u0142\u0119zi funkcjonalnych w Kubernetes jest u\u017cycie namespace'\u00f3w. W skr\u00f3cie, konfiguracja produkcyjna wygl\u0105da tak:<\/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
Dla ga\u0142\u0119zi funkcjonalnej tworzony jest namespace z jej identyfikatorem (na przyk\u0142ad numer pull requestu) oraz jakim\u015b prefiksem\/podpisem (na przyk\u0142ad, -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
Og\u00f3lnie rzecz bior\u0105c, napisa\u0142em Operator Kubernetes<\/b> (aplikacja, kt\u00f3ra ma dost\u0119p do zasob\u00f3w klastra), link do projektu na Githubie<\/a><\/noindex>. Usuwa namespace'y, kt\u00f3re odnosz\u0105 si\u0119 do starych ga\u0142\u0119zi funkcjonalnych. W Kubernetes, je\u015bli usuniesz namespace, inne zasoby w tym namespace r\u00f3wnie\u017c zostan\u0105 automatycznie usuni\u0119te.<\/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
O tym, jak wdro\u017cy\u0107 ga\u0142\u0119zie funkcjonalne w klastrze, mo\u017cna przeczyta\u0107 tutaj<\/a><\/noindex> i tutaj<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motywacja<\/h2>\n
<\/p>\n
Zobaczmy typowy cykl \u017cycia pull requestu z ci\u0105g\u0142\u0105 integracj\u0105 (ci\u0105g\u0142a integracja<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Wysy\u0142amy nowy commit do ga\u0142\u0119zi.<\/li>\n
  2. Podczas budowy uruchamiane s\u0105 linty i\/lub testy.<\/li>\n
  3. Na bie\u017c\u0105co formu\u0142owane s\u0105 konfiguracje Kubernetes dla pull requestu (na przyk\u0142ad do gotowego szablonu podstawiany jest jego numer).<\/li>\n
  4. Za pomoc\u0105 kubectl apply konfiguracje trafiaj\u0105 do klastra (wdro\u017cenie).<\/li>\n
  5. Pull request jest scalany z ga\u0142\u0119zi\u0105 g\u0142\u00f3wn\u0105.<\/li>\n<\/ol>\n
    <\/p>\n
    Podczas pracy nad pull requestem, ka\u017cdy nowy commit aktualizuje bie\u017c\u0105cy deploy dla starego kodu, a nowy deploy dla nowego kodu jest wdra\u017cany. Jednak gdy pull request zostaje po\u0142\u0105czony z ga\u0142\u0119zi\u0105 master, b\u0119dzie budowana tylko ga\u0142\u0105\u017a master. W rezultacie zapominamy o pull requestcie, a jego zasoby Kubernetes wci\u0105\u017c znajduj\u0105 si\u0119 w klastrze.<\/p>\n
    <\/p>\n
    Jak u\u017cywa\u0107<\/h2>\n
    <\/p>\n
    Zainstaluj projekt poni\u017csz\u0105 komend\u0105:<\/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
    Utw\u00f3rz plik z nast\u0119puj\u0105c\u0105 zawarto\u015bci\u0105 i zainstaluj za pomoc\u0105 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
    Parametr namespaceSubstring<\/b> jest potrzebny, aby filtrowa\u0107 namespace'y dla pull request\u00f3w od innych namespace'\u00f3w. Na przyk\u0142ad, je\u015bli w klastrze s\u0105 nast\u0119puj\u0105ce namespace'y: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, wtedy kandydatami do usuni\u0119cia b\u0119d\u0105 habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Parametr afterDaysWithoutDeploy<\/b> jest potrzebny, aby usuwa\u0107 stare namespace'y. Na przyk\u0142ad, je\u015bli namespace zosta\u0142 stworzony 3 dni 1 godzina<\/code> temu, a w parametrze wskazano 3 dni<\/code>, ten namespace zostanie usuni\u0119ty. Dzia\u0142a to r\u00f3wnie\u017c w drug\u0105 stron\u0119, je\u015bli namespace zosta\u0142 utworzony 2 dni 23 godziny<\/code> temu, a w parametrze wskazano 3 dni<\/code>, ten namespace nie zostanie usuni\u0119ty.<\/p>\n
    <\/p>\n
    Jest jeszcze jeden parametr, kt\u00f3ry odpowiada za to, jak cz\u0119sto skanowa\u0107 wszystkie namespace'y i sprawdza\u0107 dni bez deploy'u \u2014 checkEveryMinutes<\/b>. Domy\u015blnie wynosi 30 minut<\/code>.<\/p>\n
    <\/p>\n
    Jak to dzia\u0142a<\/h2>\n
    <\/p>\n
    W praktyce, potrzebne b\u0119dzie:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> do pracy w izolowanym \u015brodowisku.<\/li>\n
    2. Minikube<\/a><\/noindex> uruchomi lokalnie klaster Kubernetes.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 interfejs wiersza polece\u0144 do zarz\u0105dzania klastrem.<\/li>\n<\/ol>\n
      <\/p>\n
      Uruchamiamy lokalnie klaster Kubernetes:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 na Darwin 10.15.5\nU\u017cywaj\u0105c sterownika docker opartego na istniej\u0105cym profilu.\nRozpoczynanie w\u0119z\u0142a kontrolnego minikube w klastrze minikube.<\/code><\/pre>\n
      <\/p>\n
      Ustawiamy kubectl<\/code> u\u017cyj lokalnego klastra domy\u015blnie:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nPrze\u0142\u0105czono na kontekst \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Pobieramy konfiguracje dla \u015brodowiska produkcyjnego:<\/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
      Poniewa\u017c konfiguracje produkcyjne s\u0105 skonfigurowane do sprawdzania starych namespace'\u00f3w, a w naszym nowo utworzonym klastrze ich nie ma, zmie\u0144my zmienn\u0105 \u015brodowiskow\u0105 IS_DEBUG<\/code> na true<\/code>. Przy takim ustawieniu parametr afterDaysWithoutDeploy<\/code> nie jest brane pod uwag\u0119, a namespace'y nie s\u0105 sprawdzane na dni bez deploy'u, tylko na obecno\u015b\u0107 podci\u0105gu (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Je\u015bli jeste\u015b na Linuxa<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Je\u015bli jeste\u015b na macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Instalujemy projekt:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Sprawdzamy, czy w klastrze pojawi\u0142 si\u0119 zas\u00f3b StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nNAZWA                 ... APIGROUP                             ... RODZAJ\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      Sprawdzamy, czy w klastrze pojawi\u0142 si\u0119 operator:<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nNAZWA                                           ... STATUS  ... WIEK\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... Dzia\u0142a ... 38s<\/code><\/pre>\n
      <\/p>\n
      Je\u015bli zajrzymy do jego log\u00f3w, jest gotowy do przetwarzania zasob\u00f3w 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
      Instalujemy gotowe fixtures<\/code> (gotowe konfiguracje do modelowania zasob\u00f3w klastra) dla zasobu 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
      W konfiguracjach wskazano, aby wyszukiwa\u0107 namespace'y zawieraj\u0105ce podci\u0105g -pr-<\/code> raz na 1 minut\u0119<\/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
      Operator zareagowa\u0142 i jest gotowy do sprawdzania namespace'\u00f3w:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Stale feature branch jest przetwarzany.\",\"namespaceSubstring\":\"-pr-\",\"afterDaysWithoutDeploy\":1,\"checkEveryMinutes\":1,\"isDebug\":\"true\"}<\/code><\/pre>\n
      <\/p>\n
      Instalujemy fixtures<\/code>, zawieraj\u0105ce dwa namespace'y (project-pr-1<\/code>, project-pr-2<\/code>) i ich deployments<\/code>, services<\/code>, ingress<\/code>, i tak dalej:<\/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 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\ningress.extensions\/project-pr-2 created<\/code><\/pre>\n
      <\/p>\n
      Sprawdzamy, czy wszystkie powy\u017csze zasoby zosta\u0142y pomy\u015blnie utworzone:<\/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
      Poniewa\u017c w\u0142\u0105czyli\u015bmy debug<\/code>, namespace'y project-pr-1<\/code> i project-pr-2<\/code>, co oznacza, \u017ce wszystkie pozosta\u0142e zasoby powinny zosta\u0107 natychmiast usuni\u0119te niezale\u017cnie od parametru afterDaysWithoutDeploy<\/code>. W logach operatora wida\u0107 to:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Namespace powinien zosta\u0107 usuni\u0119ty, poniewa\u017c tryb debugowania jest w\u0142\u0105czony.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Namespace jest przetwarzany.\",\"namespaceName\":\"project-pr-1\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace zosta\u0142 usuni\u0119ty.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Namespace powinien zosta\u0107 usuni\u0119ty, poniewa\u017c tryb debugowania jest w\u0142\u0105czony.\",\"namespaceName\":\"project-pr-2\"}\n... \"msg\":\"Namespace jest przetwarzany.\",\"namespaceName\":\"project-pr-2\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace zosta\u0142 usuni\u0119ty.\",\"namespaceName\":\"project-pr-2\"}<\/code><\/pre>\n
      <\/p>\n
      Je\u015bli sprawdzimy dost\u0119pno\u015b\u0107 zasob\u00f3w, b\u0119d\u0105 one w statusie Terminating<\/code> (proces usuwania) lub ju\u017c usuni\u0119te (wyj\u015bcie z polecenia puste).<\/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
      Mo\u017cesz powt\u00f3rzy\u0107 proces tworzenia fixtures<\/code> Kilka razy upewnij si\u0119, \u017ce zostan\u0105 usuni\u0119te w ci\u0105gu minuty.<\/p>\n
      <\/p>\n
      Alternatywy<\/h2>\n
      <\/p>\n
      Co mo\u017cna zrobi\u0107 zamiast operatora dzia\u0142aj\u0105cego w klastrze? Istnieje kilka podej\u015b\u0107, wszystkie s\u0105 niedoskona\u0142e (ich wady s\u0105 subiektywne), a ka\u017cdy sam decyduje, co najlepiej pasuje do konkretnego projektu:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Usun\u0105\u0107 ga\u0142\u0105\u017a feature podczas budowy ci\u0105g\u0142ej integracji ga\u0142\u0119zi master.<\/p>\n
        <\/p>\n