Actualizar un live chat self-hosted sin perder una sola conversación

Alojar usted mismo el live chat de su sitio web es la decisión correcta si le importa quién guarda las conversaciones con sus clientes. También significa que las actualizaciones son suyas. Chatwoot avanza deprisa, y una plataforma de chat que se queda muy atrás se convierte en un proyecto que actualizar en lugar de una rutina. Este es el método que usamos para mantener al día un Chatwoot self-hosted sin perder una sola conversación, y sin un widget que parece correcto a su monitorización mientras falla para sus visitantes.

Sepa qué está actualizando

Un despliegue típico de Chatwoot en contenedores tiene cinco piezas móviles:

• el contenedor web (la aplicación Rails y la API),
• el contenedor worker (Sidekiq, que envía notificaciones y ejecuta tareas en segundo plano),
• PostgreSQL (conversaciones, contactos, mensajes, configuración),
• Redis (colas y estado en vivo),
• un reverse proxy como nginx por delante, terminando TLS y pasando el tráfico WebSocket.

En nuestras plataformas estos funcionan como contenedores Podman, arrancados por una unidad systemd para que la pila vuelva en orden tras un reinicio. Anote, antes de empezar, las etiquetas de imagen de cada contenedor, la versión del esquema de la base de datos y el estado de los paquetes del sistema operativo. Los necesitará para el rollback.

Paso uno: tome una referencia con la que comparar

Antes de tocar nada, registre lo que contiene la base de datos:

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

Guarde la salida con una marca de tiempo. Tras la actualización y de nuevo tras un reinicio, ejecute la misma consulta. Conversaciones, usuarios, bandejas y mensajes deberían ser idénticos; los contactos pueden crecer ligeramente, porque siguen llegando visitantes en vivo. Cualquier otra cosa es motivo para detenerse.

Paso dos: deje en reposo, después vuelque

Un volcado tomado mientras los workers escriben es un volcado de un blanco en movimiento. Detenga los contenedores web y worker, deje la base de datos funcionando, y después vuelque:

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

Copie junto a él el fichero de entorno, el fichero compose, la configuración del proxy y la unidad systemd, en un directorio con fecha. Mantenga descargadas las imágenes de contenedor anteriores; no deje que una tarea de limpieza las elimine hasta que la nueva versión haya funcionado durante un tiempo.

Paso tres: escriba el rollback antes de necesitarlo

Escriba ahora, mientras está tranquilo, los comandos exactos para volver a la versión anterior. Para Chatwoot el rollback es: detener la pila, restaurar los ficheros compose y de entorno anteriores, arrancar solo la base de datos y Redis, eliminar y recrear la base de datos, restaurar el volcado, arrancar la pila, y confirmar que la API informa de la versión antigua.

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

Tenga en cuenta que la base de datos debe volver atrás junto con la aplicación. Chatwoot ejecuta migraciones de esquema al actualizar, y una aplicación antigua contra un esquema migrado no es un estado soportado.

Paso cuatro: actualice en un solo movimiento deliberado

Cambie la etiqueta de imagen de web y worker a la vez, descargue, y ejecute el paso de preparación de la base de datos antes de que la aplicación empiece a servir:

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

Si va varias versiones por detrás, lea las notas de cada versión que vaya a cruzar, no solo la más reciente.

Es también un buen momento para poner al día los paquetes del sistema operativo del host y reiniciar, para que la plataforma y su base se mantengan al mismo paso. Hágalo en la misma ventana, después de verificar la aplicación una vez, para saber qué cambio causó qué.

Paso cinco: compruebe desde el lado del visitante

La mayoría de la monitorización comprueba que una URL devuelve un estado correcto. Un widget de chat puede pasar eso y seguir roto para todos los visitantes. Compruebe las cosas que realmente hace un navegador:

• La API responde e informa de la nueva versión, con su cola y sus servicios de datos sanos: curl -s https://chat.example.com/api.
• La página de inicio de sesión y el acceso de superadministrador responden correctamente.
• El script del widget carga: curl -sI https://chat.example.com/packs/js/sdk.js.
• La página del widget carga con un user agent de navegador real. Las versiones recientes de Chatwoot omiten las peticiones que parecen de crawlers, así que un curl a secas puede recibir una respuesta vacía que no es un fallo. Pruebe con un navegador, o envíe un user agent de navegador.
• La conexión en vivo se actualiza: una petición WebSocket a /cable debería responder con 101 Switching Protocols. Si su proxy no pasa las cabeceras de upgrade, el chat parece cargado pero los mensajes nunca llegan en tiempo real.
• Los adjuntos y los avatares cargan, lo que demuestra que el storage de ficheros está montado y es legible.
• Las cabeceras de inserción siguen siendo correctas. La directiva frame-ancestors de Content-Security-Policy debe seguir enumerando los sitios web que insertan el widget.

Después ejecute de nuevo los recuentos de registros, reinicie, y ejecute todo una vez más. Una pila que solo funciona hasta el siguiente reinicio no se ha actualizado.

Un detalle de contenedores que ahorra horas

Volúmenes compartidos y SELinux. Si dos contenedores comparten un volumen de storage (los contenedores web y worker suelen compartir el storage de ficheros usado para los adjuntos), móntelo con la etiqueta compartida :z, no con la etiqueta privada :Z. Una etiqueta privada se aplica a un contenedor cada vez, y al otro contenedor se le niega entonces el acceso a ficheros que necesita, lo que aparece como errores de servidor en imágenes y adjuntos en lugar de como un problema evidente de permisos. Mantenga SELinux enforcing; etiquete el volumen correctamente en su lugar.

Tras una actualización, envíe una notificación de prueba y confirme que llega.

Qué comprobar en su propia plataforma de chat

• ¿Sabe qué versión ejecuta, y cuánto va por detrás?
• ¿Tiene un volcado de antes de su última actualización, y las imágenes que van con él?
• ¿Está su rollback escrito, o solo en la cabeza de alguien?
• ¿Carga su monitorización el widget como un navegador, incluido el WebSocket?
• ¿Coinciden sus recuentos de registros antes y después de cada cambio?

Recorra esa lista una vez y la siguiente actualización se convierte en una tarea rutinaria de una tarde en lugar de un riesgo.

CTA

Si quiere que su live chat se opere así, en su propia instancia, nuestros ingenieros pueden ayudarle. Hable con un ingeniero

Related

Relacionado: Managed live chat con Chatwoot, en su propia instancia · Plataformas al día y disciplina de actualización