Eu definitivamente não estou tentando transferir a culpa. O problema com a auto-hospedagem, mais especificamente, não é necessariamente entender o SO (sistema operacional) do servidor. A maioria das pessoas instala um SO e geralmente o mantém atualizado. Mas, frequentemente, com o LTS (suporte de longo prazo), pode não saber ou entender como atualizar o SO, especialmente se estiver acostumada com lançamentos contínuos.
Por exemplo, uma empresa que ajudo, após não atualizar por um tempo, notou que havia uma atualização disponível. Então, eles atualizaram o Docker através da interface web, o que então permitiu que atualizassem o Discourse.
Devido ao Ubuntu LTS não ser novo o suficiente, a atualização do Docker não atendia ao requisito mínimo. A interface web ainda permitiu a tentativa de atualização, que, obviamente, falhou e derrubou o site.
Então, eles tentaram uma reconstrução pela linha de comando, que, obviamente, falhou devido aos requisitos mínimos não serem atendidos.
Se a atualização na web identificasse que a versão do Docker não era a mínima, poderia ter abortado o processo de atualização, notificando uma dependência não atendida, sem que o site caísse.
Dei uma olhada geral para eles. Como parece que eles podem estar executando outras coisas no servidor, instruí-os a pedir para o técnico deles verificar a atualização do LTS para uma versão mais recente, pois eu não queria tentar atualizar o SO, caso isso quebrasse outras coisas que eles estão executando.
Existe uma maneira fácil de reiniciar o contêiner antes da tentativa de reconstrução via web e linha de comando?
Eu tentei ./launcher start app
O que falhou.
A outra coisa. Devido a como o site Discourse caiu, iniciar um novo servidor com rsync funcionaria? Eles estão executando a versão estável em vez dos testes aprovados recomendados.
Se eles executarem o ‘: ‘do-release-upgrade’’ e atualizarem o Docker manualmente, isso seria eficaz para atualizar o PostgreSQL?
