Está correto? Quanto tempo para instalar a versão dev?

Estou tentando instalar a versão de desenvolvimento do Discourse em um droplet Ubuntu 20.04 na DigitalOcean, com o único objetivo de migrar um fórum FluxBB para o Discourse, exportar e depois importar para uma versão de produção do Discourse.

Não tive problemas ao instalar a versão de produção do Docker como teste (sem migrar do FluxBB).

No entanto, ao tentar instalar a versão de desenvolvimento do Discourse seguindo este guia:

Percebo que o comando nunca conclui quando executo:

bundle exec rake autospec

Após cerca de 30 minutos esperando que termine, minha sessão remota é encerrada por tempo esgotado.

Além disso, recebo muitos erros. Infelizmente, não os tenho à mão, mas todos são do tipo em que alguma função sempre retorna “nil”.

Como não sei o que esse comando faz ou se é necessário (as instruções apenas dizem “tente executar os specs”, sem explicar o que isso faz ou por que fazê-lo), segui em frente e tentei o próximo comando:

bundle exec rails server --binding=0.0.0.0

E estou percebendo que isso também leva uma eternidade e exibe uma série de informações no Terminal que não entendo. Talvez sejam erros, talvez não.

Então, minha pergunta é: isso é um comportamento esperado ou estou fazendo algo errado? Aproximadamente quanto tempo seria esperado para esses comandos concluírem?

E é possível migrar o fórum FluxBB usando apenas a versão de produção/Docker do Discourse, sem precisar usar a versão de desenvolvimento? Atualmente, nem mesmo tenho um site de produção, então não me preocupo em quebrá-lo; posso destruí-lo e recriá-lo quando quiser.

1 curtida

Isso significa que o servidor está em execução. E, claro, continuará rodando até que você pressione Control+C ou feche o terminal.

Informações são impressas no terminal indefinidamente, a menos que você pare o servidor.

Dentro de alguns segundos após o início, a página web estará disponível no seu navegador.

Você está se conectando na porta correta no seu navegador? Geralmente, essa porta é a 3000.

1 curtida

Existem vários tópicos de como fazer sobre a execução de importações em servidores de produção. Você pode usar um deles como guia para executar o script que deseja rodar.

Parece que você instalou o ambiente de desenvolvimento e que deve executar o script nele.

1 curtida

Não estou vendo nada no navegador. Vejo um processo Ruby em execução se eu executar ‘top’ no terminal.

Se a saída do terminal continuar rodando indefinidamente após executar

bundle exec rails server --binding=0.0.0.0

isso não deveria ser explicitado na documentação? Normalmente, quando sigo um guia passo a passo, espero que um comando execute uma ação, termine e exiba uma mensagem informando que a instalação foi concluída e que estou pronto para usar.

1 curtida

Existem vários tópicos de como fazer sobre executar importações em servidores de produção.

Onde eles podem estar localizados? O único que vejo para o FluxBB diz explicitamente para fazer isso em uma instalação de desenvolvimento:

Acho que é considerado senso comum que, se você inicia um servidor web, ele não deve ser interrompido a menos que o administrador queira. Servidores web geralmente são feitos para servir páginas dia após dia após dia… mas, claro, alguém poderia adicionar essa esclarecimento. Qualquer pessoa pode enviar melhorias propostas para o guia por meio de PR.

1 curtida

Mas é senso comum que aquele comando inicia um servidor web? Ele apenas diz ‘rails server’, o que não precisa necessariamente ser um servidor web. Quando você inicia um servidor web Apache, você é imediatamente retornado ao prompt de comando; ele não despeja informações no Terminal infinitamente…

Rails é um framework para aplicações web. Não acho justo compará-lo diretamente ao Apache.

Gosto do fato de poder vê-lo trabalhando ativamente. Quando ele para, geralmente algo está errado! A saída pode ser útil em algumas situações, especialmente no desenvolvimento. Você pode alterar a quantidade de informações exibidas usando a configuração do ambiente.

Aliás, de acordo com a documentação, o Rails pode ser ‘daemonizado’ com a opção -d. Sinta-se à vontade para investigar por que isso não parece funcionar na instalação padrão; pode haver uma limitação introduzida por isso. A equipe é a melhor pessoa para conversar sobre isso.

1 curtida

Olá @epsteindidnt

Quando você pegar o ritmo do desenvolvimento com Rails, vai descobrir, se for como eu, que o que você descreveu como “jogar coisas no Terminal sem parar” se torna um dos seus melhores amigos.

Por exemplo, estou desenvolvendo atualmente uma aplicação Rails para um cliente onde estamos transformando toda a lógica de negócios legada (de várias décadas atrás) para Rails. Na verdade, comprei um novo monitor só para poder ver o “coisas no Terminal sem parar” (suas palavras), porque essa informação é ouro puro para um desenvolvedor.

Além do incrível log do servidor Rails, que fornece detalhes intrincados do que está acontecendo, há também outro “melhor amigo do desenvolvedor”: o console do Rails!

Quando escrevo código para Rails, basicamente faço o rascunho no VS Code e depois copio e colar trechos no console do Rails para garantir que tudo funcione como esperado.

Ao depurar, escrevo instruções de impressão em Ruby (p, puts) no código e observo o que acontece no “fluxo interminável de informações douradas do log do servidor Rails” na tela. Quase todos os meus erros são corrigidos dessa forma! Como disse, recentemente comprei um novo monitor curvo de jogos, dedicado, só para ver as informações do log do servidor Rails que você está irritado :slight_smile:

Pelo que vejo lendo suas postagens, parece que você é um pouco como eu no início deste ano, migrando para uma aplicação Rails sem experiência prévia em desenvolvimento com Rails. No começo, também me senti irritado com o Rails (talvez até mais do que um pouco); e agora, 9 meses depois, desenvolvo exclusivamente em Rails todos os dias para clientes (meu limite é trabalho para clientes em meio período, já que estou semi-aposentado) e parei todo o trabalho anterior com PHP. Sério, descobri uma nova paixão por Rails (e Ruby), e muito. Melhor tarde do que nunca, como diz o ditado!

Quanto ao Apache2, o Apache não fornece os detalhes intrincados do que está acontecendo nos bastidores de uma aplicação como o Rails faz. Eu executo o Apache2 como um proxy reverso na frente de todas as minhas aplicações Rails e, para ser franco, não me lembro da última vez que olhei para um arquivo de log do Apache; porque faço toda a depuração usando o log do servidor Rails que você está atualmente irritado :slight_smile:

Para encerrar, espero sinceramente que uma perspectiva diferente de alguém que já “migrar um fórum para Rails” ajude de alguma pequena forma. Para mim, ter sido compelido a sair das aplicações web LAMP e ir para as aplicações web Rails foi uma das melhores “coisas de tecnologia” que aconteceram comigo (pessoalmente) em 2020.

Boas festas!

1 curtida

Eu também tenho ficado um pouco assustado com isso ultimamente. Eis o que percebi hoje:

A saída em um terminal rails s mostrará um monte de consultas na inicialização, mas então também inclui saída dos trabalhos sidekiq do discourse (pelo menos no ambiente de desenvolvimento docker). Portanto, se você estiver executando uma importação muito grande, terá uma fila sidekiq muito grande de trabalhos de pós-processamento que podem demorar muito depois. Acho que são trabalhos não essenciais, por exemplo, carregar caches, que não parecem impedir você de navegar no site antes de terminarem.

Isso estava me confundindo muito porque fiz uma grande importação, depois saí e reinicializei o banco de dados para fazer uma pequena importação de teste, e ainda estava girando sem parar fazendo consultas relacionadas ao banco de dados que não existia mais! A solução foi esvaziar as filas sidekiq usando um console rails.

Tarde demais para te ajudar, mas pensei em compartilhar isso.