Passer au contenu principal

Mises à jour et mise à l'échelle

Opérations du deuxième jour : obtenir de nouvelles versions et donner plus de place à Kanera à mesure que l'équipe s'agrandit.

Mises à jour​

Chaque version de Kanera est une version étiquetée telle que v1.9.0 avec le sien docker-compose.yml. La mise à jour signifie échanger le fichier de composition de la nouvelle version et extraire ses images. Vous pouvez ignorer les versions : passer directement de la v1.9.0 à la v1.12.0 est très bien, car chaque migration de base de données en attente s'exécute dans l'ordre pendant la mise à jour.

Mise à jour vers la dernière version​

De votre kanera répertoire sur le serveur :

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

Avant de l'exécuter, lisez le notes de version pour chaque version entre votre version et la nouvelle. Un changement qui nécessite une action, comme un nouveau paramètre ou une reconnexion unique, est répertorié sous la version qui l'a introduit, donc passer de la v1.9.0 à la v1.12.0 signifie lire les notes 1.10.0, 1.11.0 et 1.12.0.

Pour passer à une version spécifique au lieu de la dernière, téléchargez son fichier de composition par balise :

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

Vérifiez quelle version vous utilisez​

docker compose images api

Le TAG la colonne montre la version, par exemple 1.9.0. La première ligne de docker-compose.yml le nomme aussi.

Avant la mise à jour​

  • Sauvegardez la base de données et les téléchargements. Le pg_dump ci-dessus couvre la base de données ; le kanera_uploads le volume a besoin de sa propre copie. Gardez les deux, plus votre .env, sur le disque principal du serveur. Voir Stockage et sauvegardes.
  • Conservez le fichier de composition précédent. Le cp ci-dessus l'enregistre sous docker-compose.previous.yml, c'est ce que vous devez restaurer.
  • Gardez vos modifications hors de docker-compose.yml. La mise à jour remplace ce fichier. Placez les ports, les réseaux supplémentaires ou d'autres modifications locales dans un docker-compose.override.yml à côté; Compose le fusionne automatiquement et les mises à jour le laissent tranquille.
  • Assurez-vous que le déploiement actuel est sain. Une mise à jour ne doit pas masquer un problème de base de données, de stockage ou de routage existant.

Vérifier la mise à jour​

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

Le api l'image doit montrer la nouvelle version, et migrate doit s'afficher comme quitté avec le code 0. Vérifiez également les points de terminaison de l'API publique et de l'intégrité MCP si vous les exposez. Connectez-vous ensuite, ouvrez un tableau rempli, puis créez et supprimez une carte temporaire.

Si une mise à jour échoue​

  • La migration n'a pas démarré : corrigez l’erreur de composition ou d’environnement et réexécutez docker compose up -d.
  • La migration a échoué : conservez les journaux et la sauvegarde, et ne la réexécutez pas à plusieurs reprises sans comprendre l'erreur. Ouvrir un problème avec le migrate journaux.
  • Il faut revenir en arrière : une version plus ancienne ne peut pas s'exécuter sur une base de données que la version plus récente a migrée. Arrêtez Kanera (docker compose down), restaurez la base de données de pré-mise à jour et les téléchargements ensemble, remettez le fichier de composition précédent (mv docker-compose.previous.yml docker-compose.yml), et exécutez docker compose up -d.
  • Ne restaurez jamais une sauvegarde sur une version plus récente en cours d’exécution. Testez votre procédure de restauration sur une base de données ou un hôte distinct avant de vous y fier.

Remarques sur la mise à l'échelle​

Le déploiement par défaut utilise plusieurs réplicas d'API d'application et un seul travailleur.

  • API_REPLICAS contrôle le nombre de processus de l’API de l’application. La valeur par défaut est 2.
  • PUBLIC_API_REPLICAS contrôle le nombre de processus d’API publique. La valeur par défaut est 1.
  • MCP_REPLICAS contrôle le nombre de processus MCP. La valeur par défaut est 1.
  • Garder worker à exactement 1.
  • Valkey est requis pour la diffusion en temps réel, la présence et les limites de débit partagé.

Créez des réplicas uniquement lorsque le serveur dispose de suffisamment de capacité de CPU, de mémoire et de connexion à la base de données. Si vous relancez API_REPLICAS, révision PG_POOL_MAX et PostgreSQL max_connections.

Le travailleur célibataire est délibéré. Il exécute des planificateurs, des notifications et des livraisons de webhooks, ainsi que des tâches de nettoyage, et une deuxième copie dupliquerait ce travail plutôt que de le partager. Si la livraison prend du retard, examinez la capacité de la base de données et du réseau sortant avant d’envisager davantage de processus de travail.