Nota. transl.: Na comunidade de Kubernetes, unha tendencia chamada GitOps está gañando popularidade obvia, como vimos persoalmente. KubeCon Europe 2019. Este termo foi relativamente recente polo xefe de Weaveworks - Alexis Richardson - e significa o uso de ferramentas coñecidas para os desenvolvedores (principalmente Git, de aí o nome) para resolver problemas operativos. En particular, estamos a falar do funcionamento de Kubernetes almacenando as súas configuracións en Git e implementando automaticamente cambios no clúster. Matthias Jg fala de dous enfoques para este lanzamento neste artigo.
O ano pasado, (de feito, formalmente isto ocorreu en agosto de 2017 - aprox. traduc.) Hai un novo enfoque para implementar aplicacións en Kubernetes. Chámase GitOps e baséase na idea básica de que as versións de implantación son rastrexadas no entorno seguro dun repositorio de Git.
As principais vantaxes deste enfoque son as seguintes::
- Historial de versións e cambios de implementación. O estado de todo o clúster gárdase nun repositorio de Git e os despregamentos actualízanse só mediante commits. Ademais, pódense seguir todos os cambios mediante o historial de commit.
- Reversións usando comandos Git coñecidos. Simple
git resetpermítelle restablecer os cambios nos despregamentos; estados pasados sempre están dispoñibles. - Control de acceso listo. Normalmente, un sistema Git contén moitos datos sensibles, polo que a maioría das empresas prestan especial atención a protexelos. En consecuencia, esta protección tamén se aplica ás operacións con despregamentos.
- Políticas para implantacións. A maioría dos sistemas Git admiten de forma nativa políticas de rama por rama; por exemplo, só as solicitudes de extracción poden actualizar o mestre e os cambios deben ser revisados e aceptados por outro membro do equipo. Do mesmo xeito que co control de acceso, as mesmas políticas aplícanse ás actualizacións de implantación.
Como podes ver, hai moitos beneficios para o método GitOps. Durante o ano pasado, dous enfoques gañaron especial popularidade. Un está baseado en push, o outro está baseado en pull. Antes de miralos, vexamos primeiro como son as implementacións típicas de Kubernetes.
Métodos de implantación
Nos últimos anos, Kubernetes estableceu varios métodos e ferramentas para as implantacións:
- Baseado en modelos nativos de Kubernetes/Kustomize. Esta é a forma máis sinxela de implementar aplicacións en Kubernetes. O programador crea os ficheiros YAML básicos e aplícaos. Para desfacerse de reescribir constantemente os mesmos modelos, desenvolveuse Kustomize (transforma os modelos de Kubernetes en módulos). Nota. transl.: Kustomize integrouse en kubectl con .
- Gráficos de Helm. Os gráficos Helm permítenche crear conxuntos de modelos, contedores de inicio, sidecars, etc., que se usan para implementar aplicacións con opcións de personalización máis flexibles que nun enfoque baseado en modelos. Este método baséase en ficheiros YAML modelo. Helm éncheos con varios parámetros e despois envíaos a Tiller, un compoñente do clúster que os desprega no clúster e permite actualizacións e restauracións. O importante é que Helm simplemente insire os valores desexados nos modelos e despois aplícaos do mesmo xeito que se fai no enfoque tradicional. (le máis información sobre como funciona todo e como podes usalo no noso - aprox. transl.). Hai unha gran variedade de gráficos Helm preparados que abarcan unha gran variedade de tarefas.
- Ferramentas alternativas. Hai moitas ferramentas alternativas. O que todos teñen en común é que converten algúns ficheiros de modelos en ficheiros YAML lexibles por Kubernetes e despois utilízanos.
No noso traballo, usamos constantemente os gráficos Helm para ferramentas importantes (xa que xa teñen moitas cousas listas, o que facilita moito a vida) e ficheiros YAML de Kubernetes "puros" para implementar as nosas propias aplicacións.
Tirar e empurrar
Nunha das miñas publicacións recentes no blog, presentei a ferramenta , que lle permite enviar modelos ao repositorio de Git e actualizar a implantación despois de cada commit ou push do contedor. A miña experiencia demostra que esta ferramenta é unha das principais na promoción do enfoque pull, polo que moitas veces me referirei a ela. Se queres saber máis sobre como usalo, aquí .
NB! Todos os beneficios de usar GitOps seguen sendo os mesmos para ambos enfoques.
Enfoque baseado en tirar
O enfoque de extracción baséase no feito de que todos os cambios aplícanse desde dentro do clúster. Dentro do clúster hai un operador que verifica regularmente os repositorios de rexistro Git e Docker asociados. Se se produce algún cambio neles, o estado do clúster actualízase internamente. Este proceso considérase xeralmente moi seguro, xa que ningún cliente externo ten acceso aos dereitos de administrador do clúster.
Pros:
- Ningún cliente externo ten dereitos para facer cambios no clúster; todas as actualizacións desenvólvense desde dentro.
- Algunhas ferramentas tamén permiten sincronizar as actualizacións de gráficos Helm e vinculalas ao clúster.
- O Rexistro de Docker pódese escanear para buscar novas versións. Se hai unha nova imaxe dispoñible, o repositorio e a implementación de Git actualízanse á nova versión.
- As ferramentas de extracción pódense distribuír en diferentes espazos de nomes con diferentes repositorios e permisos de Git. Grazas a isto, pódese utilizar un modelo multitenant. Por exemplo, o equipo A pode usar o espazo de nomes A, o equipo B pode usar o espazo de nomes B e o equipo de infraestrutura pode usar o espazo global.
- Como regra xeral, as ferramentas son moi lixeiras.
- Combinado con ferramentas como operador , os segredos pódense almacenar cifrados nun repositorio de Git e recuperalos dentro do clúster.
- Non hai conexión coas canalizacións de CD xa que os despregamentos ocorren dentro do clúster.
Contra:
- Xestionar os segredos de implementación dos gráficos Helm é máis difícil que os habituais, xa que primeiro teñen que ser xerados en forma de, por exemplo, segredos selados, despois descifrados por un operador interno e só despois están dispoñibles para a ferramenta de extracción. A continuación, pode executar a versión en Helm cos valores dos segredos xa despregados. O xeito máis sinxelo é crear un segredo con todos os valores de Helm utilizados para a súa implantación, descifralo e comprometelo a Git.
- Cando te achegas a tiróns, estás atado ás ferramentas de tiro. Isto limita a capacidade de personalizar o proceso de implantación nun clúster. Por exemplo, Kustomize é complicado polo feito de que debe executarse antes de que os modelos finais estean comprometidos con Git. Non digo que non poidas usar ferramentas autónomas, pero son máis difíciles de integrar no teu proceso de implantación.
Enfoque baseado en push
No enfoque push, un sistema externo (principalmente canalizacións de CD) lanza despregamentos no clúster despois dunha confirmación no repositorio de Git ou se a canalización CI anterior ten éxito. Neste enfoque, o sistema ten acceso ao clúster.
Pros:
- A seguridade está determinada polo repositorio de Git e a canalización de construción.
- Implementar gráficos Helm é máis sinxelo e admite complementos Helm.
- Os segredos son máis fáciles de xestionar porque os segredos pódense usar en canalizacións e tamén se poden almacenar cifrados en Git (dependendo das preferencias do usuario).
- Non hai conexión cunha ferramenta específica, xa que se pode usar calquera tipo.
- As actualizacións da versión do contedor pódense iniciar mediante a canalización de compilación.
Contra:
- Os datos de acceso ao clúster están dentro do sistema de compilación.
- A actualización dos contedores de implantación aínda é máis fácil cun proceso de extracción.
- Gran dependencia do sistema de CD, xa que as canalizacións que necesitamos poden estar escritas orixinalmente para Gitlab Runners, e entón o equipo decide pasar a Azure DevOps ou Jenkins... e terá que migrar un gran número de canalizacións de compilación.
Resultados: Push or Pull?
Como adoita ser o caso, cada enfoque ten os seus pros e contras. Algunhas tarefas son máis fáciles de realizar cunha e máis difícil con outra. Ao principio estaba facendo despregamentos manualmente, pero despois de atopar algúns artigos sobre Weave Flux, decidín implementar procesos GitOps para todos os proxectos. Para os modelos básicos, isto foi sinxelo, pero entón comecei a ter problemas cos gráficos Helm. Nese momento, Weave Flux só ofrecía unha versión rudimentaria do Helm Chart Operator, pero aínda agora algunhas tarefas son máis difíciles debido á necesidade de crear manualmente segredos e aplicalos. Poderíase argumentar que o enfoque de extracción é moito máis seguro porque as credenciais do clúster non son accesibles fóra do clúster, polo que o fai moito máis seguro que paga a pena o esforzo extra.
Despois de pensar un pouco, cheguei á conclusión inesperada de que isto non é así. Se falamos de compoñentes que requiren a máxima protección, esta lista incluirá almacenamento secreto, sistemas CI/CD e repositorios Git. A información no seu interior é moi vulnerable e necesita a máxima protección. Ademais, se alguén entra no teu repositorio de Git e pode enviar código alí, pode implementar o que queira (xa sexa pull ou push) e infiltrarse nos sistemas do clúster. Así, os compoñentes máis importantes que deben protexerse son o repositorio Git e os sistemas CI/CD, non as credenciais do clúster. Se tes políticas e controis de seguranza ben configurados para este tipo de sistemas e as credenciais do clúster só se extraen en canalizacións como segredos, a seguridade engadida dun enfoque de extracción pode non ser tan valiosa como se pensaba orixinalmente.
Entón, se o enfoque pull é máis laborioso e non proporciona un beneficio de seguridade, non é lóxico usar só o enfoque push? Pero alguén podería argumentar que no enfoque push estás demasiado ligado ao sistema de CD e, quizais, é mellor non facelo para que sexa máis fácil realizar migracións no futuro.
Na miña opinión (coma sempre), deberías usar o máis axeitado para un caso particular ou combinar. Persoalmente, uso ambos enfoques: Weave Flux para despregamentos baseados en pull que inclúen na súa maioría os nosos propios servizos, e un enfoque push con Helm e complementos, que facilita a aplicación de gráficos Helm ao clúster e permite crear segredos sen problemas. Penso que nunca haberá unha única solución apta para todos os casos, porque sempre hai moitos matices e dependen da aplicación concreta. Dito isto, recomendo encarecidamente GitOps: facilita moito a vida e mellora a seguridade.
Espero que a miña experiencia neste tema che axude a decidir cal é o método máis axeitado para o teu tipo de implantación, e encantaríame escoitar a túa opinión.
PS Nota do tradutor
A desvantaxe do modelo de extracción é que é difícil poñer manifestos renderizados en Git, pero non hai ningunha desvantaxe de que a canalización de CD do modelo de extracción viva separada do lanzamento e se converta esencialmente nunha canalización de categorías. Aplicación continua. Polo tanto, será necesario aínda máis esforzo para recoller o seu estado de todas as implementacións e, dalgún xeito, proporcionar acceso aos rexistros/estado, preferentemente con referencia ao sistema de CD.
Neste sentido, o modelo push permítenos ofrecer polo menos algunhas garantías de lanzamento, xa que a vida útil do gasoduto pódese igualar á vida útil do lanzamento.
Probamos os dous modelos e chegamos ás mesmas conclusións que o autor do artigo:
- O modelo de extracción é axeitado para organizar actualizacións dos compoñentes do sistema nun gran número de clústeres (ver. ).
- O modelo push baseado en GitLab CI é moi axeitado para lanzar aplicacións usando gráficos Helm. Ao mesmo tempo, o lanzamento dos despregamentos dentro das canalizacións é monitor mediante a ferramenta . Por certo, no contexto deste noso proxecto, escoitamos o constante “GitOps” cando falamos dos problemas urxentes dos enxeñeiros de DevOps no noso stand en KubeCon Europe'19.
PPS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Estás a usar GitOps?
-
Si, aproximación tirada
-
Si, empurra
-
Si, tirar + empurrar
-
Si, outra cousa
-
Non
Votaron 30 usuarios. 10 usuarios abstivéronse.
Fonte: www.habr.com