Uma organização sem fins lucrativos com a qual trabalho tem uma instalação do Discourse 2.9.0.beta1, cuja manutenção ficou comigo quando o administrador original se afastou. Ao tentar atualizar as credenciais SMTP, descobri que a instalação não pode se reconstruir nem atualizar com segurança, via web ou linha de comando. (Se eu não tivesse um backup recente da instância feito antes do início do trabalho, este teria sido um momento ruim.) O problema parece ocorrer bem no fundo do Ruby, e posso capturar logs se parecerem úteis.
Pensei que talvez estivesse muito antiga para atualizar graciosamente, então tentei um processo de recuperação em vez disso, criando uma nova instância Discourse e, em seguida, carregando o backup mais recente do fórum nela, mas esse processo também falhou inconclusivamente, com o que acho que foram erros de coluna de banco de dados antes que o processo de atualização ficasse sem resposta.
Qual seria a melhor maneira de prosseguir a partir de onde estamos? O fórum está atualmente funcional neste minuto, mas não consigo atualizar nem, aparentemente, usar um backup. Devo continuar tentando a recuperação, devo redobrar meus esforços para atualizar e capturar logs para começar, ou há uma terceira opção que não vejo?
Você precisa mover para uma nova máquina virtual. É provável que seu sistema operacional seja muito antigo para atualizar o Docker para uma versão suportada.
É melhor mover para uma nova VM que estará em hardware mais novo, mais rápido e mais barato.
A versão do Docker não parece ter desempenhado um papel no colapso das compilações do Ruby, mas suponho que seja possível. As extrações do Docker que fizeram parte da reconstrução não apresentaram nenhum estado de falha excepcional. Isso parece que posso tentar, no entanto. Obrigado pela resposta!
Sua migração foi um pouco mais complicada porque você tinha backups no S3 configurados no banco de dados em vez de em variáveis de ambiente, como descrito em Configurar um provedor de armazenamento de objetos compatível com S3 para uploads (embora isso seja para uploads, então você precisaria não usar a configuração use_s3, apenas o bucket e a localização de backup. EDIT: E então a restauração falhou porque sua EC2 não tem acesso de gravação ao bucket.
Ter um balanceador de carga na frente do seu site também muda as coisas em relação à maioria das pessoas.
E como suas credenciais são para a EC2 em vez de tê-las no banco de dados ou no arquivo YML, a restauração não pode ser concluída.