Ao atualizar usando o atualizador da interface do usuário na seção de administração - Sempre falha. Falhou desde que instalei o Discourse há mais de um ano. Posso facilmente acessar meu servidor via SSH e atualizar manualmente, mas é frustrante ter um recurso que não está se comportando corretamente.
Como o Discourse é executado com Docker, e não tenho muito conhecimento sobre ele, gostaria de saber se alguém tem problemas como este também, e como posso corrigi-lo.
Em resumo: O atualizador da interface do usuário sempre falha, a linha de comando funciona na primeira tentativa e gostaria de corrigi-lo para não ter que acessar o servidor via SSH (com tanta frequência).
Percebo que, após pesquisar um pouco, pode ser que eu esteja usando a quantidade mínima de RAM recomendada, mas esta é para uma instalação privada com menos de 50 usuários, então realmente não preciso ir além do mínimo para o meu caso de uso.
Eu costumava conseguir fazer uma atualização com 2G de RAM + 2G de swap, mas isso foi, acho que, antes do Ember, que é muito exigente. Se você tiver espaço em disco para aumentar o swap para 4G, isso pode resolver. Ou, temporariamente e com cuidado, migre para uma instância com mais RAM, faça a atualização e migre de volta.
O que quer que você faça, faça um backup e baixe-o primeiro.
Eu costumava ter 2 GB de RAM e 40 GB de disco, dependendo do .\discourse-setup para configurar o swap, as atualizações da interface do usuário da web eram lentas
No mercado dos EUA, tanto a Contabo quanto a IONOS permitem a porta 25 de entrada, o que é crucial para configurações de mail-receiver — portanto, não há limitação funcional nesse aspecto.
A diferença real reside na confiabilidade e reputação do suporte:
Contabo (Trustpilot 4.2/5, ~6.700 avaliações) oferece preços agressivos e especificações altas, mas usuários baseados nos EUA frequentemente relatam alta latência, resposta de suporte mais lenta e instabilidade de desempenho, especialmente sob carga. Os data centers da Contabo nos EUA existem, mas nem sempre são tão responsivos quanto o esperado.
IONOS (Trustpilot 4.5/5, ~31.000 avaliações) tem um desempenho melhor nos EUA do que muitos imaginam. Possui uma reputação de suporte mais forte e infraestrutura mais confiável, com menos avaliações de 1 estrela (~10% contra 16% da Contabo). Os usuários relatam consistentemente melhor uptime, suporte ao vivo e gerenciamento de conta em comparação com a Contabo.
Conclusão (EUA):
Se você está nos EUA e precisa de estabilidade, suporte rápido e baixo risco para cargas de trabalho de produção, a IONOS é a escolha mais segura. A Contabo ainda pode valer a pena considerar para ambientes de desenvolvimento/teste ou implantações sensíveis a custos, mas espere compromissos em latência e qualidade de suporte.
O meu também começou a fazer isso, funcionou perfeitamente por mais de 4 anos e agora falha. Embora às vezes ele afirme que falhou, quando atualizo tudo está em dia e não há mais nada para atualizar. Mas quase sempre termina com
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Comando foi encerrado com SIGKILL (Terminação forçada): ember build -prod /var/www/discourse/script/assemble_ember_build.rb:103:in `system': Comando falhou com saída 1: pnpm (RuntimeError) from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>' Docker Manager: FALHA AO ATUALIZAR
Era isso que eu estava me perguntando - se estava conectado a um problema com o próprio código e não tanto com o hardware do meu servidor.
Acho que minha próxima possibilidade é simplesmente escrever meu próprio plugin com um script para me atualizar manualmente.
Ainda bem que outros têm o mesmo problema, então não sou só eu (eu sei que é ruim). Talvez alguém que desenvolva ativamente com Discourse possa investigar. Eu também gostaria que houvesse mais informações de depuração, mais do que apenas “falha”.
Não sou um desenvolvedor nem um especialista em servidores e tudo mais. Optei pela Digital Ocean, apenas porque foi a mencionada nas instruções oficiais de instalação, e porque tenho visto esse nome mencionado repetidamente ao longo dos anos.
No momento, estou no segundo plano mais barato, que custa US$ 6 por mês por um servidor que parece ser muito “mais lento” do que os oferecidos pela Contabo ou IONOS. Como o mínimo para um bom desempenho do Discourse é pelo menos 2 GB de RAM, eu teria que atualizar para o plano de US$ 12. Para a Contabo, por US$ 4,95 por mês, eu teria 8 GB… é uma diferença “pequena” tanto no preço quanto na RAM, sem mencionar o espaço em disco, etc.
Então, perguntando a você e a outros usuários experientes, faz sentido migrar meu Discourse para a Contabo, por exemplo, em vez de ficar com a Digital Ocean? Mesmo que eu ainda esteja construindo toda a comunidade e tudo mais, até agora a DO tem sido ok, exceto pelo problema de atualizar o Discourse na web, mesmo com um swapfile de 4 GB (porque meu espaço em disco é de apenas 25 GB), mas não quero migrar tudo para depois começar a notar outros problemas.
Encontrei esta página, mas não tenho certeza de quão confiáveis são esses testes e se são suficientes para me fazer mudar?
Qualquer feedback seria muito apreciado!
Obrigado!
********************************************************
*** Por favor, seja paciente, os próximos passos podem demorar um pouco ***
********************************************************
Cycling Unicorn, para liberar memória
Reiniciando o pid do unicorn: 1580
Aguardando o Unicorn recarregar.
Aguardando o Unicorn recarregar..
Aguardando o Unicorn recarregar...
Aguardando o Unicorn recarregar....
Aguardando o Unicorn recarregar.....
Aguardando o Unicorn recarregar......
Aguardando o Unicorn recarregar.......
Aguardando o Unicorn recarregar........
Aguardando o Unicorn recarregar.........
Aguardando o Unicorn recarregar..........
Aguardando o Unicorn recarregar...........
Aguardando o Unicorn recarregar............
Aguardando o Unicorn recarregar.............
Aguardando o Unicorn recarregar..............
Parando 1 worker(s) do Unicorn, para liberar memória
Parando a fila de trabalhos para recuperar memória, o pid mestre é 1585
$ cd /var/www/discourse && git fetch --tags --prune-tags --prune --force
$ cd /var/www/discourse && git reset --hard HEAD@{upstream}
HEAD está agora em 20ff23ed0 DEV: remove traduções redundantes para o botão de novo tópico desativado (#33929)
$ bundle install --retry 3 --jobs 4
Bundle completo! 160 dependências do Gemfile, 207 gems agora instaladas.
Gems nos grupos 'test' e 'development' não foram instaladas.
Gems empacotados são instalados em './vendor/bundle'
3 gems instaladas que você depende diretamente estão procurando por financiamento.
Execute `bundle fund` para detalhes
$ if [ -f yarn.lock ]; then yarn install; else CI=1 pnpm install; fi
Escopo: todos os 16 projetos de espaço de trabalho
O lockfile está atualizado, o passo de resolução foi pulado
Já está atualizado
Concluído em 2.9s usando pnpm v9.15.9
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-custom-wizard já está na versão compatível mais recente
docker_manager já está na versão compatível mais recente
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
O migrador multisite está em execução usando 1 threads
Migrando o padrão
Populando o padrão
*** Empacotando assets. Isso levará um tempo ***
$ bundle exec rake themes:update assets:precompile
Atualizando temas com concorrência: 10
[db:default] 'Air Theme' - verificando...
[db:default] 'Air Theme' - atualizado
[db:default] 'Modern Category + Group Boxes' - verificando...
[db:default] 'Modern Category + Group Boxes' - atualizado
[db:default] 'Clickable Topic' - verificando...
[db:default] 'Clickable Topic' - atualizado
[db:default] 'Search Banner' - verificando...
O limite de heap_size do Node.js é menor que 2048MB. Definindo --max-old-space-size=2048 e CHEAP_SOURCE_MAPS=1
O build existente não é reutilizável.
- Existente: {"ember_env"=>"production", "core_tree_hash"=>"cd74e4ac33647244c041061633d6ca67f9166e5c"}
- Atual: {"ember_env"=>"production", "core_tree_hash"=>"7ac67590cc51e22690a2711b593892cd1d266781"}
Executando build completo do core...
Construindo
Ambiente: production
A configuração 'staticAddonTrees' terá o valor padrão true na próxima versão do Embroider e não poderá ser desativada. Para se preparar para isso, você deve definir 'staticAddonTrees: true' em sua configuração do Embroider.
A configuração 'staticAddonTestSupportTrees' terá o valor padrão true na próxima versão do Embroider e não poderá ser desativada. Para se preparar para isso, você deve definir 'staticAddonTestSupportTrees: true' em sua configuração do Embroider.
construindo...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] Aviso: O gerador de código desotimizou a estilização de /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js pois excede o máximo de 500KB.
[BABEL] Aviso: O gerador de código desotimizou a estilização de /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js pois excede o máximo de 500KB.
...[Babel: @glimmer/component > applyPatches]
...[Babel: @ember/test-waiters > applyPatches]
...[Babel: ember-this-fallback > applyPatches]
...[Babel: ember-cache-primitive-polyfill > applyPatches]
...[Babel: select-kit > applyPatches]
...[@embroider/compat/app]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
undefined
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Comando foi encerrado com SIGKILL (Terminação forçada): ember build -prod
/var/www/discourse/script/assemble_ember_build.rb:103:in `system': Comando falhou com saída 1: pnpm (RuntimeError)
from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>'
Docker Manager: FALHA AO ATUALIZAR
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:211:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:112:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `block in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2/lib/active_support/execution_wrapper.rb:91:in `wrap'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:70:in `conditional_executor'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:178:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor.rb:538:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:73:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:65:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:143:in `with_argv'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:63:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands.rb:18:in `<main>'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.18.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
Iniciando 1 worker(s) do Unicorn que foram parados inicialmente
tanto no preço quanto na RAM, sem mencionar o espaço em disco, etc.