🥇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 interativo sobre este tópico está disponível по ссылке.

Resumindo, GitOps é um conjunto de práticas para usar solicitações pull do Git para gerenciar configurações de infraestrutura e aplicativos. O repositório Git no GitOps é tratado como uma fonte única de informações sobre o estado do sistema, e quaisquer alterações nesse estado são totalmente rastreáveis e auditáveis.

A ideia de rastreamento de alterações no GitOps não é de forma alguma nova; essa abordagem tem sido usada há muito tempo quase universalmente ao trabalhar com o código-fonte do aplicativo. GitOps simplesmente implementa recursos semelhantes (revisões, solicitações pull, tags, etc.) no gerenciamento de infraestrutura e configuração de aplicativos e oferece benefícios semelhantes aos do gerenciamento de código-fonte.

Não existe uma definição acadêmica ou um conjunto de regras aprovado para GitOps, apenas um conjunto de princípios sobre os quais esta prática é construída:

A descrição declarativa do sistema é armazenada no repositório Git (configuração, monitoramento, etc.).
As 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 do GitOps

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

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

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

Ao armazenar e versionar o estado desejado dos sistemas no Git, podemos implementar e reverter facilmente alterações em 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 de configuração podem ser aplicadas automaticamente por meio de 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 entregues a outros membros da equipe para revisão ou executados em testes de CI, etc.

E, ao mesmo tempo, não há necessidade de distribuir poderes administrativos a torto e a direito. Para confirmar alterações de configuração, os usuários só precisam de permissões apropriadas no repositório Git onde essas configurações estão armazenadas.

Resolvendo o problema de desvio descontrolado de configurações

Depois que o estado desejado do sistema for armazenado em um repositório Git, tudo o que precisamos fazer é encontrar um software que garanta que o estado atual do sistema corresponda ao estado desejado. Se este não for o caso, então este software deverá - dependendo das configurações - eliminar a discrepância por conta própria ou notificar-nos sobre desvios de configuração.

Modelos GitOps para OpenShift

Reconciliador de recursos no cluster

Segundo esse modelo, o cluster possui um controlador responsável por comparar os recursos do Kubernetes (arquivos YAML) do repositório Git com os recursos reais do cluster. Se forem detectadas discrepâncias, o controlador envia notificações e possivelmente toma medidas para corrigir as discrepâncias. Este modelo GitOps é usado no Anthos Config Management e no Weaveworks Flux.

Reconciliador de Recursos Externos (Push)

Este modelo pode ser considerado uma variação do anterior, quando temos um ou mais controladores responsáveis por sincronizar recursos nos pares “repositório Git - cluster Kubernetes”. A diferença aqui é que cada cluster gerenciado não possui necessariamente seu próprio controlador separado. Os pares de cluster Git - k8s são frequentemente definidos como CRDs (definições de recursos personalizados), que podem descrever como o controlador deve realizar a sincronização. Dentro deste modelo, os controladores comparam o repositório Git especificado no CRD com os recursos do cluster Kubernetes, que também são especificados no CRD, e executam ações apropriadas com base nos resultados da comparação. Em particular, este modelo GitOps é usado no ArgoCD.

GitOps na plataforma OpenShift

Administração de infraestrutura Kubernetes multi-cluster

Com a disseminação do Kubernetes e a crescente popularidade das estratégias multinuvem e da computação de ponta, o número médio de clusters OpenShift por cliente também está aumentando.

Por exemplo, ao usar a computação de ponta, os clusters de um 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 têm de ser resolvidos, em particular:

Controle se os clusters estão em um estado idêntico (configuração, monitoramento, armazenamento, etc.)
Recrie (ou restaure) clusters com base em um estado conhecido.
Crie novos clusters com base em um estado conhecido.
Implemente alterações em vários clusters OpenShift.
Reverter alterações em vários clusters OpenShift.
Vincule configurações de modelo a diferentes ambientes.

Configurações de aplicativos

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

Neste caso, as seguintes tarefas devem ser resolvidas:

Garantir a movimentação de aplicações (binários, configurações, etc.) entre clusters (dev, stage, etc.).
Implemente alterações em aplicativos (binários, configurações, etc.) em vários clusters OpenShift.
Reverter alterações em aplicativos para um estado conhecido anterior.

Casos de uso do OpenShift GitOps

1. Aplicando alterações do repositório Git

Um administrador de cluster pode armazenar configurações de cluster OpenShift em um repositório Git e aplicá-las automaticamente para criar novos clusters sem esforço e colocá-los em 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 apropriado como o Vault, a fim de gerenciá-los usando ferramentas especialmente criadas para isso.

3. Controle de configurações de desvio

O administrador só será favorável se o próprio OpenShift GitOps identificar e avisar sobre discrepâncias entre as configurações reais e as especificadas no repositório, para que possam responder rapidamente ao desvio.

4. Notificações sobre desvios de configuração

Eles são úteis no caso em que o administrador deseja aprender rapidamente sobre casos de desvio de configuração para tomar rapidamente 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 desvio de configuração, para retornar rapidamente o cluster a um estado conhecido anterior.

6. Sincronização automática de configurações durante a deriva

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

7. Vários clusters – 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 uma hierarquia de configurações de cluster no repositório (estágio, produção, portfólio de aplicativos, etc. com herança). Em outras palavras, pode determinar se as configurações devem ser aplicadas a um ou mais clusters.

Por exemplo, se um administrador definir a hierarquia “Clusters de produção (prod) → Clusters do sistema X → Clusters de produção do sistema X” no repositório Git, uma combinação das seguintes configurações será aplicada aos clusters de produção do sistema X:

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

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

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

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

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

11. Suporte a modelos

Os desenvolvedores se beneficiarão da capacidade de escolher como os recursos do aplicativo serão definidos (Helm Chart, yaml puro do Kubernetes, etc.) para usar o formato mais apropriado para cada aplicativo específico.

Ferramentas GitOps na plataforma OpenShift

Argo CD

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

Site oficial

Fluxo

O Flux implementa um modelo On-Cluster Resource Reconcile e, como resultado, não há gerenciamento centralizado do repositório de definições, o que é um ponto fraco. Por outro lado, justamente pela falta de centralização, a capacidade de gerenciar aplicações permanece mesmo se um cluster falhar.

Site oficial

Instalando ArgoCD no OpenShift

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

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

Implantando componentes 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}')

Melhoria do Servidor ArgoCD para que possa ser visto pelo 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

Implantando 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

Alterando a senha de administrador do servidor ArgoCD

# 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

Depois de concluir essas etapas, você pode trabalhar com o ArgoCD Server por meio do console da 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” - é o que dizem sobre uma situação em que se perde a oportunidade de fazer algo. No caso do OpenShift, o desejo de começar imediatamente a usar essa nova plataforma bacana geralmente cria exatamente essa situação com o gerenciamento e a manutenção de rotas, implantações e outros objetos do OpenShift. Mas será que a oportunidade está sempre completamente perdida?

Continuando a série de artigos sobre GitOps, hoje mostraremos como transformar uma aplicação artesanal e seus recursos em um processo onde tudo é gerenciado por ferramentas GitOps. Para fazer isso, primeiro implantaremos manualmente o aplicativo httpd. A captura de tela abaixo mostra como criamos um namespace, 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

Então temos uma aplicação artesanal. Agora ele precisa ser transferido sob gerenciamento GitOps sem perda de disponibilidade. Resumindo, ele faz isso:

Crie um repositório Git para o código.
Exportamos nossos objetos atuais e os carregamos no repositório Git.
Selecionando e implantando ferramentas GitOps.
Adicionamos nosso repositório a este kit de ferramentas.
Definimos o aplicativo em nosso kit de ferramentas GitOps.
Realizamos um teste do aplicativo usando o kit de ferramentas GitOps.
Sincronizamos objetos usando o kit de ferramentas GitOps.
Habilite a remoção e a sincronização automática de objetos.

Como mencionado no anterior статье, no GitOps há uma e apenas uma fonte de informações sobre todos os objetos no(s) cluster(s) Kubernetes - o repositório Git. A seguir, partimos da premissa de que sua organização já utiliza um repositório Git. Pode ser público ou privado, mas deve ser acessível aos clusters Kubernetes. Este pode ser o mesmo repositório do código do aplicativo ou um repositório separado criado especificamente para implantações. É recomendado ter permissões estritas no repositório, pois segredos, 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 chamá-lo como quiser, usamos o nome blogpost.

Se os arquivos de objeto YAML não foram armazenados localmente ou no Git, você terá que usar os binários oc ou kubectl. Na captura de tela abaixo estamos solicitando YAML para nosso namespace, implantação, serviço e rota. Antes disso, clonamos o repositório recém-criado e fizemos o cd nele.

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 deploy.yaml para remover o campo que o Argo CD não pode sincronizar.

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

Além disso, a rota precisa ser alterada. Primeiro definiremos uma variável multilinha e depois 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

Então, classificamos os arquivos, só falta salvá-los no repositório Git. Depois disso, este repositório se torna a única fonte de informação, e quaisquer alterações manuais nos objetos devem ser estritamente proibidas.

git commit -am ‘initial commit of objects’
git push origin master

Além disso, partimos do fato de que você já implantou o ArgoCD (como fazer isso - veja o anterior postar). Portanto, adicionaremos ao CD Argo o repositório que criamos, contendo o código da aplicação 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 vamos criar o aplicativo. O aplicativo define valores para que o kit de ferramentas GitOps entenda qual repositório e caminhos usar, qual OpenShift é necessário para gerenciar objetos, 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 um aplicativo é especificado no CD Argo, o kit de ferramentas começa a verificar os objetos já implementados em relação às definições no repositório. Em nosso exemplo, a sincronização automática e a limpeza estão desabilitadas, portanto os elementos ainda não mudam. Observe que na interface do Argo CD nosso aplicativo terá o status “Fora de sincronia” porque não há rótulo fornecido pelo ArgoCD.
É por isso que quando iniciarmos a sincronização um pouco mais tarde, os objetos não serão reimplantados.

Agora vamos fazer um teste para ter certeza de que não há 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, veremos que o status do aplicativo mudou para Saudável ou Sincronizado. Isto significará que todos os recursos no repositório Git agora correspondem aos recursos que já foram 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
...

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

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

Portanto, colocamos com sucesso um aplicativo sob o controle do GitOps que inicialmente não usava o GitOps de forma alguma.

Fonte: habr.com

Introdução ao GitOps para OpenShift