Atualizei meus sites de 3.1.0.beta1 para 3.1.0.beta2, e após inicializar a nova versão, mas antes de destruir os contêineres da aplicação antiga e iniciar novos, pelo menos um desses sites começou a apresentar a página de erro genérica aos usuários.
Não notei isso no meu site de teste ou nos outros sites que administro, mas é possível que tenha acontecido e eu não tenha visto.
Em qualquer caso, para mim, em pelo menos um caso, o processo de atualização “zero downtime” não foi bem-sucedido.
9 posts foram divididos em um novo tópico: Problemas com upgrade auto-hospedado para 3.x: não é possível reverter
Uma postagem foi mesclada em um tópico existente: Problemas com upgrade auto-hospedado para 3.x: não é possível reverter
Gostaria de repetir que eu não estava usando o atualizador gráfico. Eu tenho uma instalação multi-container. Eu fiz:
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
(Eu uso app para o aplicativo web mesmo para instalações multi-container. Eu sei que não é a prática normal. Eu odeio digitar web_only)
Algum tempo depois que eu iniciei o bootstrap e antes de destruir o aplicativo, a versão antiga rodando contra o novo banco de dados mostrou apenas uma tela de erro. Eu não me lembro do conteúdo, e eu não criei uma interrupção mais longa parando para tirar um print screen antes de fazer o destroy/start, mas era apenas texto em branco e não era a página de manutenção do sistema. Eu vi isso apenas algumas vezes antes, que quando o bootstrap executa db:migrate como parte da reconstrução assíncrona de “zero downtime”, o software antigo ainda rodando falha devido a uma inconsistência de esquema.
O que eu vi foi o que quer que aconteça no caso de inconsistência do banco de dados. Isso é muito melhor do que continuar pacificamente, quebrando o banco de dados! Quando eu postei, foi para avisar que este era um daqueles casos raros em que a aplicação de uma atualização pontual (aqui de 3.1.0.beta1 para 3.1.0.beta2) criou uma incompatibilidade de esquema entre o código 3.1.0.beta1 e o banco de dados após a execução do db:migrate do 3.1.0.beta2, como acontece raramente, mas ocasionalmente com as atualizações normais de baixa interrupção na implantação multi-container.
Minha experiência é diferente do erro que foi relatado com ruby no atualizador gráfico. É um problema completamente não relacionado. Reconheço que minha postagem foi movida do anúncio para um tópico geral de “problemas com”, mas quero deixar claro que o motivo pelo qual a postei no anúncio foi para avisar outros auto-hospedeiros como eu quando eles vissem o anúncio que esta atualização em particular era uma que poderia ter este impacto.
Minha mensagem não foi uma reclamação sobre um bug, ou mesmo um problema. Foi destinada apenas como um aviso de um caso normal, mas infrequente, associado a esta versão em particular e não destacado nas notas de lançamento.
As reclamações sobre o gerenciador docker não reconhecer que ele não pode atualizar de dentro da imagem são completamente não relacionadas à minha tentativa de fornecer uma notificação útil para outros administradores de auto-hospedagem.
Faria muito sentido separar essas questões não relacionadas em tópicos independentes para problemas independentes. EDIT por @supermathie: Feito
Você está fazendo uma migração de dois estágios com Introducing Post Deployment Migration?
Este padrão é crítico se você estiver fazendo, por exemplo, uma implantação azul/verde e precisar que a versão anterior continue funcionando.
Eu acho que isso responde à pergunta. O script launcher não tem suporte para SKIP_POST_DEPLOYMENT_MIGRATIONS
Novamente, não estou relatando um bug. Apenas tentando alertar outros com a instalação padrão multi-container usando o processo documentado normal para usar launcher com uma instalação multi-container que esta é diferente da experiência típica deles.
Realmente, verdadeiramente, honestamente, eu quero dizer, este não é um relatório de bug!
Se eu quiser implantação azul/verde com launcher, devo fornecer um PR para launcher para implementá-la. 
Eu não criei o “problema” no título do tópico; isso foi feito quando meu comentário foi movido do tópico de anúncio. Modifiquei o título para deixar claro, espero, que não estou reclamando de um problema.
Tudo bem!
Suspeito que haja um número muito pequeno de usuários fazendo blue/green com vários contêineres, mas agradeceríamos sugestões sobre como fazer isso.
E também, como encontrar o tópico que eu linkei; suspeito que não seja fácil de encontrar se alguém não souber que ele existe.
Eu tinha visto a documentação do SKIP_POST_DEPLOYMENT_MIGRATIONS. O que eu realmente tinha perdido era esta postagem que mostra como fazer implantações sem tempo de inatividade com launcher:
Então, agora tenho que pensar sobre isso, já que sei que é viável. Se eu fizer isso, atualizarei MKJ's Opinionated Discourse Deployment Configuration com o que eu fizer.
Tenho tido muitos problemas para me animar com isso quando estou fornecendo quatro, alguns meses quatro e meio noves de disponibilidade em um serviço que administro gratuitamente no meu tempo livre. É um testemunho da qualidade do desenvolvimento do Discourse que eu possa fazer isso com uma política de testes aprovados, incluindo coisas como o minuto extra de inatividade que vi desta vez, e às vezes reiniciando o host para atualizações de segurança.
O script ansible que dashboard.literatecomputing.com usa executa uma tarefa rake após o novo contêiner ser iniciado para fazer as migrações pós-implantação. Ele conta com SKIP_POST_DEPLOYMENT_MIGRATIONS ativado em web_only.yml. Eu faço isso apenas em sites que sei que serão gerenciados por meus scripts, pois se você não entender como funciona, pode ser uma bomba-relógio.
Note que para muitas atualizações, inicializar o novo contêiner não quebrará as coisas para o contêiner em execução, mas para algumas sim. Não é incomum que uma atualização migre de tal forma que o contêiner antigo não possa usar o banco de dados (sem usar SKIP_POST_DEPLOYMENT_MIGRATIONS).