Problema extraño en Postgres DB con nueva instalación

Aquí hay uno que no logro resolver después de muchas instalaciones y migraciones impecables de Discourse.

Antecedentes:

Teníamos Discourse funcionando correctamente en un contenedor Docker y estábamos trabajando en algunos matices de la base de datos PostgreSQL.

El problema ocurrió cuando no quedamos satisfechos con los resultados de la regeneración de publicaciones crudas, y por lo tanto, nada funcionaba según lo planeado, así que decidimos eliminar la base de datos PostgreSQL y volver a crearla; pero la aplicación seguía dando varios errores de permisos, etc.

Entonces, decidimos “ir a lo duro” y optamos por destruirlo en un estilo de “qué más da”; y simplemente entramos en PostgreSQL (sabiendo que esto no saldría bien, pero queriendo intentarlo) y eliminamos todos los temas y publicaciones de la base de datos (DELETE FROM topics; DELETE FROM posts;). Esto funcionó en cierta medida; pero no quedamos satisfechos con los resultados (la experiencia terminó), así que decidimos reconstruir Discourse desde cero, moviendo el antiguo /var/discourse a un lado y obteniendo una versión fresca desde git para empezar de nuevo.

El problema

Cuando construimos totalmente nuevo desde una descarga de git, la construcción funcionó bien hasta el punto en que fuimos al sitio para crear el inicio de sesión de administrador.

Cuando fuimos al inicio de sesión de administrador para una instalación nueva, ¡era el sitio antiguo que habíamos destruido! Esto fue una sorpresa.

Así que decidimos entrar en esta nueva aplicación e intentar eliminar todas las tablas de Discourse de la base de datos, lo cual hicimos; pero, sorpresa, cuando volvimos a construir la aplicación, no era un sitio nuevo, sino el mismo sitio roto mencionado anteriormente.

Entonces, eliminamos todos los directorios /var/*discourse*; y eliminamos todas las imágenes de Docker, pensando que esto sería totalmente limpio, y comenzamos de nuevo descargando desde git a /var/discourse y construyendo desde lo que pensábamos que era totalmente desde cero; pero sorpresa… el sitio antiguo sigue ahí.

Pensando: “¿cómo es posible esto”…??

Hicimos un ps aux | grep postgres fuera del contenedor Docker y notamos que PostgreSQL existía fuera del contenedor (lo cual fue una sorpresa, ya que erróneamente pensábamos que la instalación de Discourse en Docker estaba todo dentro del contenedor); y entonces intentamos encontrar dónde limpiar, pero sin éxito.

Buscamos hasta que los enlaces de Google se volvieron morados, y probamos tanto… pero no podemos obtener una instalación limpia de Discourse.

Pensando que nos estaba faltando algo, nos pusimos en un servidor nuevo, nunca con Discourse instalado, e instalamos Discourse desde cero, y funcionó impecablemente como de costumbre (otro servidor).

La pregunta

Mi pregunta es, supongo… cuando una instalación se ha salido totalmente de los cauces (por un medio u otro), ¿cómo hacemos para devolver el servidor, incluida PostgreSQL, al punto cero para que este problema desaparezca y podamos tener una instalación completamente nueva y fresca?

Disculpen por una publicación tan larga, cuando La pregunta podría haber sido suficiente para obtener ayuda.

Gracias.

En lugar de eliminar o vaciar las tablas, simplemente elimina la base de datos.

Gracias. Lo probaré y publicaré los resultados.

Intenté eliminar la base de datos, pero sigo recibiendo este error de permisos:

/var/discourse# ./launcher enter neo
/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Escribe "help" para obtener ayuda.
postgres=# drop database discourse;
ERROR: la base de datos "discourse" está siendo accedida por otros usuarios
DETALLE: Hay 3 otras sesiones utilizando la base de datos.

¿Alguna pista?

Mi mejor suposición es que no eliminaste el contenedor Docker en ejecución, pero afirmas que eliminaste las imágenes. Y parece que deberías haber recibido alguna otra indicación.

¿O estás usando un PostgreSQL externo en lugar del que está en el contenedor?

Por lo general, eliminar /var/discourse/shared y realizar una reconstrucción soluciona el problema.

Gracias.

Acabamos de finalizar todas las sesiones previas de la base de datos discourse, lo que nos permitió eliminar la base de datos discourse.

Ahora estamos ejecutando nuevamente el proceso de ./launcher rebuild app. Publicaré los resultados más adelante.

./launch rebuild app no funcionó; así que hicimos lo siguiente:

Luego:

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…


Aún no funciona después de una reconstrucción y un lanzamiento sin errores.

Así que lo intentamos de nuevo, desactivando la opción LETSENCRYPT:

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

Y sigue construyendo la instancia anterior (destruida hace horas), porque en esa instancia instalamos varios temas y aún siguen presentes en esta compilación, incluso después de haber `dropped` la base de datos `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


¿Cómo es posible que, después de eliminar toda la base de datos `discourse`, purgar todas las imágenes y contenedores de Docker, borrar `rm -rf /var/discourse` y reconstruir desde cero, sigamos viendo todos los temas instalados de la compilación de hace muchas horas que intentamos destruir por completo?

No tiene sentido en una instalación nueva.

Bueno, volvimos a empezar y comentamos las plantillas de LETSENCRYPT y la opción de correo electrónico, y logramos que se reconstruyera correctamente y apareciera la página de inicio de sesión de celebración del administrador.

¡Progreso!

Ahora editaremos app.yml e intentaremos activar SSL nuevamente.

Bueno. Eso es interesante…

Si reconstruyo la aplicación con SSL (LETS ENCRYPT) habilitado, obtengo dos sitios diferentes…

  • HTTP: Nuevo sitio como se esperaba
  • HTTPS: Sitio antiguo roto

Hmmmm. ¡Esto es realmente desconcertante!

¿Qué muestra

 docker ps

?

Antes de cada compilación, eliminamos todas las imágenes antiguas de Docker, etc., de la siguiente manera:

docker system prune -a

Por lo tanto, no se trata de un problema con una imagen de Docker.

Creemos que el problema está relacionado con el certificado SSL de LETSENCRYPT; porque cuando cambiamos el subdominio y generamos un nuevo certificado SSL en el proceso de compilación en la misma dirección IP del servidor, funciona como debería; pero cuando volvemos al subdominio original, el problema persiste.

Por lo tanto, hemos dejado de usar el subdominio problemático por ahora (de todos modos era solo un dominio de pruebas); y hemos seguido adelante.

Gracias por las ideas.

Cuídense.

Pero eso solo elimina las imágenes no utilizadas. ¿Estás seguro de que no hay contenedores en ejecución?

Suena como si tuvieras más de un contenedor: ¿hay algo más que un app.yml en tu carpeta de contenedores?

docker ps muestra solo un contenedor en ejecución y solo hay un archivo app.yml en /var/discourse/containers

¡Gracias por todas las buenas ideas, de todos modos!

Muy agradecido.