Zum Hauptinhalt springen

Updates und Skalierung

Operationen am zweiten Tag: Neue Veröffentlichungen einführen und Kanera mehr Raum geben, wenn das Team wächst.

Aktualisierungen​

Jede Kanera-Veröffentlichung ist eine getaggte Version wie z v1.9.0 mit seinem eigenen docker-compose.yml. Aktualisieren bedeutet, die Compose-Datei der neuen Version auszutauschen und deren Bilder abzurufen. Sie können Veröffentlichungen überspringen: Der direkte Wechsel von Version 1.9.0 zu Version 1.12.0 ist in Ordnung, da jede ausstehende Datenbankmigration während des Updates der Reihe nach ausgeführt wird.

Aktualisieren Sie auf die neueste Version​

Von Ihrem kanera Verzeichnis auf dem Server:

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

Bevor Sie es ausführen, lesen Sie die Versionshinweise für jede Veröffentlichung zwischen Ihrer Version und der neuen. Eine Änderung, die Maßnahmen erfordert, wie z. B. eine neue Einstellung oder eine einmalige erneute Verbindung, wird unter der Version aufgeführt, die sie eingeführt hat. Wenn Sie also von v1.9.0 auf v1.12.0 wechseln, müssen Sie die Hinweise zu 1.10.0, 1.11.0 und 1.12.0 lesen.

Um zu einer bestimmten Version anstelle der neuesten Version zu wechseln, laden Sie deren Compose-Datei nach Tag herunter:

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

Überprüfen Sie, welche Version Sie verwenden​

docker compose images api

Die TAG In der Spalte wird beispielsweise die Freigabe angezeigt 1.9.0. Die erste Zeile von docker-compose.yml benennt es auch.

Vor dem Update​

  • Sichern Sie die Datenbank und Uploads. Die pg_dump oben deckt die Datenbank ab; die kanera_uploads Der Datenträger benötigt eine eigene Kopie. Behalten Sie beides, plus Ihr eigenes .env, von der primären Festplatte des Servers. Siehe Speicherung und Backups.
  • Behalten Sie die vorherige Compose-Datei bei. Die cp oben speichert es als docker-compose.previous.yml, was Sie zum Zurücksetzen benötigen.
  • Halten Sie Ihre Änderungen fern docker-compose.yml. Das Update ersetzt diese Datei. Fügen Sie Ports, zusätzliche Netzwerke oder andere lokale Änderungen hinzu docker-compose.override.yml daneben; Compose führt es automatisch zusammen und Aktualisierungen lassen es in Ruhe.
  • Stellen Sie sicher, dass die aktuelle Bereitstellung fehlerfrei ist. Ein Update sollte kein bestehendes Datenbank-, Speicher- oder Routingproblem verbergen.

Überprüfen Sie das Update​

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

Die api Das Bild sollte die neue Version zeigen und migrate sollte als beendet mit Code 0 angezeigt werden. Überprüfen Sie auch die öffentlichen API- und MCP-Integritätsendpunkte, wenn Sie sie verfügbar machen. Melden Sie sich dann an, öffnen Sie ein bestücktes Forum und erstellen und löschen Sie eine temporäre Karte.

Wenn ein Update fehlschlägt​

  • Die Migration wurde nicht gestartet: Beheben Sie den Compose- oder Umgebungsfehler und führen Sie ihn erneut aus docker compose up -d.
  • Die Migration ist fehlgeschlagen: Bewahren Sie die Protokolle und die Sicherung auf und führen Sie sie nicht wiederholt aus, ohne den Fehler zu verstehen. Öffnen Sie ein Problem mit dem migrate Protokolle.
  • Sie müssen zurückgehen: Eine ältere Version kann nicht mit einer Datenbank ausgeführt werden, die von der neueren Version migriert wurde. Stoppen Sie Kanera (docker compose down), die Datenbank vor dem Update und die Uploads zusammen wiederherstellen, die vorherige Compose-Datei zurücksetzen (mv docker-compose.previous.yml docker-compose.yml) und laufen docker compose up -d.
  • Stellen Sie niemals ein Backup über eine laufende neuere Version wieder her. Testen Sie Ihren Wiederherstellungsvorgang auf einer separaten Datenbank oder einem separaten Host, bevor Sie sich darauf verlassen.

Hinweise zur Skalierung​

Die Standardbereitstellung verwendet mehrere App-API-Replikate und einen Worker.

  • API_REPLICAS Steuert die Anzahl der App-API-Prozesse. Standardmäßig ist 2.
  • PUBLIC_API_REPLICAS Steuert die Anzahl der öffentlichen API-Prozesse. Standardmäßig ist 1.
  • MCP_REPLICAS steuert die MCP-Prozessanzahl. Standardmäßig ist 1.
  • Behalten worker genau 1.
  • Valkey ist für Echtzeit-Fanout, Präsenz und gemeinsame Ratenbegrenzungen erforderlich.

Erhöhen Sie Replikate nur, wenn der Server über genügend CPU-, Arbeitsspeicher- und Datenbankverbindungskapazität verfügt. Wenn Sie erhöhen API_REPLICAS, Rezension PG_POOL_MAX und PostgreSQL max_connections.

Der einzelne Arbeiter ist bewusst. Es führt Planer, Benachrichtigungen und Webhook-Zustellung sowie Bereinigungsjobs aus, und eine zweite Kopie würde diese Arbeit duplizieren, anstatt sie zu teilen. Wenn die Bereitstellung ins Hintertreffen gerät, prüfen Sie die Kapazität der Datenbank und des ausgehenden Netzwerks, bevor Sie weitere Worker-Prozesse in Betracht ziehen.