{"id":35594,"date":"2019-10-31T22:05:15","date_gmt":"2019-10-31T19:05:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/gitops-sravnenie-metodov-pull-i-push\/"},"modified":"2019-10-31T22:05:15","modified_gmt":"2019-10-31T19:05:15","slug":"gitops-sravnenie-metodov-pull-i-push","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: comparaci\u00f3n de m\u00e9todos Pull y Push","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota de traducci\u00f3n.<\/b>: En la comunidad de Kubernetes, est\u00e1 ganando una notable popularidad una tendencia llamada GitOps, de la que nos convencimos personalmente, al asistir<\/a><\/noindex> a KubeCon Europe 2019. Este t\u00e9rmino fue creado relativamente recientemente por el fundador de Weaveworks, Alexis Richardson, y se refiere a la aplicaci\u00f3n de herramientas familiares para los desarrolladores (principalmente Git, de donde proviene su nombre) para abordar tareas de operaci\u00f3n. En particular, se trata de operar Kubernetes almacenando sus configuraciones en Git y desplegando autom\u00e1ticamente cambios en el cl\u00faster. Matthias Jg explica en este art\u00edculo dos enfoques para este despliegue.<\/a><\/noindex> El a\u00f1o pasado<\/i><\/p>\n

\"GitOps:
\n
\n(de hecho, formalmente ocurri\u00f3 en agosto de 2017 - nota del traductor) apareci\u00f3 un nuevo enfoque para el despliegue de aplicaciones en Kubernetes. Se llama GitOps, y se basa en la idea fundamental de que el seguimiento de versiones de despliegues se realiza en un entorno seguro de repositorio Git.<\/i> ha surgido un nuevo enfoque para el despliegue de aplicaciones en Kubernetes. Se llama GitOps, y se basa en la premisa fundamental de que el seguimiento de las versiones de los despliegues se realiza en un entorno seguro de repositorio Git.<\/a><\/noindex><\/p>\n

Versionado de despliegues e historial de cambios<\/b>:<\/p>\n

    \n
  1. Versionado de despliegues e historial de cambios<\/b>. El estado de todo el cl\u00faster se almacena en un repositorio Git, y los despliegues solo se actualizan mediante commits. Adem\u00e1s, todos los cambios se pueden rastrear a trav\u00e9s del historial de commits.<\/li>\n
  2. . Un simple<\/b>git reset permite revertir cambios en los despliegues; siempre hay estados anteriores disponibles.<\/code> permite revertir cambios en los despliegues; siempre est\u00e1n disponibles estados anteriores.<\/li>\n
  3. . Por lo general, un sistema Git contiene muchos datos confidenciales, por lo que la mayor\u00eda de las empresas prestan especial atenci\u00f3n a su protecci\u00f3n. Por lo tanto, esta protecci\u00f3n se extiende tambi\u00e9n a las operaciones con despliegues.<\/b>. Normalmente, el sistema Git contiene muchos datos confidenciales, por lo que la mayor\u00eda de las empresas presta especial atenci\u00f3n a su protecci\u00f3n. En consecuencia, esta protecci\u00f3n tambi\u00e9n se aplica a las operaciones con los despliegues.<\/li>\n
  4. . La mayor\u00eda de los sistemas Git inicialmente soportan pol\u00edticas para diferentes ramas, por ejemplo, solo los pull requests pueden actualizar el master, y otro miembro del equipo debe revisar y aprobar los cambios. Al igual que con el control de acceso, las mismas pol\u00edticas se aplican a las actualizaciones de los despliegues.<\/b>. La mayor\u00eda de los sistemas Git inicialmente admiten pol\u00edticas para diferentes ramas \u2014 por ejemplo, solo los pull requests pueden actualizar master, y los cambios deben ser revisados y aceptados por otro miembro del equipo. Al igual que con el control de acceso, se aplican las mismas pol\u00edticas a las actualizaciones de los despliegues.<\/li>\n<\/ol>\n

    \nComo pueden ver, el m\u00e9todo GitOps tiene muchas ventajas. En el \u00faltimo a\u00f1o, dos enfoques han ganado especial popularidad. Uno se basa en push, el otro en pull. Antes de examinarlos, veamos primero c\u00f3mo se ven los t\u00edpicos despliegues de Kubernetes.<\/p>\n

    En los \u00faltimos a\u00f1os, han surgido varios m\u00e9todos y herramientas para despliegues en Kubernetes:<\/h2>\n

    \nBasados en plantillas nativas de Kubernetes\/Kustomize<\/p>\n

      \n
    1. Basado en plantillas nativas de Kubernetes\/Kustomize<\/b>. Esta es la forma m\u00e1s sencilla de desplegar aplicaciones en Kubernetes. El desarrollador crea archivos YAML b\u00e1sicos y los aplica. Para evitar reescribir constantemente las mismas plantillas, se desarroll\u00f3 Kustomize (que convierte las plantillas de Kubernetes en m\u00f3dulos). Nota de traducci\u00f3n.<\/b>: Kustomize se ha integrado en kubectl con el lanzamiento de Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Chartes de Helm<\/b>. Los charts de Helm permiten crear conjuntos de plantillas, init-containers, sidecars, etc., que se utilizan para desplegar aplicaciones con capacidades de configuraci\u00f3n m\u00e1s flexibles que en el enfoque basado en plantillas. Este m\u00e9todo se basa en archivos YAML parametrizados. Helm los completa con varios par\u00e1metros y luego los env\u00eda a Tiller, que es un componente del cl\u00faster que los despliega en el cl\u00faster y permite realizar actualizaciones y retrocesos. Es importante que, en esencia, Helm simplemente inserta los valores necesarios en las plantillas y luego las aplica de la misma manera que se hace en el enfoque tradicional (para m\u00e1s informaci\u00f3n sobre c\u00f3mo funciona todo esto y c\u00f3mo se puede usar, lea nuestro art\u00edculo sobre Helm<\/a><\/noindex> \u2014 nota del traductor)<\/i>. Hay una gran variedad de Chartes de Helm listos que abarcan un amplio espectro de tareas.<\/li>\n
    3. Herramientas alternativas<\/b>. Hay muchas herramientas alternativas. Todas ellas comparten el hecho de que convierten algunos archivos de plantilla en comprensibles archivos YAML de Kubernetes y luego los aplican.<\/li>\n<\/ol>\n

      \nEn nuestro trabajo, usamos constantemente los Chartes de Helm para herramientas importantes (ya que muchos de ellos ya est\u00e1n listos, lo que simplifica mucho la vida) y archivos YAML 'limpios' de Kubernetes para desplegar nuestras propias aplicaciones.<\/p>\n

      Pull & Push<\/h2>\n

      \nEn una de sus publicaciones recientes en el blog, present\u00e9 la herramienta Weave Flux<\/a><\/noindex>, permitiendo hacer commits de las plantillas en el repositorio Git y actualizar el despliegue despu\u00e9s de cada commit o push del contenedor. Mi experiencia muestra que esta herramienta es una de las principales en la promoci\u00f3n del enfoque pull, por lo que me referir\u00e9 a ella con frecuencia. Si deseas saber m\u00e1s sobre c\u00f3mo usarla, aqu\u00ed tienes el enlace al art\u00edculo<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Todas las ventajas del uso de GitOps se mantienen para ambos enfoques.<\/i><\/p>\n

      Enfoque basado en Pull<\/h2>\n

      \n\"GitOps:
      \n
      \nLa base del enfoque pull radica en el hecho de que todos los cambios se aplican desde dentro del cl\u00faster. Dentro del cl\u00faster hay un operador que verifica regularmente los repositorios de Git y el Docker Registry relacionados. Si hay alg\u00fan cambio en ellos, el estado del cl\u00faster se actualiza desde adentro. Por lo general, se considera que este proceso es bastante seguro, ya que ning\u00fan cliente externo tiene acceso a los derechos de administrador del cl\u00faster.<\/p>\n

      Pros:<\/b><\/p>\n

        \n
      1. Ning\u00fan cliente externo tiene derechos para realizar cambios en el cl\u00faster; todas las actualizaciones se implementan desde adentro.<\/li>\n
      2. Algunas herramientas tambi\u00e9n permiten sincronizar actualizaciones de Helm charts y vincularlas al cl\u00faster.<\/li>\n
      3. Se puede escanear el Docker Registry en busca de nuevas versiones. Si aparece una nueva imagen, el repositorio de Git y el despliegue se actualizan a la nueva versi\u00f3n.<\/li>\n
      4. Las herramientas pull pueden estar distribuidas en diferentes espacios de nombres con diferentes repositorios de Git y derechos de acceso. Esto permite aplicar un modelo multicliente (multitenant). Por ejemplo, el equipo A puede usar el espacio de nombres A, el equipo B utiliza el espacio de nombres B, y el equipo encargado de la infraestructura puede usar un espacio global.<\/li>\n
      5. Por lo general, las herramientas son bastante ligeras.<\/li>\n
      6. En combinaci\u00f3n con herramientas como el operador Bitnami Sealed Secrets<\/a><\/noindex>, los secretos pueden almacenarse encriptados en el repositorio de Git y ser extra\u00eddos dentro del cl\u00faster.<\/li>\n
      7. No hay conexi\u00f3n con las canalizaciones de CD, ya que los despliegues ocurren dentro del cl\u00faster.<\/li>\n<\/ol>\n

        \nDesventajas<\/b>:<\/p>\n

          \n
        1. Gestionar los secretos de los despliegues a partir de gr\u00e1ficos Helm es m\u00e1s complicado que con los convencionales, ya que primero hay que generarlos como, digamos, secretos sellados, luego desencriptarlos con un operador interno y solo despu\u00e9s estar\u00e1n disponibles para la herramienta de pull. Despu\u00e9s se puede ejecutar el lanzamiento en Helm con los valores ya dentro de los secretos desplegados. La forma m\u00e1s simple es crear un secreto con todos los valores de Helm utilizados para el despliegue, desencriptarlo y hacer un commit en Git.<\/li>\n
        2. Al aplicar un enfoque de pull, est\u00e1s atado a herramientas que operan con pull. Esto limita la capacidad de personalizar el proceso de despliegue en el cl\u00faster. Por ejemplo, trabajar con Kustomize se complica porque debe ejecutarse antes de que las plantillas finales lleguen a Git. No digo que no se puedan usar herramientas separadas, pero es m\u00e1s dif\u00edcil integrarlas en el proceso de despliegue.<\/li>\n<\/ol>\n

          <\/p>\n

          Enfoque basado en Push<\/h2>\n

          \n\"GitOps:
          \n
          \nEn el enfoque push, un sistema externo (principalmente tuber\u00edas CD) inicia despliegues en el cl\u00faster despu\u00e9s de un commit en el repositorio de Git o en caso de que una tuber\u00eda CI anterior se ejecute con \u00e9xito. En este enfoque, el sistema tiene acceso al cl\u00faster.<\/p>\n

          Ventajas<\/b>:<\/p>\n

            \n
          1. La seguridad est\u00e1 definida por el repositorio de Git y la tuber\u00eda de construcci\u00f3n.<\/li>\n
          2. Es m\u00e1s f\u00e1cil desplegar gr\u00e1ficos de Helm, hay soporte para plugins de Helm.<\/li>\n
          3. Es m\u00e1s sencillo gestionar secretos, ya que se pueden aplicar en las tuber\u00edas y tambi\u00e9n almacenar en Git de manera cifrada (dependiendo de las preferencias del usuario).<\/li>\n
          4. No hay dependencia de una herramienta espec\u00edfica, ya que se pueden utilizar cualquier tipo de ellas.<\/li>\n
          5. Las actualizaciones de versiones de contenedores pueden ser iniciadas por la tuber\u00eda de construcci\u00f3n.<\/li>\n<\/ol>\n

            \nDesventajas<\/b>:<\/p>\n

              \n
            1. Los datos de acceso al cl\u00faster se encuentran dentro del sistema de construcci\u00f3n.<\/li>\n
            2. Actualizar los contenedores de despliegue sigue siendo m\u00e1s f\u00e1cil con el proceso de pull.<\/li>\n
            3. Fuerte dependencia del sistema CD, ya que las tuber\u00edas necesarias pueden haber sido inicialmente escritas para Gitlab Runners, y luego el equipo decide migrar a Azure DevOps o Jenkins\u2026 y habr\u00e1 que realizar una migraci\u00f3n de un gran n\u00famero de tuber\u00edas de construcci\u00f3n.<\/li>\n<\/ol>\n

              <\/p>\n

              Conclusiones: \u00bfPush o Pull?<\/h2>\n

              \nComo suele suceder, cada enfoque tiene sus ventajas y desventajas. Algunas tareas son m\u00e1s f\u00e1ciles de realizar con uno y m\u00e1s dif\u00edciles con otro. Al principio, realizaba implementaciones manualmente, pero tras encontrar varios art\u00edculos sobre Weave Flux, decid\u00ed adoptar procesos GitOps para todos los proyectos. Para las plantillas b\u00e1sicas esto result\u00f3 f\u00e1cil, pero luego empec\u00e9 a enfrentar dificultades al trabajar con gr\u00e1ficos de Helm. En ese momento, Weave Flux solo ofrec\u00eda una versi\u00f3n incipiente del Helm Chart Operator, pero incluso ahora algunas tareas son m\u00e1s complicadas debido a la necesidad de crear secretos manualmente y aplicarlos. Se podr\u00eda argumentar que el enfoque pull es mucho m\u00e1s seguro, ya que las credenciales del cl\u00faster no est\u00e1n disponibles fuera de \u00e9l, lo que aumenta la seguridad lo suficiente como para justificar el esfuerzo adicional.<\/p>\n

              Despu\u00e9s de reflexionar un poco, llegu\u00e9 a la conclusi\u00f3n inesperada de que no es as\u00ed. En cuanto a los componentes que requieren m\u00e1xima protecci\u00f3n, esta lista incluir\u00eda los almacenes de secretos y los sistemas de CI\/CD, as\u00ed como los repositorios de Git. La informaci\u00f3n dentro de ellos es bastante vulnerable y necesita la m\u00e1xima protecci\u00f3n. Adem\u00e1s, si alguien logra infiltrarse en tu repositorio de Git y puede hacer push de c\u00f3digo, podr\u00e1 desplegar lo que desee (independientemente del enfoque elegido, ya sea pull o push), e infiltrarse en los sistemas del cl\u00faster. Por lo tanto, los componentes m\u00e1s importantes que requieren protecci\u00f3n son el repositorio de Git y los sistemas de CI\/CD, y no las credenciales del cl\u00faster. Si tienes pol\u00edticas y medidas de seguridad bien configuradas para sistemas de este tipo y las credenciales del cl\u00faster se extraen en los pipelines solo como secretos, la seguridad adicional del enfoque de pull podr\u00eda resultar no tan valiosa como se supon\u00eda originalmente.<\/p>\n

              Entonces, si el enfoque pull es m\u00e1s laborioso y no ofrece una ventaja en seguridad, \u00bfno ser\u00eda l\u00f3gico usar solo el enfoque push? Pero alguien podr\u00eda argumentar que en el enfoque push est\u00e1s demasiado atado al sistema de CD y, quiz\u00e1s, ser\u00eda mejor evitarlo para facilitar futuras migraciones.<\/p>\n

              En mi opini\u00f3n (como siempre), se debe utilizar lo que mejor se adapte a cada caso o combinar ambos. Personalmente, utilizo ambos enfoques: Weave Flux para despliegues basados en pull, que principalmente incluyen nuestros propios servicios, y el enfoque push con Helm y complementos, que simplifica la aplicaci\u00f3n de gr\u00e1ficos Helm al cl\u00faster y permite crear secretos sin problemas. Creo que nunca habr\u00e1 una \u00fanica soluci\u00f3n que funcione para todos los casos, porque siempre hay muchos matices y dependen del caso de uso espec\u00edfico. Por lo tanto, recomiendo encarecidamente GitOps: facilita mucho las cosas y mejora la seguridad.<\/p>\n

              Espero que mi experiencia sobre este tema ayude a decidir qu\u00e9 m\u00e9todo es m\u00e1s adecuado para su tipo de despliegues, y estar\u00e9 encantado de conocer su opini\u00f3n.<\/p>\n

              P.D. Nota del traductor<\/h2>\n

              \nEn las desventajas del modelo pull hay un punto sobre lo dif\u00edcil que es poner en Git los manifiestos renderizados, sin embargo, no hay desventaja en que el pipeline de CD en el modelo pull vive por separado del despliegue y esencialmente se convierte en un pipeline de la categor\u00eda Continuous Apply<\/i>. Por lo tanto, se requerir\u00e1n a\u00fan m\u00e1s esfuerzos para recopilar el estado de todos los despliegues y proporcionar acceso a los registros\/estados, preferiblemente vinculado al sistema CD.<\/p>\n

              En este sentido, el modelo push permite dar algunas garant\u00edas sobre el lanzamiento, porque se puede igualar la vida \u00fatil del pipeline con el tiempo de vida del lanzamiento.<\/p>\n

              Hemos probado ambos modelos y llegamos a las mismas conclusiones que el autor del art\u00edculo:<\/p>\n

                \n
              1. El modelo pull es adecuado para organizar la actualizaci\u00f3n de componentes del sistema en un gran n\u00famero de cl\u00fasteres (ver el art\u00edculo sobre addon-operator<\/a><\/noindex>).<\/li>\n
              2. El modelo push basado en GitLab CI es muy adecuado para el lanzamiento de aplicaciones usando gr\u00e1ficos Helm. Al mismo tiempo, el lanzamiento de despliegues en el marco de los pipelines se monitorea con la herramienta werf<\/a><\/noindex>. Vale la pena mencionar que en el contexto de este proyecto escuchamos constantemente 'GitOps' cuando discut\u00edamos los problemas actuales de los ingenieros DevOps en nuestro stand en KubeCon Europe '19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.D. del traductor<\/h2>\n

                \nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n