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 com kubectl;

Requisitos

Na sua máquina local, você precisa ter as seguintes ferramentas instaladas:

  • Docker para implantar os contêineres KinD;

  • Terraform para provisionar toda a pilha;

  • kubectl ou k9spara interagir com seu cluster;

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

  1. Clone o repositório e cd na pasta examples/kind.

  2. 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;

  3. No módulo oidc, adapte a variável user_map como desejar (verifique a seção OIDC para mais informações).

  4. 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
  5. 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[]
  6. 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
  7. 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 arquivo locals.tf ou pode simplesmente deletar a linha nas declarações dos módulos, já que esta variável é definida como true por padrão em cada módulo.

    DICA: Anote o local chamado app_autosync. Se você definir a condição do operador ternário como false 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