{"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":"Eliminiamo il branch feature obsoleto nel cluster Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Eliminiamo<\/p>\n

Ciao! Ramo funzionale<\/b> (aka deploy preview, review app) \u2014 \u00e8 quando vengono distribuite non solo la branch master, ma anche ogni pull request su un URL unico. Si pu\u00f2 verificare se il codice funziona nell'ambiente di produzione, e la funzionalit\u00e0 pu\u00f2 essere mostrata ad altri programmatori o product manager. Mentre si lavora nella pull request, ogni nuovo commit elimina il deploy attuale per il vecchio codice, e viene effettuato un nuovo deploy per il nuovo codice. Possono sorgere domande quando si \u00e8 fuso il 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 degli approcci 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 certo 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 Operatore Kubernetes<\/b> (un'applicazione che ha accesso alle risorse del cluster), link al progetto su Github<\/a><\/noindex>. Rimuove i namespace che appartengono a vecchie feature branch. In Kubernetes, se si elimina un namespace, anche 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
Su come implementare le feature branch nel cluster, si pu\u00f2 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 (continuous integration<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Pushiamo un nuovo commit nella branch.<\/li>\n
  2. Durante la build, vengono eseguiti linters e\/o test.<\/li>\n
  3. Le configurazioni di Kubernetes della pull request vengono create al volo (ad esempio, il suo numero viene inserito in un modello pronto).<\/li>\n
  4. Utilizzando kubectl apply, le configurazioni vengono caricate nel cluster (distribuzione).<\/li>\n
  5. Il pull request viene unito nella branch master.<\/li>\n<\/ol>\n
    <\/p>\n
    Mentre si lavora nella pull request, ogni nuovo commit elimina il deploy attuale per il vecchio codice, e viene effettuato un nuovo deploy per il nuovo codice. Ma quando il pull request viene fuso nella branch master, verr\u00e0 costruita solo la branch master. Alla fine, si dimentica il 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 seguente:<\/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
    Parametro namespaceSubstring<\/b> necessario per 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
    Parametro afterDaysWithoutDeploy<\/b> necessario per eliminare i vecchi namespace. Ad esempio, se il namespace \u00e8 stato creato 3 giorni 1 ora<\/code> fa, e nel parametro \u00e8 specificato 3 giorni<\/code>, questo namespace verr\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 verr\u00e0 rimosso.<\/p>\n
    <\/p>\n
    C'\u00e8 un altro parametro, che determina la frequenza con cui scansionare tutti i namespace e controllare i giorni senza deploy \u2014 checkEveryMinutes<\/b>. Per impostazione predefinita \u00e8 uguale a 30 minuti<\/code>.<\/p>\n
    <\/p>\n
    Come funziona<\/h2>\n
    <\/p>\n
    Nella pratica, servir\u00e0:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> per lavorare in un ambiente isolato.<\/li>\n
    2. Minikube<\/a><\/noindex> alzer\u00e0 il cluster Kubernetes localmente.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 interfaccia della riga di comando per gestire il cluster.<\/li>\n<\/ol>\n
      <\/p>\n
      Alziamo il cluster Kubernetes localmente:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 su Darwin 10.15.5\nUtilizzando il driver docker basato sul profilo esistente.\nAvviando il nodo del piano di controllo minikube nel cluster minikube.<\/code><\/pre>\n
      <\/p>\n
      Specifichiamo 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 controllare i vecchi namespace, e nel nostro nuovo cluster non ce ne sono, sostituiamo la variabile di ambiente IS_DEBUG<\/code> in true<\/code>. Con questo valore, il parametro afterDaysWithoutDeploy<\/code> non viene considerato e i namespace non vengono controllati per i giorni senza deploy, solo per la presenza della sottostringa (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Se sei 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 sei 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
      Controlliamo che nel cluster sia apparso il risorsa StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nNOME                 ... APIGROUP                             ... TYPE\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      Controlliamo 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 si guarda 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\":\"Versione dell'operatore: 0.0.1\"\n...\n... \"msg\":\"Avvio di EventSource\", ... , \"source\":\"tipo sorgente: \/, Tipo=\"}\n... \"msg\":\"Avvio del Controller\", ...}\n... \"msg\":\"Avvio dei lavoratori\", ..., \"numero di lavoratori\":1}<\/code><\/pre>\n
      <\/p>\n
      Installiamo i pronti fixtures<\/code> (configurazioni pronte per la modellazione delle 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
      \u00c8 specificato di cercare namespace contenenti 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 risposto 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\":\"La feature branch obsoleta \u00e8 in fase di elaborazione.\",\"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\/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
      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 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
      Poich\u00e9 abbiamo attivato debug<\/code>, namespace project-pr-1<\/code> e project-pr-2<\/code>, di conseguenza tutte le altre risorse, dovranno essere eliminate immediatamente senza considerare il parametro afterDaysWithoutDeploy<\/code>. Nei log dell'operatore questo \u00e8 visibile:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Il namespace deve essere eliminato poich\u00e9 la modalit\u00e0 debug \u00e8 abilitata.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Il namespace \u00e8 in fase di elaborazione.\",\"namespaceName\":\"project-pr-1\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Il namespace \u00e8 stato eliminato.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Il namespace deve essere eliminato poich\u00e9 la modalit\u00e0 debug \u00e8 abilitata.\",\"namespaceName\":\"project-pr-2\"}\n... \"msg\":\"Il namespace \u00e8 in fase di elaborazione.\",\"namespaceName\":\"project-pr-2\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Il namespace \u00e8 stato eliminato.\",\"namespaceName\":\"project-pr-2\"}<\/code><\/pre>\n
      <\/p>\n
      Se controlliamo la presenza 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 assicurarti che vengano eliminate entro un minuto.<\/p>\n
      <\/p>\n
      Alternative<\/h2>\n
      <\/p>\n
      Cosa si pu\u00f2 fare al posto dell'operatore che lavora in un cluster? Ci sono diversi approcci, tutti imperfetti (e i loro svantaggi sono soggettivi), e ciascuno decide cosa si adatta meglio al progetto specifico:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Eliminare il branch feature durante la build del branch master di integrazione continua.<\/p>\n
        <\/p>\n