Acho que eles têm 
Aguarde que este PR seja mesclado e, em seguida, siga as etapas listadas:
Cerca de 100Gb 
farei isso
Então, ao pensar em automatizar essa atualização, percebo que saber quando fazer essa ação de pular a migração pós-implementação é bastante complicado.
Para instalações de único container, a menos que haja alguma migração bizarra (esta é a primeira que conheço em meus 4 anos), não há vantagem em fazer dessa maneira. A maioria das atualizações terá poucas migrações e, provavelmente, nenhuma que seja intensiva em computação.
Para instalações de dois containers, é sempre uma boa ideia usar SKIP_POST_DEPLOYMENT_MIGRATIONS, pois você pode desabilitar seu site se as migrações quebrarem o container em execução, o que remove parte da vantagem de poder inicializar o novo container enquanto o antigo continua rodando. MAS, mesmo assim, nem toda atualização inclui migrações que quebram coisas, então a solução de duas reinicializações fornecida por esse commit (muito bem-vindo) provavelmente resultará em mais tempo de inatividade (dois ciclos de reinicialização) do que simplesmente operar na borda.
Minha ideia atual é que uma solução melhor seria fazer com que o bootstrap sempre execute as migrações com SKIP_POST_DEPLOYMENT_MIGRATIONS=1 e, em seguida, execute uma migração na primeira inicialização. No entanto, não tenho uma solução elegante para como exatamente isso funcionaria. Existe uma maneira rápida de verificar se há migrações pendentes? Acredito que o script de inicialização poderia ter algo como se houver migrações pendentes, execute uma migração logo após iniciar o unicorn. Isso é bastante complicado, porém, e provavelmente não vale a pena para a maioria das instalações na maioria das vezes.
Definitivamente não vale a pena na maioria das vezes, mas se as atualizações do seu software raramente (mas às vezes) levam 10 vezes mais tempo que o normal, isso é um problema real para muitos usuários.
Depois disso, não farei atualizações do Discourse até pelo menos uma semana após o lançamento. Claro, você pode argumentar que sou um idiota por não ter esperado desde o início, que eu mesmo me meti nessa, que deveria saber melhor, e tudo isso está completamente correto! Ainda assim, tornar os tempos de atualização mais consistentes e previsíveis seria um grande favor para todos os outros idiotas por aí.
Alternativamente, a atualização via interface do usuário através do docker_manager lida com isso automaticamente.
Isso é incrível! Eu quase nunca atualizo dessa maneira, então nunca teria pensado nisso. Obrigado.
Desculpe, para esclarecer: se adicionarmos essa variável de ambiente ao nosso contêiner de aplicação:
Ou seja:
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
ou
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
Ao executar o launcher, ele irá pular todas as migrações do banco de dados quando fizermos a reconstrução?
Essa é a compreensão correta?
Não exatamente. Veja Introducing Post Deployment Migration
Olá, consegui atualizar tudo usando este método (ou seja, via interface), mas depois disso começa a executar esse processo de implantação com instruções de migração (aquele que havia sido ignorado desde o início) e assim por diante, e eventualmente falha, informando que a atualização não foi bem-sucedida. No entanto, o fórum funciona normalmente e o painel de administração mostra tudo como atualizado.
Minha pergunta é: preciso fazer mais alguma coisa? Especificamente sobre esse processo de implantação, preciso executá-lo via linha de comando (para evitar travamentos)? Existem comandos específicos para isso e isso irá interromper o fórum enquanto estiver em execução?
Você ainda tem os logs relevantes? É necessário executar as migrações, caso contrário a busca ficará quebrada no site.
./launcher enter app
bundle exec rails db:migrate
Sem logs, mas foram as mesmas consultas mencionadas anteriormente neste tópico.
Antes de iniciar esse processo e deixá-lo em execução, isso vai quebrar temporariamente o site (como uma reconstrução) ou é “seguro”? Peço desculpas por insistir nessa questão específica, mas este é um site de produção e uma indisponibilidade de 10 a 15 minutos é aceitável; no entanto, um ou dois dias não são, e devem ser cuidadosamente considerados caso não haja outras opções disponíveis.
Se você já atualizou para a versão mais recente, executar as migrações não causará nenhuma indisponibilidade no seu site. Por atualizado, quero dizer que a nova versão foi implantada, mas a migração pós-implantação descrita neste tópico falhou.
Obrigado. Acabei voltando às atualizações via interface, tentei mais uma vez e as migrações de banco de dados pós-implementação realmente foram concluídas. Levou várias horas (e muito uso de CPU 
), mas foram finalizadas e agora tudo está totalmente atualizado! 