Operação: CLI, backup e atualização

O CLI aptabit instala, atualiza, faz backup, restaura e diagnostica a Aptabit Platform a partir de um único arquivo de configuração, o config.yaml.

Comandos do CLI

Comandos avançados, listados por aptabit help --all, incluem logs, doctor, init, self-update, recover-root e uninstall. O uninstall é o único comando que apaga dados: ele pede a digitação do caminho da instalação para confirmar.

Opções frequentes: --config escolhe a instalação quando há mais de uma (na maioria dos comandos também como --instance); --dry-run mostra o que seria feito em install, up, down, uninstall e backup rollback; --yes dispensa a confirmação; --lang pt-BR ou --lang en escolhe o idioma em qualquer comando.

Atualização

aptabit update --check   # apenas verifica se há versão nova
aptabit update           # atualiza para a versão estável mais recente

A atualização:

1. Cria um backup de segurança.
2. Baixa as novas imagens.
3. Atualiza api, worker e web, um de cada vez, aguardando a verificação de saúde de cada um, e só então recria o proxy.
4. Se a nova versão não subir, volta automaticamente ao backup feito no passo 1.

As migrações do banco rodam automaticamente quando a API inicia. Para fixar uma versão, use aptabit update:<versao>; aptabit update --latest remove a fixação. O aptabit self-update atualiza o próprio CLI, conferindo o manifesto assinado pela Aptabit.

Backup e restauração

aptabit backup
aptabit backup list
aptabit backup rollback <id>

O backup é um ponto de restauração local com os arquivos de configuração e os volumes do PostgreSQL, do MinIO, do Milvus e do etcd da stack. A plataforma é parada por alguns instantes para garantir a consistência.

• Dependências externas (PostgreSQL, Redis, S3 ou Milvus gerenciados) não entram no backup do CLI; use as ferramentas desses serviços.
• A pasta identity/ não é copiada, porque contém a chave privada da instalação.
• O backup é gravado em disco local, sem cifragem; copie-o para o sistema de backup da organização.

Dependências externas

Cada dependência pode apontar para um serviço que a organização já opera. O comando avançado aptabit init gera a configuração:

aptabit init \
  --config /opt/aptabit/producao/config.yaml \
  --database external \
  --database-url postgres://usuario:senha@db.example.com:5432/aptabit \
  --redis external \
  --redis-url redis://redis.example.com:6379 \
  --storage s3-external \
  --storage-endpoint https://s3.example.com \
  --storage-bucket aptabit-prod \
  --storage-access-key <access-key> \
  --storage-secret-key <secret-key> \
  --vector external \
  --vector-endpoint http://milvus.example.com:19530 \
  --force

O docker-compose.yml gerado omite os serviços e volumes locais correspondentes. Para validar sem iniciar containers:

docker compose -f /opt/aptabit/producao/docker-compose.yml config --quiet
aptabit up --config /opt/aptabit/producao/config.yaml --dry-run

Várias instalações no mesmo servidor

Cada instalação tem pasta, projeto Compose, nomes de containers e rede próprios, e pode ser nomeada com aptabit install --name <nome>. Sem --config, os comandos agem sobre a instalação atual; o CLI lista as demais quando existem.

Diagnóstico

aptabit status --json
aptabit logs --service api --service worker --follow --tail 100
aptabit support-bundle

• Cada comando grava um log da execução em ~/.aptabit/logs/, com segredos substituídos por <redacted>; os 50 mais recentes são mantidos.
• Uma falha termina com um código estável, um ID e o caminho do log. Informe o ID ao suporte.
• O pacote de suporte reúne a verificação da máquina, a configuração, o estado dos containers com as últimas 300 linhas de log, a situação do setup e da licença e os logs recentes, sem senhas, chaves ou tokens.

Observabilidade

• Logs estruturados em JSON.
• Endpoints /health e /ready para verificações de disponibilidade.
• Exportação de traces e logs por OpenTelemetry para o coletor da organização, configurada em Configurações > Logs.
• Configurações > Sistema mostra CPU, memória, discos e GPUs da máquina.

Limites atuais

• Cada instalação roda em um único servidor; alta disponibilidade depende de dependências gerenciadas externamente.
• O proxy atende HTTP; o TLS é terminado na infraestrutura da organização.
• O instalador guiado usa Docker; o suporte a Podman é parcial.
• Existe um chart Helm inicial, mas o CLI não opera instalações em Kubernetes.