Saltar al contenido principal

Actualizaciones y escalamiento

Operaciones del segundo día: incorporar nuevos lanzamientos y darle a Kanera más espacio a medida que el equipo crece.

Actualizaciones​

Cada versión de Kanera es una versión etiquetada como v1.9.0 con su propio docker-compose.yml. Actualizar significa intercambiar el archivo de redacción de la nueva versión y extraer sus imágenes. Puede omitir versiones: pasar de la versión 1.9.0 directamente a la versión 1.12.0 está bien, porque cada migración de base de datos pendiente se ejecuta en orden durante la actualización.

Actualizar a la última versión​

De tu kanera directorio en el 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 ejecutarlo, lea el notas de lanzamiento para cada lanzamiento entre su versión y la nueva. Un cambio que requiere acción, como una nueva configuración o una reconexión única, aparece en la versión que lo introdujo, por lo que pasar de v1.9.0 a v1.12.0 significa leer las notas 1.10.0, 1.11.0 y 1.12.0.

Para pasar a una versión específica en lugar de la más reciente, descargue su archivo de redacción por etiqueta:

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

Comprueba qué versión estás ejecutando​

docker compose images api

el TAG La columna muestra el lanzamiento, por ejemplo. 1.9.0. La primera línea de docker-compose.yml lo nombra también.

Antes de actualizar​

  • Haga una copia de seguridad de la base de datos y las cargas. el pg_dump arriba cubre la base de datos; el kanera_uploads El volumen necesita su propia copia. Conserva ambos, más tu .env, fuera del disco principal del servidor. Ver Almacenamiento y copias de seguridad.
  • Conserve el archivo de redacción anterior. el cp arriba lo guarda como docker-compose.previous.yml, que es lo que necesitas para revertir.
  • Mantenga sus cambios fuera de docker-compose.yml. La actualización reemplaza ese archivo. Poner puertos, redes adicionales u otros cambios locales en un docker-compose.override.yml al lado; Compose lo fusiona automáticamente y las actualizaciones lo dejan en paz.
  • Asegúrese de que la implementación actual esté en buen estado. Una actualización no debe ocultar un problema de enrutamiento, almacenamiento o base de datos existente.

Verificar la actualización​

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

el api la imagen debe mostrar la nueva versión, y migrate debería mostrarse como salido con el código 0. También verifique los puntos finales de salud públicos de API y MCP si los expone. Luego inicie sesión, abra un tablero lleno y cree y elimine una tarjeta temporal.

Si falla una actualización​

  • La migración no comenzó: corrija el error de redacción o entorno y vuelva a ejecutar docker compose up -d.
  • La migración falló: conserve los registros y la copia de seguridad, y no los vuelva a ejecutar repetidamente sin comprender el error. abrir un problema con el migrate registros.
  • Necesitas regresar: una versión anterior no se puede ejecutar en una base de datos que la más nueva ha migrado. Detener Kanera (docker compose down), restaure la base de datos previa a la actualización y las cargas juntas, vuelva a colocar el archivo de redacción anterior (mv docker-compose.previous.yml docker-compose.yml), y ejecutar docker compose up -d.
  • Nunca restaure una copia de seguridad sobre una versión más reciente en ejecución. Pruebe su procedimiento de restauración en una base de datos o host independiente antes de confiar en él.

Notas de escala​

La implementación predeterminada utiliza varias réplicas de API de aplicaciones y un trabajador.

  • API_REPLICAS controla el recuento de procesos API de la aplicación. El valor predeterminado es 2.
  • PUBLIC_API_REPLICAS controla el recuento de procesos de API pública. El valor predeterminado es 1.
  • MCP_REPLICAS controla el recuento de procesos MCP. El valor predeterminado es 1.
  • mantener worker exactamente en 1.
  • Se requiere Valkey para la distribución en tiempo real, la presencia y los límites de velocidad compartida.

Genere réplicas solo cuando el servidor tenga suficiente CPU, memoria y capacidad de conexión a la base de datos. si levantas API_REPLICAS, revisión PG_POOL_MAX y PostgreSQL max_connections.

El trabajador único es deliberado. Ejecuta programadores, entrega de notificaciones y webhooks, y trabajos de limpieza, y una segunda copia duplicaría ese trabajo en lugar de compartirlo. Si la entrega se está retrasando, observe la capacidad de la base de datos y de la red saliente antes de considerar más procesos de trabajo.