Thanks
Anu reference or file need to be removed?
I needed to run development discourse (set up following Install Discourse for development using Docker ) using database from another container. To do so, I had to modify the installation steps as follows:
git clone https://github.com/discourse/discourse.gitcd discoursevim config/database.yml, on the top of the file, make it into:
development:
prepared_statements: false
adapter: postgresql
#database: <%= ENV['DISCOURSE_DEV_DB'] || 'discourse_development' %>
database: discourse
username: discourse
password: yourdbpassword
host: postgres
min_messages: warning
pool: 5
timeout: 5000
checkout_timeout: <%= ENV['CHECKOUT_TIMEOUT'] || 5 %>
host_names:
### Don't include the port number here. Change the "port" site setting instead, at /admin/site_settings.
### If you change this setting you will need to
### - restart sidekiq if you change this setting
### - rebake all to posts using: `RAILS_ENV=production bundle exec rake posts:rebake`
- "localhost"
vim bin/docker/boot_dev, find the line starting withdocker run, and add a network definition matching the docker network to which your postgres container is attached to:docker run --network my-docker_network-name -d -p 4305:..../bin/docker/boot_dev./bin/docker/unicorn- you may need to run migrations:
docker exec -it discourse_dev /bin/bash -c "cd /src; ./bin/rails db:migrate RAILS_ENV=development" - visit http://localhost:9292/ and log in with credentials you set up earlier on that database
Is there a simpler way to do it, just with environment variables?
3 curtidas
This failed for me. Any suggestions on how to fix it ?
I am able to access DB discourse remotely from command line so the connection to DB looks good
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 274 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
578a8ec702d0025b01a0b8396985b8bfc25c7029769c2960b58693c64609a62a
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one
I got the same error with the following lines in the log above:
rake aborted!
PG::ConnectionBad: could not connect to server: Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5432?
Currently I am trying to find a fix.
1 curtida
The only way for me to rebuild with external postgres was the command mentioned earlier:
rebuild app --docker-args --net=host --skip-mac-address
But in this case unicorn is started with default port 3000. Exposing ports is disabled as well. I cannot explain exactly, but something has changed since Sep '17, probably in launcher code.
2 curtidas
Hey guys,
what´s the best practice to migrate from docker based postgre db to dedicated?
The setup of the dedicated is described farther up this thread, right, but how can I then move the data from docker to dedicated db ?
Probably with backup & restore, but is there a tutorial for that available ?
Thanks and greetings,
Julian
1 curtida
Ideally, you have discourse stopped.
Dump your database with pg_dump and restore with pg_restore.
see PostgreSQL Restore Database
Before starting up Discourse using the new database, issue as admin:
grant all privileges on database discourse to discourse;
alter schema public owner to discourse;
create extension if not exists hstore;
create extension if not exists pg_trgm;
2 curtidas
Também podemos usar o endereço IP do host em vez de usar --net=host.
172.17.0.1 é o endereço padrão para a máquina host a partir da rede do Docker em máquinas Unix.
Usar --net=host nos restringe a usar a opção -p como argumento do Docker.
DISCOURSE_DB_HOST = 172.17.0.1
4 curtidas
Olá,
Obrigado pelo excelente guia.
Infelizmente, encontrei um erro ao tentar reproduzi-lo.
Inicialmente, criei o Discourse usando o launcher para tudo — app/redis/postgres — e funcionou perfeitamente.
Porém, ao tentar com um RDS externo, o launcher falhou:
root@ip-172-31-42-129:/var/discourse# ./launcher rebuild app
Garantindo que o launcher esteja atualizado
Buscando origin
O launcher está atualizado
Parando o container antigo
+ /usr/bin/docker stop -t 60 app
app
cd /pups && git pull && git checkout v1.0.3 && /pups/bin/pups --stdin
docker: Erro na resposta do daemon: não foi possível obter o container para discourse.xxxxxxxx.us-west-2.rds.amazonaws.com: Nenhum container encontrado: discourse.xxxxxxxx.us-west-2.rds.amazonaws.com.
Veja 'docker run --help'.
cat: cids/app_bootstrap.cid: Arquivo ou diretório inexistente
"docker rm" requer pelo menos 1 argumento.
Veja 'docker rm --help'.
Uso: docker rm [OPÇÕES] CONTAINER [CONTAINER...]
Remove um ou mais containers
rm: não foi possível remover 'cids/app_bootstrap.cid': Arquivo ou diretório inexistente
** FALHA NO BOOTSTRAP ** Por favor, role para cima e procure mensagens de erro anteriores; pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.
Por favor, oriente como resolver esse problema.
Obrigado,
Alexander K
Existe alguma maneira de pré-criar e popular o banco de dados sem precisar passar pelas etapas de migração? Estamos executando no AKS com um PostgreSQL externo e a configuração do banco de dados parece levar um tempo que considero anormalmente longo (~8-9 minutos). Acelerar isso seria ótimo. Ou isso é um problema conhecido nessa configuração?
1 curtida
Essa não é uma configuração suportada.
Se você estiver construindo uma imagem, muito mais do que apenas o banco de dados está sendo compilado; várias templates estão sendo pré-compiladas. Acredito que esse seja apenas o tempo que vai levar.
1 curtida
Sim, você pode inicializá-lo em outro lugar e depois mover os dados para seu PostgreSQL de produção.
No entanto, isso tornará as atualizações muito trabalhosas.
2 curtidas
Três coisas a serem observadas.
Um: por padrão, o PostgreSQL escuta em localhost. Altere o endereço de escuta no arquivo postgresql.conf conforme mostrado abaixo.
listen_addresses = ‘localhost,172.17.0.1’
Dois: instrua o PostgreSQL a aceitar conexões de imagens do docker adicionando a seguinte linha ao arquivo pg_hba.conf.
host all all 172.17.0.0/16 scram-sha-256
Reinicie o serviço PostgreSQL após as duas alterações acima.
Três: se ainda não conseguir se conectar, verifique o firewall que pode estar bloqueando conexões de entrada na porta 5432.
2 curtidas
@Falco há algum risco de apagar tabelas existentes caso eu use um banco de dados existente?
Além disso, existe alguma forma de adicionar um prefixo para as tabelas do Discourse?
Não, a menos que entrem em conflito com os nomes do Discourse.
Mas acho que é uma má ideia.
Não. Recomendo que você use um banco de dados separado, a menos que haja algum motivo para que eles precisem ser conectados.
Que problema você está resolvendo ao compartilhar um banco de dados?
1 curtida
Obrigado, estou usando o AWS RDS, acabei de descobrir que posso ter vários bancos de dados na mesma instância, portanto, criei um novo banco de dados com um novo usuário.
2 curtidas
Tenho uma instância do Discourse recém-instalada rodando via Docker em uma VM no Google Cloud. Atualmente, tenho uploads de arquivos e backups do Discourse para buckets no Google Cloud habilitados e essas funções estão funcionando corretamente após seguir as instruções no tópico Configurar um provedor de armazenamento de objetos compatível com S3 para uploads. Posso ver os uploads de teste no bucket e, quando olho para os URLs de upload, todos os uploads estão mostrando o URL correto da CDN, então eles parecem estar sendo puxados corretamente do bucket.
Em seguida, criei uma instância PostgreSQL 15.2 no Google Cloud e executei o procedimento de configuração do banco de dados descrito no primeiro post e também configurei o arquivo app.yml. A porta padrão para PostgreSQL no Google Cloud é 5432, então omiti essas linhas.
Se eu usar o endereço IP público da instância postgres no arquivo app.yml, ao reconstruir o aplicativo, recebo o seguinte:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1024 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
a6a71b00bce378aa6334ae1c9fe103778d260bb699fe598f9685689e8b5ce450
Apenas para ver o que está acontecendo, tentei usar os outros IPs da instância postgres.
Se eu usar o endereço IP privado da instância postgres, recebo o seguinte:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1024 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
7333126c522eb51ace4d55ea89803eea54b96704baab70c322008cf2836ba47a
Se eu usar o endereço IP de saída da instância postgres, recebo o seguinte:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1026 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c588d2b6977b9e7d493b0b59bc694369cb7c2219de67d5886112ed16312626ae
Usando todos os IPs diferentes, as mensagens de falha são muito semelhantes e o banco de dados postgres não recebe nenhum dado ou conexão. Alguém tem alguma ideia do que estou fazendo de errado?
Além disso, meu problema está sendo causado por não usar o Cloud SQL Auth Proxy na instância VM? Se estiver, acho que terei que criar um script para executar o proxy e cronometrá-lo antes da reconstrução do aplicativo. Alguém tem alguma ideia sobre isso?
Obrigado pelo tempo, pessoal.
Tentei reconstruir mais algumas vezes alternando entre os IPs e parece que o banco de dados do discourse eventualmente foi preenchido com tabelas. Então agora estou ainda mais perplexo sobre o que está acontecendo.
alguém poderia me informar para qual versão do Discourse as instruções originais foram escritas?
Deve funcionar para uma instalação padrão nos últimos 5 anos ou talvez para sempre.
Você está tendo algum problema?
1 curtida