No mundo acelerado do desenvolvimento de software, a automação se torna não apenas uma vantagem, mas uma necessidade. Uma ferramenta que tem ganhado destaque nesse cenário é o Argo CD. Se você está procurando uma maneira eficiente de implantar suas aplicações de forma consistente e confiável, o Argo CD pode ser a solução que você está buscando.
Neste artigo, vamos explorar o que é o Argo CD, como funciona e como você pode começar a utilizá-lo. Prepare-se para mergulhar no mundo da implantação contínua e automatizada de software!
O que é ArgoCD?
ArgoCD é uma ferramenta declarativa para GitOps, entrega continua para ambiente Kubernetes.
As aplicações devem ser declarativas e controladas por versionamento, permitindo que, junto ao ArgoCD, possamos fazer deployments automatizados auditáveis e fácil de recuperar um estado anterior através de roolbacks.
ArgoCD usa repositórios git como um ponto de verdade para definir o estado desejado de uma aplicação dentro do cluster Kubernetes. Ele usa branchs, tags ou pins para determinar se houve uma alteração no estado desejado da aplicação.
Podemos usar os seguintes manifestos Kubernetes:
-
- Kustomize
-
- Helm Chart
- Diretório de manifestos YAML/JSON
Para seguir com o guia faça o clone do seguinte repositório para ter acesso aos templates usados.
<ADICIONAR REPO URL>
Instalando o ArgoCD
Para seguir os seguintes passos será necessário instalar as seguintes ferramentas:
Para instalar o ArgoCD no cluster Kubernetes use o seguinte comando para adicionar o repositório do Argo na sua máquina:
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
Caso deseje alterar alguma configuração de como o ArgoCD será instalado, como, por exemplo, resources, nodeSelector, etc. Use o seguinte comando para puxar o arquivo de values, que contém as configurações padrão da instalação, o comando irá criar um arquivo chamado “argocd-values.yaml” no diretório em que for executado o comando:
helm show values argo/argo-cd > argocd-values.yaml
Use o seguinte comando para instalar o helm chart do ArgoCD. O comando irá instalar o chart com o nome de “release argocd” no namespace argocd. Caso o namespace não exista, ele será criado automaticamente devido a flag “–create-namespace” e utilizando as configurações do arquivo “argocd-values.yaml”:
helm install argocd argo/argo-cd -f argocd-values.yaml -n argocd --create-namespace
Para atualizar o ArgoCD, faça qualquer alteração no arquivo de values e execute o seguinte comando:
helm upgrade argocd argo/argo-cd –f argocd-values.yaml -n argocd
Para listar os recursos instalados e verificar o status dos pods, execute o seguinte comando, ele irá listar todos os pods dentro do namespace argocd:
kubectl get pods –n argocd
Acessando a Interface
Para acessar a interface do ArgoCD podemos usar as seguintes opções:
Ingress
No arquivo de values do ArgoCD, altere os campos de ingress como a imagem abaixo, procure pela sessão “server” e dentro dele procure por “ingress”. Altere os seguintes campos:
-
- enabled -> true (para criar o ingress)
-
- controller -> generic (tambem pode ser definido aws ou gke, dependendo da plataforma de cloud usada)
- ingressClassName -> “nginx” (neste exemplo estou assumindo que os ingress no cluster estão sendo controlados pelo nginx ingress)
- hostname: “argocd.mydomain.com” (domínio em que deseja acessar a interface grafica do ArgoCD)
Uma segunda alternativa para o ingress, caso você não deseje usar o arquivo de values, será criar um manifesto Kubernetes e criar um ingress apontando para o serviço do ArgoCD, como o exemplo abaixo. O namespace deve ser idêntico ao qual o ArgoCD está instalado, caso não for ser usado as configurações de TLS, altere a porta de “443” para “80”:
Port-forward
Para acessar a interface do ArgoCD via port-forward, verifique se você está conectado ao cluster. Para verificar se você está no contexto do cluster use o seguinte comando:
kubectl config get-contexts
Caso você não esteja no contexto do cluster use o seguinte comando:
kubectl config set-context <NOME DO CLUSTER>
Agora, será preciso identificar o “service” e sua porta para abrirmos uma conexão. Para visualizar os “services” dos pods do ArgoCD utilize o seguinte comando:
kubectl get services –n argocd
Por padrão, o service terá o nome “argocd-server”, e suas portas será “80” e “443”, caso você altere no arquivo de values a variável “nameOverride”, ele será modificado de acordo com o nome que você definiu.
Agora, com as informações necessárias, use o seguinte comando para criar o port-foward para o serviço do ArgoCD. O seguinte comando irá fazer um tunel ssh do serviço do cluster para a sua máquina, ele irá expor a porta 80 do serviço argocd-server na porta 8080 da sua máquina. Caso a porta 8080 da sua máquina esteja sendo utilizada, altere a porta para uma disponível:
kubectl port-forward service/argocd-server 8080:80 -n argocd
Obs.: esse comando irá travar o seu terminal enquanto você estiver usando a interface do ArgoCD, abra outro terminal para seguir com os próximos passos.
Em um navegador de sua preferência acesse o seguinte endereço “localhost:8080” (Obs.: caso você tenha alterado a porta exposta na sua máquina altera na URL).
Painel
Neste momento, se você tiver acessado via port-forward ou ingress, você estará vendo a página inicial do ArgoCD.
Por padrão o ArgoCD, crie um usuário “admin” e uma senha aleatória. Para recuperar a senha, use o seguinte comando, ele irá pegar o campo password na secret “argocd-initial-admin-secret” e decriptar:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
Use as credenciais para acessar o painel. Obs.: Caso apareça o símbolo de porcentagem (%) ao final da senha ignore-o, ele não faz parte da senha.
Configurando acesso a repositórios
Após acessar o painel com as credenciais, vamos acessar no painel esquerdo Settings -> Repositories.
No canto superior esquerdo, clique em CONNECT REPO.
Aqui teremos algumas opções para se conectar a um repositório.
SSH/HTTPS
Caso você escolha se conectar via SSH, configure os seguintes campos:
-
- Name – Nome do repositório ao qual está configurando a conexão
-
- Project – escolha a opção “default” (Depois iremos abordar o assunto sobre projetos)
- Repository URL – Adicione a URL do repositório, exemplo https://github.com/ORG_NAME/REPO_NAME
- SSH Private key data – Valor da sua PAT (Personal Access Token). Caso seu repositório seja público, não será necessário configurar esse campo.
Caso a conexão falhe, clique em cima da conexão criada.
No canto superior direito, clique em EDIT e configure os seguintes campos. Isto irá mudar para o tipo de conexão HTTPS:
-
- Username – nome do usuário git
-
- Password – chave PAT
Caso a conexão tenha sido estabelecida com sucesso, você verá no campo CONNECTION STATUS marcado como Successful.
Github App
Para configurar a conexão com o Github App, configure os seguintes campos:
-
- Type – tipo da sua conta Github
-
- Project – “default”
- Repository URL – Adicione a URL do repositório, exemplo https://github.com/ORG_NAME/REPO_NAME
- Github App ID – Ao criar um Github App será gerado um ID único para ele.
- Github App Installation ID – No seu Github App acesse public page -> Install -> Selecione opção para repositórios -> Install -> Na URL terá o ID installation. Exemplo https://github.com/settings/installations/492343278
- Github App Private Key – Conteúdo da chave privada gerada no seu Github App
Declarativo
Para configurar de forma declarativa, podemos criar um arquivo do tipo YAML e definir as configurações de conexão ao repositório usando os mesmos valores configurados anteriormente.
O exemplo abaixo é uma configuração declarativa de uma secret Kubernetes do tipo HTTPS. Repare que temos dois valores para configurar em relação ao método anterior: “namespace” que deve ser exatamente o namespace onde a aplicação ArgoCD está instalada, e a label “argocd.argoproj.io/secret-type”. Essa label é usada para o ArgoCD identificar que essa secret pertence a ele e determinar o tipo dela:
Para aplicar essa configuração, use o seguinte comando. Ele irá criar a secret dentro do cluster seguindo as configurações definidas do manifesto:
kubectl –f <NOME_DO_ARQUIVO>.yaml
O método anterior defini uma secret específica para um único repositório, porém, se precisarmos usar mais de um repositório, e usar as mesmas credenciais, podemos usar a seguinte configuração:
No exemplo está sendo gerado três secrets, uma definindo as credenciais do Github App e duas secrets apenas informando a URL dos repositórios.
Na primeira secret, o tipo dela é “repo-creds”, esse tipo possibilita o ArgoCD de usar as credenciais definidas nele para todos os repositórios na organização que informarmos.
Nas duas seguintes secrets, precisamos apenas definir o tipo “repository” e informar a URL do repositório, o próprio ArgoCD irá entender que os repositórios estão na mesma organização em que as credenciais foram definidas e irá usá-las para estabelecer a conexão.
Configurando uma Application
Após criar a conexão com o repositório, podemos criar uma Application que irá gerenciar nosso projeto.
Acesse Applications -> NEW APP
Irá abrir uma nova configuração onde iremos definir algumas informações para a Application.
Em GENERAL configure os seguintes campos:
-
- Applications Name: nome de identificação da aplicação a ser criada no cluster
-
- Project Name: “default”
- Sync Policy: “Manual” (Manual será necessário aplicar as modificações manualmente. Use esta opção inicialmente)
- Sync Options -> Auto-create Namespace: caso o nomespace em que a aplicação será criada não exista, ele irá criar automaticamente
Em SOURCE configure os seguintes campos:
-
- Repository URL: clique na caixa ele irá exibir todos os repositórios que você configurou
-
- Revision: nome da branch que deseja utilizar para que o ArgoCD leia os manifestos
- Path: caminho dentro do repositório e da branch especificada para os manifestos (OBS.: Não é necessário passar o nome do arquivo apenas o diretório)
Em DESTINETION configure os seguintes campos:
-
- Cluster URL: em qual cluster será instalado a aplicação
-
- Namespace: nome do namespace em que a aplicação será criada (Se não informado será criado no namespace default)
Após configurar todos os campos clique em CREATE no topo das configurações.
Application Declarativo
Assim como nos passos anteriores, neste exemplo, estamos criando uma Application com os mesmos parâmetros, porém, esta forma facilita a entender como está configurado uma Application e mantemos o seu estado salvo assim como em secrets.
O tipo (kind) desse recurso é criado através de um CRD (Custom Resource Definition), para listar as Application já criadas use o seguinte comando:
Kubectl get applications –n argocd
Ele irá retornar uma lista com o nome das Applications e seus status (SYNC e HEALTH).
Application
Você verá a Application criada, porém com status “Missing” e “OutOfSync”, isso acontecerá na primeira vez em que a Application for criada.
-
- Missing: quer dizer que os recursos que estão no manifesto não existem dentro do cluster
-
- OutOfSync: diz que o estado desejado (as configurações dos manifestos) está diferente do que está no cluster, já que eles não existem.
Note que no painel esquerdo mostra os status Sync e Health. Você pode filtrar por Applications que estejam Degraded (quando algum recurso não foi criado com sucesso), Unknown (quando não foi possível encontrar os manifestos no repositório), etc.
Clique na Application criada para acessar e visualizar o que será criado no cluster.
Assim como na página anterior, aqui temos também a barra lateral esquerda informado os status, porém esses status são relacionados aos recursos que será criado:
Sync Status:
-
- Synced – Os recursos foram criados ou atualizados com sucesso
-
- OutOfSync – Há recursos que não foram criados ou atualizados
Health Status:
-
- Healthy – Recursos que estão saudáveis
-
- Progressing – Recursos sendo atualizados
- Degreded – Recursos não saudáveis, houve alguma falha na sua criação
- Suspended – Recursos estão suspensos e esperando por um evento externo ser executado
- Missing – Recursos não encontrados no cluster (normalmente aparece em recursos que será criado pela primeira vez)
- Unknown – Não foi possível identificar o recurso, pode ocorrer quando em um manifesto a “apiVersion” ou “kind” são inseridos de forma errada ou um CRD que não foi encontrado no cluster
Primeiro Sync
No topo da página você tem algumas opções:
-
- DETAILS – Informações sobre a Application
-
- DIFF – Diferença de estado dos recursos comparado com o estado atual no cluster e o estado desejado no repositório
- SYNC – Aplica as modificações encontradas
- SYNC STATUS – Informações do último Sync executado
- HISTORY AND ROLLBACK – Uma lista dos estados anteriores, a cada Sync é gerado um novo item nesta lista onde é possível voltar para um estado desejado caso alguma configuração nova tenha falhado
- DELETE – Remove a Application e os recursos do cluster que foram criados pela Application
- REFRESH – Verifica se tem alguma alteração de estado no repositório (Por padrão o ArgoCD faz um refresh a cada 5 minutos)
E por fim, nós temos o campo onde mostra os nossos recursos que serão criados. Note que eles possuem ícones em cada recurso, isso ajuda a identificar o estado desses recursos.
Clique em cada recurso para obter detalhes sobre eles, é possível identificar informações sobre o recurso, diferenças de estado, logs e eventos.
Clicando em “SYNC” irá aparecer um painel lateral direto com algumas opções de sincronização.
Aqui temos algumas opções para aplicar as modificações, irei descrever algumas das mais importante:
-
- PRUNE – Após feito o sync novos pods será criado e deleta os pods antigos
-
- FORCE – Força a modificação dos estados desejados (Use com cuidado)
- REPLACE – Subistitui recursos já existentes dentro do cluster (Use com cuidado)
- SYNCHRONIZE RESOURCES – Lista de itens que serão criados ou modificados, você pode desmarcar ou marcar os recursos que deseja sincronizar
No momento, deixe tudo como está e clique em “Synchronize” no topo.
Após clicar em “Synchronize” os recursos serão criados, e agora podemos observar alguns detalhes. Diversas informações mudaram depois que a aplicação foi sincronizada, informando que a aplicação está saudável e foi sincronizada com sucesso
Aplicando modificações
Agora iremos fazer uma alteração na imagem do deployment. Mude a tag da imagem para qualquer versão (no caso estou alterando de “latest” para “stable-alpine”). Suba a mudança para o seu repositório e clique em “REFRESH”, o ArgoCD irá identificar que houve uma mudança de estado desejado (repositório) em relação ao estado atual (cluster).
Note que no painel o status de sync agora ficou como “OutOfSync” e os recursos que forem ser alterados estão com o mesmo símbolo, clique em qualquer um deles para visualizar as alterações que será feito e clique em “DIFF”.
Você pode marcar “compact diff” e “inline diff” para uma melhor visualização das alterações.
Linhas demarcadas em vermelho identifica o que será modificado.
Linhas demarcadas em verde será o novo valor a ser configurado.
Confirme as diferenças que será aplicada, caso algo esteja fora do que você modificou, ou do que você deseja, corrija nos manifestos. Se tudo estiver de acordo clique em “SYNC” novamente e depois em “Synchronize”.
Após a sincronização a Application irá retornar para o status de Synced.
Para entender o que acontece quando uma configuração errada é aplica e como retornar à configuração anterior, iremos realizar mais uma modificação. Altere a versão da imagem para algo que não exista, commit essa modificação e clique em “REFRESH”. Valide a diferença que será aplicada e faça o sync da Application.
Após a sincronização, note que a saúde da Application está em “Progressing”, e temos dois pods, onde o que está saudável é o anterior da modificação e só irá ser removido quando o novo pod estiver saudável, e temos o segundo pod com status “Degreded” onde há um erro na sua criação.
Clique no pod com status “Degraded” e em seguida clique em Events. Irá aparecer um painel onde podemos entender melhor o porquê do pod não estar conseguindo ser criado. Em alguns casos, a aba de Events pode não trazer uma informação relevante. Verifique a aba de Logs para visualizar informações internas do container.
Note que nos eventos temos algumas informações importantes que diz muito sobre o tipo de erro que está ocorrendo. Como este erro foi proposital, sabemos que a versão da imagem não existe, logo não será possível encontrar e fazer o pull dessa imagem.
History e Rollback
Agora que temos um cenário onde um deploy feito foi quebrado, iremos recuperar o estado anterior da aplicação.
Na parte superior clique em “HISTORY AND ROLLBACK” um painel irá aparecer trazendo uma lista dos últimos depolys. Clique em cada um para visualizar o autor, nome do commit e quando foi feito o commit.
Clique nos três pontos do lado direto de uma das revisões, você verá a opção de “ROLLBACK”. Faça o rollback para a revisão anterior que estava funcionando para recuperar o estado da sua aplicação.
O novo pod, com status “Degreded”, será desescalado, porém, a Application irá se manter como status “OutOfSync” porque a última modificação que está no repositório não está aplicada (mesmo que você tenha aplicado e quebrado a aplicação). Agora, seria um trabalho de corrigir a versão da imagem no repositório e realizar o sync da aplicação novamente.
Obs.: note que uma forma de identificar as versões de deploy feita no ArgoCD é através do momento em que o sync foi feito e através de commits. Crie seus commits de forma específica e fácil de se identificar as mudanças para um melhor controle de revisões.
Novo recurso & deletando recurso
Criar e remover recursos utilizando o ArgoCD basta adicionar ou remover um template da pasta em que a Application está configurada.
No exemplo abaixo será criado um recurso (ConfigMap) e deletado um recursos existente (Service). Note que o recurso que será deletado está com um ícone de lixeira, se esse comportamento não for esperado não faça o sync, recupere o arquivo e adicione na pasta, faça o REFRESH novamente para ele identificar os arquivos no repositório. Apenas quando tudo estiver de acordo com o desejado faça o sync.
Uma outra alternativa é sincronizar apenas o recurso que você identificou que está correto.