{"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\/fr\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Suppression de la branche de fonctionnalit\u00e9s obsol\u00e8te dans le cluster Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Suppression<\/p>\n

Bonjour ! Branche de fonctionnalit\u00e9<\/b> (aka d\u00e9ploiement de pr\u00e9visualisation, application de r\u00e9vision) \u2014 c'est lorsque non seulement la branche master est d\u00e9ploy\u00e9e, mais aussi chaque pull request sur une URL unique. Vous pouvez v\u00e9rifier si le code fonctionne dans un environnement de production, la fonctionnalit\u00e9 peut \u00eatre montr\u00e9e \u00e0 d'autres d\u00e9veloppeurs ou chefs de produits. Tant que vous travaillez dans la pull request, chaque nouveau commit supprime le d\u00e9ploiement actuel pour l'ancien code et un nouveau d\u00e9ploiement pour le nouveau code est cr\u00e9\u00e9. Des questions peuvent survenir lorsque vous avez fusionn\u00e9 la pull request dans la branche master. La branche de fonctionnalit\u00e9 n'est plus n\u00e9cessaire, mais les ressources Kubernetes sont toujours pr\u00e9sentes dans le cluster.<\/p>\n

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

\u00c0 propos des branches de fonctionnalit\u00e9s<\/h2>\n

<\/p>\n

Une des approches pour cr\u00e9er des branches de fonctionnalit\u00e9s dans Kubernetes consiste \u00e0 utiliser des namespaces. En r\u00e9sum\u00e9, la configuration de production ressemble \u00e0 ceci :<\/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
Pour la branche de fonctionnalit\u00e9, un namespace est cr\u00e9\u00e9 avec son identifiant (par exemple, le num\u00e9ro de la pull request) et un certain pr\u00e9fixe\/suffixe (par exemple, -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
En g\u00e9n\u00e9ral, j'ai \u00e9crit Kubernetes Operator<\/b> (une application qui a acc\u00e8s aux ressources du cluster), lien vers le projet sur Github<\/a><\/noindex>). Il supprime les namespaces associ\u00e9s aux anciennes branches de fonctionnalit\u00e9s. Dans Kubernetes, si vous supprimez un namespace, les autres ressources dans ce namespace sont \u00e9galement automatiquement supprim\u00e9es.<\/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
Pour savoir comment int\u00e9grer les branches de fonctionnalit\u00e9s dans le cluster, vous pouvez lire ici<\/a><\/noindex> et ici<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motivation<\/h2>\n
<\/p>\n
Examiner le cycle de vie typique d'une pull request avec int\u00e9gration continue (int\u00e9gration continue<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Nous poussons un nouveau commit dans la branche.<\/li>\n
  2. Lors de la construction, des linters et\/ou des tests sont lanc\u00e9s.<\/li>\n
  3. Les configurations Kubernetes de la pull request sont g\u00e9n\u00e9r\u00e9es \u00e0 la vol\u00e9e (par exemple, en ins\u00e9rant son num\u00e9ro dans un mod\u00e8le pr\u00eat).<\/li>\n
  4. Les configurations sont appliqu\u00e9es au cluster \u00e0 l'aide de kubectl (d\u00e9ploiement).<\/li>\n
  5. La pull request est fusionn\u00e9e dans la branche master.<\/li>\n<\/ol>\n
    <\/p>\n
    Tant que vous travaillez dans la pull request, chaque nouveau commit supprime le d\u00e9ploiement actuel pour l'ancien code et un nouveau d\u00e9ploiement pour le nouveau code est cr\u00e9\u00e9. Mais lorsque la pull request est fusionn\u00e9e dans la branche master, seul la branche master sera construite. En fin de compte, nous avons oubli\u00e9 la pull request, mais ses ressources Kubernetes sont toujours pr\u00e9sentes dans le cluster.<\/p>\n
    <\/p>\n
    Comment utiliser<\/h2>\n
    <\/p>\n
    Installez le projet avec la commande ci-dessous :<\/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
    Cr\u00e9ez un fichier avec le contenu suivant et installez-le via 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
    Param\u00e8tre namespaceSubstring<\/b> n\u00e9cessaire pour filtrer les namespaces pour les pull requests des autres namespaces. Par exemple, si le cluster contient les namespaces suivants : habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, alors les candidats \u00e0 la suppression seront habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Param\u00e8tre afterDaysWithoutDeploy<\/b> n\u00e9cessaire pour supprimer les anciens namespaces. Par exemple, si un namespace est cr\u00e9\u00e9 il y a 3 jours et 1 heure<\/code> , et que le param\u00e8tre sp\u00e9cifie 3 jours<\/code>, ce namespace sera supprim\u00e9. Cela fonctionne aussi dans l'autre sens, si le namespace a \u00e9t\u00e9 cr\u00e9\u00e9 il y a 2 jours et 23 heures<\/code> , et que le param\u00e8tre sp\u00e9cifie 3 jours<\/code>, ce namespace ne sera pas supprim\u00e9.<\/p>\n
    <\/p>\n
    Il y a un autre param\u00e8tre qui d\u00e9termine \u00e0 quelle fr\u00e9quence tous les namespaces doivent \u00eatre scann\u00e9s et v\u00e9rifi\u00e9s pour les jours sans d\u00e9ploiement \u2014 checkEveryMinutes<\/b>. Par d\u00e9faut, il est \u00e9gal \u00e0 30 minutes<\/code>.<\/p>\n
    <\/p>\n
    Comment cela fonctionne<\/h2>\n
    <\/p>\n
    En pratique, il faut :<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> pour fonctionner dans un environnement isol\u00e9.<\/li>\n
    2. Minikube<\/a><\/noindex> va lancer un cluster Kubernetes localement.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 interface en ligne de commande pour g\u00e9rer le cluster.<\/li>\n<\/ol>\n
      <\/p>\n
      Lan\u00e7ons le cluster Kubernetes localement :<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 sur Darwin 10.15.5\nUtilisation du pilote docker bas\u00e9 sur le profil existant.\nD\u00e9marrage du n\u0153ud du plan de contr\u00f4le minikube dans le cluster minikube.<\/code><\/pre>\n
      <\/p>\n
      Indiquons kubectl<\/code> d'utiliser le cluster local par d\u00e9faut :<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nContexte \"minikube\" activ\u00e9.<\/code><\/pre>\n
      <\/p>\n
      T\u00e9l\u00e9chargeons les configurations pour l'environnement de production :<\/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
      Comme les configurations de production sont r\u00e9gl\u00e9es pour v\u00e9rifier les anciens namespaces, et qu'il n'y en a pas dans notre nouveau cluster, rempla\u00e7ons la variable d'environnement IS_DEBUG<\/code> sur true<\/code>. Avec cette valeur, le param\u00e8tre afterDaysWithoutDeploy<\/code> n'est pas pris en compte et les namespaces ne sont pas v\u00e9rifi\u00e9s pour les jours sans d\u00e9ploiement, seulement pour la pr\u00e9sence de sous-cha\u00eenes (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Si vous \u00eates sur Linux<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Si vous \u00eates sur macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Installons le projet :<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      V\u00e9rifions que la ressource est apparue dans le cluster StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nNOM                 ... APIGROUP                             ... TYPE\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      V\u00e9rifions que l'op\u00e9rateur est apparu dans le cluster :<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nNOM                                           ... \u00c9TAT  ... \u00c2GE\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... En cours d'ex\u00e9cution ... 38s<\/code><\/pre>\n
      <\/p>\n
      Si nous regardons ses logs, il est pr\u00eat \u00e0 traiter les ressources StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Version de l'op\u00e9rateur : 0.0.1\"}\n...\n... \"msg\":\"D\u00e9marrage de EventSource\", ... , \"source\":\"kind source: \/, Kind=\"}\n... \"msg\":\"D\u00e9marrage du contr\u00f4leur\", ...}\n... \"msg\":\"D\u00e9marrage des travailleurs\", ..., \"worker count\":1}<\/code><\/pre>\n
      <\/p>\n
      Installons les fixtures<\/code> (configurations pr\u00eates pour la mod\u00e9lisation des ressources de cluster) pour la ressource 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
      Les configurations indiquent de rechercher des namespaces contenant une sous-cha\u00eene -pr-<\/code> toutes les 1 minute<\/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'op\u00e9rateur a r\u00e9agi et est pr\u00eat \u00e0 v\u00e9rifier les namespaces :<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"La branche de fonctionnalit\u00e9 obsol\u00e8te est en cours de traitement.\",\"namespaceSubstring\":\"-pr-\",\"afterDaysWithoutDeploy\":1,\"checkEveryMinutes\":1,\"isDebug\":\"true\"}<\/code><\/pre>\n
      <\/p>\n
      Nous installons fixtures<\/code>, contenant deux namespaces (project-pr-1<\/code>, project-pr-2<\/code>) et leurs d\u00e9ploiements<\/code>, services<\/code>, ingress<\/code>, et ainsi de suite :<\/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 cr\u00e9\u00e9\nd\u00e9ploiement.apps\/project-pr-1 cr\u00e9\u00e9\nservice\/project-pr-1 cr\u00e9\u00e9\nhorizontalpodautoscaler.autoscaling\/project-pr-1 cr\u00e9\u00e9\nsecret\/project-pr-1 cr\u00e9\u00e9\nconfigmap\/project-pr-1 cr\u00e9\u00e9\ningress.extensions\/project-pr-1 cr\u00e9\u00e9\nnamespace\/project-pr-2 cr\u00e9\u00e9\nd\u00e9ploiement.apps\/project-pr-2 cr\u00e9\u00e9\nservice\/project-pr-2 cr\u00e9\u00e9\nhorizontalpodautoscaler.autoscaling\/project-pr-2 cr\u00e9\u00e9\nsecret\/project-pr-2 cr\u00e9\u00e9\nconfigmap\/project-pr-2 cr\u00e9\u00e9\ningress.extensions\/project-pr-2 cr\u00e9\u00e9<\/code><\/pre>\n
      <\/p>\n
      V\u00e9rifions que toutes les ressources ci-dessus ont \u00e9t\u00e9 cr\u00e9\u00e9es avec succ\u00e8s :<\/p>\n
      <\/p>\n
      $ kubectl get namespace,pods,d\u00e9ploiement,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,d\u00e9ploiement,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2\n...\nNOM                              ... PR\u00caT ... STATUT  ... \u00c2GE\npod\/project-pr-1-848d5fdff6-rpmzw ... 1\/1   ... En cours d'ex\u00e9cution ... 67s\n\nNOM                         ... PR\u00caT ... DISPONIBLE ... \u00c2GE\nd\u00e9ploiement.apps\/project-pr-1 ... 1\/1   ... 1         ... 67s\n...<\/code><\/pre>\n
      <\/p>\n
      Puisque nous avons activ\u00e9 debug<\/code>, namespaces project-pr-1<\/code> et project-pr-2<\/code>, tous les autres ressources devraient \u00e9galement \u00eatre supprim\u00e9es imm\u00e9diatement, sans tenir compte du param\u00e8tre afterDaysWithoutDeploy<\/code>. Dans les logs de l'op\u00e9rateur, cela est visible :<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Le namespace doit \u00eatre supprim\u00e9 car le mode d\u00e9bogage est activ\u00e9.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Le namespace est en cours de traitement.\",\"namespaceName\":\"project-pr-1\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Le namespace a \u00e9t\u00e9 supprim\u00e9.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Le namespace doit \u00eatre supprim\u00e9 car le mode d\u00e9bogage est activ\u00e9.\",\"namespaceName\":\"project-pr-2\"}\n... \"msg\":\"Le namespace est en cours de traitement.\",\"namespaceName\":\"project-pr-2\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Le namespace a \u00e9t\u00e9 supprim\u00e9.\",\"namespaceName\":\"project-pr-2\"}<\/code><\/pre>\n
      <\/p>\n
      Si nous v\u00e9rifions la pr\u00e9sence des ressources, elles seront dans l'\u00e9tat Terminating<\/code> (processus de suppression) ou d\u00e9j\u00e0 supprim\u00e9es (le r\u00e9sultat de la commande est vide).<\/p>\n
      <\/p>\n
      $ kubectl get namespace,pods,d\u00e9ploiement,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,d\u00e9ploiement,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2\n...<\/code><\/pre>\n
      <\/p>\n
      Vous pouvez r\u00e9p\u00e9ter le processus de cr\u00e9ation fixtures<\/code> assurez-vous plusieurs fois qu'ils seront supprim\u00e9s dans la minute.<\/p>\n
      <\/p>\n
      Alternatives<\/h2>\n
      <\/p>\n
      Que peut-on faire \u00e0 la place d'un op\u00e9rateur fonctionnant dans un cluster ? Plusieurs approches sont possibles, toutes ne sont pas id\u00e9ales (et leurs inconv\u00e9nients sont subjectifs), et chacun d\u00e9cide ce qui convient le mieux \u00e0 son projet sp\u00e9cifique :<\/p>\n
      <\/p>\n
        \n
      1. \n
        Supprimer la branche feature pendant le build de la branche master d'int\u00e9gration continue.<\/p>\n
        <\/p>\n