{"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\/sq\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Heqim branch-in e vjetruar t\u00eb funksionalitetit n\u00eb klasterin Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Heqim<\/p>\n

P\u00ebrsh\u00ebndetje! Dega feature<\/b> (aka deploy preview, review app) \u2014 kur \u00ebsht\u00eb kur depozitohet jo vet\u00ebm dega master, por edhe \u00e7do pull request n\u00eb nj\u00eb URL unik. Mund ta kontrolloni n\u00ebse kodi funksionon n\u00eb ambientin prodhues, mund t\u00eb tregoni tiparin p\u00ebr programues t\u00eb tjer\u00eb ose menaxhues produktesh. P\u00ebr sa koh\u00eb q\u00eb jeni duke punuar n\u00eb pull request, \u00e7do commit i ri aktualizon depozitimin p\u00ebr kodin e vjet\u00ebr, nd\u00ebrsa nj\u00eb depozit\u00eb e re p\u00ebr kodin e ri krijohet. Pyetje mund t\u00eb lindin at\u00ebher\u00eb kur ju e bashkoni pull request me deg\u00ebn master. Dega e tipareve (feature branch) nuk ju nevojitet m\u00eb, por burimet Kubernetes ende gjenden n\u00eb klaster.<\/p>\n

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

M\u00eb shum\u00eb rreth feature branch<\/h2>\n

<\/p>\n

Nj\u00eb nga qasjet p\u00ebr t\u00eb krijuar feature branch n\u00eb Kubernetes \u00ebsht\u00eb p\u00ebrdorimi i namespace-ve. N\u00eb m\u00ebnyr\u00eb t\u00eb shkurt\u00ebr, konfigurimet prodhuese duket k\u00ebshtu:<\/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
P\u00ebr feature branch krijohet nj\u00eb namespace me identifikuesin e saj (p.sh., numri i pull request) dhe ndonj\u00eb prefiks\/postfix (p.sh., -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
N\u00eb p\u00ebrgjith\u00ebsi, un\u00eb shkrova Kubernetes Operator<\/b> (aplikacioni q\u00eb ka qasje n\u00eb resurset e klasterit), shkolla p\u00ebr projektin n\u00eb Github<\/a><\/noindex>. Ai eliminon namespace-t q\u00eb i p\u00ebrkasin feature branch-ve t\u00eb vjetra. N\u00eb Kubernetes, n\u00ebse nj\u00eb namespace fshihet, burime t\u00eb tjera n\u00eb at\u00eb namespace fshihen automatikisht gjithashtu.<\/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
P\u00ebr m\u00ebnyr\u00ebn se si t\u00eb implementoni feature branch n\u00eb klaster, mund t\u00eb lexoni k\u00ebtu<\/a><\/noindex> dhe k\u00ebtu<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motivimi<\/h2>\n
<\/p>\n
Le t\u00eb shikojm\u00eb nj\u00eb cik\u00ebl tipik t\u00eb jet\u00ebs s\u00eb nj\u00eb pull requesti me integrimin e vazhduesh\u00ebm (integrimi i vazhduesh\u00ebm<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Shtojm\u00eb nj\u00eb commit t\u00eb ri n\u00eb deg\u00eb.<\/li>\n
  2. Gjat\u00eb nd\u00ebrtimit, aktivizohen linters dhe\/ose testet.<\/li>\n
  3. Konfigurimet Kubernetes t\u00eb pull requestit krijohen n\u00eb fluks (p.sh., numri i tij vendoset n\u00eb nj\u00eb model t\u00eb gatsh\u00ebm).<\/li>\n
  4. Me ndihm\u00ebn e kubectl apply, konfigurimet hyjn\u00eb n\u00eb klaster (deploy).<\/li>\n
  5. K\u00ebrkesat p\u00ebr t\u00ebrheqje bashkohen n\u00eb deg\u00ebn master.<\/li>\n<\/ol>\n
    <\/p>\n
    P\u00ebr sa koh\u00eb q\u00eb jeni duke punuar n\u00eb pull request, \u00e7do commit i ri aktualizon depozitimin p\u00ebr kodin e vjet\u00ebr, nd\u00ebrsa nj\u00eb depozit\u00eb e re p\u00ebr kodin e ri krijohet. Por kur pull requesti bashkohet me deg\u00ebn master, vet\u00ebm dega master do t\u00eb nd\u00ebrtohet. Si rezultat, ne harrojm\u00eb p\u00ebr pull requestin, nd\u00ebrsa burimet e tij Kubernetes akoma ndodhen n\u00eb klaster.<\/p>\n
    <\/p>\n
    Si t\u00eb p\u00ebrdorim<\/h2>\n
    <\/p>\n
    Instaloni projektin me komand\u00ebn m\u00eb posht\u00eb:<\/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
    Krijo nj\u00eb skedar me p\u00ebrmbajtjen e m\u00ebposhtme dhe vendos p\u00ebrmes 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
    Parametri namespaceSubstring<\/b> nevojitet, p\u00ebr t\u00eb filtruar namespace-t p\u00ebr pull requestet nga namespace t\u00eb tjera. P\u00ebr shembull, n\u00ebse klasteri ka namespace t\u00eb m\u00ebposhtme: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, at\u00ebher\u00eb kandidat\u00ebt p\u00ebr fshirje do t\u00eb jen\u00eb habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Parametri afterDaysWithoutDeploy<\/b> nevojitet p\u00ebr t\u00eb fshir\u00eb namespace t\u00eb vjetra. P\u00ebr shembull, n\u00ebse namespace \u00ebsht\u00eb krijuar 3 dit\u00eb 1 or\u00eb<\/code> m\u00eb par\u00eb, dhe n\u00eb parametrin \u00ebsht\u00eb caktuar 3 dit\u00eb<\/code>, ky namespace do t\u00eb fshihet. Funksionon edhe n\u00eb an\u00ebn tjet\u00ebr, n\u00ebse namespace \u00ebsht\u00eb krijuar 2 dit\u00eb 23 or\u00eb<\/code> m\u00eb par\u00eb, dhe n\u00eb parametrin \u00ebsht\u00eb caktuar 3 dit\u00eb<\/code>, ky namespace nuk do t\u00eb fshihet.<\/p>\n
    <\/p>\n
    Ka gjithashtu nj\u00eb paramet\u00ebr tjet\u00ebr, i cili p\u00ebrgjigjet p\u00ebr sa shpesh do t\u00eb skanohet t\u00eb gjith\u00eb namespace-t dhe do t\u00eb kontrollohet p\u00ebr dit\u00ebt pa ndonj\u00eb depozitim \u2014 checkEveryMinutes<\/b>. N\u00eb m\u00ebnyr\u00eb t\u00eb paracaktuar, ai \u00ebsht\u00eb i barabart\u00eb me 30 minuta<\/code>.<\/p>\n
    <\/p>\n
    Si funksionon<\/h2>\n
    <\/p>\n
    N\u00eb praktik\u00eb, do t\u00eb nevojitet:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> p\u00ebr t\u00eb punuar n\u00eb nj\u00eb mjedis t\u00eb izoluar.<\/li>\n
    2. Minikube<\/a><\/noindex> do t\u00eb ngrej\u00eb klasterin Kubernetes lokal.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 nd\u00ebrfaqja e komandave p\u00ebr t\u00eb menaxhuar klasterin.<\/li>\n<\/ol>\n
      <\/p>\n
      Ngrem\u00eb klasterin Kubernetes lokal:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 n\u00eb Darwin 10.15.5\nDuke p\u00ebrdorur drejtuesin docker n\u00eb baz\u00eb t\u00eb profilit ekzistues.\nDuke filluar kontrollin e planeve minikube n\u00eb klasterin minikube.<\/code><\/pre>\n
      <\/p>\n
      Tregojm\u00eb kubectl<\/code> p\u00ebrdor klasterin lokal si parazgjedhje:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nSwitched to context \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Po shkarkojm\u00eb konfiguratat p\u00ebr ambientin e production-it:<\/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
      Pasi konfigurimet prodhuese jan\u00eb caktuar p\u00ebr t\u00eb kontrolluar namespace t\u00eb vjetra, dhe n\u00eb klasterin ton\u00eb t\u00eb sapo ngritur nuk ka ato, do t\u00eb z\u00ebvend\u00ebsojm\u00eb variablin e mjedisit IS_DEBUG<\/code> n\u00eb e v\u00ebrtet\u00eb<\/code>. Me k\u00ebt\u00eb vler\u00eb, parametri afterDaysWithoutDeploy<\/code> nuk konsiderohet dhe namespace-t nuk kontrollohen p\u00ebr dit\u00ebt pa ndonj\u00eb depozitim, vet\u00ebm p\u00ebr p\u00ebrfshirjen e nj\u00eb n\u00ebnstringu (-pr-<\/code>).<\/p>\n
      <\/p>\n
      N\u00ebse jeni n\u00eb Linux<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      N\u00ebse jeni n\u00eb macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Po instalojm\u00eb projektin:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Po kontrollojm\u00eb q\u00eb resurset jan\u00eb shfaqur n\u00eb klaster StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nEMRI                 ... APIGROUP                             ... LLOJI\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      Po kontrollojm\u00eb q\u00eb operatori \u00ebsht\u00eb shfaqur n\u00eb klaster:<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nEMRI                                           ... STATUS  ... MOSHA\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... Duke funksionuar ... 38s<\/code><\/pre>\n
      <\/p>\n
      N\u00ebse shikoni n\u00eb logjet e tij, ai \u00ebsht\u00eb gati t\u00eb p\u00ebrpunoj\u00eb resurset 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
      Instalojm\u00eb gotiot fixtures<\/code> (konfigurime t\u00eb gatshme p\u00ebr simulimin e burimeve t\u00eb klas\u00ebs) p\u00ebr burimin 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
      N\u00eb konfigurime \u00ebsht\u00eb e specifikuar t\u00eb k\u00ebrkohen namespace me n\u00ebnstring -pr-<\/code> nj\u00eb her\u00eb n\u00eb 1 minut\u00eb<\/code>.:<\/p>\n
      <\/p>\n
      apiVersion: feature-branch.dmytrostriletskyi.com\/v1\nlloji: StaleFeatureBranch\nmetadata:\n  emri: stale-feature-branch\nspec:\n  namespaceSubstring: -pr-\n  afterDaysWithoutDeploy: 1 \n  checkEveryMinutes: 1<\/code><\/pre>\n
      <\/p>\n
      Operatori ka reaguar dhe \u00ebsht\u00eb gati p\u00ebr t\u00eb kontrolluar namespace-t:<\/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
      Instalojm\u00eb fixtures<\/code>, q\u00eb p\u00ebrmbajn\u00eb dy namespace (project-pr-1<\/code>, project-pr-2<\/code>) dhe sh\u00ebrbimet e tyre dispozita<\/code>, , dhe k\u00ebshtu me radh\u00eb:<\/code>, ingress<\/code>, dhe k\u00ebshtu me radh\u00eb:<\/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\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
      Kontrollojm\u00eb q\u00eb t\u00eb gjitha burimet e lartp\u00ebrmendura jan\u00eb krijuar me sukses:<\/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
      Duke b\u00ebr\u00eb k\u00ebt\u00eb, debug<\/code>, namespace-t project-pr-1<\/code> dhe project-pr-2<\/code>, gjithashtu t\u00eb gjitha burimet e tjera, duhet t\u00eb fshihen menj\u00ebher\u00eb pa marr\u00eb parasysh parametrin afterDaysWithoutDeploy<\/code>. N\u00eb log\u00ebt e operatorit kjo \u00ebsht\u00eb e dukshme:<\/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
      N\u00ebse kontrolloni disponueshm\u00ebrin\u00eb e burimeve, ato do t\u00eb jen\u00eb n\u00eb statusin Duke u p\u00ebrfunduar<\/code> (procesi i fshirjes) ose tashm\u00eb jan\u00eb fshir\u00eb (dalja e komand\u00ebs \u00ebsht\u00eb e zbraz\u00ebt).<\/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
      Mund t\u00eb p\u00ebrs\u00ebrisni procesin e krijimit fixtures<\/code> disa her\u00eb dhe t\u00eb siguroheni q\u00eb ato do t\u00eb fshihen brenda nj\u00eb minute.<\/p>\n
      <\/p>\n
      Alternativat<\/h2>\n
      <\/p>\n
      \u00c7far\u00eb mund t\u00eb b\u00ebni n\u00eb vend t\u00eb operatorit q\u00eb punon n\u00eb klaster? Ka disa qasje, t\u00eb gjitha nuk jan\u00eb t\u00eb p\u00ebrsosura (dhe disavantazhet e tyre jan\u00eb subjektive), dhe secili vendos se cila \u00ebsht\u00eb m\u00eb e p\u00ebrshtatshme p\u00ebr projektin specifik:<\/p>\n
      <\/p>\n
        \n
      1. \n
        T\u00eb fshini branch-in e karakteristikave gjat\u00eb nd\u00ebrtimit t\u00eb integrimit t\u00eb vazhduesh\u00ebm t\u00eb branch-it master.<\/p>\n
        <\/p>\n