No mundo acelerado do DevOps, manter o delicado equilíbrio entre velocidade e estabilidade é crucial. O GitOps, uma abordagem moderna para implantação contínua, surgiu como um divisor de águas ao aproveitar o poder do controle de versão e da automação para gerenciar implantações de infraestrutura e aplicações. Na vanguarda desse movimento está o ArgoCD, uma ferramenta GitOps robusta e amigável que simplifica a implantação e o gerenciamento de aplicações Kubernetes.

Mas o que acontece quando sua arquitetura de microsserviços envolve múltiplos clusters e ambientes, cada um com seu próprio conjunto de aplicações e configurações? É aqui que o conceito de “App of Apps” do ArgoCD entra em cena. Usando essa abordagem, as equipes de DevOps podem alcançar um nível mais alto de controle, escalabilidade e eficiência no gerenciamento de implantações complexas de Kubernetes.

Neste artigo, vamos mergulhar fundo no mundo do GitOps e explorar como implementar a estratégia App of Apps do ArgoCD para alcançar um gerenciamento de aplicações abrangente e simplificado.

Stack Used Stack Used


Requisitos

  • Um Cluster Kubernetes.
  • Pelo menos um repositório, onde armazenaremos nossas configurações.
  • Um domínio e certificados SSL, se você quiser expor seu ArgoCD através do seu domínio.

Arquitetura

Para implementar uma abordagem de app-of-apps, precisaremos de pelo menos quatro apps que chamaremos de “Aplicativos Centrais”. Que são:

  1. argocd: aplicação para gerenciar o próprio servidor argocd. Esta aplicação apontará para o chart do ArgoCD que implantamos.
  2. argocd-projects: aplicação para gerenciar os AppProjects. Esta aplicação identificará recursivamente todos os AppProjects que vamos definir para o nosso ArgoCD, para ter uma melhor organização dos nossos projetos e impor algumas regras.
  3. argocd-applications: aplicação para gerenciar os ApplicationSets. Esta aplicação identificará recursivamente todos os ApplicationSets que vamos definir para as aplicações que queremos implantar em nosso cluster.

Idealmente, você deve ter um repositório apenas para gerenciar o ArgoCD, e muitos outros para os charts e valores das suas aplicações. Architecture

O diagrama acima é um exemplo, você pode imaginá-lo com quantos apps quiser, e também criar apps personalizados para gerenciar seus próprios clusters. Por exemplo, você pode criar um repositório com algumas definições de namespaces ou quotas, e usá-las para gerenciar seu cluster através de um app chamado “namespace-management”, por exemplo. Resumindo… não há limite, mas há um aviso: nunca exclua um app central.

Padrão

Sugiro sempre organizar o repositório de seus charts na seguinte estrutura:

application-repo/
├─ chart/ 
values-dev.yaml
values-prod.yaml
values-common.yaml

or for single deployment
application-repo/
├─ chart/ 
values-override.yaml

Mas claro, existem alguns casos que não será possível seguir a estrutura acima, por isso, use sua imaginação.

E, na pasta chart, coloque o chart baixado. Examplo: And then, in the chart folder put the downloaded chart. Example:

helm pull application_you_want
tar -xzf application_you_want.tar
mv application_you_want chart
touch values-YOUR_VALUES_NAME.yaml

Por que baixar os charts?

Na minha opinião, é mais seguro quando você deseja atualizar o chart. Quando você baixa um novo chart, pode facilmente validar, usando o Merge/Pull Request Diff, se há alguma alteração no arquivo values.yaml padrão ou qualquer outra mudança significativa no manifesto do Kubernetes que possa quebrar sua implantação atual do helm.

Implantação

Agora, vou explicar meu exemplo pessoal. No meu repositório, encontraremos mais detalhes sobre a configuração geral que você pode fazer para o seu caso de uso, como configuração do Google SSO, instalação local e mais.

Minha Stack

  • GKE Cluster — Auto Pilot
  • Cloudflare

Instalação

  1. Clone meu projeto de exemplo: https://github.com/andersondario/argocd-gitops
  2. Obtenha as credenciais do seu cluster.
  3. Crie seus segredos TLS. No meu caso, criei um Certificado de Origem do Cloudflare.

Cluster Certificate

  1. Baixe os certificados e coloque-os na pasta argocd-install/keys.

  2. Vamos começar a instalação.

# Go to argocd-install folder
cd argocd-install

# Create Namespaces
kubectl create ns argocd
kubectl create namespace ingress-nginx

## Deploy Secrets
kubectl -n argocd create secret tls argocd-server-tls --cert keys/tls.crt --key keys/tls.key

# Install the ingress-controller using helm first with ssl-passthrough enabled
helm install -n ingress-nginx argocd-ingress-nginx ./ingress-nginx --set "controller.extraArgs.enable-ssl-passthrough=" --set controller.admissionWebhooks.enabled=false

# Install Argo
helm install -n argocd argocd ./argo-cd -f values-<YOUR_FILE>.yaml
  1. Obtenha o ArgoCD Ingress IP

Argo Ingress IP

  1. Adicione uma entrada DNS para esse IP. Se você estiver usando o Cloudflare como eu, lembre-se de habilitar o modo Proxy e também habilitar o SSL Full Strict.

DNS Config 1

DNS Config 2

  1. Obtenha a credencial de admin e faça login:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Login on Argo

  1. Adicione o seu root repository. No meu caso, é o que compartilhei previamente acima com vocês.

Add the Root Repo 1

Add the Root Repo 2

  1. Aplique o core projects e apps configs.
kubectl apply -f argocd-core-projects.yaml
kubectl apply -f argocd-core-applications.yaml

… então, você verá os seguintes aplicativos, os aplicativos centrais descritos anteriormente, na sua tela.

Apps Running

  1. Então você pode definir seu ApplicationSet e fazer o commit dentro da pasta argocd-applications, e o Argo sincronizará suas mudanças. Aqui está um exemplo, onde implantei um aplicativo Aquasec/trivy. O mesmo se aplica ao seu AppProject, adicionando alguns arquivos dentro da pasta argocd-appprojects.

AppProject ApplicationSets Trivy

Dicas e Truques

Para GKE, não siga a documentação oficial para expor seu servidor

Se você estiver usando GKE, nunca exponha seu servidor usando a configuração Ingress padrão. Por quê? Se você atualizar seu cluster ArgoCD com uma nova versão do ArgoCD Chart, seus novos pods ficarão presos neste problema: https://github.com/kubernetes/ingress-gce/issues/1718. Portanto, sugiro implantar um controlador de ingress diferente, como o Nginx, e evitar seguir a documentação oficial do ArgoCD que nos diz para usar FrontendConfig + BackendConfig + Ingress para GKE.

Se você quiser migrar aplicativos de um cluster Argo antigo para um novo

É fácil. Você precisará:

  1. Adicionar em seus ApplicationSets a configuração: spec.syncPolicy.preserveResourcesOnDeletion=true,
  2. Aplicar.
  3. Verificar se na última configuração aplicada esta configuração está presente, e então
  4. Excluir o ApplicationSet do cluster atual e recriá-lo no novo cluster sem as linhas adicionadas no passo 1.

Seguindo isso, você não perderá os aplicativos durante o processo.

Se você quiser “importar” um aplicativo existente implantado manualmente

Se você quiser que o Argo comece a rastrear um aplicativo implantado manualmente com helm em seu cluster, basta criar um ApplicationSet que gerará um Application com o mesmo nome usado na implantação do helm (nome da release) e com os mesmos valores. Então o Argo apenas identificará os recursos já implantados em vez de implantar novos.

Testes de ApplicationSets

Você pode testar seu ApplicationSet aplicando manualmente; você poderá ver o aplicativo gerado dentro do ArgoCD, e somente quando terminar seus testes você pode fazer o merge do código dentro da pasta argocd-applications, então você poderá ver o ApplicationSet lá também.

Backup

Sempre faça backup da lista de seus repositórios após adicionar um novo, o mesmo para cluster. Isso ajudará a configurar rapidamente em caso de DR. Você pode executar os seguintes comandos e salvar os arquivos em um local seguro.

kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=repository -o yaml > repositories.yaml
kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=cluster -o yaml > repositories.yaml

Produção e Laboratório

Você pode ter dois projetos, um de produção e um de laboratório, apenas duplicando o repositório e alterando algumas configurações. Caso queira testar mudanças críticas, como atualizar o ArgoCD, você pode implantar seu projeto de laboratório e testá-lo antes de aplicar as mudanças no projeto de produção.


Fonte


Referências

Suporte

Se você achar meus posts úteis e quiser me apoiar, por favor, me compre um café: Anderson Dario is personal blog and tech blog

Isso é tudo. Obrigado.