{"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\/es\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Eliminando la rama de caracter\u00edsticas obsoleta en el cl\u00faster de Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Eliminando<\/p>\n

\u00a1Hola! Rama de caracter\u00edsticas<\/b> (aka deploy preview, review app) \u2014 esto es cuando se despliega no solo la rama master, sino tambi\u00e9n cada pull request en una URL \u00fanica. Se puede comprobar si el c\u00f3digo funciona en un entorno de producci\u00f3n, o se puede mostrar la funci\u00f3n a otros programadores o product managers. Mientras trabajas en el pull request, cada nuevo commit elimina el despliegue actual para el c\u00f3digo antiguo y se despliega el nuevo c\u00f3digo. Pueden surgir preguntas cuando has fusionado el pull request en la rama master. La feature branch ya no la necesitas, pero los recursos de Kubernetes todav\u00eda est\u00e1n en el cl\u00faster.<\/p>\n

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

M\u00e1s sobre feature branches<\/h2>\n

<\/p>\n

Uno de los enfoques para hacer feature branches en Kubernetes es usar namespaces. En resumen, la configuraci\u00f3n de producci\u00f3n se ve as\u00ed:<\/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
Para la feature branch se crea un namespace con su identificador (por ejemplo, el n\u00famero del pull request) y alg\u00fan prefijo\/sufijo (por ejemplo, -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 general, escrib\u00ed Kubernetes Operator<\/b> (una aplicaci\u00f3n que tiene acceso a los recursos del cl\u00faster), enlace al proyecto en Github<\/a><\/noindex>. Elimina los namespaces que pertenecen a las antiguas feature branches. En Kubernetes, si se elimina un namespace, otros recursos en ese namespace tambi\u00e9n se eliminan autom\u00e1ticamente.<\/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
Sobre c\u00f3mo implementar feature branches en el cl\u00faster, se puede leer aqu\u00ed<\/a><\/noindex> y aqu\u00ed<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motivaci\u00f3n<\/h2>\n
<\/p>\n
Veamos el ciclo de vida t\u00edpico de un pull request con integraci\u00f3n continua (continuous integration<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Hacemos push de un nuevo commit en la rama.<\/li>\n
  2. En la compilaci\u00f3n, se ejecutan linters y\/o pruebas.<\/li>\n
  3. Las configuraciones de Kubernetes del pull request se generan din\u00e1micamente (por ejemplo, su n\u00famero se inserta en una plantilla lista).<\/li>\n
  4. Con kubectl apply, las configuraciones se env\u00edan al cl\u00faster (despliegue).<\/li>\n
  5. El pull request se fusiona en la rama master.<\/li>\n<\/ol>\n
    <\/p>\n
    Mientras trabajas en el pull request, cada nuevo commit elimina el despliegue actual para el c\u00f3digo antiguo y se despliega el nuevo c\u00f3digo. Pero cuando el pull request se fusiona en la rama master, solo se construir\u00e1 la rama master. Al final, resulta que nos olvidamos del pull request, pero sus recursos de Kubernetes a\u00fan est\u00e1n en el cl\u00faster.<\/p>\n
    <\/p>\n
    C\u00f3mo usar<\/h2>\n
    <\/p>\n
    Instala el proyecto con el siguiente comando:<\/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 archivo con el siguiente contenido e inst\u00e1lalo a trav\u00e9s de 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
    Par\u00e1metro namespaceSubstring<\/b> se necesita, para filtrar los namespaces de los pull requests de otros namespaces. Por ejemplo, si en el cl\u00faster hay los siguientes namespaces: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, entonces los candidatos para eliminaci\u00f3n ser\u00e1n habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Par\u00e1metro afterDaysWithoutDeploy<\/b> se necesita para eliminar los antiguos namespaces. Por ejemplo, si se cre\u00f3 un namespace hace 3 d\u00edas 1 hora<\/code> , y en el par\u00e1metro se indica 3 d\u00edas<\/code>, este namespace ser\u00e1 eliminado. Funciona al rev\u00e9s: si el namespace fue creado hace 2 d\u00edas 23 horas<\/code> , y en el par\u00e1metro se indica 3 d\u00edas<\/code>, este namespace no ser\u00e1 eliminado.<\/p>\n
    <\/p>\n
    Hay otro par\u00e1metro que indica con qu\u00e9 frecuencia escanear todos los namespaces y verificar los d\u00edas sin despliegue \u2014 checkEveryMinutes<\/b>. Por defecto es 30 minutos<\/code>.<\/p>\n
    <\/p>\n
    \u00bfC\u00f3mo funciona?<\/h2>\n
    <\/p>\n
    En la pr\u00e1ctica, ser\u00e1 necesario:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> para trabajar en un entorno aislado.<\/li>\n
    2. Minikube<\/a><\/noindex> levantar\u00e1 el cl\u00faster de Kubernetes localmente.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 interfaz de l\u00ednea de comandos para gestionar el cl\u00faster.<\/li>\n<\/ol>\n
      <\/p>\n
      Levantamos el cl\u00faster de Kubernetes localmente:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 en Darwin 10.15.5\nUsando el driver docker basado en el perfil existente.\nIniciando el nodo del plano de control minikube en el cl\u00faster minikube.<\/code><\/pre>\n
      <\/p>\n
      Especificamos kubectl<\/code> usar el cl\u00faster local por defecto:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nSwitched to context \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Descargamos configuraciones para el entorno de producci\u00f3n:<\/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
      Dado que las configuraciones de producci\u00f3n est\u00e1n configuradas para verificar los antiguos namespaces, y en nuestro nuevo cl\u00faster no hay ninguno, reemplazaremos la variable de entorno IS_DEBUG<\/code> en true<\/code>. Con este valor, el par\u00e1metro afterDaysWithoutDeploy<\/code> no se considera y los namespaces no se verifican por d\u00edas sin despliegue, solo por la coincidencia de subcadenas (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Si est\u00e1s en Linux<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Si est\u00e1s en macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Instalamos el proyecto:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Verificamos que el recurso ha aparecido en el cl\u00faster StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nNOMBRE                 ... GRUPO DE APIS                             ... TIPO\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      Verificamos que el operador ha aparecido en el cl\u00faster:<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nNOMBRE                                           ... ESTADO  ... EDAD\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... Ejecut\u00e1ndose ... 38s<\/code><\/pre>\n
      <\/p>\n
      Si miramos sus registros, est\u00e1 listo para procesar recursos StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Versi\u00f3n del operador: 0.0.1\"}\n...\n... \"msg\":\"Iniciando EventSource\", ... , \"source\":\"tipo de fuente: \/, Tipo=\"}\n... \"msg\":\"Iniciando Controlador\", ...}\n... \"msg\":\"Iniciando trabajadores\", ..., \"worker count\":1}<\/code><\/pre>\n
      <\/p>\n
      Instalamos los fixtures<\/code> (configuraciones listas para modelar los recursos del cl\u00faster) para el recurso 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
      Las configuraciones indican buscar namespaces que contengan la subcadena -pr-<\/code> cada 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
      El operador ha respondido y est\u00e1 listo para verificar los namespaces:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"La rama de funci\u00f3n obsoleta est\u00e1 siendo procesada.\",\"namespaceSubstring\":\"-pr-\",\"afterDaysWithoutDeploy\":1,\"checkEveryMinutes\":1,\"isDebug\":\"true\"}<\/code><\/pre>\n
      <\/p>\n
      Instalamos fixtures<\/code>, que contienen dos namespaces (project-pr-1<\/code>, project-pr-2<\/code>) y sus despliegues<\/code>, servicios<\/code>, ingress<\/code>, y as\u00ed sucesivamente:<\/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
      Verificamos que todos los recursos anteriores se han creado con \u00e9xito:<\/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
      Dado que hemos habilitado debug<\/code>, namespaces project-pr-1<\/code> y project-pr-2<\/code>, por lo tanto, todos los dem\u00e1s recursos deben eliminarse de inmediato sin tener en cuenta el par\u00e1metro afterDaysWithoutDeploy<\/code>. En los logs del operador esto se puede ver:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"El namespace debe ser eliminado porque el modo de depuraci\u00f3n est\u00e1 habilitado.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"El namespace est\u00e1 siendo procesado.\",\"namespaceName\":\"project-pr-1\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"El namespace ha sido eliminado.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"El namespace debe ser eliminado porque el modo de depuraci\u00f3n est\u00e1 habilitado.\",\"namespaceName\":\"project-pr-2\"}\n... \"msg\":\"El namespace est\u00e1 siendo procesado.\",\"namespaceName\":\"project-pr-2\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"El namespace ha sido eliminado.\",\"namespaceName\":\"project-pr-2\"}<\/code><\/pre>\n
      <\/p>\n
      Si se verifica la existencia de recursos, estar\u00e1n en estado Terminating<\/code> (proceso de eliminaci\u00f3n) o ya eliminados (la salida del comando est\u00e1 vac\u00eda).<\/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
      Puedes repetir el proceso de creaci\u00f3n fixtures<\/code> varias veces y asegurarte de que ser\u00e1n eliminados en un minuto.<\/p>\n
      <\/p>\n
      Alternativas<\/h2>\n
      <\/p>\n
      \u00bfQu\u00e9 se puede hacer en lugar de un operador que trabaja en un cl\u00faster? Hay varios enfoques, todos ellos son imperfectos (y sus desventajas son subjetivas), y cada uno decide qu\u00e9 es lo que mejor se adapta a su proyecto espec\u00edfico:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Eliminar la rama de caracter\u00edsticas durante la integraci\u00f3n continua de la rama master.<\/p>\n
        <\/p>\n