{"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":"Hoqim marramend\u00ebsit e vjetruar t\u00eb feature branch n\u00eb klasterin Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hoqim<\/p>\n

\ud83e\udd47Si t\u00eb arrish n\u00eb qiell dhe t\u00eb b\u00ebhesh pilot | ProHoster Devi n\u00eb ve\u00e7ori<\/b> (aka deploy preview, review app) \u2014 kur \u00ebsht\u00eb kur depelohet jo vet\u00ebm dega master, por edhe \u00e7do pull request n\u00eb nj\u00eb URL unik. Mund t\u00eb kontrolloni n\u00ebse kodi punon n\u00eb mjedisin production, dhe funksionalitetin mund ta tregoni programuesve t\u00eb tjer\u00eb ose menaxher\u00ebve t\u00eb produkteve. Nd\u00ebrsa punoni mbi pull request, \u00e7do commit i ri fshin deploy-in aktual p\u00ebr kodin e vjet\u00ebr, dhe nj\u00eb deploy i ri p\u00ebr kodin e ri krijohet. Pyetje mund t\u00eb lindin kur e keni bashkuar pull request-in n\u00eb deg\u00ebn master. Dega e funksionalitetit nuk ju nevojitet m\u00eb, por burimet e Kubernetes jan\u00eb ende n\u00eb klaster.<\/p>\n

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

S\u00ebrish mbi deg\u00ebt e funksionalitetit<\/h2>\n

<\/p>\n

Nj\u00eb nga qasjet si t\u00eb b\u00ebni deg\u00ebt e funksionalitetit n\u00eb Kubernetes \u2014 t\u00eb p\u00ebrdorni namespace. N\u00ebse flasim shkurt, konfigurimet production duken 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 deg\u00ebn e funksionalitetit krijohet nj\u00eb namespace me identifikuesin e saj (p\u00ebr shembull, numrin e pull request-it) dhe nj\u00eb prefiks\/sufiks (p\u00ebr shembull, -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> (nj\u00eb aplikacion q\u00eb ka qasje n\u00eb burimet e klasterit), linku p\u00ebr projektin n\u00eb Github<\/a><\/noindex>. Ai fshin namespace-t q\u00eb i p\u00ebrkasin deg\u00ebve t\u00eb vjetra t\u00eb funksionalitetit. N\u00eb Kubernetes, n\u00ebse fshihni nj\u00eb namespace, burimet e tjera n\u00eb k\u00ebt\u00eb namespace fshihen gjithashtu automatikisht.<\/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 si t\u00eb implementoni deg\u00ebt e funksionalitetit 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 shohim nj\u00eb cik\u00ebl t\u00eb zakonsh\u00ebm jet\u00ebsor t\u00eb nj\u00eb pull request-i me integrimin e vazhduesh\u00ebm (integrim i vazhduesh\u00ebm<\/code>):<\/p>\n
<\/p>\n
    \n
  1. D\u00ebrgojm\u00eb nj\u00eb commit t\u00eb ri n\u00eb deg\u00eb.<\/li>\n
  2. N\u00eb nd\u00ebrtim, lan\u00e7ohet linterat dhe\/ose testet.<\/li>\n
  3. Konfigurimet e Kubernetes p\u00ebr pull request-in krijohen n\u00eb flak\u00eb (p\u00ebr shembull, numri i tij vendoset n\u00eb nj\u00eb model t\u00eb gatsh\u00ebm).<\/li>\n
  4. Me ndihm\u00ebn e kubectl apply, konfigurimet shkojn\u00eb n\u00eb klaster (implementohet).<\/li>\n
  5. K\u00ebrkesa e t\u00ebrheqjes bashkohet n\u00eb deg\u00ebn master.<\/li>\n<\/ol>\n
    <\/p>\n
    Nd\u00ebrsa punoni n\u00eb pull request, \u00e7do commit i ri fshin deploy-in aktual p\u00ebr kodin e vjet\u00ebr, dhe nj\u00eb deploy i ri p\u00ebr kodin e ri krijohet. Por kur pull request-i bashkohet n\u00eb deg\u00ebn master, do t\u00eb nd\u00ebrtohet vet\u00ebm dega master. Si rezultat, ne harrojm\u00eb p\u00ebr pull request-in, nd\u00ebrsa burimet e tij n\u00eb Kubernetes jan\u00eb ende n\u00eb klaster.<\/p>\n
    <\/p>\n
    Si t\u00eb p\u00ebrdorni<\/h2>\n
    <\/p>\n
    Instaloni projektin me komand\u00ebn e m\u00ebposhtme:<\/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
    Krijoni nj\u00eb sked\u00eb me p\u00ebrmbajtjen e m\u00ebposhtme dhe instaloni 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 request-et nga namespace t\u00eb tjera. P\u00ebr shembull, n\u00ebse n\u00eb klaster ka k\u00ebto namespace: 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 e vjetra. P\u00ebr shembull, n\u00ebse namespace \u00ebsht\u00eb krijuar 3 dit\u00eb 1 or\u00eb<\/code> mbrapa, dhe n\u00eb parametrin \u00ebsht\u00eb e p\u00ebrcaktuar 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> mbrapa, dhe n\u00eb parametrin \u00ebsht\u00eb e p\u00ebrcaktuar 3 dit\u00eb<\/code>, ky namespace nuk do t\u00eb fshihet.<\/p>\n
    <\/p>\n
    Ka nj\u00eb paramet\u00ebr tjet\u00ebr, ai p\u00ebrcakton se sa shpesh t\u00eb skanohet t\u00eb gjitha namespace-t dhe t\u00eb kontrollohen p\u00ebr dit\u00ebt pa deploy \u2014 checkEveryMinutes<\/b>. N\u00eb m\u00ebnyr\u00eb default, ai \u00ebsht\u00eb baras 30 minutave<\/code>.<\/p>\n
    <\/p>\n
    Si funksionon kjo<\/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 ambient t\u00eb izoluar.<\/li>\n
    2. Minikube<\/a><\/noindex> do t\u00eb ngrej\u00eb klusterin Kubernetes lokal.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 nd\u00ebrfaqe komandash p\u00ebr menaxhimin e klusterit.<\/li>\n<\/ol>\n
      <\/p>\n
      Ngrem\u00eb klusterin 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 duke u bazuar n\u00eb profilin ekzistues.\nDuke nisur pik\u00ebn e kontrollit minikube n\u00eb klusterin minikube.<\/code><\/pre>\n
      <\/p>\n
      Specifikoni kubectl<\/code> p\u00ebrdor klusterin lokal si default:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nKaluan n\u00eb kontekstin \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Shkarkojm\u00eb konfigurimet p\u00ebr mjedisin 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
      Duke pasur parasysh se konfigurimet production jan\u00eb t\u00eb vendosura p\u00ebr t\u00eb kontrolluar namespace-t e vjetra, dhe n\u00eb klasterin ton\u00eb t\u00eb sapo ngritur nuk ka atyre, do t\u00eb z\u00ebvend\u00ebsojm\u00eb variablin e ambientit IS_DEBUG<\/code> n\u00eb true<\/code>. Me k\u00ebt\u00eb vler\u00eb, parametri afterDaysWithoutDeploy<\/code> nuk merret parasysh dhe namespace-t nuk kontrollohen p\u00ebr dit\u00ebt pa deploy, vet\u00ebm p\u00ebr p\u00ebrfshirjen e n\u00ebnstring\u00ebs (-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
      Instalojm\u00eb projektin:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Kontrollojm\u00eb q\u00eb n\u00eb kluster \u00ebsht\u00eb shfaqur burimi StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nEMRI                 ... GRUPI I API-s\u00eb                             ... LLOJI\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      Kontrollojm\u00eb q\u00eb n\u00eb kluster \u00ebsht\u00eb shfaqur operatori:<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nEMRI                                           ... STATUS  ... MOSH\u00cb\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... Duke punuar ... 38s<\/code><\/pre>\n
      <\/p>\n
      N\u00ebse shohim n\u00eb logjet e tij, ai \u00ebsht\u00eb gati p\u00ebr t\u00eb procesuar burimet StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Versioni e Operatorit: 0.0.1\"\n...\n... \"msg\":\"Duke filluar EventSource\", ... , \"source\":\"burimi i llojit: \/, Lloji=\"}\n... \"msg\":\"Duke filluar Kontrolluesin\", ...}\n... \"msg\":\"Duke filluar pun\u00ebtor\u00ebt\", ..., \"numri i pun\u00ebtor\u00ebve\":1}<\/code><\/pre>\n
      <\/p>\n
      Instalojm\u00eb fixtures-n\u00eb aparatet<\/code> (konfigurata t\u00eb gatshme p\u00ebr modelimin e burimeve t\u00eb klasterit) 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-t me nj\u00eb n\u00ebnstring\u00eb -pr-<\/code> nj\u00eb her\u00eb n\u00eb 1 minut\u00eb<\/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
      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\":\"Duke procesuar branch-in e vjet\u00ebr t\u00eb ve\u00e7orive.\",\"namespaceSubstring\":\"-pr-\",\"afterDaysWithoutDeploy\":1,\"checkEveryMinutes\":1,\"isDebug\":\"true\"}<\/code><\/pre>\n
      <\/p>\n
      Instalojm\u00eb aparatet<\/code>, q\u00eb p\u00ebrfshin dy namespace (project-pr-1<\/code>, project-pr-2<\/code>) dhe t\u00eb tyre deployed<\/code>, sh\u00ebrbimet<\/code>, ingress<\/code>, etj.:<\/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
      Po kontrollojm\u00eb q\u00eb t\u00eb gjitha burimet e m\u00ebsip\u00ebrme 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
      Pasi kemi aktivizuar debug<\/code>, namespace-t project-pr-1<\/code> dhe project-pr-2<\/code>, pra edhe t\u00eb gjitha burimet e tjera, do t\u00eb 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 duhet t\u00eb fshihet pasi q\u00eb \u00ebsht\u00eb aktivizuar moda e DEBUG.\",\"namespaceName\":\"projekt-pr-1\"}\n... \"msg\":\"Namespace \u00ebsht\u00eb duke u procesuar.\",\"namespaceName\":\"projekt-pr-1\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace \u00ebsht\u00eb fshir\u00eb.\",\"namespaceName\":\"projekt-pr-1\"}\n... \"msg\":\"Namespace duhet t\u00eb fshihet pasi q\u00eb \u00ebsht\u00eb aktivizuar moda e DEBUG.\",\"namespaceName\":\"projekt-pr-2\"}\n... \"msg\":\"Namespace \u00ebsht\u00eb duke u procesuar.\",\"namespaceName\":\"projekt-pr-2\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace \u00ebsht\u00eb fshir\u00eb.\",\"namespaceName\":\"projekt-pr-2\"}<\/code><\/pre>\n
      <\/p>\n
      N\u00ebse kontrolloni pranin\u00eb e burimeve, ato do t\u00eb jen\u00eb n\u00eb statusin Terminating<\/code> (procesi i fshirjes) ose tashm\u00eb t\u00eb fshira (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 aparatet<\/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 funksionon n\u00eb klaster? Ka disa qasje, t\u00eb gjitha jan\u00eb t\u00eb pafund dhe t\u00eb metat e tyre jan\u00eb subjektive, dhe secili vendos se cila \u00ebsht\u00eb m\u00eb e p\u00ebrshtatshme p\u00ebr projektin e tij:<\/p>\n
      <\/p>\n
        \n
      1. \n
        T\u00eb fshihen branch-at e ve\u00e7orive gjat\u00eb nd\u00ebrtimit t\u00eb branch-it master t\u00eb integrimit t\u00eb vazhduesh\u00ebm.<\/p>\n
        <\/p>\n