Não é possível passar da fase de bootstrap

Instalação
1

Eu agora instalei o Discourse em 2 VMs diferentes.
Estou usando as instruções oficiais de instalação.
Uma executando Debian 12 em uma instância VMWare Fusion em um Mac Pro, a outra é Ubuntu 24 em uma VM rodando sob TrueNAS.
Ambas estão em servidores dedicados na minha rede local com redes bridged e têm endereços IP acessíveis únicos.
O servidor TN hospeda vários outros aplicativos em contêineres Docker e todos eles estão funcionando e acessíveis via LAN e Internet, o Mac Pro hospeda nativamente uma wiki.
Em ambos, a função de bootstrap termina, mas não obtenho um site funcional. Apenas ‘servidor não responde’ no navegador.
De acordo com docker ps o container “app” está ativo e rodando, ouvindo nas portas 80 e 443, o ufw relata que essas portas estão sendo permitidas.
Por um tempo, o site Debian mostrava uma página de boas-vindas padrão do nginx, mas agora nem isso responde mais.
Não sou nenhum desenvolvedor ou especialista em web, então não sei como solucionar problemas, pedi ajuda ao Grok, mas até agora nada funcionou.

Agradeço qualquer ajuda dada.

2

Se eles não estiverem na internet pública com um nome de domínio apontando para eles, você não poderá fazer uma instalação padrão.

Você pode dar uma olhada em Install Discourse on a residential internet with Cloudflare Tunnel

1 curtida
3

Tenho um endereço IP estático disponível publicamente e um nome de domínio apontando para esse endereço.
Geralmente, uso um registro A curinga para apontar qualquer host para esse IP, mas, durante minha resolução de problemas, encontrei uma postagem dizendo que o Discourse pode não se comportar bem com endereços proxy no DNS do Cloudflare, então criei um registro A dedicado e desativei o proxy para esse registro.

4

Você executou discourse-setup? Ele passou no teste de conexão?

5

Estou usando o termo ‘função bootstrap’ corretamente?
Só quero ter certeza de que estamos falando sobre a mesma coisa.
./discourse-setup é o bootstrap, certo?
Então, se eu digo que ele faz bootstrap, e o container está rodando, então o teste de conexão, que acontece no início da configuração, passou.

Faz sentido tudo isso?

6

[citação=“tknospdr, post:5, tópico:364284”]
./discourse-setup é o bootstrap, certo?
[/citação]

Bem, mais ou menos. Ele cria um app.yml e depois executa ./launcher bootstrap app.

Se você o executou várias vezes sem o DNS funcionando direito, então atingiu os limites de taxa com o Let’s Encrypt. As soluções mais fáceis são esperar uma semana ou usar um nome de domínio diferente.

[citação=“tknospdr, post:3, tópico:364284”]
Eu criei um registro A dedicado e desativei o proxy para esse.
[/citação]

E nada mais está rodando naquela máquina?

E quando você executou discourse-setup, não reclamou por não conseguir se conectar a ele mesmo?

7

Eu só o executei uma vez em cada VM e usei um nome de host diferente para cada uma.

VMs novinhas em folha sem nada mais rodando nelas. No hardware real existem outras coisas rodando. Mas elas têm endereços IP internos separados de seus hosts.

Correto.

8

Aqui estão os erros que encontrei na saída da instalação, nenhum parece ser um impeditivo:

690:M 30 de abr de 2025 22:05:22.859 # Aviso: Não foi possível criar o soquete de escuta TCP do servidor *:6379: bind: Endereço já em uso
690:M 30 de abr de 2025 22:05:22.859 # Falha ao escutar na porta 6379 (TCP), abortando.

109:M 30 de abr de 2025 21:59:42.411 # AVISO: A sobreexecução de memória deve estar habilitada! Sem ela, uma gravação em segundo plano ou replicação pode falhar sob condição de baixa memória...

30 de abr de 2025 21:59:41.125 UTC [60] postgres@postgres ERRO: banco de dados "discourse" já existe
30 de abr de 2025 21:59:41.274 UTC [63] postgres@discourse ERRO: papel "discourse" já existe

AVISO: Specs não resolvidos ou ambíguos durante Gem::Specification.reset:
      stringio (>= 0)
      Versões disponíveis/instaladas desta gema:
      - 3.1.7
      - 3.1.5
      - 3.1.1
AVISO: Limpando specs não resolvidos. Tente 'gem cleanup <gema>'
Por favor, reporte um bug se isso causar problemas.

A configuração 'staticAddonTrees' será padrão para true na próxima versão do Embroider e não pode ser desativada. Para se preparar, você deve definir 'staticAddonTrees: true' na sua configuração do Embroider.
A configuração 'staticAddonTestSupportTrees' será padrão para true na próxima versão do Embroider e não pode ser desativada. Para se preparar, defina 'staticAddonTestSupportTrees: true' na sua configuração do Embroider.

O limite de heap do Node.js é menor que 2048MB. Definindo --max-old-space-size=2048 e CHEAP_SOURCE_MAPS=1

-e DISCOURSE_SMTP_DOMAIN=discourse.example.com

[BABEL] Nota: O gerador de código desotimizou o estilo do arquivo /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js porque ele excede 500KB.
[BABEL] Nota: O gerador de código desotimizou o estilo do arquivo /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js porque ele excede 500KB.
9

Quais são as especificações das suas VMs? Ou seja, quantos vCPUs/ RAM são alocados para elas?

10

Ambos têm 2/2

1 curtida
11

Aumentar para 4 GB de RAM ajuda? Acho que os requisitos de memória podem ter aumentado.

1 curtida
12

Eu não estava pensando no fato de que, já que a porta 80 já está em uso e eu só tenho o IP externo, mesmo que a verificação do domínio estivesse passando durante o processo de configuração, eu tive que alterar as portas do lado do host para fazer as coisas funcionarem.

Estou usando NPM internamente.

Passos para fazer funcionar:

  1. Alterar a porta do lado do host para 7080 para HTTP
  2. Como vou passar o tráfego pelo meu gerenciador de proxy, simplifiquei minha vida e desativei os scripts do LE
  3. Atualizei o aplicativo
  4. Passei ‘ext IP:80’ para ‘int IP:7080’ no proxy reverso, então o contêiner reverteu as portas… então eles fizeram a Hokey Pokey e se viraram.

Agora tudo parece estar funcionando até agora.

2 curtidas