Olá,
Estou atualmente migrando de uma configuração clássica de dois contêineres (contêineres web_only e de dados separados) para uma configuração onde o banco de dados é hospedado em um servidor de banco de dados central (não dentro de um contêiner Docker).
O banco de dados central foi criado a partir do dump.sql que faz parte do arquivo de backup. O docker compose web_only.yaml usa
Durante a compilação do web_only, recebo o seguinte erro:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' falhou com retorno #<Process::Status: pid 741 exit 1>
Localização da falha: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec falhou com os parâmetros {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap falhou com código de saída 1
** FALHA AO INICIALIZAR ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
O host do banco de dados é acessível com esses dados. Alguma ideia do que está acontecendo aqui? A mesma compilação com o contêiner de banco de dados padrão termina com sucesso.
Tem certeza de que o banco de dados remoto está disponível no servidor? Parece que não está. Você pode usar o telnet para a porta do banco de dados a partir da máquina do servidor web?
Em relação ao DISCOURSE_DB_SOCKET: ‘’: como usamos uma conexão remota, eu presumiria que o valor do socket não é relevante em nenhum dos casos (dados em contêiner ou dados remotos)
…
docker_manager já está na versão compatível mais recente
wp-discourse já está na versão compatível mais recente
I, [2023-11-10T21:08:17.388213 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
O nome do plugin é 'discourse-topic-voting', mas o diretório do plugin é chamado 'discourse-voting'
rake aborted!
ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: permissão negada para a tabela users (ActiveRecord::StatementInvalid)
Então, boas notícias! Está conectando bem, são as permissões do banco de dados que precisam ser ajustadas.
… ok ok, parece que tenho mais problemas de permissão aqui, veja /var/log/postgresql/postgresql-13-main.log:
2023-11-10 22:07:58.371 UTC [196127] postgres@postgres STATEMENT: ALTER DEFAULT PRIVILEGES IN SCHEMA 'public' GRANT ALL ON TABLES TO 'discourse';
2023-11-10 22:10:18.270 UTC [196160] discourse@discourse ERROR: permission denied for table site_settings
2023-11-10 22:10:18.270 UTC [196160] discourse@discourse STATEMENT: SELECT name, data_type, value FROM site_settings
2023-11-10 22:10:18.313 UTC [196160] discourse@discourse ERROR: permission denied for table users
2023-11-10 22:10:18.313 UTC [196160] discourse@discourse STATEMENT: SELECT COUNT(*) FROM (SELECT 1 AS one FROM "users" LIMIT 20) subquery_for_count
OK, como sempre, foi um “problema de camada 8”
Eu já tinha um banco de dados discourse no postgres, mas o usuário/role do discourse não tinha todos os privilégios necessários nele. E eu perdi algumas diferenças importantes de “comportamento” entre mariadb e postgres…
Agora eu recriei tudo: usuário, banco de dados, permissões para o usuário/role (incluindo ALTER DEFAULT PRIVILEGES FOR ROLE discourse IN SCHEMA public GRANT ALL ON TABLES TO “discourse”; para corresponder às tabelas criadas por este usuário no futuro)
A compilação terminou e a instância está rodando bem com o servidor postgres remoto, então está pronta para importar o backup da instância mais antiga.
