Atualizar o live chat self-hosted sem perder uma única conversa

Fazer self-hosting do live chat do seu website é a escolha certa se lhe importa quem guarda as conversas com os seus clientes. Significa também que as atualizações são suas. O Chatwoot evolui depressa, e uma plataforma de chat que fica muito para trás torna-se um projeto para atualizar em vez de uma rotina. Este é o método que usamos para manter um Chatwoot self-hosted atualizado sem perder uma única conversa, e sem um widget que parece bem à sua monitorização enquanto falha para os seus visitantes.

Saiba o que está a atualizar

Uma instalação típica do Chatwoot em containers tem cinco peças em movimento:

• o container web (a aplicação Rails e a API),
• o container worker (Sidekiq, que envia notificações e executa tarefas em segundo plano),
• PostgreSQL (conversas, contactos, mensagens, configuração),
• Redis (filas e estado em tempo real),
• um reverse proxy como o nginx à frente, a terminar o TLS e a passar o tráfego WebSocket.

Nas nossas plataformas estes correm como containers Podman, iniciados por uma unit systemd para que a stack volte pela ordem certa depois de um reboot. Anote, antes de começar, as image tags de cada container, a versão do esquema da base de dados e o estado dos pacotes do sistema operativo. Vai precisar deles para o rollback.

Primeiro passo: registe uma referência com que possa comparar

Antes de tocar no que quer que seja, registe o que a base de dados contém:

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 o resultado com uma marca temporal. Depois da atualização e de novo depois de um reboot, execute a mesma query. Conversas, utilizadores, inboxes e mensagens devem ser idênticos. Os contactos podem crescer ligeiramente, porque continuam a chegar visitantes. Qualquer outra diferença é razão para parar.

Segundo passo: ponha o sistema em repouso e depois faça o dump

Um dump feito enquanto os workers escrevem é um dump de um alvo em movimento. Pare os containers web e worker, deixe a base de dados a correr e depois faça o dump:

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

Copie para junto dele o ficheiro de ambiente, o ficheiro compose, a configuração do proxy e a unit systemd, para um diretório com data. Mantenha as imagens anteriores dos containers descarregadas. Não deixe que uma tarefa de limpeza as remova até a nova versão ter corrido durante algum tempo.

Terceiro passo: escreva o rollback antes de precisar dele

Escreva os comandos exatos para regressar à versão anterior, agora, enquanto está calmo. Para o Chatwoot o rollback é: parar a stack, repor os ficheiros compose e de ambiente anteriores, iniciar apenas a base de dados e o Redis, apagar e recriar a base de dados, repor o dump, iniciar a stack e confirmar que a API reporta a versão antiga.

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

Note que a base de dados tem de voltar atrás juntamente com a aplicação. O Chatwoot executa migrações de esquema na atualização, e uma aplicação antiga sobre um esquema migrado não é um estado suportado.

Quarto passo: atualize num único movimento deliberado

Altere a image tag do web e do worker em conjunto, faça pull e execute o passo de preparação da base de dados antes de a aplicação começar a servir:

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

Se estiver várias versões atrasado, leia as notas de lançamento de cada versão que atravessa, não apenas da mais recente.

Este é também um bom momento para atualizar os pacotes do sistema operativo do host e reiniciar, para que a plataforma e a sua base se mantenham a par. Faça-o na mesma janela, depois de a aplicação ter sido verificada uma vez, para saber que alteração causou o quê.

Quinto passo: verifique do lado do visitante

A maior parte da monitorização verifica que um URL devolve um estado de sucesso. Um widget de chat pode passar nisso e continuar avariado para todos os visitantes. Verifique as coisas que um browser realmente faz:

1. A API responde e reporta a nova versão, com a fila e os serviços de dados saudáveis: curl -s https://chat.example.com/api.
2. A página de login e o início de sessão de super admin devolvem sucesso.
3. O script do widget carrega: curl -sI https://chat.example.com/packs/js/sdk.js.
4. A página do widget carrega com um user agent de browser real. As versões recentes do Chatwoot ignoram pedidos que parecem crawlers, por isso um curl simples pode receber uma resposta vazia que não é uma falha. Teste com um browser, ou envie um user agent de browser.
5. A ligação em tempo real faz upgrade: um pedido WebSocket a /cable deve responder com 101 Switching Protocols. Se o seu proxy não passar os upgrade headers, o chat parece carregado mas as mensagens nunca chegam em tempo real.
6. Os anexos e os avatares carregam, o que prova que o file storage está montado e legível.
7. Os headers de incorporação continuam corretos. A diretiva frame-ancestors do Content-Security-Policy tem de continuar a listar os websites que incorporam o widget.

Depois execute de novo as contagens de registos, reinicie e execute tudo mais uma vez. Uma stack que só funciona até ao próximo reboot não foi atualizada.

Um detalhe de containers que poupa horas

Volumes partilhados e SELinux. Se dois containers partilham um volume de armazenamento (os containers web e worker partilham habitualmente o file storage usado para os anexos), monte-o com a label partilhada :z, não com a label privada :Z. Uma label privada é aplicada para um container de cada vez, e ao outro container é então negado o acesso a ficheiros de que precisa, o que aparece como erros de servidor em imagens e anexos em vez de um problema óbvio de permissões. Mantenha o SELinux enforcing. Em vez disso, aplique a label correta ao volume.

Depois de uma atualização, envie uma notificação de teste e confirme que chega.

O que verificar na sua própria plataforma de chat

• Sabe que versão executa, e quão atrasada está?
• Tem um dump de antes da última atualização, e as imagens que lhe correspondem?
• O seu rollback está escrito, ou só na cabeça de alguém?
• A sua monitorização carrega o widget como um browser, incluindo o WebSocket?
• As suas contagens de registos coincidem antes e depois de cada alteração?

Percorra esta lista uma vez e a próxima atualização torna-se uma tarefa noturna de rotina em vez de um risco.

CTA

Se quer o seu live chat operado desta forma, na sua própria instância, os nossos engenheiros podem ajudar. Fale com um engenheiro

Related

Relacionados: Managed live chat em Chatwoot, na sua própria instância · Plataformas atuais e disciplina de atualizações