Introdução ao GitOps para OpenShift

Hoje falaremos sobre os princípios e modelos do GitOps, bem como como esses modelos são implementados na plataforma OpenShift. Um guia on-line para este tópico está disponível aqui .



Em resumo, o GitOps é um conjunto de métodos práticos para usar solicitações pull do Git para gerenciar configurações de infraestrutura e aplicativos. O repositório Git no GitOps é considerado como uma única fonte de informações sobre o estado do sistema, e quaisquer alterações nesse estado são totalmente monitoradas e auditadas.

A idéia de rastreamento de alterações no GitOps não é de forma alguma nova; essa abordagem há muito tempo é usada em quase todos os lugares ao trabalhar com o código-fonte do aplicativo. O GitOps simplesmente implementa funções semelhantes (revisar verificações, solicitações pull, tags, etc.) ao gerenciar configurações de infraestrutura e aplicativos e oferece vantagens semelhantes, como no caso do gerenciamento de código-fonte.

Para o GitOps, não há definição acadêmica ou conjunto de regras aprovado, apenas um conjunto de princípios nos quais essa prática se baseia:

• A descrição declarativa do sistema é armazenada no repositório Git (configurações, monitoramento etc.).
• Alterações de estado são feitas por meio de solicitações pull.
• O estado dos sistemas em execução é alinhado com os dados no repositório usando solicitações push do Git.

Princípios GitOps

• As definições do sistema são descritas como código fonte.

A configuração do sistema é considerada como código, para que possa ser armazenada e versionada automaticamente no repositório Git, que serve como a única fonte de verdade. Essa abordagem facilita a implementação e a reversão de alterações nos sistemas.

• O estado desejado e a configuração do sistema são definidos e versionados no Git

Armazenando e versionando no Git o estado desejado dos sistemas, temos a capacidade de reverter facilmente as alterações nos sistemas e aplicativos. Também podemos usar os mecanismos de segurança do Git para controlar a propriedade do código e verificar sua autenticidade.

• As alterações na configuração podem ser aplicadas automaticamente usando solicitações pull.

Usando solicitações pull do Git, podemos controlar facilmente como as alterações são aplicadas às configurações no repositório. Por exemplo, eles podem ser enviados para verificação a outros membros da equipe ou executados através de testes de IC, etc.

E, ao mesmo tempo, você não precisa dar autoridade de administrador à direita e à esquerda. Para confirmar as alterações na configuração, os usuários têm permissões suficientes no repositório Git onde essas configurações estão armazenadas.

• Corrigir configurações de desvio não controlado

Quando o estado desejado do sistema é armazenado no repositório Git, podemos encontrar apenas softwares que controlam que o estado atual do sistema corresponda ao estado desejado. Se não for assim, esse software deve - dependendo das configurações - corrigir a discrepância por conta própria ou nos notificar sobre o desvio da configuração.

Modelos GitOps para OpenShift

Reconciliador de recursos no cluster

De acordo com esse modelo, o cluster possui um controlador responsável por comparar os recursos do Kubernetes (arquivos YAML) no repositório Git com os recursos reais do cluster. Em caso de discrepâncias, o controlador envia notificações e, possivelmente, toma medidas para eliminar inconsistências. Este modelo GitOps é usado pelo Anthos Config Management e pelo Weaveworks Flux.

Reconciliador de recursos externos (push)

Esse modelo pode ser considerado uma variação do anterior, quando temos um ou mais controladores responsáveis ​​pela sincronização de recursos nos pares “repositório Git - cluster Kubernetes”. A diferença aqui é que cada cluster gerenciado não precisa ter seu próprio controlador separado. Os pares de clusters Git - k8s geralmente são definidos como CRDs de definição de recursos personalizados, que descrevem como o controlador deve executar a sincronização. Nesse modelo, os controladores comparam o repositório Git especificado no CRD com os recursos do cluster Kubernetes, que também são definidos no CRD, e executam as ações correspondentes com base nos resultados da comparação. Em particular, esse modelo GitOps é usado no ArgoCD.

GitOps na plataforma OpenShift

Administração de infraestrutura Kubernetes multicluster

Com a disseminação do Kubernetes e a crescente popularidade de estratégias de múltiplas nuvens e computação de ponta, também aumentou o número médio de clusters OpenShift por cliente.

Por exemplo, ao usar a computação periférica, os clusters de um único cliente podem ser implantados em centenas ou até milhares. Como resultado, ele é forçado a gerenciar vários clusters OpenShift independentes ou coordenados na nuvem pública e no local.

Ao mesmo tempo, muitos problemas precisam ser resolvidos, em particular:

• Para controlar se os clusters estão em condições idênticas (configurações, monitoramento, armazenamento etc.)
• Recrie (ou restaure) clusters de acordo com um estado conhecido.
• Crie novos clusters de acordo com um estado conhecido.
• Faça alterações em vários clusters do OpenShift.
• Reverter as alterações para vários clusters do OpenShift.
• Vincule configurações padronizadas a diferentes ambientes.

Configurações de aplicativo

Durante seu ciclo de vida, os aplicativos geralmente passam por uma cadeia de clusters (dev, stage, etc.) antes de entrarem em um cluster de produção. Além disso, devido aos requisitos de disponibilidade e escalabilidade, os clientes geralmente implantam aplicativos em vários clusters no local ou em várias regiões de uma plataforma de nuvem pública.

Nesse caso, é necessário resolver os seguintes problemas:

• Garanta a movimentação de aplicativos (binários, configurações, etc.) entre os clusters (dev, stage, etc.).
• Agrupe as alterações nos aplicativos (binários, configurações, etc.) em vários clusters do OpenShift.
• Reverter as alterações nos aplicativos para o nível do estado conhecido anterior.

Cenários de uso do OpenShift GitOps

1. Aplique alterações no repositório Git

O administrador do cluster pode armazenar as configurações de cluster do OpenShift no repositório Git e aplicá-las automaticamente para criar novos clusters sem nenhum esforço extra e trazê-los para um estado idêntico ao estado conhecido armazenado no repositório Git.

2. Sincronize com o Secret Manager

O administrador também achará útil sincronizar objetos secretos do OpenShift com o software apropriado, como o Vault, para gerenciá-los usando ferramentas especialmente criadas para isso.

3. Configurações de desvio de controle

O administrador será favorável apenas se o OpenShift GitOps detectar e avisar sobre discrepâncias entre configurações reais e as especificadas no repositório, para que você possa responder rapidamente à deriva.

4. Notificações de desvio de configuração

Será útil quando o administrador quiser descobrir rapidamente as configurações de desvio, a fim de tomar as medidas apropriadas por conta própria.

5. Sincronização manual de configurações durante a deriva

Permite que o administrador sincronize o cluster OpenShift com o repositório Git em caso de configurações de desvio, para retornar rapidamente o cluster a um estado conhecido anterior.

6. Sincronização automática de configurações de desvio

O administrador também pode configurar o cluster do OpenShift para sincronizar automaticamente com o repositório quando um desvio é detectado, para que a configuração do cluster sempre corresponda às configurações do Git.

7. Clusters múltiplos - um repositório

O administrador pode armazenar configurações de vários clusters OpenShift diferentes em um repositório Git e aplicá-las seletivamente, conforme necessário.

8. Hierarquia de configurações de cluster (herança)

O administrador pode definir a hierarquia das configurações de cluster no repositório (estágio, prod, portfólio de aplicativos etc. com herança). Em outras palavras, ele pode determinar como as configurações devem ser aplicadas - a um ou vários clusters.

Por exemplo, se o administrador definir a hierarquia “Clusters de Produção (prod) → Clusters do Sistema X → Clusters de Produção do Sistema X” no repositório Git, as seguintes configurações serão aplicadas aos clusters de produção do Sistema X:

• Configura comum a todos os clusters de produção.
• Configura para o sistema de cluster X.
• Configura para o cluster de produção do sistema X.

9. Padrões e substituições de configuração

O administrador pode substituir o conjunto de configurações herdadas e seus valores, por exemplo, para ajustar a configuração de clusters específicos aos quais eles serão aplicados.

10. Inclusão seletiva e exclusão para configurações, configuração de aplicativos

O administrador pode definir as condições para aplicar ou não determinadas configurações a clusters com determinadas características.

11. Suporte de padrão

Os desenvolvedores acharão útil escolher como os recursos do aplicativo serão determinados (Helm Chart, puro Kubernetes yaml etc.) para usar o formato mais adequado para cada aplicativo específico.

Ferramentas GitOps na plataforma OpenShift

Argocd

O ArgoCD implementa o modelo External Resource Reconcile e oferece uma interface de usuário centralizada para orquestrar relacionamentos entre clusters e repositórios Git de uma maneira um para muitos. As desvantagens deste programa incluem a incapacidade de gerenciar aplicativos enquanto o ArgoCD não está funcionando.

Site oficial

Flux

O Flux implementa o modelo On-Cluster Resource Reconcile e, como resultado, não há gerenciamento centralizado do repositório de definições, que é um ponto fraco. Por outro lado, precisamente devido à falta de centralização, a capacidade de gerenciar aplicativos é preservada mesmo quando um cluster falha.

Site oficial

Instale o ArgoCD no OpenShift

O ArgoCD oferece uma excelente interface de linha de comando e console da web; portanto, não consideraremos o Flux e outras alternativas aqui.

Para implantar o ArgoCD na plataforma OpenShift 4, siga estas etapas como administrador de cluster:

Implantando componentes do ArgoCD na plataforma OpenShift

# Create a new namespace for ArgoCD components oc create namespace argocd # Apply the ArgoCD Install Manifest oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml # Get the ArgoCD Server password ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}') 

Refinamento do servidor ArgoCD para ser visto pela rota OpenShift

 # Patch ArgoCD Server so no TLS is configured on the server (--insecure) PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}' oc -n argocd patch deployment argocd-server -p $PATCH # Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect 

Implantar a ferramenta ArgoCD Cli

 # Download the argocd binary, place it under /usr/local/bin and give it execution permissions curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd chmod +x /usr/local/bin/argocd 

Alterar senha do administrador ArgoCD Server

 # Get ArgoCD Server Route Hostname ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}') # Login with the current admin password argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD} # Update admin's password argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password 

Após concluir essas etapas, você poderá trabalhar com o ArgoCD Server por meio do console da web do ArgoCD WebUI ou da ferramenta de linha de comando ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - nunca é tarde demais

"O trem partiu" - é o que dizem sobre a situação em que a oportunidade de fazer algo é perdida. No caso do OpenShift, o desejo de começar imediatamente a usar essa nova plataforma legal geralmente cria exatamente essa situação com o gerenciamento e a manutenção de rotas, implantações e outros objetos do OpenShift. Mas a chance é sempre completamente perdida?

Continuando uma série de artigos sobre GitOps , hoje mostraremos como transformar um aplicativo criado manualmente e seus recursos em um determinado processo em que o kit de ferramentas GitOps controla tudo. Para fazer isso, primeiro implantamos o aplicativo httpd com nossas mãos. A captura de tela abaixo mostra como criamos um espaço para nome, implantação e serviço e, em seguida, expomos esse serviço para criar uma rota.

 oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml oc expose svc/httpd -n simple-app 

Portanto, temos um aplicativo criado manualmente. Agora, ele deve ser transferido sob o controle do GitOps sem perda de disponibilidade. Em suma, faz o seguinte:

• Crie um repositório Git para o código.
• Exportamos nossos objetos atuais e os carregamos no repositório Git.
• Selecione e implante o kit de ferramentas GitOps.
• Adicione nosso repositório a este kit de ferramentas.
• Definimos o aplicativo em nosso kit de ferramentas GitOps.
• Execute uma execução de avaliação do aplicativo usando o kit de ferramentas GitOps.
• Sincronizamos objetos usando o kit de ferramentas GitOps.
• Ativamos a poda e a sincronização automática de objetos.

Como mencionado no artigo anterior, o GitOps possui uma e apenas uma fonte de informações sobre todos os objetos no (s) cluster (s) Kubernetes - o repositório Git. Além disso, partimos da premissa de que sua organização já usa um repositório Git. Pode ser público ou privado, mas deve estar disponível para os clusters do Kubernetes. Pode ser o mesmo repositório que o código do aplicativo ou um repositório separado criado especificamente para implementação. É recomendável que você tenha permissões estritas no repositório, pois objetos secretos, rotas e outras coisas sensíveis à segurança serão armazenadas lá.

Em nosso exemplo, criaremos um novo repositório público no GitHub. Você pode nomear o que quiser, usamos o nome blogpost.

Se os arquivos YAML dos objetos não foram armazenados localmente ou no Git, você precisará usar os binários oc ou kubectl. Na captura de tela abaixo, solicitamos o YAML para nosso namespace, implantação, serviço e rota. Antes disso, clonamos o repositório recém-criado e passamos a ele com o comando cd.

 oc get namespace simple-app -o yaml --export > namespace.yaml oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml oc get service httpd -o yaml -n simple-app --export > service.yaml oc get route httpd -o yaml -n simple-app --export > route.yaml 

Agora corrija o arquivo deployment.yaml para remover um campo que o CD do Argo não pode sincronizar.

 sed -i '/\sgeneration: .*/d' deployment.yaml 

Além disso, você precisa alterar a rota. Primeiro, definiremos a variável multiline e, em seguida, substituir ingress: null pelo conteúdo dessa variável.

 export ROUTE=" ingress:\\ - conditions:\\ - status: 'True'\\ type: Admitted" sed -i "s/ ingress: null/$ROUTE/g" route.yaml 

Portanto, com os arquivos organizados, resta salvá-los no repositório Git. Depois disso, esse repositório se torna a única fonte de informação e qualquer alteração manual nos objetos deve ser estritamente proibida.

 git commit -am 'initial commit of objects' git push origin master 

Além disso, procedemos do fato de que o ArgoCD já está implantado para você (como fazer isso, consulte a postagem anterior). Portanto, adicionamos ao CD do Argo o repositório que criamos que contém o código do aplicativo do nosso exemplo. Apenas certifique-se de especificar o repositório exato que você criou anteriormente.

 argocd repo add https://github.com/cooktheryan/blogpost 

Agora crie o aplicativo. O aplicativo define os valores para que o kit de ferramentas GitOps entenda qual repositório e caminhos usar, qual OpenShift é necessário para gerenciar objetos, bem como qual ramificação específica do repositório é necessária e se os recursos devem ser sincronizados automaticamente.

 argocd app create --project default \ --name simple-app --repo https://github.com/cooktheryan/blogpost.git \ --path . --dest-server https://kubernetes.default.svc \ --dest-namespace simple-app --revision master --sync-policy none 

Depois que o aplicativo é especificado no CD do Argo, este kit de ferramentas começa a verificar se os objetos já implantados estão em conformidade com as definições no repositório. No nosso exemplo, a sincronização automática e a limpeza estão desabilitadas, portanto os elementos ainda não são alterados. Observe que, na interface do CD do Argo, nosso aplicativo terá o status "Fora de sincronia" (não sincronizado), pois não existe uma etiqueta de etiqueta que o ArgoCD afixe.
É por isso que, quando iniciarmos a sincronização um pouco mais tarde, a reimplementação de objetos não será realizada.

Agora execute um teste para garantir que não haja erros em nossos arquivos.

 argocd app sync simple-app --dry-run 

Se não houver erros, você poderá prosseguir para a sincronização.

 argocd app sync simple-app 

Depois de executar o comando argocd get em nosso aplicativo, devemos ver que o status do aplicativo mudou para Íntegro ou Sincronizado. Isso significa que todos os recursos no repositório Git agora correspondem aos recursos que já estão implantados.

 argocd app get simple-app Name: simple-app Project: default Server: https://kubernetes.default.svc Namespace: simple-app URL: https://argocd-server-route-argocd.apps.example.com/applications/simple-app Repo: https://github.com/cooktheryan/blogpost.git Target: master Path: . Sync Policy: <none> Sync Status: Synced to master (60e1678) Health Status: Healthy ... 

Mas agora você pode ativar a sincronização automática e a limpeza para garantir que nada seja criado manualmente e que sempre que o objeto for criado ou atualizado no repositório, a implantação será executada.

 argocd app set simple-app --sync-policy automated --auto-prune 

Portanto, transferimos com sucesso para o controle do GitOps um aplicativo que inicialmente não usava o GitOps.