Я обновил свои сайты с версии 3.1.0.beta1 до 3.1.0.beta2. После инициализации новой версии, но до удаления старых контейнеров приложений и запуска новых, хотя бы один из этих сайтов начал показывать пользователям общую страницу ошибки.
На моём тестовом сайте и на других сайтах, которые я поддерживаю, я этого не заметил, но возможно, что это произошло, и я просто не обратил внимания.
В любом случае, по крайней мере в одном случае у меня процесс обновления с «нулевым временем простоя» не удался.
Я хотел бы ещё раз подчеркнуть, что я не использовал графический интерфейс обновлений. У меня установка с несколькими контейнерами. Я выполнил:
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
(Я использую app для веб-приложения даже в установках с несколькими контейнерами. Знаю, что это не стандартная практика. Я ненавижу вводить web_only)
Некоторое время после запуска bootstrap и до уничтожения приложения старая версия, работающая с новой базой данных, показывала только экран ошибки. Я не помню содержания, и я не стал создавать дополнительную простои, останавливаясь, чтобы сделать скриншот перед выполнением destroy/start, но это был просто текст на белом фоне, и это не была страница системного обслуживания. Я видел это лишь несколько раз раньше: когда bootstrap запускает db:migrate как часть асинхронной «перестройки без простоя», старое программное обеспечение, всё ещё работающее, падает из-за несоответствия схемы.
То, что я увидел, — это то, что происходит в случае несоответствия базы данных. Это намного лучше, чем бездумно продолжать работу и сломать базу данных! Я опубликовал это сообщение, чтобы предупредить, что это один из тех редких случаев, когда применение точечного обновления (здесь с 3.1.0.beta1 до 3.1.0.beta2) создаёт несовместимость схемы между кодом 3.1.0.beta1 и базой данных после выполнения db:migrate версии 3.1.0.beta2, что случается редко, но иногда происходит при обычных обновлениях с минимальным простоем в развёртывании с несколькими контейнерами.
Мой опыт отличается от ошибки, о которой сообщалось в отношении Ruby в графическом интерфейсе обновлений. Это совершенно другая проблема. Я понимаю, что мой пост был перемещён из объявления в общую тему «проблемы с», но я хочу чётко заявить, что причина, по которой я опубликовал его в объявлении, заключалась в том, чтобы предупредить других администраторов, осуществляющих самостоятельное размещение, как я, когда они увидят объявление, что это конкретное обновление могло иметь такое воздействие.
Моё сообщение не было жалобой на ошибку или даже проблему. Оно было намеренно опубликовано только как уведомление о нормальной, но редкой ситуации, связанной с этим конкретным выпуском и не указанной в примечаниях к выпуску.
Жалобы на то, что Docker Manager не распознаёт невозможность обновления изнутри образа, совершенно не связаны с моей попыткой предоставить полезное уведомление другим администраторам, осуществляющим самостоятельное размещение.
Было бы очень логично разделить эти несвязанные проблемы на независимые темы для независимых проблем. РЕДАКТИРОВАНО пользователем @supermathie: Готово
Вы выполняете двухэтапную миграцию с помощью Introducing Post Deployment Migration?
Этот паттерн критически важен, если вы используете, например, сине-зеленое развертывание и вам нужно, чтобы предыдущая версия продолжала работать.
Кажется, это отвечает на вопрос. Скрипт launcher не поддерживает переменную SKIP_POST_DEPLOYMENT_MIGRATIONS.
Ещё раз: я не сообщаю об ошибке. Просто пытаюсь предупредить других, использующих стандартную установку с несколькими контейнерами по обычной документированной процедуре работы с launcher в многоконтейнерной среде, что этот случай отличается от их типичного опыта.
Честно, действительно, искренне, я имею в виду это: это не отчёт об ошибке!
Если я хочу использовать стратегию blue/green развертывания с launcher, мне следует предоставить PR для launcher, чтобы реализовать эту функцию. 
Я не придумывал «проблему» в заголовке темы; это произошло, когда мой комментарий был перемещён из ветки объявления. Я теперь изменил заголовок, чтобы, надеюсь, стало ясно, что я не жалуюсь на проблему.
Всё отлично!
Полагаю, что очень небольшое количество пользователей использует стратегию blue/green с несколькими контейнерами, но мы будем рады предложениям о том, как это реализовать.
А также, как найти тему, на которую я дал ссылку; подозреваю, что её непросто найти, если не знаешь заранее о её существовании.
Я уже видел документацию по SKIP_POST_DEPLOYMENT_MIGRATIONS. Но то, что я действительно упустил, — это пост, в котором показано, как выполнять развертывания без простоя с помощью launcher:
Теперь, зная, что это возможно, мне нужно обдумать этот вопрос. Если я решу это реализовать, я обновлю MKJ's Opinionated Discourse Deployment Configuration, описав свои действия.
Мне очень сложно волноваться по этому поводу, учитывая, что я обеспечиваю доступность сервиса на уровне четырёх девяток (а иногда и четырёх с половиной), который я бесплатно поддерживаю в своё свободное время. Это говорит о качестве разработки Discourse: я могу работать по политике «только после успешного прохождения тестов», включая такие моменты, как лишняя минута простоя, которую я наблюдал на этот раз, или даже перезагрузка хоста для установки обновлений безопасности.
Ansible-скрипт, используемый dashboard.literatecomputing.com, запускает задачу rake после запуска нового контейнера для выполнения пост-миграций. Он рассчитывает на то, что в файле web_only.yml включена переменная SKIP_POST_DEPLOYMENT_MIGRATIONS. Я делаю это только на сайтах, которые, как я знаю, будут управляться моими скриптами, так как если вы не понимаете, как это работает, это может стать бомбой замедленного действия.
Обратите внимание, что для многих обновлений запуск нового контейнера не нарушит работу запущенного контейнера, но для некоторых это так. Не редкость, когда обновление приводит к миграции, из-за которой старый контейнер не может использовать базу данных (без использования SKIP_POST_DEPLOYMENT_MIGRATIONS).