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 Me gusta
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 me gusta
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 Me gusta
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 me gusta
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 Me gusta
También podemos usar la dirección IP del host en lugar de utilizar --net=host.
172.17.0.1 es la dirección predeterminada para la máquina host desde la red de Docker en máquinas Unix.
Usar --net=host nos restringe a usar la opción -p como argumento de Docker.
DISCOURSE_DB_HOST = 172.17.0.1
4 Me gusta
Hola,
Gracias por la excelente guía.
Desafortunadamente, obtuve un error al intentar reproducirla.
Inicialmente, creé Discourse utilizando el launcher para todo: app/redis/postgres, y funcionó correctamente.
Sin embargo, al usar un RDS externo, el launcher falló:
root@ip-172-31-42-129:/var/discourse# ./launcher rebuild app
Asegurando que el launcher esté actualizado
Obteniendo origen
El launcher está actualizado
Deteniendo el contenedor anterior
+ /usr/bin/docker stop -t 60 app
app
cd /pups && git pull && git checkout v1.0.3 && /pups/bin/pups --stdin
docker: Error response from daemon: could not get container for discourse.xxxxxxxx.us-west-2.rds.amazonaws.com: No such container: discourse.xxxxxxxx.us-west-2.rds.amazonaws.com.
Vea 'docker run --help'.
cat: cids/app_bootstrap.cid: No existe el archivo o el directorio
"docker rm" requiere al menos 1 argumento.
Vea 'docker rm --help'.
Uso: docker rm [OPCIONES] CONTENEDOR [CONTENEDOR...]
Eliminar uno o más contenedores
rm: no se puede eliminar 'cids/app_bootstrap.cid': No existe el archivo o el directorio
** FALLO AL INICIAR ** Por favor, desplácese hacia arriba y busque mensajes de error anteriores; puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
Por favor, indique cómo resolver este problema.
Gracias,
Alexander K
¿Existe alguna forma de precrear y poblar la base de datos sin tener que pasar por los pasos de migración? Estamos ejecutando en AKS con PostgreSQL externo y la configuración de la base de datos parece tomar lo que considero una cantidad de tiempo anormalmente larga (~8-9 minutos). Sería excelente acelerar este proceso. ¿O es este un problema conocido en esa configuración?
1 me gusta
Esa no es una configuración compatible.
Si estás construyendo una imagen, se está compilando mucho más que solo la base de datos, como una serie de plantillas que se están precompilando. Creo que eso es simplemente lo que va a tardar.
1 me gusta
Sí, puedes inicializarla en otro lugar y luego mover los datos a tu PostgreSQL de producción.
Sin embargo, esto hará que las actualizaciones sean muy engorrosas.
2 Me gusta
Tres cosas a tener en cuenta.
Uno: por defecto, PostgreSQL escucha en localhost. Cambia la dirección de escucha en el archivo postgresql.conf como se muestra a continuación.
listen_addresses = ‘localhost,172.17.0.1’
Dos: indica a PostgreSQL que acepte conexiones de imágenes de Docker añadiendo la siguiente línea al archivo pg_hba.conf.
host all all 172.17.0.0/16 scram-sha-256
Reinicia el servicio de PostgreSQL después de los dos cambios anteriores.
Tres: si sigues sin poder conectar, comprueba el firewall que podría estar bloqueando las conexiones entrantes en el puerto 5432.
2 Me gusta
@Falco ¿existe algún riesgo de borrar tablas existentes si utilizo una base de datos existente?
Además, ¿hay alguna forma de añadir un prefijo a las tablas de Discourse?
No, a menos que entren en conflicto con los nombres de Discourse.
Pero creo que es una mala idea.
No. Recomiendo que utilice una base de datos separada a menos que haya alguna razón por la que necesiten estar conectadas.
¿Qué problema está resolviendo al compartir una base de datos?
1 me gusta
Gracias, estoy usando AWS RDS, acabo de descubrir que puedo tener varias bases de datos en la misma instancia, por lo tanto, he creado una nueva base de datos con un nuevo usuario.
2 Me gusta
Tengo una instancia de Discourse recién instalada que se ejecuta a través de docker en una VM en Google Cloud. Actualmente tengo habilitadas las cargas de archivos y las copias de seguridad de Discourse en buckets en Google Cloud, y esas funciones funcionan correctamente después de seguir las instrucciones del hilo Configurar un proveedor de almacenamiento de objetos compatible con S3 para cargas. Puedo ver las cargas de prueba en el bucket y, cuando miro las URL de carga, todas las cargas muestran la URL correcta desde la CDN, por lo que parecen extraerse correctamente del bucket.
Luego creé una instancia de PostgreSQL 15.2 en Google Cloud y realicé el procedimiento de configuración de la base de datos que se describe en la primera publicación y también configuré el archivo app.yml. El puerto predeterminado para PostgreSQL en Google Cloud es 5432, así que omití esas líneas.
Si uso la dirección IP pública de la instancia de postgres en la configuración de app.yml, cuando reconstruyo la aplicación, obtengo lo siguiente:
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
Solo para ver qué está pasando, intenté usar las otras IPs de la instancia de postgres.
Si uso la dirección IP privada de la instancia de postgres, obtengo lo siguiente:
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
Si uso la dirección IP saliente de la instancia de postgres, obtengo lo siguiente:
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 todas las IPs diferentes, los mensajes fallidos son muy similares y la base de datos postgres no recibe ningún dato ni conexión. ¿Alguien tiene alguna idea de lo que estoy haciendo mal?
Además, ¿mi problema se debe a no usar el Cloud SQL Auth Proxy en la instancia de VM? Si es así, supongo que tendré que crear un script para ejecutar el proxy y cronometrarlo antes de la reconstrucción de la aplicación. ¿Alguien tiene alguna idea sobre eso?
Gracias por el tiempo, chicos.
Intenté reconstruir varias veces más, cambiando entre las IPs y parece que la base de datos de discourse finalmente se pobló con tablas. Así que ahora estoy aún más perplejo sobre lo que está pasando.
¿Alguien podría decirme para qué versión de Discourse se escribieron las instrucciones originales?
Debería funcionar para una instalación estándar de los últimos 5 años o quizás para siempre.
¿Tienes algún problema?
1 me gusta