Olá! Ao instalar o Discourse (Docker), não vejo qual senha definir para meu banco de dados.
Preciso dela porque quero usar conexão remota com o banco de dados e acho que o Discourse define uma senha para todas as imagens do Docker.
Olá moschino
,
Não sei muito sobre coisas técnicas, mas acho que quando você estiver dentro do container, poderá se conectar ao banco de dados usando o nome de usuário discourse sem nenhuma senha.
Me diga se isso ajuda:
./launcher enter app
su - discourse
psql
Por que você quer fazer isso? Geralmente o explorador de dados é uma maneira melhor de fazer isso.
Por padrão, o banco de dados não é exposto a uma porta.
Se você realmente quiser expor seu banco de dados ao mundo, reinstale com uma configuração de dois contêineres (discourse-setup --two-container). Se for mais fácil fazer isso em um novo servidor, mas existem tópicos sobre como fazer a transição.
É quase certamente uma má ideia. Use o explorador de dados ou a API.
Então, qual é o bom conteúdo do config/database.yml? Por favor, você pode compartilhar um exemplo de produção?
Não vejo um banco de dados listado lá e o Ruby está falhando em algumas tarefas (como exportar override_translations). Suspeito que minha instalação tenha algo quebrado.
Atualmente, só vejo bancos de dados dev e test no config/database.yml e quero realmente corrigi-lo para o esquema de banco de dados de trabalho atual ![]()
Consigo ler o banco de dados de produção dentro do psql em uma instância Discourse em contêiner.
Como você instalou o discourse?
Que problema você está tentando resolver?
Qual a evidência de que algo está errado?
Você pode ver o que um
rake db:migrate
fará?
O nome do banco de dados está em uma variável de ambiente.
Não consigo exportar o idioma personalizado es_XX e suspeito que isso possa estar relacionado a uma configuração incorreta, mas então vejo que a senha de produção e o host parecem não estar declarados nos arquivos yml.
Tentei mexer com LANG e DISCOURSE_DEFAULT_LOCALE, mas isso não deveria ser suficiente.
Atualmente, tenho LANG = en_US.UTF-8 e DISCOURSE_DEFAULT_LOCALE = es (e isso me permite corrigir o problema de nível de confiança em idioma personalizado como uma solução alternativa).
Acho que esta não é uma instalação padrão.
Sim, é, mas acho que misturei desenvolvimento com produção ou algo assim.
Talvez eu tenha problemas com emojis em strings de localidade personalizadas, vou verificar isso.