Aggiornare una live chat self-hosted senza perdere una conversazione

Ospitare in proprio la live chat del vostro sito è la scelta giusta se vi importa di chi detiene le conversazioni con i vostri clienti. Significa anche che gli aggiornamenti sono vostri. Chatwoot si muove in fretta, e una piattaforma di chat rimasta molto indietro diventa un progetto da aggiornare invece di una routine. Questo è il metodo che usiamo per tenere aggiornato un Chatwoot self-hosted senza perdere una sola conversazione, e senza un widget che sembra a posto al vostro monitoraggio mentre fallisce per i vostri visitatori.

Sappiate cosa state aggiornando

Un tipico deployment di Chatwoot in container ha cinque parti mobili:

• il container web (l'applicazione Rails e l'API),
• il container worker (Sidekiq, che invia le notifiche ed esegue i job in background),
• PostgreSQL (conversazioni, contatti, messaggi, configurazione),
• Redis (code e stato live),
• un reverse proxy come nginx davanti, che termina il TLS e passa il traffico WebSocket.

Sulle nostre piattaforme girano come container Podman, avviati da una unit systemd così che lo stack torni su nell'ordine giusto dopo un riavvio. Scrivete, prima di cominciare, i tag delle immagini di ogni container, la versione dello schema del database e lo stato dei pacchetti del sistema operativo. Vi serviranno per il rollback.

Passo uno: prendete una baseline con cui confrontarvi

Prima di toccare qualunque cosa, registrate cosa contiene il database:

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

Salvate l'output con un timestamp. Dopo l'upgrade, e di nuovo dopo un riavvio, eseguite la stessa query. Conversazioni, utenti, inbox e messaggi devono essere identici; i contatti possono crescere leggermente, perché i visitatori live continuano ad arrivare. Qualunque altra cosa è un motivo per fermarsi.

Passo due: fermate, poi fate il dump

Un dump preso mentre i worker scrivono è il dump di un bersaglio in movimento. Fermate i container web e worker, lasciate il database in esecuzione, poi fate il dump:

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

Copiate accanto il file di environment, il file compose, la configurazione del proxy e la unit systemd, in una directory datata. Tenete scaricate le immagini container precedenti; non lasciate che un job di pulizia le rimuova finché la nuova versione non ha girato per un po'.

Passo tre: scrivete il rollback prima di averne bisogno

Scrivete i comandi esatti per tornare alla versione precedente, adesso, mentre siete tranquilli. Per Chatwoot il rollback è: fermare lo stack, ripristinare i file compose ed environment precedenti, avviare solo database e Redis, eliminare e ricreare il database, ripristinare il dump, avviare lo stack, e confermare che l'API riporta la vecchia versione.

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

Notate che il database deve tornare indietro insieme all'applicazione. Chatwoot esegue le migrazioni dello schema all'upgrade, e una vecchia applicazione su uno schema migrato non è uno stato supportato.

Passo quattro: aggiornate con una sola mossa deliberata

Cambiate il tag dell'immagine per web e worker insieme, fate il pull, ed eseguite il passo di preparazione del database prima che l'applicazione cominci a servire:

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

Se siete indietro di diverse release, leggete le note di rilascio di ogni release che attraversate, non solo dell'ultima.

È anche un buon momento per portare al corrente i pacchetti del sistema operativo dell'host e riavviare, così la piattaforma e la sua base restano al passo. Fatelo nella stessa finestra, dopo che l'applicazione è stata verificata una volta, così sapete quale modifica ha causato cosa.

Passo cinque: controllate dal lato del visitatore

La maggior parte dei monitoraggi controlla che un URL restituisca uno stato di successo. Un widget di chat può passare quel controllo ed essere comunque rotto per ogni visitatore. Controllate le cose che un browser fa davvero:

1. L'API risponde e riporta la nuova versione, con la coda e i servizi dati sani: curl -s https://chat.example.com/api.
2. La pagina di login e l'accesso super admin rispondono con successo.
3. Lo script del widget si carica: curl -sI https://chat.example.com/packs/js/sdk.js.
4. La pagina del widget si carica con un vero user agent da browser. Le release recenti di Chatwoot saltano le richieste che sembrano crawler, quindi un curl nudo può ricevere una risposta vuota che non è un guasto. Testate con un browser, o inviate uno user agent da browser.
5. La connessione live fa l'upgrade: una richiesta WebSocket a /cable deve rispondere con 101 Switching Protocols. Se il vostro proxy non passa gli header di upgrade, la chat sembra caricata ma i messaggi non arrivano mai in tempo reale.
6. Allegati e avatar si caricano, il che prova che lo storage dei file è montato e leggibile.
7. Gli header di embedding sono ancora corretti. La direttiva frame-ancestors della Content-Security-Policy deve elencare ancora i siti web che incorporano il widget.

Poi eseguite di nuovo i conteggi dei record, riavviate, ed eseguite tutto un'altra volta. Uno stack che funziona solo fino al prossimo riavvio non è stato aggiornato.

Un dettaglio sui container che fa risparmiare ore

Volumi condivisi e SELinux. Se due container condividono un volume di storage (i container web e worker condividono di solito lo storage dei file usato per gli allegati), montatelo con l'etichetta condivisa :z, non con l'etichetta privata :Z. Un'etichetta privata viene applicata per un container alla volta, e all'altro container viene poi negato l'accesso a file di cui ha bisogno, il che si manifesta come errori del server su immagini e allegati invece che come un evidente problema di permessi. Tenete SELinux in enforcing; etichettate correttamente il volume invece.

Dopo un upgrade, inviate una notifica di prova e confermate che arriva.

Cosa controllare sulla vostra piattaforma di chat

• Sapete quale release eseguite, e quanto è indietro?
• Avete un dump di prima del vostro ultimo upgrade, e le immagini che lo accompagnano?
• Il vostro rollback è scritto, o solo nella testa di qualcuno?
• Il vostro monitoraggio carica il widget come un browser, WebSocket compreso?
• I vostri conteggi dei record coincidono prima e dopo ogni modifica?

Percorrete quella lista una volta e il prossimo upgrade diventa un compito serale di routine invece di un rischio.

Se volete che la vostra live chat sia gestita così, sulla vostra istanza, i nostri ingegneri possono aiutarvi.

cta: Parla con un ingegnere

Related

• /what-we-do/platforms/live-chat/
• /what-we-do/operations/platform-currency/