Αναβάθμιση self-hosted live chat χωρίς να χαθεί ούτε μία συνομιλία

Το self-hosting του live chat του website σας είναι η σωστή επιλογή αν σας ενδιαφέρει ποιος κρατά τις συνομιλίες με τους πελάτες σας. Σημαίνει επίσης ότι οι αναβαθμίσεις είναι δικές σας. Το Chatwoot κινείται γρήγορα, και μια πλατφόρμα chat που μένει πολύ πίσω γίνεται έργο για να αναβαθμιστεί αντί για ρουτίνα. Αυτή είναι η μέθοδος που χρησιμοποιούμε για να κρατάμε ένα self-hosted Chatwoot ενημερωμένο χωρίς να χάνεται ούτε μία συνομιλία, και χωρίς ένα widget που φαίνεται εντάξει στην παρακολούθησή σας ενώ αποτυγχάνει για τους επισκέπτες σας.

Μάθετε τι αναβαθμίζετε

Μια τυπική εγκατάσταση Chatwoot σε containers έχει πέντε κινούμενα μέρη:

• το container web (η εφαρμογή Rails και το API),
• το container worker (Sidekiq, που στέλνει ειδοποιήσεις και τρέχει εργασίες στο παρασκήνιο),
• PostgreSQL (συνομιλίες, επαφές, μηνύματα, ρυθμίσεις),
• Redis (ουρές και ζωντανή κατάσταση),
• έναν reverse proxy όπως το nginx μπροστά, που τερματίζει το TLS και περνά την κίνηση WebSocket.

Στις πλατφόρμες μας αυτά τρέχουν ως Podman containers, που ξεκινούν από ένα systemd unit ώστε το stack να επανέρχεται με σειρά μετά από επανεκκίνηση. Γράψτε, πριν ξεκινήσετε, τα image tags κάθε container, την έκδοση του σχήματος της βάσης δεδομένων και την κατάσταση των πακέτων του λειτουργικού συστήματος. Θα τα χρειαστείτε για το rollback.

Βήμα πρώτο: πάρτε μια γραμμή αναφοράς για να συγκρίνετε

Πριν αγγίξετε οτιδήποτε, καταγράψτε τι κρατά η βάση δεδομένων:

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

Αποθηκεύστε το αποτέλεσμα με χρονοσήμανση. Μετά την αναβάθμιση και ξανά μετά από επανεκκίνηση, τρέξτε το ίδιο query. Συνομιλίες, χρήστες, inboxes και μηνύματα πρέπει να είναι ίδια. Οι επαφές μπορεί να αυξηθούν ελαφρά, επειδή συνεχίζουν να φτάνουν ζωντανοί επισκέπτες. Οτιδήποτε άλλο είναι λόγος να σταματήσετε.

Βήμα δεύτερο: ηρεμήστε το σύστημα, μετά κάντε dump

Ένα dump που παίρνετε ενώ οι workers γράφουν είναι dump ενός κινούμενου στόχου. Σταματήστε τα containers web και worker, αφήστε τη βάση δεδομένων να τρέχει, και μετά κάντε dump:

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

Αντιγράψτε δίπλα του το αρχείο περιβάλλοντος, το αρχείο compose, τις ρυθμίσεις του proxy και το systemd unit, σε έναν κατάλογο με ημερομηνία. Κρατήστε τα προηγούμενα images των containers κατεβασμένα. Μην αφήσετε μια εργασία καθαρισμού να τα αφαιρέσει μέχρι η νέα έκδοση να έχει τρέξει για λίγο.

Βήμα τρίτο: γράψτε το rollback πριν το χρειαστείτε

Γράψτε τις ακριβείς εντολές για να επιστρέψετε στην προηγούμενη έκδοση, τώρα, όσο είστε ήρεμοι. Για το Chatwoot το rollback είναι: σταματάτε το stack, επαναφέρετε τα προηγούμενα αρχεία compose και περιβάλλοντος, ξεκινάτε μόνο τη βάση δεδομένων και το Redis, διαγράφετε και ξαναδημιουργείτε τη βάση δεδομένων, επαναφέρετε το dump, ξεκινάτε το stack, και επιβεβαιώνετε ότι το API αναφέρει την παλιά έκδοση.

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

Σημειώστε ότι η βάση δεδομένων πρέπει να γυρίσει πίσω μαζί με την εφαρμογή. Το Chatwoot τρέχει migrations σχήματος στην αναβάθμιση, και μια παλιά εφαρμογή πάνω σε migrated σχήμα δεν είναι υποστηριζόμενη κατάσταση.

Βήμα τέταρτο: αναβαθμίστε με μία συνειδητή κίνηση

Αλλάξτε το image tag για web και worker μαζί, κάντε pull, και τρέξτε το βήμα προετοιμασίας της βάσης δεδομένων πριν η εφαρμογή αρχίσει να εξυπηρετεί:

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

Αν είστε αρκετές εκδόσεις πίσω, διαβάστε τις σημειώσεις έκδοσης για κάθε έκδοση που περνάτε, όχι μόνο για τη νεότερη.

Αυτή είναι επίσης καλή στιγμή να φέρετε τα πακέτα του λειτουργικού συστήματος του host στην τρέχουσα κατάσταση και να επανεκκινήσετε, ώστε η πλατφόρμα και το θεμέλιό της να μένουν σε βήμα. Κάντε το στο ίδιο παράθυρο, αφού η εφαρμογή επαληθευτεί μία φορά, ώστε να ξέρετε ποια αλλαγή προκάλεσε τι.

Βήμα πέμπτο: ελέγξτε από την πλευρά του επισκέπτη

Η περισσότερη παρακολούθηση ελέγχει ότι ένα URL επιστρέφει επιτυχή κατάσταση. Ένα widget chat μπορεί να το περάσει αυτό και πάλι να είναι χαλασμένο για κάθε επισκέπτη. Ελέγξτε αυτά που κάνει πραγματικά ένας browser:

1. Το API απαντά και αναφέρει τη νέα έκδοση, με την ουρά και τις υπηρεσίες δεδομένων του υγιείς: curl -s https://chat.example.com/api.
2. Η σελίδα login και η σύνδεση super admin επιστρέφουν επιτυχώς.
3. Το script του widget φορτώνει: curl -sI https://chat.example.com/packs/js/sdk.js.
4. Η σελίδα του widget φορτώνει με πραγματικό user agent browser. Οι πρόσφατες εκδόσεις Chatwoot παραλείπουν αιτήματα που μοιάζουν με crawlers, οπότε ένα σκέτο curl μπορεί να πάρει κενή απάντηση που δεν είναι βλάβη. Δοκιμάστε με browser, ή στείλτε user agent browser.
5. Η ζωντανή σύνδεση αναβαθμίζεται: ένα αίτημα WebSocket στο /cable πρέπει να απαντά με 101 Switching Protocols. Αν ο proxy σας δεν περνά τα upgrade headers, το chat φαίνεται φορτωμένο αλλά τα μηνύματα δεν φτάνουν ποτέ σε πραγματικό χρόνο.
6. Τα συνημμένα και τα avatars φορτώνουν, που αποδεικνύει ότι το file storage είναι mounted και αναγνώσιμο.
7. Τα headers ενσωμάτωσης είναι ακόμα σωστά. Η οδηγία frame-ancestors του Content-Security-Policy πρέπει να εξακολουθεί να απαριθμεί τα websites που ενσωματώνουν το widget.

Μετά τρέξτε ξανά τις μετρήσεις εγγραφών, επανεκκινήστε, και τρέξτε τα πάντα άλλη μία φορά. Ένα stack που δουλεύει μόνο μέχρι την επόμενη επανεκκίνηση δεν έχει αναβαθμιστεί.

Μια λεπτομέρεια containers που γλιτώνει ώρες

Κοινόχρηστα volumes και SELinux. Αν δύο containers μοιράζονται ένα volume αποθήκευσης (τα containers web και worker συνήθως μοιράζονται το file storage για τα συνημμένα), κάντε το mount με το κοινόχρηστο label :z, όχι με το ιδιωτικό :Z. Το ιδιωτικό label εφαρμόζεται για ένα container τη φορά, και στο άλλο container απαγορεύεται τότε η πρόσβαση σε αρχεία που χρειάζεται, κάτι που εμφανίζεται ως σφάλματα server σε εικόνες και συνημμένα αντί ως προφανές πρόβλημα δικαιωμάτων. Κρατήστε το SELinux enforcing. Βάλτε σωστό label στο volume αντί γι' αυτό.

Μετά από αναβάθμιση, στείλτε μια δοκιμαστική ειδοποίηση και επιβεβαιώστε ότι φτάνει.

Τι να ελέγξετε στη δική σας πλατφόρμα chat

• Ξέρετε ποια έκδοση τρέχετε, και πόσο πίσω είναι;
• Έχετε dump από πριν από την τελευταία αναβάθμισή σας, και τα images που πάνε μαζί του;
• Είναι το rollback σας γραμμένο, ή μόνο στο κεφάλι κάποιου;
• Φορτώνει η παρακολούθησή σας το widget όπως ένας browser, μαζί με το WebSocket;
• Ταιριάζουν οι μετρήσεις εγγραφών σας πριν και μετά από κάθε αλλαγή;

Περάστε αυτή τη λίστα μία φορά και η επόμενη αναβάθμιση γίνεται μια βραδινή εργασία ρουτίνας αντί για ρίσκο.

CTA

Αν θέλετε το live chat σας να τρέχει έτσι, στο δικό σας instance, οι μηχανικοί μας μπορούν να βοηθήσουν. Μιλήστε με έναν μηχανικό

Related

Σχετικά: Managed live chat σε Chatwoot, στο δικό σας instance · Επικαιρότητα πλατφορμών και πειθαρχία αναβαθμίσεων