Charts Disponíveis
ChatCLI Server
Gateway gRPC multi-provedor de LLMs com modo agente, K8s watcher, MCP e AIOps.
Registry OCI:
oci://ghcr.io/diillson/charts/chatcliChatCLI Operator
Operator Kubernetes para detecção autônoma de incidentes, análise com IA e remediação automática.
Registry OCI:
oci://ghcr.io/diillson/charts/chatcli-operatorComo Funciona a Integração
A integração com o ArtifactHub é totalmente automatizada e baseada em três pilares:1. Arquivos de Repositório (artifacthub/)
No diretório artifacthub/ do projeto existem dois arquivos separados, um para cada chart, que registram os repositórios no ArtifactHub:
artifacthub/chatcli-repo.yml
artifacthub/chatcli-operator-repo.yml
application/vnd.cncf.artifacthub.repository-metadata.layer.v1.yaml, permitindo que o ArtifactHub descubra e indexe os charts automaticamente.
Cada chart possui um
repositoryID único e seu próprio arquivo de metadados. O ArtifactHub lê esses artefatos OCI para sincronizar os metadados dos repositórios automaticamente.2. Anotações nos Charts (Chart.yaml)
Os arquivos Chart.yaml de cada chart contêm anotações específicas do ArtifactHub que enriquecem a página do pacote no catálogo:
Anotações Disponíveis
| Anotação | Descrição | Server | Operator |
|---|---|---|---|
artifacthub.io/license | Licença do chart | Apache-2.0 | Apache-2.0 |
artifacthub.io/operator | Indica se é um operador Kubernetes | false | true |
artifacthub.io/operatorCapabilities | Nível de maturidade do operador | — | Seamless Upgrades |
artifacthub.io/containsSecurityUpdates | Sinaliza atualizações de segurança | false | false |
artifacthub.io/prerelease | Marca como versão pré-release | false | false |
artifacthub.io/crds | Lista de CRDs instaladas pelo chart | 17 CRDs | 17 CRDs |
artifacthub.io/crdsExamples | Exemplos de uso das CRDs | 3 exemplos | 4 exemplos |
artifacthub.io/links | Links para documentação e código-fonte | 2 links | 2 links |
artifacthub.io/maintainers | Mantenedores do chart | 1 | 1 |
3. Pipeline de Publicação (GitHub Actions)
A publicação é completamente automatizada via GitHub Actions no workflow3-publish-release.yml. A cada release:
Trigger do release
Um push na branch
main aciona o Release Please, que cria automaticamente um PR de release e, ao ser mergeado, gera a GitHub Release com a tag de versão.Injeção de changelog
O script
scripts/generate-artifacthub-changelog.sh extrai as mudanças do CHANGELOG.md e injeta como anotação artifacthub.io/changes nos Chart.yaml, com tipos estruturados (added, fixed, changed, etc.) e links para PRs.Assinatura com Cosign
Ambos os charts são assinados com Cosign usando OIDC keyless, garantindo a integridade e procedência dos artefatos:
Push de metadados ArtifactHub via ORAS
Os arquivos de repositório são enviados como artefatos OCI com MIME types específicos do ArtifactHub, permitindo a descoberta automática:
CRDs Documentadas
Ambos os charts declaram 17 Custom Resource Definitions nas anotações, que aparecem automaticamente na página do ArtifactHub:| CRD | Versão | Descrição |
|---|---|---|
AIInsight | v1alpha1 | Análise e recomendações geradas por IA para problemas detectados |
Anomaly | v1alpha1 | Sinal bruto dos watchers, antes da correlação em issues |
ApprovalPolicy | v1alpha1 | Requisitos de aprovação para ações de remediação (auto/manual/quórum) |
ApprovalRequest | v1alpha1 | Aprovação pendente com avaliação de blast radius |
AuditEvent | v1alpha1 | Registro imutável de ações na plataforma AIOps |
ChaosExperiment | v1alpha1 | Experimento de engenharia do caos em recursos Kubernetes |
ClusterRegistration | v1alpha1 | Cluster registrado para federação multi-cluster |
EscalationPolicy | v1alpha1 | Cadeias de escalação para gestão de incidentes |
IncidentSLA | v1alpha1 | Metas de SLA para resposta e resolução por severidade |
Instance | v1alpha1 | Configuração de instância do ChatCLI |
Issue | v1alpha1 | Problema operacional detectado e correlacionado |
NotificationPolicy | v1alpha1 | Regras de entrega de notificações multicanal |
PostMortem | v1alpha1 | Relatório completo do ciclo de vida do incidente |
RemediationPlan | v1alpha1 | Plano de remediação com mais de 54 tipos de ação |
Runbook | v1alpha1 | Procedimentos operacionais vinculados a tipos de issue |
ServiceLevelObjective | v1alpha1 | SLO com alertas de burn rate e error budgets |
SourceRepository | v1alpha1 | Vincula workloads ao repositório de código-fonte |
As CRDs são compartilhadas entre os charts server e operator. Se ambos estiverem instalados no mesmo cluster, as CRDs do chart instalado primeiro serão utilizadas.
Instalação via ArtifactHub
ChatCLI Server
ChatCLI Operator
A Partir do Código-Fonte
Usando um Secret Existente
Atualização e Remoção
Atualizar para a Última Versão
CRDs são atualizados automaticamente (GAP-06 fix). Ambos charts incluem
um Helm Job O
pre-install,pre-upgrade que roda kubectl apply --server-side
em todas as CRDs do chart antes do controller rolar. Sem esse hook, o
helm upgrade mantém os CRDs antigos por design do Helm 3 e o binário novo
quebra ao escrever campos/enums que o schema antigo não conhece (foi
exatamente o sintoma da regressão pós-1.139.0).Opt-out quando você gerencia CRDs fora do Helm (cert-manager-style
chart separado, GitOps com aplicação explícita):NOTES.txt printa um warning com o comando manual quando o hook está
desabilitado. Veja Chaos Test Fixes — GAP-06
para o detalhe completo.Desinstalar
Estrutura dos Charts
Os Helm charts ficam emdeploy/helm/ no repositório:
Diferenças entre os Charts
| Aspecto | ChatCLI Server | ChatCLI Operator |
|---|---|---|
| Função | Gateway gRPC de LLMs com agentes e watcher | Detecção autônoma de incidentes e remediação |
| Tipo no ArtifactHub | Application | Operator |
artifacthub.io/operator | false | true |
| Capabilities | — | Seamless Upgrades |
| Exemplos de CRDs | Issue, ApprovalPolicy, SLO | Issue, ApprovalPolicy, ChaosExperiment, SLO |
| Keywords | chatcli, llm, grpc, ai, mcp, aiops | operator, aiops, remediation, sre, chaos-engineering |
| Registry OCI | oci://ghcr.io/diillson/charts/chatcli | oci://ghcr.io/diillson/charts/chatcli-operator |
Segurança dos Charts
Ambos os charts seguem as melhores práticas de segurança para Kubernetes:Non-Root
Containers executam como usuário não-root (UID 1000) com
runAsNonRoot: true.Filesystem Read-Only
readOnlyRootFilesystem: true — apenas volumes montados são graváveis.Capabilities Removidas
Todas as Linux capabilities são removidas com
drop: ["ALL"].Seccomp
Perfil
RuntimeDefault do seccomp habilitado por padrão.Requisitos
- Kubernetes: 1.30+
- Helm: 3.10+ (suporte a registros OCI)
- Provedor LLM: Pelo menos uma API key configurada (OpenAI, Anthropic, Google, xAI, StackSpot, GitHub Copilot ou Ollama)
Próximos Passos
Deploy com Docker e K8s
Guia completo de deployment com Docker, Compose e Helm.
K8s Operator
Detalhes do operator AIOps com 17 CRDs.
Plataforma AIOps
Visão geral da plataforma de operações inteligentes.