Skip to main content
O ChatCLI publica seus Helm charts no ArtifactHub, o registro público oficial de pacotes para o ecossistema Cloud Native. Isso permite que qualquer pessoa descubra, instale e mantenha os charts atualizados diretamente pelo catálogo do ArtifactHub ou via CLI do Helm.

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/chatcli

ChatCLI 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-operator

Como 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
Esses arquivos são enviados para o registro OCI via ORAS com o MIME type 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 workflow 3-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 recursos Instance antes de remover o operator: o operator remove o finalizer deles, e uma Instance apagada depois que ele saiu fica em Terminating (veja Desinstalar).
As CRDs não são removidas automaticamente pelo Helm. Para removê-las manualmente:

Estrutura dos Charts

Os Helm charts ficam em deploy/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.