Mettre à niveau un live chat auto-hébergé sans perdre une seule conversation

Auto-héberger le live chat de votre site web est le bon choix si vous tenez à savoir qui détient les conversations avec vos clients. Cela signifie aussi que les mises à niveau vous appartiennent. Chatwoot évolue vite, et une plateforme de chat qui prend beaucoup de retard devient un projet à mettre à niveau au lieu d'une routine. Voici la méthode que nous utilisons pour garder un Chatwoot auto-hébergé à jour sans perdre une seule conversation, et sans un widget qui paraît en ordre à votre supervision pendant qu'il échoue pour vos visiteurs.

Sachez ce que vous mettez à niveau

Un déploiement typique de Chatwoot en conteneurs a cinq pièces mobiles :

• le conteneur web (l'application Rails et l'API),
• le conteneur worker (Sidekiq, qui envoie les notifications et exécute les tâches en arrière-plan),
• PostgreSQL (conversations, contacts, messages, configuration),
• Redis (files d'attente et état en direct),
• un reverse proxy comme nginx devant, qui termine le TLS et fait passer le trafic WebSocket.

Sur nos plateformes, ils tournent comme conteneurs Podman, démarrés par une unité systemd pour que la stack revienne dans l'ordre après un redémarrage. Notez, avant de commencer, les tags d'image de chaque conteneur, la version du schéma de la base de données et l'état des paquets du système d'exploitation. Vous en aurez besoin pour le rollback.

Étape un : prenez une référence à laquelle comparer

Avant de toucher à quoi que ce soit, enregistrez ce que contient la base de données :

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;"

Sauvegardez le résultat avec un horodatage. Après la mise à niveau et de nouveau après un redémarrage, exécutez la même requête. Conversations, utilisateurs, inboxes et messages doivent être identiques. Les contacts peuvent augmenter légèrement, parce que des visiteurs continuent d'arriver. Tout le reste est une raison de s'arrêter.

Étape deux : mettez le système au repos, puis faites le dump

Un dump pris pendant que les workers écrivent est le dump d'une cible mouvante. Arrêtez les conteneurs web et worker, laissez la base de données tourner, puis faites le dump :

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

Copiez à côté le fichier d'environnement, le fichier compose, la configuration du proxy et l'unité systemd, dans un répertoire daté. Gardez les images de conteneurs précédentes téléchargées. Ne laissez pas une tâche de nettoyage les supprimer tant que la nouvelle version n'a pas tourné un moment.

Étape trois : écrivez le rollback avant d'en avoir besoin

Écrivez les commandes exactes pour revenir à la version précédente, maintenant, pendant que vous êtes calme. Pour Chatwoot, le rollback est : arrêter la stack, restaurer les fichiers compose et d'environnement précédents, démarrer seulement la base de données et Redis, supprimer et recréer la base de données, restaurer le dump, démarrer la stack, et confirmer que l'API rapporte l'ancienne version.

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

Notez que la base de données doit revenir en arrière avec l'application. Chatwoot exécute des migrations de schéma à la mise à niveau, et une ancienne application sur un schéma migré n'est pas un état pris en charge.

Étape quatre : mettez à niveau en un seul geste délibéré

Changez le tag d'image pour web et worker ensemble, faites le pull, et exécutez l'étape de préparation de la base de données avant que l'application ne commence à servir :

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

Si vous avez plusieurs versions de retard, lisez les notes de version de chaque version que vous franchissez, pas seulement de la plus récente.

C'est aussi le bon moment pour mettre à jour les paquets du système d'exploitation de l'hôte et redémarrer, pour que la plateforme et sa fondation restent au même pas. Faites-le dans la même fenêtre, après une première vérification de l'application, pour savoir quel changement a causé quoi.

Étape cinq : vérifiez du côté du visiteur

La plupart des supervisions vérifient qu'une URL renvoie un statut de succès. Un widget de chat peut passer ce test et rester cassé pour chaque visiteur. Vérifiez ce qu'un navigateur fait réellement :

1. L'API répond et rapporte la nouvelle version, avec sa file d'attente et ses services de données en bonne santé : curl -s https://chat.example.com/api.
2. La page de connexion et la connexion super admin aboutissent.
3. Le script du widget se charge : curl -sI https://chat.example.com/packs/js/sdk.js.
4. La page du widget se charge avec un vrai user agent de navigateur. Les versions récentes de Chatwoot ignorent les requêtes qui ressemblent à des crawlers, donc un simple curl peut recevoir une réponse vide qui n'est pas une panne. Testez avec un navigateur, ou envoyez un user agent de navigateur.
5. La connexion en direct s'établit : une requête WebSocket vers /cable doit répondre 101 Switching Protocols. Si votre proxy ne transmet pas les en-têtes d'upgrade, le chat paraît chargé mais les messages n'arrivent jamais en temps réel.
6. Les pièces jointes et les avatars se chargent, ce qui prouve que le stockage de fichiers est monté et lisible.
7. Les en-têtes d'intégration sont toujours corrects. La directive frame-ancestors de Content-Security-Policy doit toujours lister les sites web qui intègrent le widget.

Relancez ensuite les comptages d'enregistrements, redémarrez, et refaites tout une fois de plus. Une stack qui ne fonctionne que jusqu'au prochain redémarrage n'a pas été mise à niveau.

Un détail de conteneurs qui fait gagner des heures

Volumes partagés et SELinux. Si deux conteneurs partagent un volume de stockage (les conteneurs web et worker partagent couramment le stockage de fichiers utilisé pour les pièces jointes), montez-le avec le label partagé :z, pas le label privé :Z. Un label privé s'applique à un conteneur à la fois, et l'autre conteneur se voit alors refuser l'accès à des fichiers dont il a besoin, ce qui apparaît comme des erreurs serveur sur les images et les pièces jointes plutôt que comme un problème de permissions évident. Gardez SELinux en mode enforcing. Étiquetez correctement le volume à la place.

Après une mise à niveau, envoyez une notification de test et confirmez qu'elle arrive.

Ce qu'il faut vérifier sur votre propre plateforme de chat

• Savez-vous quelle version vous exploitez, et quel est son retard ?
• Avez-vous un dump d'avant votre dernière mise à niveau, et les images qui vont avec ?
• Votre rollback est-il écrit, ou seulement dans la tête de quelqu'un ?
• Votre supervision charge-t-elle le widget comme un navigateur, WebSocket compris ?
• Vos comptages d'enregistrements concordent-ils avant et après chaque changement ?

Parcourez cette liste une fois et la prochaine mise à niveau devient une tâche de routine en soirée au lieu d'un risque.

CTA

Si vous voulez que votre live chat soit exploité ainsi, sur votre propre instance, nos ingénieurs peuvent vous aider. Parler à un ingénieur

Related

Sur le même sujet : Managed live chat sur Chatwoot, sur votre propre instance · Plateformes à jour et discipline de mise à niveau