A maioría de nós, notando outro termo novo na blogosfera ou conferencia informática, tarde ou cedo facemos unha pregunta semellante: “Que é isto? Só outra palabra de moda, unha "palabra de moda" ou algo verdadeiramente digno de atención, estudo e promesa de novos horizontes? A min pasoume o mesmo co termo GitOps hai algún tempo. Armado con moitos artigos existentes, así como o coñecemento dos compañeiros da empresa , tentei descubrir que tipo de besta é esta e como pode ser o seu uso na práctica.
Por certo, sobre a novidade do termo GitOps A nosa recente enquisa tamén di: máis da metade dos enquisados aínda non comezaron a traballar cos seus principios.
Polo tanto, o problema da xestión das infraestruturas non é novo. Moitos provedores de nube levan unha boa ducia de anos dispoñibles para o público en xeral e, ao parecer, deberían facer que o traballo dos equipos responsables da infraestrutura sexa sinxelo e directo. Non obstante, se se compara co proceso de desenvolvemento de aplicacións (onde a automatización está a acadar niveis cada vez máis novos), os proxectos de infraestrutura aínda implican moitas tarefas manuais e requiren coñecementos e experiencia especializada, especialmente tendo en conta os requisitos actuais de tolerancia a fallos, flexibilidade, escalabilidade e elasticidade.
Os servizos na nube cumpriron estes requisitos con gran éxito e foron eles os que deron un importante impulso ao desenvolvemento do enfoque IaC. Isto é comprensible. Despois de todo, fixeron posible configurar un centro de datos completamente virtual: non hai servidores físicos, bastidores ou compoñentes de rede; toda a infraestrutura pódese describir mediante scripts e ficheiros de configuración.
Entón, cal é exactamente a diferenza? GitOps de IaC? Foi con esta pregunta que comecei a miña investigación. Despois de falar cos compañeiros, puiden facer a seguinte comparación:
GitOps
IaC
Todo o código gárdase nun repositorio git
A versión do código é opcional
Código Declarativo Descrición / Idempotencia
As descricións declarativas e imperativas son aceptables
Os cambios entran en vigor mediante os mecanismos Solicitude de combinación/Solicitude de extracción
O acordo, a aprobación e a colaboración son facultativos
O proceso de lanzamento da actualización está automatizado
O proceso de lanzamento da actualización non está estandarizado (automático, manual, copiando ficheiros, usando a liña de comandos, etc.)
Noutras palabras GitOps naceu precisamente pola aplicación dos principios IaC. En primeiro lugar, agora poderían almacenarse a infraestrutura e as configuracións do mesmo xeito que as aplicacións. O código é fácil de almacenar, compartir, comparar e usar as capacidades de versión. Versións, ramas, historia. E todo isto nun lugar accesible ao público para todo o equipo. Polo tanto, o uso de sistemas de control de versións converteuse nun desenvolvemento completamente natural. En particular, git, como o máis popular.
Por outra banda, fíxose posible automatizar os procesos de xestión de infraestruturas. Agora pódese facer máis rápido, máis fiable e máis barato. Ademais, os principios de CI/CD xa eran coñecidos e populares entre os desenvolvedores de software. Só era necesario transferir e aplicar coñecementos e habilidades xa coñecidas a unha nova área. Estas prácticas, con todo, foron máis aló da definición estándar de Infraestrutura como código, de aí o concepto GitOps.
Curiosidade GitOps, por suposto, tamén no feito de que non se trata dun produto, complemento ou plataforma asociada a ningún vendedor. É máis un paradigma e un conxunto de principios, semellante a outro termo que coñecemos: DevOps.
En compañía elaboramos dúas definicións deste novo termo: teórica e práctica. Comecemos polo teórico:
GitOps é unha metodoloxía que toma os mellores principios de DevOps utilizados para o desenvolvemento de aplicacións, como o control de versións, a colaboración, a orquestración, CI/CD, e aplícaos aos retos da automatización da xestión da infraestrutura.
Todos os procesos GitOps Traballo usando ferramentas existentes. Todo o código de infraestrutura gárdase no repositorio git xa coñecido, os cambios pasan polo mesmo proceso de aprobación que calquera outro código de programa e o proceso de lanzamento está automatizado, o que nos permite minimizar os erros humanos, aumentar a fiabilidade e a reproducibilidade.
Dende o punto de vista práctico, describimos GitOps do seguinte xeito:
Xa falamos da infraestrutura como código como un dos compoñentes clave desta fórmula. Imos presentar ao resto dos participantes.
Solicitude de combinación (nome alternativo Pull Request). En termos de proceso, MR é unha solicitude para aplicar cambios de código e, a continuación, fusionar ramas. Pero en canto ás ferramentas que usamos, esta é máis unha oportunidade para obter unha imaxe completa de todos os cambios que se están a facer: non só a diferenza de código recollida a partir dun determinado número de commits, senón tamén o contexto, os resultados das probas e o resultado final esperado. Se estamos a falar de código de infraestrutura, entón estamos interesados en como cambiará exactamente a infraestrutura, cantos novos recursos se engadirán ou eliminarán, cambiarán. Preferiblemente nalgún formato máis cómodo e fácil de ler. Para os provedores de nube, é unha boa idea saber cal será o impacto financeiro deste cambio.
Pero a RM tamén é un medio de colaboración, interacción e comunicación. O lugar onde entra en xogo o sistema de contrapesos. Desde simples comentarios ata aprobacións e aprobacións formais.
Pois ben, o último compoñente: CI/CD, como xa sabemos, permite automatizar o proceso de realización de cambios e probas na infraestrutura (desde unha simple comprobación de sintaxe ata unha análise de código estático máis complexo). E tamén na posterior detección da deriva: diferenzas entre o estado real e desexado do sistema. Por exemplo, como resultado de cambios manuais non autorizados ou fallos do sistema.
Si, o termo GitOps non nos introduce en nada completamente novo, non reinventa a roda, senón que simplemente aplica a experiencia xa acumulada nunha nova área. Pero aquí reside a súa forza.
E se de súpeto te interesas como se ve todo isto na práctica, invitoche a mirar o noso , no que vos conto paso a paso como usar GitLab:
-
Implementar os principios básicos de GitOps
-
Crear e facer cambios na infraestrutura da nube (usando o exemplo de Yandex Cloud)
-
Automatiza a detección da deriva do sistema desde o estado desexado mediante a monitorización activa
https://bit.ly/34tRpwZ
Fonte: www.habr.com