Странная проблема с Postgres DB при новой установке

Вот один случай, который я не могу решить, несмотря на множество безупречных установок и миграций Discourse.

Предыстория:

Discourse работал стабильно в контейнере Docker, и мы разбирались с некоторыми нюансами базы данных PostgreSQL.

Проблема возникла, когда нас не устроили результаты пересборки сырых постов (re-baking raw posts), и ничего не работало по плану. Тогда мы решили удалить базу данных PostgreSQL и создать её заново, но приложение продолжало выдавать различные ошибки прав доступа и т. д.

Затем мы решили «идти до конца» и в стиле «а чёрт с ним» уничтожить всё; мы зашли в PostgreSQL (зная, что это может плохо закончиться, но желая попробовать) и удалили все темы и посты из БД (DELETE FROM topics; DELETE FROM posts;). Это отчасти сработало, но нас не устроили результаты (эксперимент окончен), поэтому мы решили пересобрать Discourse с нуля, переместив старый каталог /var/discourse в сторону и загрузив свежую версию из git.

Проблема

Когда мы собирали совершенно новый проект из git, всё работало нормально (процесс сборки), вплоть до момента, когда мы перешли на сайт для создания входа администратора.

При попытке войти в админку для новой установки мы увидели старый сайт, который мы уничтожили! Это стало сюрпризом.

Тогда мы решили зайти в это новое приложение и попробовать удалить все таблицы Discourse из БД, что мы и сделали; но, к нашему удивлению, при повторной сборке приложения это оказался не новый сайт, а тот же сломанный сайт, о котором речь выше.

Поэтому мы удалили все каталоги /var/*discourse* и все образы Docker, полагая, что это будет полностью чисто, и начали заново: загрузили код из git в /var/discourse и собрали его, думая, что начинаем с абсолютного нуля; но, сюрприз… старый сайт всё ещё там.

Думая: «Как это возможно»…??

Мы выполнили команду ps aux | grep postgres вне контейнера Docker и обнаружили, что PostgreSQL работает вне контейнера (что стало сюрпризом, так как мы ошибочно полагали, что установка Discourse через Docker происходит полностью внутри контейнера); затем мы попытались найти, где можно провести очистку, но безуспешно.

Мы искали так долго, что ссылки в Google уже стали фиолетовыми, перепробовали многое… но нам не удаётся получить чистую установку Discourse.

Поскольку, возможно, мы что-то упустили, мы взяли новый сервер, на котором Discourse никогда не устанавливался, установили Discourse с нуля, и всё заработало безупречно, как обычно (на другом сервере).

Вопрос

Мой вопрос, думаю, таков: когда установка полностью пошла наперекосяк (любыми путями), как вернуть сервер, включая PostgreSQL, в исходное состояние («ground zero»), чтобы эта проблема исчезла и мы могли запустить совершенно новую чистую установку?

Извините за такой длинный пост, когда, возможно, одного Вопроса хватило бы для получения помощи.

Спасибо.

Вместо удаления или очистки таблиц просто удалите базу данных.

Спасибо. Попробую и напишу о результатах.

Попытался удалить базу данных, но постоянно получаю ошибку прав доступа:

/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Введите "help" для справки.
postgres=# drop database discourse;
ERROR: база данных "discourse" используется другими пользователями
DETAIL: 3 других сессии используют базу данных.

Есть какие-то идеи?

Мое предположение: вы не удалили запущенный контейнер Docker, хотя утверждаете, что удалили образы. И, похоже, вы получили бы какое-то другое уведомление.

Или вы используете внешний PostgreSQL, а не тот, что внутри контейнера?

Обычно удаление /var/discourse/shared и повторная сборка решают проблему.

Спасибо.

Мы только что завершили все предыдущие сессии базы данных discourse, что позволило нам удалить базу данных discourse.

Теперь снова выполняем команду ./launcher rebuild app. Сообщим о результатах.

./launch rebuild app не сработал; поэтому мы сделали следующее:

Затем:

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…


После безошибочной пересборки и запуска всё ещё не работает.

Поэтому попробовали снова, отключив опцию LETSENCRYPT:

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

Но система всё ещё собирает предыдущий уничтоженный (несколько часов назад) экземпляр, потому что в том экземпляре мы установили несколько тем, и они всё ещё присутствуют в этой сборке, даже после того, как мы ```удалили``` базу данных ```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


Как возможно, что после удаления всей базы данных ```discourse```, очистки всех образов и контейнеров Docker, удаления ```rm -rf /var/discourse``` и пересборки с нуля, мы всё ещё видим все установленные темы из сборки, которую пытаемся полностью уничтожить, хотя она была создана много часов назад?

В случае чистой установки это не имеет никакого смысла.

Что ж, мы начали заново, закомментировали шаблоны LETSENCRYPT и опцию электронной почты, и у нас получилось успешно пересобрать проект, получив страницу входа для администратора с поздравлениями.

Прогресс!

Теперь отредактируем app.yml и попробуем снова настроить SSL.

Что ж. Это интересно…

Если я пересоберу приложение с включенной поддержкой SSL (LETS ENCRYPT), у меня появятся два разных сайта…

  • HTTP: Новый сайт, как и ожидалось
  • HTTPS: Старый сломанный сайт

Хм. Это действительно сбивает с толку!

Что показывает команда

 docker ps

?

Перед каждой сборкой мы удаляли все старые образы Docker и прочее, выполнив следующую команду:

docker system prune -a

Таким образом, проблема не в образе Docker.

Мы считаем, что проблема связана с SSL-сертификатом LETSENCRYPT: когда мы изменили поддомен и сгенерировали новый SSL-сертификат в процессе сборки на том же IP-адресе сервера, всё работало как положено; но при возврате к исходному поддомену проблема сохраняется.

Поэтому мы временно отказались от использования проблемного поддомена (это всё равно был только тестовый домен) и перешли к другим задачам.

Спасибо за идеи.

Берегите себя.

Но это удаляет только неиспользуемые изображения. Вы уверены, что нет запущенных контейнеров?

Похоже, у вас больше одного контейнера — есть ли в папке с контейнерами что-то ещё, кроме app.yml?

Команда docker ps показывает только один запущенный контейнер, и в каталоге /var/discourse/containers присутствует только один файл app.yml.

Спасибо за все отличные идеи, хотя!

Очень признателен.