Instalar Discourse para desenvolvimento usando Docker

Documentação Guias do Desenvolvedor
, ,
168

Obrigado pelo guia.

No entanto, estou tendo problemas ao criar um backup na seção de administração.
O erro que estou recebendo é:
pg_dump: error: connection to database "discourse development" failed: FATAL: Peer authentication failed for user "postgres".

Verifiquei o arquivo pg_hba.conf e configurei todas as opções para trust.

Seria ótimo se pudesse receber alguma ajuda sobre como fazer isso funcionar.

Tentei no Ubuntu e também no MacOSX. Tudo está funcionando bem em ambos (criando Posts, API…) exceto a funcionalidade de backup.

169

Obrigado por essa solução fantástica com Docker.

Para executar os testes de plugins, isso funciona muito bem:

d/rake plugin:spec["discourse-follow"]

Existe alguma maneira de direcionar testes específicos de plugins, como em um ambiente de desenvolvimento sem Docker? Por exemplo:

LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/requests/follow_controller_spec.rb:32

Tentei, por exemplo:

d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10 LOAD_PLUGINS=1 RAILS_ENV=test

Mas estou recebendo um erro.

170

LOAD_PLUGINS e RAILS_ENV devem anteceder o comando para atribuir variáveis de ambiente. Após o comando, eles são tratados como argumentos para rspec, que não os reconhece.

LOAD_PLUGINS=1 RAILS_ENV=test d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10

171

Não, não estou convencido de que isso funciona — você realmente testou?

Eu recebo:

NameError:
  uninitialized constant Follow

Suspeito que isso seja porque as variáveis de ambiente não estão sendo passadas para o processo do Docker?

Foi por isso que eu as estava tornando argumentos.

172

Peço desculpas, interpretei mal seus dois comandos como “o primeiro funciona para essa outra especificação, o segundo não funciona para essa especificação”. Não tenho um ambiente de desenvolvimento configurado para testar.

Analisando o arquivo rspec no GitHub, acho que você está certo ao dizer que as variáveis de ambiente não estão sendo passadas. Parece que você deve conseguir executar d/shell para obter um shell dentro do container e, em seguida, executar seu comando rspec lá.

1 curtida
173

Simon, isso é mais do que uma solução alternativa excelente e funcional, obrigado!

Acabei de testar e funciona, ou seja:

my-blah-machine:~/discourse$ d/shell
discourse@discourse:/src$ LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

Adicionei isso e a versão completa do plugin à Wiki.

1 curtida
174

Dando uma olhada mais de perto em d/exec, que tanto o d/shell quanto o d/rspec utilizam, acho que também pode ser encurtado assim:

RAILS_ENV=test d/exec LOAD_PLUGINS=1 rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

O d/exec passa o RAILS_ENV, mas não o LOAD_PLUGINS, por isso eles aparecem de cada lado do d/exec.

1 curtida
175

Isso me gera um erro:

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "LOAD_PLUGINS=1": executable file not found in $PATH: unknown
176

Ah, imagino que variáveis de ambiente não possam ser usadas com docker exec dessa maneira. Tudo bem, pelo menos abrir o shell primeiro funciona.

1 curtida
177

Estou tendo exatamente o mesmo problema que o Max. Sempre que tento fazer um backup ou uma restauração na minha instalação local do Docker para desenvolvimento, recebo o mesmo erro: Peer authentication failed for user "postgres"

Após algumas investigações, descobri que no ambiente de desenvolvimento a configuração do banco de dados aparece assim:

BackupRestore.database_configuration
=> #<struct BackupRestore::DatabaseConfiguration host=nil, port=nil, username="postgres", password=nil, database="discourse_development">

De alguma forma, o ambiente de desenvolvimento não está definindo o nome de usuário nas variáveis de ambiente e, então, o módulo BackupRestore simplesmente define o valor do nome de usuário como postgres.

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )

Onde podemos definir o nome de usuário correto do banco de dados?

1 curtida
178

Como usamos o Install the Discourse Theme CLI console app to help you build themes aqui?

Conseguimos instalar o gem com sucesso: d/exec sudo gem install discourse_theme … agora o desafio é criar um link simbólico para o tema local …

@Simon_Manning, observe o uso do sudo para contornar permissões (obrigado pela lembrança @fzngagan)

179

Estou tentando testar um plugin usando a configuração do Docker. Aleatoriamente, o aplicativo para de carregar e eu fico apenas com uma página em branco até que eu exclua a pasta de dados e reconstrua tudo. Alguma dica sobre como depurar o problema?

180

Já houve alguma descoberta sobre isso? Ainda parece ser um problema.

181

Minha “gambiarra” foi substituir o nome de usuário de postgres para discourse no seguinte bloco de código:

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )
182

Mudei do meu Mac local para uma VM Ubuntu, esperando que isso facilitasse a execução, mas, infelizmente, até agora não tem funcionado.

Já estou enfrentando alguns problemas estranhos de permissão nas etapas iniciais. O d/bundle install relata que precisa de direitos de sudo para instalar alguns itens, e o d/rails s também retorna problemas de permissão.

Traceback (most recent call last):
        8: from /src/bin/unicorn:70:in `<main>'
        7: from /src/bin/unicorn:38:in `ensure_cache_clean!'
        6: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `mkdir_p'
        5: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `each'
        4: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `block in mkdir_p'
        3: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `reverse_each'
        2: from /usr/local/lib/ruby/2.7.0/fileutils.rb:228:in `block (2 levels) in mkdir_p'
        1: from /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `fu_mkdir'
/usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `mkdir': Permission denied @ dir_s_mkdir - /src/tmp (Errno::EACCES)

Alguma ideia do que está dando errado? Esta máquina executava anteriormente um Discourse de produção sem problemas. Eu apenas parei e removi esses containers e clonei o repositório git de desenvolvimento em um diretório diferente. Estou executando tudo através do tmux para gerenciar as diferentes instâncias de shell.

183

Ainda não estou no M1, mas pretendo migrar em breve, e realmente prefiro a conveniência da configuração do Docker.

Esse link da PR aponta para https://github.com/docker/for-mac/issues/5321, onde eles afirmam:

a única solução é migrar para imagens multi-arquitetura compatíveis com arm64. Essas também serão muito mais rápidas e, de modo geral, mais confiáveis. Recomendo investigar quais imagens base você está usando e migrar para imagens multi-arquitetura sempre que possível. Você pode ver quais arquiteturas são suportadas por cada imagem no Docker Hub: […]

Para construir sua própria imagem multi-arquitetura, recomendo o docker buildx. Confira este post no blog: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

A equipe do Discourse está disposta a apoiar uma imagem multi-arquitetura? Parece que a imagem base do Discourse é baseada em debian:buster-slim, que é multi-arquitetura, então não deveria ser excessivamente difícil tornar a imagem base do Discourse multi-arquitetura. No entanto, isso poderia colocar vocês na posição de ter que dar suporte ao ARM (em produção!). Alguém (a equipe do Discourse?) precisaria executar os testes do Discourse tanto em x86_64 quanto em ARM, corrigir problemas quando falharem, etc.

Uma PR seria bem-vinda aqui?

(IMO, parece que o ARM é a arquitetura do futuro, mesmo em ambientes hospedados na nuvem.)

2 curtidas
Install Discourse on Arm-Based Compute
184

Estou tentando configurar isso no WSL2.

Cheguei ao ponto de iniciar o ember_cli, mas o Chrome apresentou o seguinte erro:

Não há erros visíveis nem no terminal nem no log de desenvolvimento. Aceito sugestões, por favor?

1 curtida
Trouble setting up dev Discourse on WSL2 with Docker - solved
185

isso é realmente útil

186

Olá a todos,

Estou encontrando os mesmos problemas, então pensei em levantar como um bug. Por favor, veja abaixo.

Restauração de backup falhando em um ambiente docker de desenvolvimento limpo: FATAL: Peer authentication failed for user “postgres”

Me avisem se posso fornecer mais informações ou ser de alguma ajuda.

Koen

187

Não consigo fazer isso funcionar no openSUSE Leap 15. Suponho que não seja um sistema operacional compatível, embora, como estamos usando Docker, isso não deva importar muito…

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/app/assets/javascripts/plugins
/src/lib/plugin/instance.rb:441:in `ensure_directory'
/src/lib/plugin/instance.rb:713:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Tentei apenas criar manualmente “app/assets/javascripts/plugins” e isso me levou a

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/tmp
lib/discourse.rb:94:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Então vou criar tmp na pasta source…

Mas então isso me leva a:

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - /src/tmp/5ad4443faf817dc922116f8df65ae5c3
lib/discourse.rb:97:in `initialize'
lib/discourse.rb:97:in `open'
lib/discourse.rb:97:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Parece que boot_dev está executando docker exec como o usuário discourse… mas os diretórios são de propriedade de um usuário 1016 (o uid do usuário do meu host).

Imagino que muitos desenvolvedores não encontrem esse problema em seus laptops pessoais, onde o usuário deles tem um uid de 1000 e isso coincide coincidentemente…

1 curtida