Self-hosted Live-Chat aktualisieren, ohne eine Unterhaltung zu verlieren

Den Live-Chat Ihrer Website selbst zu hosten ist die richtige Entscheidung, wenn Ihnen wichtig ist, wer Ihre Kundengespräche in der Hand hat. Es bedeutet auch, dass die Upgrades Ihre Sache sind. Chatwoot entwickelt sich schnell, und eine Chat-Plattform, die weit zurückfällt, wird zu einem Projekt statt zu einer Routine. Dies ist die Methode, mit der wir ein self-hosted Chatwoot aktuell halten, ohne eine einzige Unterhaltung zu verlieren, und ohne ein Widget, das für Ihr Monitoring in Ordnung aussieht, während es für Ihre Besucher ausfällt.

Wissen, was Sie aktualisieren

Eine typische Container-Installation von Chatwoot hat fünf bewegliche Teile:

• den web-Container (die Rails-Anwendung und das API),
• den worker-Container (Sidekiq, das Benachrichtigungen versendet und Hintergrundjobs ausführt),
• PostgreSQL (Unterhaltungen, Kontakte, Nachrichten, Konfiguration),
• Redis (Queues und Live-Zustand),
• einen Reverse Proxy wie nginx davor, der TLS terminiert und WebSocket-Traffic durchreicht.

Auf unseren Plattformen laufen diese als Podman-Container, gestartet von einem systemd-Unit, damit der Stack nach einem Neustart in der richtigen Reihenfolge zurückkommt. Notieren Sie, bevor Sie beginnen, die Image-Tags jedes Containers, die Schemaversion der Datenbank und den Paketstand des Betriebssystems. Sie werden sie für das Rollback brauchen.

Schritt eins: eine Referenz erfassen, mit der Sie vergleichen können

Bevor Sie irgendetwas anfassen, halten Sie fest, was die Datenbank enthält:

podman exec chatwoot-postgres psql -U chatwoot -d chatwoot_production -At -c "
  select 'conversations', count(*) from conversations union all
  select 'contacts', count(*) from contacts union all
  select 'users', count(*) from users union all
  select 'inboxes', count(*) from inboxes union all
  select 'messages', count(*) from messages;"

Speichern Sie die Ausgabe mit Zeitstempel. Nach dem Upgrade und noch einmal nach einem Neustart führen Sie dieselbe Abfrage aus. Unterhaltungen, Benutzer, Inboxes und Nachrichten sollten identisch sein. Kontakte dürfen leicht wachsen, weil weiterhin Besucher eintreffen. Alles andere ist ein Grund anzuhalten.

Schritt zwei: stilllegen, dann dumpen

Ein Dump, der genommen wird, während Worker schreiben, ist ein Dump eines bewegten Ziels. Stoppen Sie die Container web und worker, lassen Sie die Datenbank laufen, und dumpen Sie dann:

podman stop chatwoot-web chatwoot-worker
podman exec chatwoot-postgres pg_dump -U chatwoot -Fc chatwoot_production > chatwoot_production.dump

Kopieren Sie daneben die Umgebungsdatei, die Compose-Datei, die Proxy-Konfiguration und das systemd-Unit in ein datiertes Verzeichnis. Behalten Sie die vorherigen Container-Images lokal. Lassen Sie keinen Aufräumjob sie entfernen, bevor die neue Version eine Weile gelaufen ist.

Schritt drei: das Rollback schreiben, bevor Sie es brauchen

Schreiben Sie die genauen Befehle für die Rückkehr zur vorherigen Version auf, jetzt, solange Sie ruhig sind. Für Chatwoot lautet das Rollback: den Stack stoppen, die vorherigen Compose- und Umgebungsdateien wiederherstellen, nur Datenbank und Redis starten, die Datenbank löschen und neu anlegen, den Dump wiederherstellen, den Stack starten und bestätigen, dass das API die alte Version meldet.

podman exec chatwoot-postgres dropdb -U chatwoot chatwoot_production
podman exec chatwoot-postgres createdb -U chatwoot chatwoot_production
podman exec -i chatwoot-postgres pg_restore -U chatwoot -d chatwoot_production --no-owner --no-privileges < chatwoot_production.dump

Beachten Sie, dass die Datenbank zusammen mit der Anwendung zurückgehen muss. Chatwoot führt beim Upgrade Schema-Migrationen aus, und eine alte Anwendung auf einem migrierten Schema ist kein unterstützter Zustand.

Schritt vier: in einem bewussten Zug aktualisieren

Ändern Sie das Image-Tag für web und worker gemeinsam, pullen Sie, und führen Sie den Vorbereitungsschritt der Datenbank aus, bevor die Anwendung anfängt zu bedienen:

podman-compose pull
podman-compose run --rm web bundle exec rails db:chatwoot_prepare
podman-compose up -d

Wenn Sie mehrere Releases zurückliegen, lesen Sie die Release Notes jedes Releases, das Sie überspringen, nicht nur die des neuesten.

Das ist auch ein guter Moment, die Betriebssystempakete des Hosts auf den aktuellen Stand zu bringen und neu zu starten, damit Plattform und Fundament im Gleichschritt bleiben. Tun Sie es im selben Fenster, nachdem die Anwendung einmal verifiziert wurde, damit Sie wissen, welche Änderung was verursacht hat.

Schritt fünf: aus Sicht des Besuchers prüfen

Das meiste Monitoring prüft, ob eine URL einen erfolgreichen Status zurückgibt. Ein Chat-Widget kann das bestehen und trotzdem für jeden Besucher kaputt sein. Prüfen Sie das, was ein Browser tatsächlich tut:

1. Das API antwortet und meldet die neue Version, mit gesunder Queue und gesunden Datendiensten: curl -s https://chat.example.com/api.
2. Die Login-Seite und die Super-Admin-Anmeldung liefern erfolgreich aus.
3. Das Widget-Skript lädt: curl -sI https://chat.example.com/packs/js/sdk.js.
4. Die Widget-Seite lädt mit einem echten Browser-User-Agent. Neuere Chatwoot-Releases überspringen Anfragen, die nach Crawlern aussehen, sodass ein nacktes curl eine leere Antwort bekommen kann, die kein Fehler ist. Testen Sie mit einem Browser, oder senden Sie einen Browser-User-Agent.
5. Die Live-Verbindung wird hochgestuft: Eine WebSocket-Anfrage an /cable sollte mit 101 Switching Protocols antworten. Wenn Ihr Proxy die Upgrade-Header nicht durchreicht, sieht der Chat geladen aus, aber Nachrichten kommen nie in Echtzeit an.
6. Anhänge und Avatare laden, was beweist, dass der Dateispeicher eingebunden und lesbar ist.
7. Die Einbettungs-Header stimmen noch. Die frame-ancestors-Direktive der Content-Security-Policy muss weiterhin die Websites auflisten, die das Widget einbetten.

Dann führen Sie die Datensatzzählungen erneut aus, starten neu und prüfen alles noch einmal. Ein Stack, der nur bis zum nächsten Neustart funktioniert, ist nicht aktualisiert worden.

Ein Container-Detail, das Stunden spart

Geteilte Volumes und SELinux. Wenn zwei Container sich ein Storage-Volume teilen (die Container web und worker teilen sich üblicherweise den Dateispeicher für Anhänge), binden Sie es mit dem geteilten Label :z ein, nicht mit dem privaten Label :Z. Ein privates Label wird jeweils für einen Container gesetzt, und dem anderen Container wird dann der Zugriff auf Dateien verweigert, die er braucht, was sich als Serverfehler bei Bildern und Anhängen zeigt statt als offensichtliches Berechtigungsproblem. Lassen Sie SELinux auf enforcing. Setzen Sie stattdessen das richtige Label auf das Volume.

Senden Sie nach einem Upgrade eine Testbenachrichtigung und bestätigen Sie, dass sie ankommt.

Was Sie auf Ihrer eigenen Chat-Plattform prüfen sollten

• Wissen Sie, welches Release Sie betreiben, und wie weit es zurückliegt?
• Haben Sie einen Dump von vor Ihrem letzten Upgrade, und die dazu passenden Images?
• Ist Ihr Rollback aufgeschrieben, oder nur in jemandes Kopf?
• Lädt Ihr Monitoring das Widget wie ein Browser, einschließlich des WebSockets?
• Stimmen Ihre Datensatzzählungen vor und nach jeder Änderung überein?

Gehen Sie diese Liste einmal durch, und das nächste Upgrade wird eine abendliche Routineaufgabe statt eines Risikos.

CTA

Wenn Sie möchten, dass Ihr Live-Chat so betrieben wird, auf Ihrer eigenen Instanz, können unsere Ingenieure helfen. Mit einem Ingenieur sprechen

Related

Verwandt: Managed Live-Chat auf Chatwoot, Ihre eigene Instanz · Aktuelle Plattformen und Upgrade-Disziplin