Pular para o conteúdo principal

Atualizações e dimensionamento

Operações do segundo dia: conseguir novos lançamentos e dar mais espaço a Kanera conforme a equipe cresce.

Atualizações​

Cada versão do Kanera é uma versão marcada como v1.9.0 com o seu próprio docker-compose.yml. Atualizar significa trocar o arquivo de composição da nova versão e extrair suas imagens. Você pode pular as versões: passar da v1.9.0 diretamente para a v1.12.0 é bom, porque toda migração de banco de dados pendente é executada em ordem durante a atualização.

Atualizar para a versão mais recente​

Do seu kanera diretório no servidor:

docker compose exec -T postgres pg_dump -U kanera kanera | gzip > kanera-$(date +%F).sql.gz
cp docker-compose.yml docker-compose.previous.yml
curl -fsSLo docker-compose.yml https://github.com/happendev/Kanera/releases/latest/download/docker-compose.yml
docker compose pull
docker compose up -d
docker compose logs migrate

Antes de executá-lo, leia o notas de lançamento para cada lançamento entre a sua versão e a nova. Uma mudança que precisa de ação, como uma nova configuração ou uma reconexão única, está listada na versão que a introduziu, portanto, passar da v1.9.0 para a v1.12.0 significa ler as notas 1.10.0, 1.11.0 e 1.12.0.

Para passar para uma versão específica em vez da mais recente, baixe seu arquivo de composição por tag:

curl -fsSLo docker-compose.yml https://github.com/happendev/Kanera/releases/download/v1.9.0/docker-compose.yml

Verifique qual versão você está executando​

docker compose images api

O TAG coluna mostra o lançamento, por exemplo 1.9.0. A primeira linha de docker-compose.yml dá nome também.

Antes de atualizar​

  • Faça backup do banco de dados e uploads. O pg_dump acima cobre o banco de dados; o kanera_uploads o volume precisa de sua própria cópia. Mantenha ambos, mais o seu .env, fora do disco primário do servidor. Veja Armazenamento e backups.
  • Mantenha o arquivo de composição anterior. O cp acima salva como docker-compose.previous.yml, que é o que você precisa para reverter.
  • Mantenha suas alterações fora de docker-compose.yml. A atualização substitui esse arquivo. Coloque portas, redes extras ou outras alterações locais em um docker-compose.override.yml próximo a ele; O Compose mescla-o automaticamente e as atualizações deixam-no como está.
  • Certifique-se de que a implantação atual esteja íntegra. Uma atualização não deve ocultar um problema existente de banco de dados, armazenamento ou roteamento.

Verifique a atualização​

docker compose images api
docker compose ps --all
docker compose logs --tail=100 api worker public-api mcp
curl https://kanera.example.com/api/health

O api a imagem deve mostrar a nova versão, e migrate deve aparecer como encerrado com o código 0. Verifique também a API pública e os endpoints de integridade do MCP se você os expor. Em seguida, faça login, abra um quadro preenchido e crie e exclua um cartão temporário.

Se uma atualização falhar​

  • A migração não começou: corrija o erro de composição ou ambiente e execute novamente docker compose up -d.
  • A migração falhou: mantenha os logs e o backup e não execute-os novamente sem entender o erro. Abra um problema com o migrate registros.
  • Você precisa voltar: uma versão mais antiga não pode ser executada em um banco de dados que a versão mais recente migrou. Pare Kanera (docker compose down), restaure o banco de dados de pré-atualização e os uploads juntos, coloque o arquivo de composição anterior de volta (mv docker-compose.previous.yml docker-compose.yml) e execute docker compose up -d.
  • Nunca restaure um backup em uma versão mais recente em execução. Teste seu procedimento de restauração em um banco de dados ou host separado antes de confiar nele.

Notas de escala​

A implantação padrão usa várias réplicas de API de aplicativo e um trabalhador.

  • API_REPLICAS controla a contagem de processos da API do aplicativo. O padrão é 2.
  • PUBLIC_API_REPLICAS controla a contagem de processos de API pública. O padrão é 1.
  • MCP_REPLICAS controla a contagem de processos MCP. O padrão é 1.
  • Mantenha worker exatamente 1.
  • Valkey é necessário para distribuição em tempo real, presença e limites de taxa compartilhada.

Crie réplicas somente quando o servidor tiver CPU, memória e capacidade de conexão de banco de dados suficientes. Se você aumentar API_REPLICAS, revisão PG_POOL_MAX e PostgreSQL max_connections.

O único trabalhador é deliberado. Ele executa agendadores, notificação e entrega de webhook e trabalhos de limpeza, e uma segunda cópia duplicaria esse trabalho em vez de compartilhá-lo. Se a entrega estiver atrasada, observe a capacidade do banco de dados e da rede de saída antes de considerar mais processos de trabalho.