Nota. transl.: Despois dunha publicación recente sobre os métodos pull e push en GitOps, vimos interese neste modelo en xeral, pero había moi poucas publicacións en ruso sobre este tema (simplemente non hai ningunha en Habré). Polo tanto, temos o pracer de ofrecer á súa atención a tradución doutro artigo, aínda que hai case un ano! - de Weaveworks, cuxo xefe acuñou o termo "GitOps". O texto explica a esencia do enfoque e as principais diferenzas cos existentes.
Hai un ano publicamos . Daquela, compartimos como o equipo de Weaveworks lanzou un SaaS totalmente baseado en Kubernetes e desenvolveu un conxunto de mellores prácticas prescritivas para implementar, xestionar e supervisar nun ambiente nativo da nube.
O artigo resultou ser popular. Outras persoas comezaron a falar de GitOps e comezaron a publicar novas ferramentas para , , , , etcétera. Apareceu na nosa web publicacións e casos de uso de GitOps. Pero algunhas persoas aínda teñen preguntas. En que se diferencia o modelo do tradicional? e entrega continua ()? É necesario usar Kubernetes?
Pronto nos demos conta de que se necesitaba unha nova descrición que ofrecese:
- Un gran número de exemplos e historias;
- Definición específica de GitOps;
- Comparación coa entrega continua tradicional.
Neste artigo tratamos de cubrir todos estes temas. Ofrece unha introdución actualizada a GitOps e unha perspectiva para desenvolvedores e CI/CD. Centrámonos principalmente en Kubernetes, aínda que o modelo pódese xeneralizar.
Coñece GitOps
Imaxina Alicia. Dirixe o seguro familiar, que ofrece seguro de saúde, automóbil, fogar e viaxes a persoas que están demasiado ocupadas para descubrir por si mesmos os pormenores dos contratos. O seu negocio comezou como un proxecto paralelo cando Alice traballaba nun banco como científica de datos. Un día deuse conta de que podía usar algoritmos informáticos avanzados para analizar os datos de forma máis eficaz e formular paquetes de seguros. Os investimentos financiaron o proxecto, e agora a súa empresa achega máis de 20 millóns de dólares ao ano e está crecendo rapidamente. Actualmente, emprega a 180 persoas en diversos postos. Isto inclúe un equipo de tecnoloxía que desenvolve, mantén o sitio web, a base de datos e analiza a base de clientes. O equipo de 60 persoas está dirixido por Bob, o director técnico da empresa.
O equipo de Bob implanta sistemas de produción na nube. As súas aplicacións principais execútanse en GKE, aproveitando Kubernetes en Google Cloud. Ademais, empregan diversas ferramentas de datos e análises no seu traballo.
Family Insurance non se propuso utilizar contedores, pero quedou atrapado no entusiasmo de Docker. A compañía pronto descubriu que GKE facilitaba a implantación de clústeres para probar novas funcións. Engadíronse Jenkins para CI e Quay para organizar o rexistro de contedores, escribiuse scripts para Jenkins que enviaron novos contedores e configuracións a GKE.
Algún tempo pasou. Alice e Bob quedaron decepcionados co rendemento do enfoque escollido e o seu impacto no negocio. A introdución de contedores non mellorou a produtividade tanto como esperaba o equipo. Ás veces, os despregamentos rompíanse e non estaba claro se os cambios de código eran os culpables. Tamén resultou difícil rastrexar os cambios de configuración. Moitas veces era necesario crear un novo clúster e mover aplicacións a el, xa que esta era a forma máis sinxela de eliminar a desorde na que se converteu o sistema. Alicia tiña medo de que a situación empeorara a medida que se desenvolvese a aplicación (ademais, estaba a elaborar un novo proxecto baseado na aprendizaxe automática). Bob automatizara a maior parte do traballo e non entendía por que o gasoduto aínda era inestable, non se escalaba ben e necesitaba intervención manual periódicamente?
Despois aprenderon sobre GitOps. Esta decisión resultou ser exactamente a que necesitaban para seguir adiante con confianza.
Alice e Bob levan anos escoitando falar de Git, DevOps e infraestrutura como fluxos de traballo de código. O único de GitOps é que trae un conxunto de mellores prácticas, tanto definitivas como normativas, para implementar estas ideas no contexto de Kubernetes. Este tema , incluíndo en .
Family Insurance decide implementar GitOps. A empresa ten agora un modelo de operación automatizada que é compatible con Kubernetes e combina velocidade con estabilidadeporque eles:
- comprobou que a produtividade do equipo duplicouse sen que ninguén se volvese tolo;
- deixou de servir guións. Pola contra, agora poden centrarse en novas funcións e mellorar as técnicas de enxeñaría, por exemplo, implementando lanzamentos canarios e mellorando as probas;
- melloramos o proceso de implantación para que raramente se avare;
- tivo a oportunidade de restaurar as implantacións despois de fallos parciais sen intervención manual;
- comprado usadoоMaior confianza nos sistemas de entrega. Alice e Bob descubriron que podían dividir o equipo en equipos de microservizos traballando en paralelo;
- pode facer 30-50 cambios no proxecto todos os días grazas aos esforzos de cada grupo e probar novas técnicas;
- é fácil atraer novos desenvolvedores ao proxecto, que teñen a oportunidade de lanzar actualizacións á produción mediante solicitudes de extracción en poucas horas;
- pasar facilmente a auditoría no marco do SOC2 (para que os provedores de servizos cumpran cos requisitos para a xestión segura de datos; lea máis, por exemplo, - aprox. transl.).
Que pasou?
GitOps son dúas cousas:
- Modelo operativo para Kubernetes e nativo na nube. Ofrece un conxunto de mellores prácticas para a implantación, xestión e seguimento de clústeres e aplicacións en contedores. Definición elegante na forma de :
- O camiño para crear un ambiente de xestión de aplicacións centrado no desenvolvedor. Aplicamos o fluxo de traballo de Git tanto ás operacións como ao desenvolvemento. Teña en conta que non se trata só de Git push, senón de organizar todo o conxunto de ferramentas CI/CD e UI/UX.
Algunhas palabras sobre Git
Se non estás familiarizado cos sistemas de control de versións e o fluxo de traballo baseado en Git, recomendamos encarecidamente aprender sobre eles. Traballar con ramas e solicitudes de extracción pode parecer maxia negra ao principio, pero os beneficios pagan a pena. Aquí comezar.
Como funciona Kubernetes
Na nosa historia, Alice e Bob recorreron a GitOps despois de traballar con Kubernetes durante un tempo. De feito, GitOps está moi relacionado con Kubernetes: é un modelo operativo para infraestruturas e aplicacións baseadas en Kubernetes.
Que ofrece Kubernetes aos usuarios?
Aquí tes algunhas características principais:
- No modelo de Kubernetes, todo pódese describir en forma declarativa.
- O servidor da API de Kubernetes toma esta declaración como entrada e despois tenta continuamente levar o clúster ao estado descrito na declaración.
- As declaracións son suficientes para describir e xestionar unha gran variedade de cargas de traballo: "aplicacións".
- Como resultado, os cambios na aplicación e no clúster ocorren debido a:
- cambios nas imaxes do contedor;
- cambios na especificación declarativa;
- erros no medio ambiente, por exemplo, fallos de contedores.
Grandes capacidades de converxencia de Kubernetes
Cando un administrador realiza cambios de configuración, o orquestrador de Kubernetes aplicaraos ao clúster sempre que o seu estado sexa non se achegará á nova configuración. Este modelo funciona para calquera recurso de Kubernetes e é extensible con definicións de recursos personalizadas (CRD). Polo tanto, os despregamentos de Kubernetes teñen as seguintes propiedades marabillosas:
- Automatización: As actualizacións de Kubernetes proporcionan un mecanismo para automatizar o proceso de aplicación de cambios con gracia e de forma oportuna.
- Converxencia: Kubernetes continuará intentando actualizar ata que teña éxito.
- Idempotencia: As aplicacións repetidas de converxencia levan ao mesmo resultado.
- Determinismo: Cando os recursos son suficientes, o estado do clúster actualizado depende só do estado desexado.
Como funciona GitOps
Aprendemos o suficiente sobre Kubernetes para explicar como funciona GitOps.
Volvemos aos equipos de microservizos de Family Insurance. Que teñen que facer normalmente? Mire a lista que aparece a continuación (se algún elemento nel parece estraño ou descoñecido, por favor, deixe de facer críticas e quédese connosco). Estes son só exemplos de fluxos de traballo baseados en Jenkins. Hai moitos outros procesos cando se traballa con outras ferramentas.
O principal é que vemos que cada actualización remata con cambios nos ficheiros de configuración e repositorios Git. Estes cambios en Git fan que o "operador GitOps" actualice o clúster:
1. Proceso de traballo: "Jenkins build - rama mestra».
Lista de tarefas:
- Jenkins empurra as imaxes etiquetadas a Quay;
- Jenkins empurra os gráficos de configuración e Helm ao depósito de almacenamento principal;
- A función de nube copia a configuración e os gráficos do depósito de almacenamento principal ao repositorio principal de Git;
- O operador GitOps actualiza o clúster.
2. Compilación de Jenkins: publicación ou rama de revisión:
- Jenkins empurra imaxes sen etiquetar a Quay;
- Jenkins empurra os gráficos de configuración e Helm ao depósito de almacenamento;
- A función de nube copia a configuración e os gráficos desde o depósito de almacenamento para o repositorio de Git;
- O operador GitOps actualiza o clúster.
3. Jenkins build - desenvolvemento ou rama de características:
- Jenkins empurra imaxes sen etiquetar a Quay;
- Jenkins empurra os gráficos de configuración e Helm no depósito de almacenamento de desenvolvemento;
- A función na nube copia a configuración e os gráficos do depósito de almacenamento de desenvolvemento ao repositorio Git de desenvolvemento;
- O operador GitOps actualiza o clúster.
4. Engadindo un novo cliente:
- O xestor ou administrador (LCM/ops) chama a Gradle para implementar e configurar inicialmente os equilibradores de carga de rede (NLB);
- LCM/ops compromete unha nova configuración para preparar a implementación para as actualizacións;
- O operador GitOps actualiza o clúster.
Breve descrición de GitOps
- Describe o estado desexado de todo o sistema usando especificacións declarativas para cada ambiente (na nosa historia, o equipo de Bob define toda a configuración do sistema en Git).
- O repositorio Git é a única fonte de verdade sobre o estado desexado de todo o sistema.
- Todos os cambios no estado desexado realízanse mediante commits en Git.
- Todos os parámetros de clúster desexados tamén son observables no propio clúster. Deste xeito podemos determinar se coinciden (converxen, converxer) ou diferir (diverxer, diverxe) estados desexados e observados.
- Se os estados desexados e observados difiren, entón:
- Existe un mecanismo de converxencia que, tarde ou cedo, sincroniza automaticamente os estados obxectivo e observados. Dentro do clúster, Kubernetes fai isto.
- O proceso comeza inmediatamente cunha alerta de "cambio comprometido".
- Despois dun período de tempo configurable, pódese enviar unha alerta de "diferencia" se os estados son diferentes.
- Deste xeito, todos os commits en Git provocan actualizacións verificables e idempotentes no clúster.
- Rollback é a converxencia a un estado previamente desexado.
- A converxencia é definitiva. A súa aparición está indicada por:
- Non hai alertas de diferenza durante un período de tempo determinado.
- alerta "converxente" (por exemplo, webhook, evento de escritura de reembolso de Git).
Que é a diverxencia?
Repetimos de novo: todas as propiedades do clúster desexadas deben ser observables no propio clúster.
Algúns exemplos de diverxencia:
- Cambio no ficheiro de configuración debido á fusión de ramas en Git.
- Un cambio no ficheiro de configuración debido a unha confirmación de Git realizada polo cliente GUI.
- Varios cambios no estado desexado debido a PR en Git seguidos da construción da imaxe do contenedor e cambios de configuración.
- Un cambio no estado do clúster debido a un erro, un conflito de recursos que provoca un "mal comportamento" ou simplemente unha desviación aleatoria do estado orixinal.
Cal é o mecanismo de converxencia?
Algúns exemplos:
- Para contedores e clústeres, o mecanismo de converxencia é proporcionado por Kubernetes.
- O mesmo mecanismo pódese usar para xestionar aplicacións e deseños baseados en Kubernetes (como Istio e Kubeflow).
- Ofrece un mecanismo para xestionar a interacción operativa entre Kubernetes, os repositorios de imaxes e Git , que forma parte .
- Para as máquinas base, o mecanismo de converxencia debe ser declarativo e autónomo. Por experiencia propia podemos dicir que máis próximo a esta definición, pero aínda require control humano. Neste sentido, GitOps amplía a tradición da Infraestrutura como Código.
GitOps combina Git co excelente motor de converxencia de Kubernetes para proporcionar un modelo de explotación.
GitOps permítenos dicir: Só se poden automatizar e controlar aqueles sistemas que se poden describir e observar.
GitOps está pensado para toda a pila nativa da nube (por exemplo, Terraform, etc.)
GitOps non é só Kubernetes. Queremos que todo o sistema sexa dirixido de forma declarativa e use a converxencia. Por todo o sistema entendemos unha colección de ambientes que traballan con Kubernetes, por exemplo, "clúster de desenvolvemento 1", "produción", etc. Cada ambiente inclúe máquinas, clústeres, aplicacións, así como interfaces para servizos externos que proporcionan datos, monitorización. e etc.
Observe o importante que é Terraform para o problema de arranque neste caso. Kubernetes ten que ser implantado nalgún lugar, e usar Terraform significa que podemos aplicar os mesmos fluxos de traballo de GitOps para crear a capa de control que sustenta Kubernetes e as aplicacións. Esta é unha boa práctica útil.
Hai un gran foco na aplicación de conceptos de GitOps a capas enriba de Kubernetes. Neste momento, existen solucións tipo GitOps para Istio, Helm, Ksonnet, OpenFaaS e Kubeflow, así como, por exemplo, para Pulumi, que crean unha capa para o desenvolvemento de aplicacións nativas na nube.
Kubernetes CI/CD: comparando GitOps con outros enfoques
Como se dixo, GitOps son dúas cousas:
- O modelo operativo para Kubernetes e nativo na nube descrito anteriormente.
- O camiño cara a un ambiente de xestión de aplicacións centrado no desenvolvedor.
Para moitos, GitOps é principalmente un fluxo de traballo baseado en impulsos de Git. Tamén nos gusta. Pero iso non é todo: vexamos agora as conducións CI/CD.
GitOps permite a implantación continua (CD) para Kubernetes
GitOps ofrece un mecanismo de implantación continua que elimina a necesidade de "sistemas de xestión de despregamento" separados. Kubernetes fai todo o traballo por ti.
- A actualización da aplicación require unha actualización en Git. Esta é unha actualización transaccional para o estado desexado. A "Implementación" realízase entón dentro do clúster polo propio Kubernetes en función da descrición actualizada.
- Debido á natureza do funcionamento de Kubernetes, estas actualizacións son converxentes. Isto proporciona un mecanismo para o despregamento continuo no que todas as actualizacións son atómicas.
- Nota: ofrece un operador GitOps que integra Git e Kubernetes e permite realizar CD conciliando o estado desexado e actual do clúster.
Sen kubectl e scripts
Debería evitar usar Kubectl para actualizar o seu clúster e, especialmente, evitar usar scripts para agrupar comandos de kubectl. Pola contra, coa canalización de GitOps, un usuario pode actualizar o seu clúster de Kubernetes a través de Git.
Os beneficios inclúen:
- Certo. Pódense aplicar, converxer e finalmente validar un grupo de actualizacións, achegándonos ao obxectivo do despregamento atómico. Pola contra, o uso de scripts non proporciona ningunha garantía de converxencia (máis sobre isto a continuación).
- Безопасность. Kelsey Hightower: "Restrinxir o acceso ao seu clúster de Kubernetes ás ferramentas de automatización e aos administradores responsables de depuralo ou mantelo". Ver tamén sobre seguridade e cumprimento das especificacións técnicas, así como roubando credenciais dun guión de Jenkins escrito sen coidado.
- Experiencia de usuario. Kubectl expón a mecánica do modelo de obxectos de Kubernetes, que é bastante complexa. O ideal é que os usuarios interactúen co sistema nun nivel de abstracción superior. Aquí volverei a referirme a Kelsey e recomendo velo .
Diferenza entre CI e CD
GitOps mellora os modelos CI/CD existentes.
Un servidor CI moderno é unha ferramenta de orquestración. En particular, é unha ferramenta para orquestrar canalizacións de CI. Estes inclúen construír, probar, fusionar a troncal, etc. Os servidores CI automatizan a xestión de canalizacións complexas de varios pasos. Unha tentación común é crear un script dun conxunto de actualizacións de Kubernetes e executalo como parte dunha canalización para impulsar cambios no clúster. De feito, isto é o que fan moitos expertos. Non obstante, isto non é óptimo, e aquí tes por que.
Debe usarse CI para enviar actualizacións ao tronco e o clúster de Kubernetes debería cambiarse en función desas actualizacións para xestionar o CD internamente. Chamámoslle , a diferenza do modelo push CI. O CD é parte orquestración en tempo de execución.
Por que os servidores CI non deberían facer CDs mediante actualizacións directas en Kubernetes
Non use un servidor de CI para orquestrar actualizacións directas de Kubernetes como un conxunto de traballos de CI. Este é o antipatrón do que falamos no teu blog.
Volvemos a Alicia e Bob.
Que problemas se enfrontaron? O servidor CI de Bob aplica os cambios ao clúster, pero se falla durante o proceso, Bob non saberá en que estado está (ou debería estar) o clúster nin como solucionalo. O mesmo ocorre en caso de éxito.
Supoñamos que o equipo de Bob creou unha nova imaxe e despois parcheou as súas implementacións para implementar a imaxe (todo dende a canalización de CI).
Se a imaxe se constrúe normalmente, pero a canalización falla, o equipo terá que descubrir:
- A actualización lanzouse?
- Estamos lanzando unha nova construción? Conducirá isto a efectos secundarios innecesarios, coa posibilidade de ter dúas versións da mesma imaxe inmutable?
- Debemos esperar á próxima actualización antes de executar a compilación?
- Que saíu mal exactamente? Que pasos hai que repetir (e cales son seguros de repetir)?
Establecer un fluxo de traballo baseado en Git non garante que o equipo de Bob non se atope con estes problemas. Aínda poden cometer un erro co commit push, a etiqueta ou algún outro parámetro; porén, este enfoque aínda está moito máis próximo a un enfoque explícito de todo ou nada.
Para resumir, aquí tes por que os servidores CI non deberían tratar con CD:
- Os scripts de actualización non sempre son deterministas; É doado cometer erros neles.
- Os servidores de CI non converxen ao modelo de clúster declarativo.
- É difícil garantir a idempotencia. Os usuarios deben comprender a profunda semántica do sistema.
- É máis difícil recuperarse dunha falla parcial.
Nota sobre Helm: se queres usar Helm, recomendámoslle combinalo cun operador GitOps como . Isto axudará a garantir a converxencia. Helm en si non é nin determinista nin atómico.
GitOps como a mellor forma de implementar a entrega continua para Kubernetes
O equipo de Alice e Bob implementa GitOps e descobre que se fixo moito máis fácil traballar con produtos de software, manter un alto rendemento e estabilidade. Rematamos este artigo cunha ilustración que mostra como é o seu novo enfoque. Teña en conta que falamos principalmente de aplicacións e servizos, pero GitOps pódese usar para xestionar toda unha plataforma.
Modelo operativo para Kubernetes
Observa o seguinte diagrama. Presenta Git e o repositorio de imaxes do contedor como recursos compartidos para dous ciclos de vida orquestrados:
- Unha canalización de integración continua que le e escribe ficheiros en Git e pode actualizar un repositorio de imaxes de contedores.
- Unha canalización de GitOps en tempo de execución que combina a implementación con xestión e observabilidade. Le e escribe ficheiros en Git e pode descargar imaxes de contedores.
Cales son os principais achados?
- Separación de preocupacións: Teña en conta que ambas canalizacións só poden comunicarse actualizando Git ou o repositorio de imaxes. Noutras palabras, hai un firewall entre CI e o ambiente de execución. Chamámoslle o "firewall de inmutabilidade" (Firewall de inmutabilidade), xa que todas as actualizacións do repositorio crean novas versións. Para obter máis información sobre este tema, consulte as diapositivas 72-87 .
- Podes usar calquera servidor CI e Git: GitOps funciona con calquera compoñente. Podes seguir usando os teus servidores CI e Git favoritos, repositorios de imaxes e conxuntos de probas. Case todas as outras ferramentas de entrega continua do mercado requiren o seu propio servidor CI/Git ou repositorio de imaxes. Isto pode converterse nun factor limitante no desenvolvemento da nube nativa. Con GitOps, podes usar ferramentas coñecidas.
- Eventos como ferramenta de integración: En canto se actualicen os datos en Git, Weave Flux (ou o operador Weave Cloud) notifica o tempo de execución. Sempre que Kubernetes acepta un conxunto de cambios, Git actualízase. Isto proporciona un modelo de integración sinxelo para organizar fluxos de traballo para GitOps, como se mostra a continuación.
Conclusión
GitOps ofrece as fortes garantías de actualización requiridas por calquera ferramenta CI/CD moderna:
- automatización;
- converxencia;
- idempotencia;
- determinismo.
Isto é importante porque ofrece un modelo operativo para desenvolvedores nativos na nube.
- As ferramentas tradicionais para xestionar e supervisar sistemas están asociadas aos equipos de operacións que operan dentro dun runbook (un conxunto de procedementos e operacións habituais - aprox. traduc.), vinculado a un despregamento específico.
- Na xestión nativa da nube, as ferramentas de observabilidade son a mellor forma de medir os resultados dos despregamentos para que o equipo de desenvolvemento poida responder rapidamente.
Imaxina moitos clústeres espallados por diferentes nubes e moitos servizos cos seus propios equipos e plans de implantación. GitOps ofrece un modelo invariante de escala para xestionar toda esta abundancia.
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «».
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Sabías de GitOps antes de que estas dúas traducións aparecesen en Habré?
-
Si, sabía de todo
-
Só superficialmente
-
Non
Votaron 35 usuarios. 10 usuarios abstivéronse.
Fonte: www.habr.com