Implantação no KinD
Um exemplo de implantação local no KinD é fornecido aqui. Clone este repositório e modifique os arquivos conforme sua conveniência. No repositório, como em um módulo Terraform padrão, você encontrará os seguintes arquivos:
-
terraform.tf
- declaração dos provedores Terraform utilizados neste projeto bem como sua configuração; -
locals.tf
- variáveis locais usadas pelos módulos Modern Gitops Stack; -
main.tf
- definição de todos os módulos implantados; -
s3_bucket.tf
- configuração do bucket MinIO, usado como backend para Loki e Thanos; -
outputs.tf
- as variáveis de saída do Modern Gitops Stack, por exemplo. credenciais e o arquivo.kubeconfig
para usar comkubectl
;
Especificidades e explicações
Balanceador de carga local
MetalLB é usado como balanceador de carga para o cluster. Isso nos permite ter um cluster KinD de vários nós sem a necessidade de usar o Traefik em uma única réplica com uma configuração NodePort.
Autenticação OIDC
IMPORTANTE: Os módulos Modern Gitops Stack são desenvolvidos com o OIDC em mente. Na produção, você deve ter um provedor de identidade que suporte OIDC e usá-lo para autenticar os aplicativos Modern Gitops Stack.
DICA: Você pode ter um local contendo a configuração do OIDC devidamente estruturado para as aplicações Modern Gitops Stack e simplesmente usar um provedor OIDC externo em vez de usar o Keycloak. Verifique https://github.com/GersonRS/modern-gitops-stack-module-keycloak/blob/main/oidc_bootstrap/locals.tf [este locals.tf
no módulo Keycloak] para obter um exemplo.
Para implantar rapidamente um ambiente de teste no KinD você pode usar o módulo Keycloak, conforme mostrado no exemplo.
Depois de implantar o Keycloak, você pode usar o módulo de inicialização OIDC para criar o domínio, grupos, usuários do Keycloak, etc.
A variável user_map
desse módulo permite criar usuários OIDC usados para autenticar nos aplicativos Modern Gitops Stack. O módulo irá gerar uma senha para cada usuário, que você poderá verificar posteriormente após a implantação.
DICA: Se você não fornecer um valor para a variável user_map
, o módulo criará um usuário chamado moderngitopsadmin
com uma senha aleatória.
Certificados SSL autoassinados
Como o KinD está implantado em sua máquina, não há uma maneira fácil de criar certificados SSL válidos para entradas usando Let’s Encrypt. Como tal, cert-manager
está configurado para usar uma autoridade de certificação autoassinada e os módulos restantes são configurados para ignorar os avisos/erros SSL que são consequência disso.
NOTA: Ao acessar os ingressos no seu navegador, obviamente você verá avisos informando que o certificado não é válido. Você pode ignorá-los com segurança.
Implantação
-
Clone o repositório e
cd
na pastaexamples/kind
. -
Confira os módulos que deseja implantar no arquivo
main.tf
e comente os demais;DICA: Você também pode adicionar seus próprios módulos Terraform neste arquivo ou em qualquer outro arquivo na pasta raiz. Um bom lugar para começar a escrever seu próprio módulo é clonar o repositório modern-gitops-stack-module-template e adaptá-lo ao seu precisa;
-
No módulo
oidc
, adapte a variáveluser_map
como desejar (verifique a seção OIDC para mais informações). -
A partir da origem da implantação de exemplo, inicialize o Terraform, que baixa todos os provedores e módulos necessários localmente (eles serão armazenados na pasta oculta
.terraform
);terraform init
-
Configure as variáveis em
locals.tf
de acordo com sua preferência:Unresolved include directive in modules/ROOT/pages/tutorials/deploy_kind.adoc - include::examples$deploy_examples/kind/locals.tf[]
-
Por fim, execute
terraform apply
e aceite as alterações propostas para criar os nós Kubernetes como contêineres Docker e preenchê-los com nossos serviços;terraform apply
-
Após a primeira implantação (observe a etapa de solução de problemas relacionada ao Argo CD), você pode ir para locais e habilitar o booleano ServiceMonitor para ativar os exportadores do Prometheus que enviarão métricas para o Prometheus;
IMPORTANTE: Este sinalizador precisa ser definido como
false
para a primeira inicialização do cluster, caso contrário, os aplicativos falharão na implantação enquanto as definições de recursos personalizados do kube-prometheus-stack ainda não foram criadas.NOTA: Você pode definir o sinalizador como
true
no arquivolocals.tf
ou pode simplesmente deletar a linha nas declarações dos módulos, já que esta variável é definida comotrue
por padrão em cada módulo.DICA: Anote o local chamado
app_autosync
. Se você definir a condição do operador ternário comofalse
você desabilitará a sincronização automática para todos os módulos Modern Gitops Stack. Isso permite que você escolha quando sincronizar manualmente o módulo na interface do Argo CD e é útil para fins de solução de problemas.
Acesse o cluster e os aplicativos Modern Gitops Stack
Normalmente, o provedor KinD Terraform usado em nosso código já anexa as credenciais ao seu Kubeconfig padrão, portanto, você deve estar pronto para acessar o cluster.
Caso contrário, você pode usar o conteúdo da saída kubernetes_kubeconfig
para gerar manualmente um arquivo Kubeconfig ou pode usar aquele criado automaticamente na pasta raiz do projeto.
Então você pode usar o comando kubectl
ou k9s
para interagir com o cluster:
k9s --kubeconfig <PATH_TO_TERRAFORM_PROJECT>/<CLUSTER_NAME>-config
Quanto aos aplicativos Modern Gitops Stack, você pode acessá-los através do domínio de entrada que pode ser encontrado na saída ingress_domain
. Se você usou o código do exemplo sem modificar as saídas, você verá algo assim em seu terminal depois que terraform apply
tiver feito seu trabalho:
Outputs:
ingress_domain = "your.domain.here"
keycloak_admin_credentials = <sensitive>
keycloak_users = <sensitive>
kubernetes_kubeconfig = <sensitive>
Ou você pode usar kubectl
para obter todas as entradas e seus respectivos URLs:
kubectl get ingress --all-namespaces
Por exemplo, se o nome de domínio base for 172-19-0-1.nip.io
, as aplicações estarão acessíveis nos seguintes endereços:
https://grafana.apps.172-19-0-1.nip.io https://alertmanager.apps.172-19-0-1.nip.io https://prometheus.apps.172-19-0-1.nip.io https://keycloak.apps.172-19-0-1.nip.io https://minio.apps.172-19-0-1.nip.io https://argocd.apps.172-19-0-1.nip.io https://thanos-bucketweb.apps.172-19-0-1.nip.io https://thanos-query.apps.172-19-0-1.nip.io
Você pode acessar os aplicativos usando as credenciais criadas pelo módulo Keycloak. Eles são gravados na saída do Terraform:
# List all outputs
$ terraform output
keycloak_admin_credentials = <sensitive>
keycloak_users = <sensitive>
kubernetes_kubeconfig = <sensitive>
minio_root_user_credentials = <sensitive>
# To get the credentials for Grafana, Prometheus, etc.
$ terraform output keycloak_users
{
"moderngitopsadmin" = "PASSWORD"
}
Pausar o cluster
O comando docker pause
pode ser usado para interromper o cluster por um tempo para economizar energia (substitua kind-cluster
pelo nome do cluster que você definiu em locals.tf
):
# Pause o cluster:
docker pause kind-cluster-control-plane kind-cluster-worker{,2,3}
# Resume o cluster:
docker unpause kind-cluster-control-plane kind-cluster-worker{,2,3}
NOTA: Quando o computador host for reiniciado, o contêiner do Docker será iniciado novamente, mas o cluster não será retomado corretamente. Tem que ser destruído e recriado.
Pare o cluster
Para parar definitivamente o cluster com um único comando (é por isso que excluímos alguns recursos do arquivo de estado), você pode usar o seguinte comando:
terraform state rm $(terraform state list | grep "argocd_application\|argocd_project\|kubernetes_\|helm_\|keycloak_") && terraform destroy
Uma alternativa mais suja é destruir diretamente os contêineres e volumes do Docker (substitua kind-cluster
pelo nome do cluster que você definiu em locals.tf
):
# Stop and remove Docker containers
docker container stop kind-cluster-control-plane kind-cluster-worker{,2,3} && docker container rm -v kind-cluster-control-plane kind-cluster-worker{,2,3}
# Remove the Terraform state file
rm terraform.state
Conclusão
É isso, você implantou o Modern Gitops Stack localmente! Para mais informações, continue lendo documentation. Você pode explorar as possibilidades de cada módulo e obter o link para o código-fonte nas respectivas páginas de documentação.
Solução de problemas
connection_error
durante a primeira implantação
Em alguns casos, você pode encontrar um erro como este na primeira implantação:
╷
│ Error: Error while waiting for application argocd to be created
│
│ with module.argocd.argocd_application.this,
│ on .terraform/modules/argocd/main.tf line 55, in resource "argocd_application" "this":
│ 55: resource "argocd_application" "this" {
│
│ error while waiting for application argocd to be synced and healthy: rpc error: code = Unavailable desc = connection error: desc = "transport: error while dialing: dial tcp 127.0.0.1:45729: connect: connection refused"
╵
Este erro se deve à forma como provisionamos o Argo CD nas etapas finais da implantação. Usamos o bootstrap Argo CD para implantar o módulo Argo CD final, o que causa uma reimplantação do Argo CD e consequentemente uma perda momentânea de conexão entre o provedor Argo CD Terraform e o servidor Argo CD.
Você pode simplesmente executar novamente o comando terraform apply
para finalizar a inicialização do cluster.
DICA: Para obter mais informações sobre o módulo Argo CD, consulte respectiva página de documentação.
Loop de recarga da interface Argo CD ao clicar no login
Se você encontrar um loop ao clicar no botão de login na interface do Argo CD, você pode tentar excluir o pod do servidor Argo CD e deixá-lo ser recriado.
DICA: Para obter mais informações sobre o módulo Argo CD, consulte respectiva página de documentação.
Pods loki-stack-promtail
presos com status CrashLoopBackOff
Você pode encontrar loki-stack-promtail
preso em um loop de criação com os seguintes logs:
level=error ts=2023-05-09T06:32:38.495673778Z caller=main.go:117 msg="error creating promtail" error="failed to make file target manager: too many open files"
Stream closed EOF for loki-stack/loki-stack-promtail-bxcmw (promtail)
Se for esse o caso, você terá que aumentar o limite máximo do número de instâncias INotify que podem ser criadas por ID de usuário real:
# Increase the limit until next reboot
sudo sysctl fs.inotify.max_user_instances=512
# Increase the limit permanently (run this command as root)
echo 'fs.inotify.max_user_instances=512' >> /etc/sysctl.conf