Думаю, так и есть 
Подождите, пока этот PR будет принят, затем следуйте инструкциям по ссылке:
Около 100 Гб 
сделаю
Итак, когда я думаю об автоматизации этого обновления, приходит в голову, что определение момента для выполнения этого пропуска пост-развертывания — задача довольно сложная.
Для установок с одним контейнером, если только не происходит какая-то странная миграция (о такой я не слышал за свои 4 года), нет преимуществ в таком подходе. Большинство обновлений включают лишь несколько миграций, и вряд ли среди них есть вычислительно затратные.
Для установок с двумя контейнерами всегда разумно использовать SKIP_POST_DEPLOYMENT_MIGRATIONS, так как вы можете отключить сайт, если миграции сломают работающий контейнер, что снижает привлекательность возможности инициализации нового контейнера, пока старый продолжает работать. НО даже в этом случае не каждое обновление включает миграции, которые что-то ломают, поэтому решение с двумя перезагрузками, предлагаемое этим (очень полезным) коммитом, скорее всего, приведет к большему времени простоя (два цикла перезагрузки), чем просто работа на грани.
Моя текущая мысль такова: лучшим решением было бы всегда выполнять миграции при инициализации с SKIP_POST_DEPLOYMENT_MIGRATIONS=1, а затем выполнять миграцию при первой загрузке. Однако у меня пока нет элегантного способа реализовать это. Есть ли быстрый способ определить, ожидаются ли миграции? Думаю, скрипт загрузки мог бы добавить условие если ожидаются миграции, выполни их сразу после запуска unicorn? Это довольно хлопотно, и, скорее всего, не стоит того для большинства установок в большинстве случаев.
Определенно не стоит этого делать в большинстве случаев, но если обновления вашего программного обеспечения редко (но иногда) занимают в 10 раз больше времени, чем обычно, это реальная проблема для многих пользователей.
После этого я не буду запускать обновления Discourse как минимум через неделю после выпуска. Конечно, можно сказать, что я идиот, что не стал ждать изначально, что сам во всём виноват, что должен был знать лучше, и всё это абсолютно верно! Тем не менее, сделать время обновлений более последовательным и предсказуемым было бы отличной услугой для всех остальных идиотов.
Альтернативный вариант — обновление через интерфейс с помощью docker_manager, который выполняет это автоматически.
Это здорово! Я практически никогда не обновляюсь таким способом, поэтому мне бы это в голову не пришло. Спасибо.
Извините, чтобы уточнить: если мы добавим эту переменную окружения в наш контейнер приложения:
Либо:
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
Или:
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
То при запуске launcher все миграции базы данных будут пропущены при пересборке?
Правильно ли я понимаю?
Не совсем. См. Introducing Post Deployment Migration
Привет! Мне удалось обновить всё этим способом (то есть через интерфейс), но после этого система начинает процесс развёртывания с инструкциями по миграции (те, которые были пропущены изначально), и всё это приводит к сбою через некоторое время с сообщением, что обновление не удалось. Однако форум работает как положено, а в панели администратора отображается, что всё обновлено.
Мой вопрос: нужно ли мне что-то ещё сделать? В частности, насчёт этого процесса развёртывания: нужно ли запускать его через командную строку (чтобы избежать сбоя)? Есть ли для этого какие-то специальные команды, и не сломает ли это форум во время выполнения?
У вас всё ещё есть соответствующие логи? Необходимо запустить миграции, иначе поиск на сайте перестанет работать.
./launcher enter app
bundle exec rails db:migrate
Логи отсутствуют, но это были те же самые запросы, о которых упоминалось ранее в этой теме.
Прежде чем я начну этот процесс и оставлю его работать, временно ли это нарушит работу сайта (как при пересборке) или это «безопасно»? Извините, что настаиваю на этом конкретном вопросе, но это производственный сайт, и простой в 10–15 минут допустим, однако простой в день или два недопустим и должен быть тщательно обдуман, если нет других вариантов.
Если вы уже обновились до последней версии, запуск миграций не приведет к простою вашего сайта. Под обновлением я подразумеваю, что новая версия была развернута, но пост-деплойная миграция, описанная в этой теме, не удалась.
Спасибо. В итоге я вернулся к обновлениям через интерфейс, попробовал ещё раз, и миграции базы данных после развёртывания действительно завершились. Это заняло несколько часов (и много процессорного времени 
), но они были выполнены, и теперь всё полностью обновлено! 