Introdução ao GitOps para OpenShift.

Hoje, vamos falar sobre os princípios e modelos de GitOps, bem como a forma como esses modelos são implementados na plataforma OpenShift. Um guia interativo sobre este tema está disponível. no link.

Resumidamente, GitOps é um conjunto de métodos práticos que utilizam pull requests do Git para gerenciar configurações de infraestrutura e aplicativos. Um repositório Git dentro do GitOps é considerado uma única fonte de informação sobre o estado do sistema, onde quaisquer alterações nesse estado são completamente rastreáveis e auditáveis.

A ideia de rastreamento de mudanças em GitOps não é nova; essa abordagem já é amplamente utilizada no trabalho com código fonte de aplicativos. O GitOps simplesmente implementa funções semelhantes (revisões, pull requests, tags etc.) na gestão de configurações de infraestrutura e aplicativos, proporcionando benefícios similares aos da gestão de código fonte.

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

• A descrição declarativa do sistema é mantida no repositório Git (configurações, monitoramento etc.).
• Mudanças de estado são feitas através de pull requests.
• O estado dos sistemas em execução é alinhado aos dados no repositório através de push requests do Git.

Princípios do GitOps

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

A configuração dos sistemas é tratada como código, portanto, pode ser armazenada e versionada automaticamente em um repositório Git, que serve como a única fonte de verdade. Essa abordagem permite implementar (rollout) e reverter (rollback) alterações nos sistemas com facilidade.

• O estado desejado e a configuração dos sistemas são definidos e versionados no Git.

Armazenando e versionando no Git o estado desejado dos sistemas, obtemos a capacidade de implementar e reverter alterações em sistemas e aplicativos de forma simples. Além disso, podemos utilizar os mecanismos de segurança do Git para controlar a propriedade do código e validar sua autenticidade.

• As alterações nas configurações podem ser aplicadas automaticamente através de pull requests.

Usando pull requests do Git, podemos gerenciar facilmente como as mudanças são aplicadas às configurações no repositório. Por exemplo, elas podem ser enviadas para revisão por outros membros da equipe ou submetidas a testes de CI.

E, ao mesmo tempo, não é necessário conceder privilégios administrativos indiscriminadamente. Para realizar um commit das mudanças na configuração, os usuários precisam ter as permissões adequadas no repositório Git onde essas configurações são armazenadas.

• Resolvendo o problema da deriva descontrolada das configurações

Quando o estado desejado do sistema é armazenado em um repositório Git, só precisamos encontrar um software que controle se o estado atual do sistema corresponde ao seu estado desejado. Se não corresponder, esse software deve - dependendo das configurações - ou corrigir automaticamente a discrepância ou nos notificar sobre a deriva das configurações.

Modelos GitOps para OpenShift

Reconciliador de Recursos On-Cluster

De acordo com esse modelo, há um controlador no cluster que é responsável por comparar os recursos do Kubernetes (arquivos YAML) no repositório Git com os recursos reais do cluster. Ao detectar discrepâncias, o controlador envia notificações e, possivelmente, toma medidas para resolver as inconsistências. Este modelo GitOps é utilizado no Anthos Config Management e Weaveworks Flux.

Reconciliador de Recursos Externo (Push)

Este modelo pode ser visto como uma variação do anterior, onde temos um ou mais controladores responsáveis pela sincronização de recursos entre pares "repositório Git - cluster Kubernetes". A diferença é que em cada cluster gerenciado não é necessário ter seu próprio controlador separado. Os pares "Git - cluster k8s" são frequentemente definidos como descrições CRD (definição de recursos personalizados), nas quais é possível descrever como o controlador deve realizar a sincronização. Dentro desse modelo, os controladores comparam o repositório Git especificado no CRD com os recursos do cluster Kubernetes também especificados no CRD, e executam 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 expansão do Kubernetes e o aumento da popularidade de estratégias de múltiplas nuvens e computação de borda (edge computing), também cresce a média de clusters OpenShift por cliente.

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

Nesse contexto, é necessário resolver uma série de problemas, em particular:

• Controlar se os clusters estão em um estado idêntico (configurações, monitoramento, armazenamento etc.)
• Recriar (ou restaurar) clusters para um estado conhecido.
• Criar novos clusters a partir de um estado conhecido.
• Aplicar alterações em vários clusters OpenShift.
• Reverter alterações em vários clusters OpenShift.
• Vincular configurações parametrizadas a diferentes ambientes.

Configurações de aplicativo

Durante seu ciclo de vida, os aplicativos muitas vezes passam por uma cadeia de clusters (dev, staging, etc.) antes de chegar ao cluster de produção. Além disso, devido a requisitos de disponibilidade e escalabilidade, os clientes frequentemente implementam aplicativos simultaneamente em vários clusters on-premise ou em várias regiões de plataformas de nuvem pública.

Nesse cenário, é necessário resolver as seguintes tarefas:

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

Casos de uso do OpenShift GitOps

1. Aplicação de alterações a partir do repositório Git

O administrador do cluster pode armazenar as configurações do cluster OpenShift em um repositório Git e aplicá-las automaticamente, facilitando a criação de novos clusters e levando-os a um estado idêntico ao estado conhecido armazenado no repositório Git.

2. Sincronização com Secret Manager

O administrador também se beneficiará da capacidade de sincronizar objetos secretos do OpenShift com software correspondente, como o Vault, para gerenciá-los com ferramentas criadas especificamente para esse fim.

3. Controle de divergências nas configurações

O administrador ficará satisfeito se o OpenShift GitOps detectar e alertar automaticamente sobre divergências entre as configurações reais e aquelas definidas no repositório, permitindo uma resposta rápida às divergências.

4. Notificações sobre drift de configurações

Serão úteis quando o administrador quiser ser informado rapidamente sobre casos de drift de configurações, para que possa agir de forma apropriada.

5. Sincronização manual de configurações ao detectar drift

Permite ao administrador sincronizar um cluster OpenShift com um repositório Git em caso de drift de configurações, para restaurar rapidamente o cluster a um estado conhecido anterior.

6. Autossincronização de configurações ao detectar drift

O administrador também pode configurar o cluster OpenShift para sincronização automática com o repositório ao detectar drift, garantindo que as configurações do cluster estejam sempre alinhadas com os arquivos de configuração do Git.

7. Múltiplos clusters – um repositório

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

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

O administrador pode definir uma hierarquia de configurações de cluster no repositório (stage, 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 mais clusters.

Por exemplo, se o administrador define no repositório Git a hierarquia "Clusters de produção (prod) → Clusters do sistema X → Clusters de produção do sistema X", então a esses clusters de produção do sistema X se aplica a combinação das seguintes configurações:

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

9. Modelos e sobrescrição de configurações

O administrador pode sobrescrever um conjunto de configurações herdadas e seus valores, por exemplo, para ajustar mais finamente as configurações para clusters específicos a que serão aplicadas.

10. Inclusões e exclusões seletivas para configurações de aplicativos

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

11. Suporte a modelos

Será útil para os desenvolvedores poder escolher como os recursos do aplicativo serão definidos (Helm Chart, yaml puro do Kubernetes, etc.), para usar o formato mais adequado para cada aplicação específica.

Ferramentas GitOps na plataforma OpenShift

ArgoCD

O ArgoCD implementa o modelo de Reconciliação de Recursos Externos e oferece uma interface unificada para orquestrar as relações entre clusters e repositórios Git em uma configuração de "um para muitos". Entre as desvantagens desse programa, destaca-se a impossibilidade de gerenciar aplicativos quando o ArgoCD não está funcionando.

Site oficial

Flux

O Flux implementa o modelo de Reconciliação de Recursos em Cluster e, como consequência, não há uma gestão centralizada do repositório de definições, que é um ponto fraco. Por outro lado, devido à falta de centralização, a capacidade de gerenciar aplicativos é mantida mesmo quando um cluster falha.

Site oficial

Instalação do ArgoCD no OpenShift

O ArgoCD oferece uma excelente interface de linha de comando e um console web, portanto, não vamos considerar o Flux e outras alternativas aqui.

Para implantar o ArgoCD na plataforma OpenShift 4, siga os seguintes passos como administrador do cluster:

Implantação dos 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}')

Ajuste do ArgoCD Server para ser acessível via OpenShift Route

# 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

Implantação da Ferramenta de Linha de Comando do ArgoCD

# 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

Mudança da senha de administrador do 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 seguir esses passos, é possível trabalhar com o ArgoCD Server através do console web 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’ – assim se fala sobre uma situação em que a oportunidade de agir foi perdida. No caso do OpenShift, o desejo imediato de começar a usar essa nova plataforma incrível muitas vezes cria essa situação com a gestão e manutenção de rotas, deployments e outros objetos do OpenShift. Mas a chance foi realmente perdida para sempre?

Continuando a série de artigos sobre GitOps, hoje vamos mostrar como transformar um aplicativo criado manualmente e seus recursos em um processo onde tudo é gerido pela ferramenta GitOps. Para isso, inicialmente, vamos implantar manualmente o aplicativo httpd. Na tela abaixo, mostramos como criamos um namespace, um deployment e um serviço, e então fazemos o expose desse 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

Então, temos um aplicativo criado manualmente. Agora, precisamos transferi-lo para a gestão do GitOps sem perder acessibilidade. Em resumo, o processo é o seguinte:

• Criamos um repositório Git para o código.
• Exportamos nossos objetos atuais e os carregamos no repositório Git.
• Selecionamos e implantamos a ferramenta GitOps.
• Adicionamos nosso repositório a essa ferramenta.
• Definimos o aplicativo em nossa ferramenta GitOps.
• Executamos uma execução de teste do aplicativo usando a ferramenta GitOps.
• Sincronizamos os objetos usando a ferramenta GitOps.
• Ativamos a limpeza (pruning) e a autosincronização dos objetos.

Como já foi mencionado anteriormente, artigono GitOps há uma única e única fonte de informações sobre todos os objetos no(s) cluster(es) Kubernetes - o repositório Git. A partir de agora, partimos do pressuposto de que em sua organização já existe um repositório Git. Ele pode ser público ou privado, mas deve ser acessível para os clusters Kubernetes. Pode ser o mesmo repositório que contém o código dos aplicativos ou um repositório separado criado especificamente para implantações. É recomendável ter permissões rigorosas no repositório, pois ele conterá objetos secretos, rotas e outras informações sensíveis à segurança.

No nosso exemplo, criaremos um novo repositório público no GitHub. Podemos nomeá-lo como quisermos, usaremos o nome blogpost.

Se os arquivos YAML dos objetos não foram armazenados localmente ou no Git, precisaremos usar os binários oc ou kubectl. Na tela abaixo, estamos solicitando o YAML para nosso namespace, implantação, serviço e rota. Antes disso, clonamos o repositório recém-criado e entramos nele 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 vamos editar o arquivo deployment.yaml para remover o campo que o Argo CD não consegue sincronizar.

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

Além disso, precisamos alterar a rota. Primeiro, definiremos uma variável de várias linhas e, em seguida, substituiremos 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

Assim, com os arquivos prontos, precisamos salvá-los no repositório Git. Depois disso, esse repositório se torna a única fonte de informações e quaisquer alterações manuais nos objetos devem ser rigorosamente proibidas.

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

A partir de agora, presumimos que o ArgoCD já está implantado (como fazê-lo – veja acima) post). Portanto, vamos adicionar ao Argo CD o repositório que criamos, que contém o código do aplicativo do nosso exemplo. Apenas certifique-se de indicar o repositório que você criou anteriormente.

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

Agora vamos criar o aplicativo. O aplicativo define valores para que a ferramenta GitOps entenda qual repositório e quais caminhos utilizar, qual OpenShift é necessário para gerenciar os objetos, assim como qual ramificação específica do repositório é necessária e se a sincronização automática dos recursos deve ser realizada.

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 é definido no Argo CD, essa ferramenta começa a verificar os objetos já implantados quanto à conformidade com as definições no repositório. No nosso exemplo, a autosincronização e a limpeza estão desativadas, portanto os elementos ainda não mudam. Observe que, na interface do Argo CD, nosso aplicativo terá o status «Out of Sync» (Não Sincronizado), já que não existe etiqueta label marcada pelo ArgoCD.
É exatamente por isso que, quando iniciarmos a sincronização mais tarde, a reimplantação dos objetos não será realizada.

Agora vamos realizar uma execução de teste para garantir que não há erros em nossos arquivos.

argocd app sync simple-app --dry-run

Se não houver erros, podemos prosseguir para a sincronização.

argocd app sync simple-app

Após executar o comando argocd get em nosso aplicativo, devemos ver que o status do aplicativo mudou para Healthy (Saudável) ou Synced (Sincronizado). Isso significará 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:        
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

Agora podemos ativar a autosincronização e a limpeza, para garantir que nada seja criado manualmente e que cada vez que um objeto for criado ou atualizado no repositório, uma implantação será realizada.

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

Assim, conseguimos transferir para a gestão do GitOps uma aplicação que inicialmente não utilizava o GitOps de forma alguma.

Fonte: habr.com