Problema estranho no Postgres DB com nova instalação

Aqui está um caso que não consigo resolver, mesmo após muitas instalações e migrações impecáveis do Discourse.

Contexto:

Tínhamos o Discourse funcionando bem em um container Docker e estávamos trabalhando em algumas nuances do banco de dados PostgreSQL.

O problema ocorreu quando não ficamos satisfeitos com os resultados da recriação de posts brutos, e, portanto, nada funcionava como planejado. Decidimos então descartar o banco de dados PostgreSQL e recriá-lo; mas o aplicativo continuava apresentando vários erros de permissão, etc.

Então, decidimos “ir ao extremo” e resolvemos destruir tudo no estilo “e daí?”; entramos no PostgreSQL (sabendo que isso não daria certo, mas querendo tentar) e excluímos todos os tópicos e posts do banco de dados (DELETE FROM topics; DELETE FROM posts;). Isso meio que funcionou; mas não ficamos satisfeitos com os resultados (experimento encerrado), então decidimos reconstruir o Discourse do zero, movendo o antigo /var/discourse para um local seguro e puxando do git para um novo começo.

O Problema

Quando construímos totalmente novo a partir de um git pull, a construção funcionou bem até o momento em que acessamos o site para criar o login de administrador.

Quando fomos ao login de administrador de uma nova instalação, era o site antigo que havíamos destruído! Isso foi uma surpresa.

Então, decidimos entrar nesse novo aplicativo e tentar excluir todas as tabelas do Discourse do banco de dados, o que fizemos; mas, surpresa: ao reconstruir o aplicativo novamente, não era um site novo, mas sim o mesmo site quebrado mencionado acima.

Então, excluímos todos os diretórios /var/*discourse*; removemos todas as imagens do Docker, achando que isso deixaria tudo totalmente limpo, e começamos de novo, puxando do git para /var/discourse e construindo do que pensávamos ser totalmente do zero; mas, surpresa… o site antigo ainda está lá.

Pensando: “como isso é possível”…??

Executamos ps aux | grep postgres fora do container Docker e notamos que o PostgreSQL existia fora do container (o que foi uma surpresa, pois erroneamente pensávamos que a instalação do Discourse via Docker fosse totalmente dentro do container); e então tentamos encontrar onde fazer a limpeza, mas sem sucesso.

Pesquisamos até os links do Google ficarem roxos, tentamos de tudo… mas não conseguimos uma instalação limpa do Discourse.

Pensando que estávamos perdendo algo, configuramos um novo servidor, nunca com o Discourse instalado, instalamos o Discourse do zero e funcionou perfeitamente, como de costume (outro servidor).

A Pergunta

Minha pergunta é, acho que… quando uma instalação sai completamente dos trilhos (de um jeito ou de outro), como fazemos para levar o servidor, incluindo o PostgreSQL, de volta ao zero absoluto, para que esse problema desapareça e possamos iniciar uma instalação completamente nova?

Desculpe pela postagem tão longa, quando talvez apenas A Pergunta fosse suficiente para obter ajuda.

Obrigado.

Em vez de remover ou esvaziar tabelas, basta descartar o banco de dados.

Obrigado. Vou tentar isso e retornar com os resultados.

Tentei remover o banco de dados, mas continuo recebendo esse erro de permissão:

/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Digite "help" para obter ajuda.
postgres=# drop database discourse;
ERRO: o banco de dados "discourse" está sendo acessado por outros usuários
DETALHE: Existem 3 outras sessões usando o banco de dados.

Alguma ideia?

Minha melhor suposição é que você não excluiu o container Docker em execução, mas afirma que excluiu as imagens. E parece que você teria recebido alguma outra indicação.

Ou você está usando um PostgreSQL externo, em vez do que está no container?

Geralmente, excluir /var/discourse/shared e fazer uma reconstrução resolve o problema.

Obrigado.

Acabamos de encerrar todas as sessões anteriores do banco de dados discourse, o que nos permitiu excluir o banco de dados discourse.

Agora estamos executando novamente o procedimento ./launcher rebuild app. Vou retornar com os resultados.

./launch rebuild app não funcionou; então, fizemos o seguinte:

Depois:

Building app

WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed

Please be patient

Unable to find image ‘discourse/base:2.0.20200220-2221’ locally
2.0.20200220-2221: Pulling from discourse/base
bc51dd8edc1b: Pulling fs layer
27ae5d171719: Pulling fs layer
bc51dd8edc1b: Download complete
bc51dd8edc1b: Pull complete
27ae5d171719: Verifying Checksum
27ae5d171719: Download complete
27ae5d171719: Pull complete
blah blah…
blah blah…
blah blah…


Ainda não está funcionando após uma reconstrução sem erros e um novo lançamento.

Então, tentamos novamente, desativando a opção LETSENCRYPT:

* Optional email address for Let's Encrypt warnings? (Enter 'OFF' to disable.) []: OFF

E ainda está construindo a instância anterior (destruída há horas), porque naquela instância instalamos vários temas, e eles ainda estão presentes nesta nova construção, mesmo após termos ```dropped``` o banco de dados ```discourse```:

Start compiling CSS: 2020-03-15 10:16:20 UTC
Compiling css for default 2020-03-15 10:16:20 UTC
precompile target: desktop Dark
precompile target: mobile Dark
precompile target: desktop_rtl Dark
precompile target: mobile_rtl Dark
precompile target: desktop_theme Dark
precompile target: mobile_theme Dark
precompile target: admin Dark
precompile target: desktop Light
precompile target: mobile Light
precompile target: desktop_rtl Light
precompile target: mobile_rtl Light
precompile target: desktop_theme Light
precompile target: mobile_theme Light
precompile target: admin Light
precompile target: desktop
precompile target: mobile
precompile target: desktop_rtl
precompile target: mobile_rtl
precompile target: desktop_theme
precompile target: mobile_theme
precompile target: admin
Done compiling CSS: 2020-03-15 10:16:27 UTC


Como é possível que, após deletar todo o banco de dados ```discourse```, purgar todas as imagens e containers do Docker, remover ```rm -rf /var/discourse``` e reconstruir do zero, ainda vejamos todos os temas instalados da construção de muitas horas atrás que estamos tentando destruir completamente?

Isso não faz sentido em uma instalação nova.

Bem, começamos tudo de novo, comentamos os modelos do LETSENCRYPT e a opção de e-mail, e conseguimos reconstruir corretamente, obtendo a página de login do administrador de celebração.

Progresso!

Agora vamos editar o app.yml e tentar ativar o SSL novamente.

Bem. Isso é interessante…

Se eu reconstruir o aplicativo com SSL (LETS ENCRYPT) habilitado, tenho dois sites diferentes…

  • HTTP: Novo site, como esperado
  • HTTPS: Site antigo quebrado

Hmmmm. Isso é realmente intrigante!

O que o comando

 docker ps

mostra?

Antes de cada build, limpamos todas as imagens Docker antigas, etc., da seguinte forma:

docker system prune -a

Portanto, não se trata de um problema com a imagem do Docker.

Acreditamos que o problema está relacionado ao certificado SSL do LETSENCRYPT; pois quando alteramos o subdomínio e geramos um novo certificado SSL no processo de build no mesmo IP do servidor, tudo funcionou como deveria; mas ao retornar ao subdomínio original, o problema persiste.

Assim, deixamos de usar o subdomínio problemático por enquanto (era apenas um domínio de staging, de qualquer forma) e seguimos em frente.

Obrigado pelas sugestões.

Fiquem seguros.

Mas isso exclui apenas imagens não utilizadas. Tem certeza de que não há containers em execução?

Parece que você tem mais de um container — há mais de um arquivo app.yml na sua pasta de containers?

docker ps mostra apenas um contêiner em execução e há apenas um arquivo app.yml em /var/discourse/containers

Obrigado por todas as boas ideias, de qualquer forma!

Muito apreciado.