Instalar Discourse para desenvolvimento usando Docker

Documentação Guias do Desenvolvedor
, ,
320

A causa raiz pode ser que o pg15 alterou as regras de autenticação padrão.

Caminho do arquivo de configuração: /etc/postgresql/15/main/pg_hba.conf

Conteúdo do arquivo:

# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host all all 0.0.0.0/0 md5
# IPv6 local connections:
host all all ::/0 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

O comando de backup executado é:

pg_dump --schema=public -T public.pg_* --file=‘/src/tmp/backups/default/2026-02-02-063003/dump.sql.gz’ --no-owner --no-privileges --verbose --compress=4 --username=postgres discourse_development

O comando acima falha devido à regra local all postgres peer: Peer authentication failed for user "postgres"

Ideia de solução: Mudar peer para trust, permitindo todos os comandos do ambiente local. Ou seja, todos os comandos não precisarão mais de autenticação (nem de senha).

Passos específicos:

  1. Copiar o /etc/postgresql/15/main/pg_hba.conf do contêiner para o local

sudo docker cp discourse_dev:/etc/postgresql/15/main/pg_hba.conf ~/discourse/data/pg_hba.conf

Dar permissão 644

sudo chmod 644 ~/discourse/data/pg_hba.conf

Modificar a configuração em data/pg_hba.conf

# Database administrative login by Unix domain socket
local   all   postgres   trust
  1. Modificar o arquivo d/boot_dev para montar data/pg_hba.conf no contêiner, substituindo o arquivo de configuração padrão do pg.
docker run -d \
    -p $local_publish:8025:8025 \
    -p $local_publish:3000:3000 \
    -p $local_publish:4200:4200 \
    -p $local_publish:9292:9292 \
    -p $local_publish:9405:9405 \
    -v "$DATA_DIR:/shared/postgres_data:delegated" \
    # A linha abaixo é adicionada, montando o arquivo de configuração no contêiner, e dando apenas permissão de leitura ao contêiner
    -v "$SOURCE_DIR/data/pg_hba.conf:/etc/postgresql/15/main/pg_hba.conf:ro" \
    -v "$SOURCE_DIR:/src:delegated" \
    -e UNICORN_BIND_ALL=true \
    $mount_plugin_symlinks \
    $ENV_ARGS \
    --hostname=discourse \
    --name=discourse_dev \
    --restart=always \
    discourse/discourse_dev:release /sbin/boot
  1. Desligar e remover o contêiner atual, e então reconstruir o novo contêiner
d/shotdown_dev
d/boot_dev
  1. Após a reconstrução, iniciar as aplicações frontend e backend e testar se o backup está normal
d/rails s

# Executar em outro terminal
d/ember-cli

Na página de backups, clique em backup, aguarde alguns segundos e verifique a lista de arquivos de backup.

image
image1788×871 125 KB

1 curtida
321

Com base na experiência acima, o desejo de conectar um cliente de banco de dados local ao banco de dados postgreSQL no Docker agora pode ser realizado.

Modifique a configuração no arquivo d/boot_dev da seguinte forma:

docker run -d \
    -p $local_publish:8025:8025 \
    -p $local_publish:3000:3000 \
    -p $local_publish:4200:4200 \
    -p $local_publish:9292:9292 \
    -p $local_publish:9405:9405 \
    # Mapeamento de porta recém-adicionado
    -p $local_publish:55432:5432 \
    -v "$DATA_DIR:/shared/postgres_data:delegated" \
    # Manter o mapeamento do arquivo de configuração
    -v "$SOURCE_DIR/data/pg_hba.conf:/etc/postgresql/15/main/pg_hba.conf:ro" \
    -v "$SOURCE_DIR:/src:delegated" \
    -e UNICORN_BIND_ALL=true \
    $mount_plugin_symlinks \
    $ENV_ARGS \
    --hostname=discourse \
    --name=discourse_dev \
    --restart=always \
    discourse/discourse_dev:release /sbin/boot

Permitir todas as requisições de conexão com pg:

No arquivo data/pg_hba.conf, modifique a configuração da seguinte forma:

# IPv4 local connections:
host all all 0.0.0.0/0 trust
# IPv6 local connections:
host all all ::/0 trust

Reconstruir

d/shutdown_dev
d/boot_dev

Agora você pode se conectar com um cliente de banco de dados local

Estou usando o DBeaver aqui

image
image802×682 32.2 KB

  1. A porta do banco de dados é 55432, consistente com d/boot_dev, aqui é 55432 para evitar conflitos com o que já existe localmente.
  2. Nome do banco de dados
  3. Recomenda-se marcar “Mostrar todos os bancos de dados”
  4. Nome de usuário
  5. Teste se a conexão funciona
  6. Clique em OK para salvar

Finalmente, você pode visualizar os dados no banco de dados local alegremente.

1 curtida
322

É normal que esta instalação não exiba o menu corretamente?

Zrzut ekranu 2026-02-07 132306
Zrzut ekranu 2026-02-07 132306747×1035 16.3 KB

323

Olá, embora tudo pareça funcionar após seguir este tutorial em uma máquina Ubuntu 26.04, nenhum e-mail parece estar sendo enviado.

Eu executei d/mailhog em um terminal dedicado e consigo ver o código HTML/CSS do e-mail enviado após o registro de um usuário de teste, mas ele não recebe nada no endereço de e-mail que forneci…

O que eu perdi e como corrigir isso? :folded_hands:

324

O e-mail deve aparecer em http://localhost:8025, acredito (porta do MailHog).

Esta não é uma instalação de Produção, então nenhum e-mail será enviado pela internet. Para isso, você precisa de uma instalação completa de Produção e de um serviço de e-mail compatível (que hoje em dia geralmente custa dinheiro de verdade, já que gerenciar confiança tem seu custo :money_bag:).

1 curtida
325

Obrigado @merefield, eu tinha visto localhost:8025, mas por alguma razão não funcionava, e agora está tudo certo.

1 curtida
326

Essa solução funciona? Não consegui avançar além de d/boot_dev --init.

Atualização:
Entendi: se o UID do desenvolvedor não for 1000, como o usuário discourse no container discourse_dev, tudo parece desmoronar.

uid=1000(discourse) gid=1000(discourse) groups=1000(discourse)

Uma série de problemas que encontrei 
nastee@station ~/vendsrc/discourse > ./d/boot_dev --init
Usando o código-fonte em: /home/nastee/vendsrc/discourse
Usando os dados em:     /home/nastee/vendsrc/discourse/data/postgres
release: Puxando do discourse/discourse_dev
.....
Digest: sha256:e118af085d4be0486d4d9bfa83ac1c519d9975bed9a08180d10d5ad7c508632c
Status: Nova imagem baixada para discourse/discourse_dev:release
docker.io/discourse/discourse_dev:release
f517752802e70b8a9110972bb3ddc0e9343d0c430603e4a9ae3eacc5ec69a2cf
Instalando gems...
Ocorreu um erro ao tentar escrever em `/src/Gemfile.lock`. Provavelmente, você precisa conceder permissões de escrita para esse caminho.

Obrigado a: There was an error while trying to write to `/src/Gemfile.lock`. It is likely that you need to grant write permissions for that path - #2 by jacque006

Defini as permissões desse arquivo para 777 (que nojo), fiz isso e, pelo menos, as Gems agora são instaladas. Mas o próximo processo docker exec tenta escrever no diretório de origem e não consegue, pois não está sendo executado como meu usuário, então recebo:

 EACCES  EACCES: permissão negada, open '/src/_tmp_82_62be1aeb82e80c1d1054dac8bdbc5923'

Ok, por que não? sudo chmod 4777 ., onde . é o diretório de origem clonado no qual estou executando d/

Isso me leva a:

 EACCES  Erro ao tentar criar um link simbólico de "../../../node_modules/.pnpm/prettier@3.8.1/node_modules/prettier" para "/src/docs/developer-guides/node_modules/prettier". O erro ocorreu ao tentar criar o diretório pai para o destino do link simbólico. Detalhes: Error: EACCES: permissão negada, mkdir '/src/docs/developer-guides/node_modules'

Após encontrar outro problema de permissão e simplesmente ceder com chmod 777 -R .

e eventualmente culminando em:

conexão com o servidor no socket "/var/run/postgresql/.s.PGSQL.5432" falhou: Arquivo ou diretório não encontrado