A prática de GitOps permite definir a infraestrutura como código de forma declarativa. Ela serve como uma fonte única e auditada para o estado da nuvem ou cluster, trazendo benefícios como controle de versão, trilhas de auditoria para mudanças na infraestrutura e reconciliação automatizada entre os estados desejado e real. Além disso, melhora a segurança através de credenciais criptografadas e controle de acesso, simplifica a reversão de alterações e aprimora a colaboração através de fluxos de trabalho Git.
FluxCD é um projeto graduado pela CNCF que habilita práticas de GitOps no ecossistema Kubernetes. Ele automatiza a implantação, monitoramento e reconciliação de recursos do cluster com base em repositórios Git. Este artigo aborda a configuração inicial e a funcionalidade principal do FluxCD em um cluster Kubernetes.
Configuração de Dependências Git
Vamos começar criando um repositório Git no Github. Em seguida, é necessário gerar um token de acesso granular que o FluxCD usará para interagir com o repositório. Esses tokens oferecem um controle mais preciso sobre as permissões do repositório em comparação com os tokens de acesso pessoal clássicos.
Manteremos a permissão Read and write para acesso de Administration e Contents, e Read-only para acesso de Metadata, limitado ao repositório que criamos. As permissões seguem as recomendações da documentação oficial do FluxCD para esta configuração inicial.
Configuração do Flux CLI
Para começar, vamos instalar o FluxCD cli. O próximo passo é exportar as variáveis de detalhe do usuário e token github.
sudo zypper in flux2-cli
export GITHUB_TOKEN=******
export GITHUB_USER=*****
Para este artigo, estamos usando um cluster k3s hospedado localmente em uma máquina virtual. Vamos verificar se temos acesso a ele com kubectl.
# 1. Point to specific cluster we are setting up
export KUBECONFIG=~/.kube/local.config
# 2. Check for access and version
kubectl version
Vamos verificar com o Flux cli se ele também tem acesso.
flux check --pre
Bootstrap do GitOps com FluxCD
Instalaremos todos os componentes, incluindo os extras para automação de imagem.
flux bootstrap github \
--owner=$GITHUB_USER \
--repository=k8s-gitops \
--branch=main \
--path=./cluster/default \
--read-write-key \
--components source-controller,kustomize-controller,helm-controller,notification-controller \
--components-extra image-reflector-controller,image-automation-controller \
--personal
Vamos verificar a configuração do Flux passo a passo:
- O Bootstrap criou uma chave de implantação no repositório Github e a armazenou como flux-system/flux-secret.
Verificando a chave de implantação no Github e o segredo com kubectl -n flux-system get secrets.
- O Flux inicializou o repositório com o commit inicial contendo a definição dos componentes em
cluster/default, conforme especificado no comando bootstrap.
3 – O FluxCD reconciliou com o repositório Git e instalou os componentes no namespace flux-system. Vamos verificar com kubectl.
Verificação da Instalação do GitOps com FluxCD
Vamos verificar nossa instalação criando uma implantação de amostra.
apps/nginx/deployment.yaml
apiVersion: apps/v1
metadata:
name: nginx-deployment
namespace: default
kind: Deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "64Mi"
cpu: "50m"
apps/nginx/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
cluster/default/nginx.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: nginx
namespace: flux-system
spec:
interval: 5m
path: ./apps/nginx
prune: true
retryInterval: 2m
sourceRef:
kind: GitRepository
name: flux-system
targetNamespace: default
timeout: 3m
wait: true
O recurso Kustomization possui vários campos importantes:
interval: Com que frequência o Flux deve reconciliar este recurso (5m = 5 minutos).path: Diretório contendo os manifestos Kubernetes.prune: Se o Flux deve excluir recursos que não estão mais definidos no Git.retryInterval: Quanto tempo esperar entre as tentativas se a reconciliação falhar.wait: Se o Flux deve esperar que os recursos estejam prontos antes de concluir a reconciliação.timeout: Tempo máximo para aguardar a reconciliação.
Vamos enviar essas mudanças e esperar que a reconciliação termine. Após a finalização, podemos verificar se o nginx foi implantado.
O Que Acontece Se…?
Um dos principais objetivos do GitOps com FluxCD é garantir que o estado do nosso cluster sempre corresponda aos recursos definidos no nosso repositório git. Esse processo contínuo de reconciliação é o que torna o GitOps com FluxCD poderoso para manter a consistência do sistema.
Para demonstrar essa funcionalidade, excluiremos nossa implantação nginx usando kubectl e observaremos como o processo de reconciliação do Flux a restaura automaticamente ao estado desejado definido no Git. Isso mostra a capacidade de “auto cura” da abordagem GitOps com FluxCD.
No exemplo acima, o primeiro passo é verificar a implantação com kubectl get deployments para verificar se o nginx está em execução. O segundo passo é excluir a implantação com kubectl delete deployment/nginx-deployment e o terceiro passo é confirmar se a implantação nginx foi excluída com kubectl get deployment. O quarto passo é observar a reconciliação do FluxCD entrar em ação e o quinto passo é verificar se o nginx foi reimplantado após a reconciliação do Flux.
Próximos Passos
Publicações futuras explorarão padrões avançados de GitOps com FluxCD, incluindo:
- Automação de gráfico Helm.
- Automação de atualização de imagem.
- Configuração de notificação e alerta.
- Gerenciamento de segredos com SOPS.
Continue acompanhando para saber mais sobre esses tópicos. Se você busca entender mais sobre automação, veja este artigo sobre o que é automação de marketing e como usar na prática.
Este conteúdo foi auxiliado por Inteligência Artificial, mas escrito e revisado por um humano.
Via Dev.to