Integrações por cliente
O pod está Running, mas a fila está entupida ou o banco está lento. As integrações mostram os serviços de cada cliente ao lado dos clusters, com as credenciais guardadas no Kubepier.
O que faz
Cada cliente ganha menus separados para RabbitMQ, Azure Service Bus, MongoDB e Redis. Um menu só aparece quando aquele cliente tem o acesso cadastrado no formulário do cliente; sem cadastro, o menu não existe.
O que cada cadastro pede
| Serviço | Campos | O menu aparece quando |
|---|---|---|
| RabbitMQ | URL da API de gerenciamento, usuário e senha | Os três estão preenchidos |
| Azure Service Bus | Connection string do namespace | A connection string está preenchida |
| MongoDB | Connection string e nome do banco | A connection string está preenchida |
| Redis | Connection string redis:// ou rediss://, ou host, porta, usuário, senha, TLS e banco | Há connection string ou host |
Regras comuns
- Free: contagens e status, só leitura. Pro e Team: ler mensagens e chaves e abrir os painéis. Purgar e editar são só de admin: na web, hoje; no desktop, a partir da 2.7.0.
- O plano é conferido no servidor (web) e no processo principal do app (desktop), não só escondido na tela.
- Na web, cada serviço tem uma Rota de conexão: Direta (pelos IPs de saída fixos, que você libera no serviço) ou Pelo cluster (por um relay restrito num cluster do cliente, para serviços privados). No desktop, a conexão sai da sua máquina.
- Corpos de mensagem e valores de chave nunca são gravados, guardados em cache nem escritos em log.
Painel de filas
Os menus RabbitMQ e Azure Service Bus abrem na aba Painel: todas as filas do cliente numa tela, com DLQ, tendência e alertas nos planos pagos. Na web e no desktop.
Filas do pod
Na tela do pod, o Kubepier lê as variáveis de ambiente do container, descobre as filas RabbitMQ e Azure Service Bus que ele usa e mostra o tamanho de cada uma, na web e no desktop, em todos os planos.
Painel Dependências (desktop)
No desktop, o pod mostra o Apache Kafka, o Amazon SQS, o PostgreSQL, o MySQL e o Redis que ele usa, lidos das variáveis do container: do valor escrito no pod ou, quando a variável vem de um ConfigMap (configMapKeyRef), do valor daquela chave do ConfigMap, que o desktop lê com o seu kubeconfig. Aparecem só host, porta e banco (ou fila e região, no SQS); usuário, senha e parâmetros da URL ou da connection string são descartados antes da tela. Valores que vêm de Secret nunca são lidos: a variável aparece só com o aviso "vem de um Secret". Variáveis carregadas por envFrom não entram. Para os que rodam no cluster, mostra quantos endpoints do Service estão prontos.
Para ler o ConfigMap, o seu kubeconfig precisa de get em configmaps no namespace do pod; sem essa permissão, a variável não aparece no painel.