{"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\/it\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Rimuoviamo il branch feature obsoleto nel cluster Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Rimuoviamo<\/p>\n

Ciao! Branch di funzionalit\u00e0<\/b> (aka deploy preview, review app) \u2014 \u00e8 quando non viene distribuita solo la branch master, ma anche ogni pull request su un URL unico. Puoi verificare se il codice funziona in produzione, e mostrare la funzionalit\u00e0 ad altri programmatori o product manager. Mentre lavori in una pull request, ogni nuovo commit elimina l'attuale distribuzione per il vecchio codice, mentre viene distribuito un nuovo codice. Possono sorgere domande quando hai fuso la pull request nella branch master. La feature branch non \u00e8 pi\u00f9 necessaria, ma le risorse di Kubernetes sono ancora nel cluster.<\/p>\n

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

Ancora sulla feature branch<\/h2>\n

<\/p>\n

Uno dei modi per creare feature branch in Kubernetes \u00e8 utilizzare i namespace. In breve, la configurazione di produzione appare cos\u00ec:<\/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
Per la feature branch viene creato un namespace con il suo identificatore (ad esempio, il numero della pull request) e un prefisso\/postfisso (ad esempio, -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
In generale, ho scritto Kubernetes Operator<\/b> (applicazione che ha accesso alle risorse del cluster), link al progetto su Github<\/a><\/noindex>. Questo elimina i namespace relativi a vecchie feature branch. In Kubernetes, se elimini un namespace, le altre risorse in quel namespace vengono eliminate automaticamente.<\/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
Per informazioni su come implementare le feature branch nel cluster, puoi leggere qui<\/a><\/noindex> e qui<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motivazione<\/h2>\n
<\/p>\n
Diamo un'occhiata al ciclo di vita tipico di una pull request con integrazione continua (integrazione continua<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Inviamo un nuovo commit nel branch.<\/li>\n
  2. Durante la build, vengono eseguiti linters e\/o test.<\/li>\n
  3. Le configurazioni Kubernetes per la pull request vengono create al volo (ad esempio, il numero viene inserito in un modello pronto).<\/li>\n
  4. Con kubectl apply, le configurazioni vengono inviate nel cluster (deploy).<\/li>\n
  5. Il pull request viene unito nel branch master.<\/li>\n<\/ol>\n
    <\/p>\n
    Mentre lavori in una pull request, ogni nuovo commit elimina l'attuale distribuzione per il vecchio codice e viene distribuito un nuovo codice. Ma quando la pull request viene fusa nella branch master, verr\u00e0 compilata solo la branch master. Alla fine, sembra che ci siamo dimenticati della pull request, ma le sue risorse Kubernetes sono ancora nel cluster.<\/p>\n
    <\/p>\n
    Come utilizzare<\/h2>\n
    <\/p>\n
    Installa il progetto con il comando qui sotto:<\/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
    Crea un file con il seguente contenuto e installalo tramite 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
    Caratteristica namespaceSubstring<\/b> \u00e8 necessario filtrare i namespace delle pull request da altri namespace. Ad esempio, se nel cluster ci sono i seguenti namespace: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, allora i candidati per la rimozione saranno habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Caratteristica afterDaysWithoutDeploy<\/b> \u00e8 necessario per eliminare i vecchi namespace. Ad esempio, se un namespace \u00e8 stato creato 3 giorni 1 ora<\/code> fa, e nel parametro \u00e8 specificato 3 giorni<\/code>, questo namespace sar\u00e0 rimosso. Funziona anche al contrario, se un namespace \u00e8 stato creato 2 giorni 23 ore<\/code> fa, e nel parametro \u00e8 specificato 3 giorni<\/code>, questo namespace non sar\u00e0 rimosso.<\/p>\n
    <\/p>\n
    C'\u00e8 un altro parametro, che determina con quale frequenza scansionare tutti i namespace e controllare i giorni senza distribuzione \u2014 checkEveryMinutes<\/b>. Per impostazione predefinita \u00e8 pari a 30 minuti<\/code>.<\/p>\n
    <\/p>\n
    Come funziona<\/h2>\n
    <\/p>\n
    In pratica, sar\u00e0 necessario:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> per operare in un ambiente isolato.<\/li>\n
    2. Minikube<\/a><\/noindex> sollever\u00e0 un cluster Kubernetes localmente.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 interfaccia a riga di comando per gestire il cluster.<\/li>\n<\/ol>\n
      <\/p>\n
      Solleviamo un cluster Kubernetes localmente:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 on Darwin 10.15.5\nUsing the docker driver based on existing profile.\nStarting control plane node minikube in cluster minikube.<\/code><\/pre>\n
      <\/p>\n
      Indichiamo kubectl<\/code> utilizzare il cluster locale per impostazione predefinita:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nSwitched to context \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Scarichiamo le configurazioni per l'ambiente di produzione:<\/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
      Poich\u00e9 le configurazioni di produzione sono impostate per verificare i vecchi namespace e nel nostro nuovo cluster non ce ne sono, sostituiamo la variabile d'ambiente IS_DEBUG<\/code> con true<\/code>. Con questo valore, il parametro afterDaysWithoutDeploy<\/code> non viene considerato e i namespace non vengono controllati per i giorni senza distribuzione, solo per la presenza di una sottostringa (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Se ti trovi su Linux<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Se ti trovi su macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Installiamo il progetto:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Verifichiamo che nel cluster sia apparso il risorso StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nNOME                 ... APIGROUP                             ... TIPO\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      Verifichiamo che nel cluster sia apparso l'operatore:<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nNOME                                           ... STATO  ... ET\u00c0\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... In esecuzione ... 38s<\/code><\/pre>\n
      <\/p>\n
      Se guardiamo nei suoi log, \u00e8 pronto a gestire le risorse 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
      Installando i fixtures pronti fixtures<\/code> (configurazioni pronte per simulare le risorse del cluster) per la risorsa 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
      Nelle configurazioni \u00e8 specificato di cercare i namespace con la sottostringa -pr-<\/code> ogni 1 minuto<\/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
      L'operatore ha reagito ed \u00e8 pronto a controllare i namespace:<\/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
      Installiamo fixtures<\/code>, contenente due namespace (project-pr-1<\/code>, project-pr-2<\/code>) e i loro deployments<\/code>, servizi<\/code>, ingress<\/code>, e cos\u00ec via:<\/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\/progetto-pr-1 creato\ndeployment.apps\/progetto-pr-1 creato\nservice\/progetto-pr-1 creato\nhorizontalpodautoscaler.autoscaling\/progetto-pr-1 creato\nsecret\/progetto-pr-1 creato\nconfigmap\/progetto-pr-1 creato\ningress.extensions\/progetto-pr-1 creato\nnamespace\/progetto-pr-2 creato\ndeployment.apps\/progetto-pr-2 creato\nservice\/progetto-pr-2 creato\nhorizontalpodautoscaler.autoscaling\/progetto-pr-2 creato\nsecret\/progetto-pr-2 creato\nconfigmap\/progetto-pr-2 creato\ningress.extensions\/progetto-pr-2 creato<\/code><\/pre>\n
      <\/p>\n
      Verifichiamo che tutte le risorse sopra siano state create con successo:<\/p>\n
      <\/p>\n
      $ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n progetto-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n progetto-pr-2\n...\nNOME                             ... PRONTO ... STATO  ... ET\u00c0\npod\/progetto-pr-1-848d5fdff6-rpmzw ... 1\/1   ... In esecuzione ... 67s\n\nNOME                        ... PRONTO ... DISPONIBILE ... ET\u00c0\ndeployment.apps\/progetto-pr-1 ... 1\/1   ... 1         ... 67s\n...<\/code><\/pre>\n
      <\/p>\n
      Poich\u00e9 abbiamo attivato debug<\/code>, namespace project-pr-1<\/code> e project-pr-2<\/code>, tutte le altre risorse devono essere eliminate immediatamente, senza considerare il parametro afterDaysWithoutDeploy<\/code>. Questo \u00e8 visibile nei log dell'operatore:<\/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
      Se controlli la disponibilit\u00e0 delle risorse, saranno in stato Terminating<\/code> (in fase di eliminazione) o gi\u00e0 eliminate (l'output del comando \u00e8 vuoto).<\/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
      Puoi ripetere il processo di creazione fixtures<\/code> pi\u00f9 volte e verificare che vengano eliminati entro un minuto.<\/p>\n
      <\/p>\n
      Alternative<\/h2>\n
      <\/p>\n
      Cosa si pu\u00f2 fare invece di un operatore che lavora nel cluster? Ci sono diversi approcci, tutti non ideali (e i loro svantaggi sono soggettivi), e ognuno decide cosa si adatta meglio al progetto specifico:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Eliminare il branch di funzionalit\u00e0 durante la build dell'integrazione continua del branch master.<\/p>\n
        <\/p>\n