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
3. Pipeline de Publicação (GitHub Actions)
A publicação é completamente automatizada via GitHub Actions no workflow3-publish-release.yml. A cada release:
1
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.2
Versionamento automático
O pipeline atualiza a versão nos
Chart.yaml de ambos os charts:3
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.4
Empacotamento
Os charts são empacotados com
helm package:5
Push para o registro OCI
Os pacotes são enviados para o GitHub Container Registry:
6
Assinatura com Cosign
Ambos os charts são assinados com Cosign usando OIDC keyless, garantindo a integridade e procedência dos artefatos:
7
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:
8
Sincronização com o ArtifactHub
O ArtifactHub detecta os metadados no registro OCI e indexa automaticamente as novas versões dos charts no catálogo.
CRDs Documentadas
Ambos os charts declaram 17 Custom Resource Definitions nas anotações, que aparecem automaticamente na página do ArtifactHub: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
--reset-then-reuse-values (Helm 3.14+) parte dos padrões do chart novo e reaplica os seus overrides anteriores. O --reuse-values puro ignora os padrões de chaves acrescentadas por versões novas do chart e pode quebrar a renderização; com um Helm mais antigo, passe o seu arquivo de values (-f meus-values.yaml).
Antes de atualizar o operator atravessando várias releases, leia Upgrade e desinstalação: o que reinicia, o que o status da Instance mostra durante o rollout e as releases que exigem ação antes. Para o chart do servidor, veja Upgrade, rollback, desinstalação.
Os CRDs são atualizados em todo upgrade. Os dois charts rodam um Job de hook
pre-install,pre-upgrade que aplica todos os CRDs do chart com kubectl apply --server-side antes do rollout do controller novo. O Helm em si nunca atualiza crds/ depois da primeira instalação, e um controller rodando contra um schema antigo tem os campos novos descartados e os valores novos de enum recusados. Desligue o hook (--set crdUpgrade.enabled=false) só quando você gerencia os CRDs por fora, e aí aplique o crds/ do chart novo você mesmo antes do upgrade; as notas de instalação do chart do operator imprimem os comandos.Desinstalar
Apague seus recursosInstance antes de remover o operator: o operator remove o finalizer deles, e uma Instance apagada depois que ele saiu fica em Terminating (veja Desinstalar).
Estrutura dos Charts
Os Helm charts ficam emdeploy/helm/ no repositório:
Diferenças entre os Charts
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.8+ (suporte a registros OCI), Helm 4 incluído
- Provedor LLM: Uma credencial de pelo menos um provider suportado (uma API key, IAM no Bedrock, ou um Ollama local)
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.