Nota. transl.: A la comunitat Kubernetes, una tendència anomenada GitOps està guanyant popularitat òbvia, com hem vist personalment, KubeCon Europe 2019. Aquest terme era relativament recent pel cap de Weaveworks - Alexis Richardson - i significa l'ús d'eines conegudes pels desenvolupadors (principalment Git, d'aquí el nom) per resoldre problemes operatius. En particular, estem parlant del funcionament de Kubernetes emmagatzemant les seves configuracions a Git i desplegant automàticament els canvis al clúster. Matthias Jg parla de dos enfocaments d'aquest llançament en aquest article.
L'any passat, (de fet, formalment això va passar l'agost de 2017 - aprox. traducció) Hi ha un nou enfocament per desplegar aplicacions a Kubernetes. Es diu GitOps i es basa en la idea bàsica que les versions de desplegament es fan un seguiment a l'entorn segur d'un dipòsit de Git.
Els principals avantatges d'aquest enfocament són els següents::
- Versions de desplegament i historial de canvis. L'estat de tot el clúster s'emmagatzema en un dipòsit de Git i els desplegaments només s'actualitzen mitjançant commits. A més, es poden fer un seguiment de tots els canvis mitjançant l'historial de commits.
- Retrocedeix utilitzant ordres Git conegudes. Simple
git resetpermet restablir els canvis en els desplegaments; estats passats sempre estan disponibles. - Control d'accés a punt. Normalment, un sistema Git conté moltes dades sensibles, de manera que la majoria de les empreses presten especial atenció a protegir-les. En conseqüència, aquesta protecció també s'aplica a les operacions amb desplegaments.
- Polítiques de desplegaments. La majoria dels sistemes Git admeten de manera nativa les polítiques branca per branca; per exemple, només les sol·licituds d'extracció poden actualitzar el mestre, i els canvis han de ser revisats i acceptats per un altre membre de l'equip. Igual que amb el control d'accés, les mateixes polítiques s'apliquen a les actualitzacions de desplegament.
Com podeu veure, el mètode GitOps té molts avantatges. Durant l'últim any, dos enfocaments han guanyat una popularitat especial. Un està basat en push, l'altre està basat en pull. Abans de mirar-los, primer mirem com són els desplegaments típics de Kubernetes.
Mètodes de desplegament
En els darrers anys, s'han establert diversos mètodes i eines per a desplegaments a Kubernetes:
- Basat en plantilles natives de Kubernetes/Kustomize. Aquesta és la manera més senzilla de desplegar aplicacions a Kubernetes. El desenvolupador crea els fitxers YAML bàsics i els aplica. Per desfer-se de reescriure constantment les mateixes plantilles, es va desenvolupar Kustomize (converteix les plantilles de Kubernetes en mòduls). Nota. transl.: Kustomize s'ha integrat a kubectl amb .
- Llistes de timó. Els gràfics Helm us permeten crear conjunts de plantilles, contenidors d'inici, sidecars, etc., que s'utilitzen per desplegar aplicacions amb opcions de personalització més flexibles que en un enfocament basat en plantilles. Aquest mètode es basa en fitxers YAML amb plantilla. Helm els omple amb diversos paràmetres i després els envia a Tiller, un component del clúster que els desplega al clúster i permet actualitzacions i retrocessos. L'important és que, essencialment, Helm només insereix els valors desitjats a les plantilles i després els aplica de la mateixa manera que es fa en l'enfocament tradicional. (llegiu més sobre com funciona tot i com podeu utilitzar-lo al nostre -aprox. trad.). Hi ha una gran varietat de gràfics Helm ja fets que cobreixen una àmplia gamma de tasques.
- Eines alternatives. Hi ha moltes eines alternatives. El que tots tenen en comú és que converteixen alguns fitxers de plantilla en fitxers YAML llegibles per Kubernetes i després els utilitzen.
En el nostre treball, utilitzem constantment els gràfics Helm per a eines importants (ja que ja tenen moltes coses a punt, cosa que ens facilita molt la vida) i fitxers YAML de Kubernetes "purs" per desplegar les nostres pròpies aplicacions.
Estirar i empènyer
En una de les meves publicacions recents al blog, vaig presentar l'eina , que us permet enviar plantilles al repositori de Git i actualitzar el desplegament després de cada commit o push del contenidor. La meva experiència demostra que aquesta eina és una de les principals en la promoció de l'enfocament pull, per la qual cosa m'hi referiré sovint. Si voleu saber més sobre com utilitzar-lo, aquí .
NB! Tots els avantatges d'utilitzar GitOps segueixen sent els mateixos per a ambdós enfocaments.
Enfocament basat en pull
L'enfocament d'atracció es basa en el fet que tots els canvis s'apliquen des del clúster. Hi ha un operador dins del clúster que comprova regularment els dipòsits de registre Git i Docker associats. Si es produeixen canvis, l'estat del clúster s'actualitza internament. Aquest procés es considera generalment molt segur, ja que cap client extern té accés als drets d'administrador del clúster.
Pros:
- Cap client extern té drets per fer canvis al clúster; totes les actualitzacions es desenvolupen des de dins.
- Algunes eines també us permeten sincronitzar les actualitzacions de gràfics Helm i enllaçar-les al clúster.
- El registre Docker es pot escanejar per buscar noves versions. Si hi ha una imatge nova disponible, el dipòsit i el desplegament de Git s'actualitzen a la nova versió.
- Les eines d'extracció es poden distribuir en diferents espais de noms amb diferents repositoris i permisos de Git. Gràcies a això, es pot utilitzar un model multiarrendatari. Per exemple, l'equip A pot utilitzar l'espai de noms A, l'equip B pot utilitzar l'espai de noms B i l'equip d'infraestructura pot utilitzar l'espai global.
- Com a regla general, les eines són molt lleugeres.
- Combinat amb eines com l'operador , els secrets es poden emmagatzemar xifrats en un repositori Git i recuperar-los dins del clúster.
- No hi ha connexió amb canalitzacions de CD ja que els desplegaments es produeixen dins del clúster.
Contres:
- Gestionar els secrets de desplegament dels gràfics Helm és més difícil que els normals, ja que primer s'han de generar en forma, per exemple, de secrets segellats, després desxifrats per un operador intern i només després queden disponibles per a l'eina d'extracció. A continuació, podeu executar el llançament a Helm amb els valors dels secrets ja desplegats. La manera més senzilla és crear un secret amb tots els valors d'Helm utilitzats per al desplegament, desxifrar-lo i enviar-lo a Git.
- Quan fas un enfocament d'estirament, estàs lligat a les eines d'estirament. Això limita la capacitat de personalitzar el procés de desplegament en un clúster. Per exemple, Kustomize es complica pel fet que s'ha d'executar abans que les plantilles finals es comprometin a Git. No dic que no pugueu utilitzar eines autònomes, però són més difícils d'integrar al vostre procés de desplegament.
Enfocament basat en push
En l'enfocament push, un sistema extern (principalment canalitzacions de CD) llança desplegaments al clúster després d'una confirmació al dipòsit de Git o si la canalització CI anterior té èxit. En aquest enfocament, el sistema té accés al clúster.
Pros:
- La seguretat la determina el repositori Git i la canalització de compilació.
- La implementació de gràfics d'Helm és més fàcil i és compatible amb els connectors d'Helm.
- Els secrets són més fàcils de gestionar perquè els secrets es poden utilitzar en pipelines i també es poden emmagatzemar xifrats a Git (segons les preferències de l'usuari).
- No hi ha connexió amb una eina específica, ja que es pot utilitzar qualsevol tipus.
- Les actualitzacions de la versió del contenidor es poden iniciar mitjançant la canalització de compilació.
Contres:
- Les dades d'accés al clúster es troben dins del sistema de compilació.
- L'actualització dels contenidors de desplegament és encara més fàcil amb un procés d'extracció.
- Gran dependència del sistema de CD, ja que els pipelines que necessitem poden haver estat escrits originalment per a Gitlab Runners, i després l'equip decideix passar a Azure DevOps o Jenkins... i haurà de migrar un gran nombre de canalitzacions de construcció.
Resultats: empènyer o tirar?
Com sol ser el cas, cada enfocament té els seus pros i contres. Algunes tasques són més fàcils d'aconseguir amb una i més difícils amb una altra. Al principi feia desplegaments manualment, però després de trobar uns quants articles sobre Weave Flux, vaig decidir implementar processos GitOps per a tots els projectes. Per a les plantilles bàsiques això va ser fàcil, però després vaig començar a tenir dificultats amb els gràfics Helm. Aleshores, Weave Flux només oferia una versió rudimentària de l'operador Helm Chart, però fins i tot ara algunes tasques són més difícils a causa de la necessitat de crear manualment secrets i aplicar-los. Podríeu argumentar que l'enfocament d'extracció és molt més segur perquè les credencials del clúster no són accessibles fora del clúster, el que fa que sigui molt més segur que val la pena l'esforç addicional.
Després de pensar una mica, vaig arribar a la conclusió inesperada que això no és així. Si parlem de components que requereixen la màxima protecció, aquesta llista inclourà emmagatzematge secret, sistemes CI/CD i repositoris Git. La informació que contenen és molt vulnerable i necessita la màxima protecció. A més, si algú entra al vostre dipòsit de Git i hi pot enviar codi, pot desplegar el que vulgui (ja sigui pull o push) i infiltrar-se als sistemes del clúster. Així, els components més importants que s'han de protegir són el repositori Git i els sistemes CI/CD, no les credencials del clúster. Si teniu polítiques i controls de seguretat ben configurats per a aquest tipus de sistemes, i les credencials del clúster només s'extreuen a canalitzacions com a secrets, és possible que la seguretat afegida d'un enfocament d'extracció no sigui tan valuosa com es pensava originalment.
Per tant, si l'enfocament d'atracció requereix més mà d'obra i no ofereix un benefici de seguretat, no és lògic utilitzar només l'enfocament d'impuls? Però algú podria argumentar que en l'enfocament push estàs massa lligat al sistema de CD i, potser, és millor no fer-ho perquè sigui més fàcil fer migracions en el futur.
Al meu entendre (com sempre), hauríeu d'utilitzar el que sigui més adequat per a un cas concret o combinar-lo. Personalment, faig servir els dos enfocaments: Weave Flux per a desplegaments basats en pull que inclouen majoritàriament els nostres propis serveis, i un enfocament push amb Helm i complements, que facilita l'aplicació de gràfics Helm al clúster i us permet crear secrets sense problemes. Crec que mai no hi haurà una única solució adequada per a tots els casos, perquè sempre hi ha molts matisos i depenen de l'aplicació concreta. Dit això, recomano molt GitOps: fa la vida molt més fàcil i millora la seguretat.
Espero que la meva experiència en aquest tema us ajudi a decidir quin mètode és més adequat per al vostre tipus de desplegament, i m'alegraria escoltar la vostra opinió.
PS Nota del traductor
L'inconvenient del model d'extracció és que és difícil posar manifests representats a Git, però no hi ha cap inconvenient que la canalització de CD del model d'extracció visqui per separat del llançament i esdevingui essencialment una canalització de categories. Aplicació contínua. Per tant, caldrà encara més esforç per recopilar el seu estat de tots els desplegaments i d'alguna manera proporcionar accés als registres/estat, preferiblement amb referència al sistema de CD.
En aquest sentit, el model push ens permet oferir almenys algunes garanties de desplegament, perquè la vida útil del gasoducte es pot igualar a la vida útil del desplegament.
Vam provar ambdós models i vam arribar a les mateixes conclusions que l'autor de l'article:
- El model d'extracció és adequat perquè organitzem actualitzacions dels components del sistema en un gran nombre de clústers (vegeu. ).
- El model push basat en GitLab CI és adequat per desplegar aplicacions mitjançant gràfics Helm. Al mateix temps, el desplegament dels desplegaments dins de pipelines es supervisa mitjançant l'eina . Per cert, en el context d'aquest projecte nostre, vam escoltar el constant “GitOps” quan vam parlar dels problemes urgents dels enginyers de DevOps al nostre estand de KubeCon Europe'19.
PPS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Estàs utilitzant GitOps?
-
Sí, apropa't
-
Sí, empeny
-
Sí, estirar + empènyer
-
Sí, una altra cosa
-
No
Han votat 30 usuaris. 10 usuaris es van abstenir.
Font: www.habr.com