У меня был большой сайт, который неоднократно не удавалось запустить. Это установка с двумя контейнерами, поэтому старый контейнер продолжал работать, пока происходила миграция при запуске. В конце концов я решил проблему, включив SKIP_POST_DEPLOYMENT_MIGRATIONS=1 для процесса запуска, а затем запустив миграции после того, как новый контейнер был поднят. С параметром SKIP_POST_DEPLOYMENT_MIGRATIONS=1 в секции ENV миграция прошла очень быстро, и сайт смог функционировать нормально (хотя, возможно, медленнее), пока выполнялись миграции, что заняло, по-моему, более 20 минут.
Я думаю, но ещё не проверил, что использование этого же приёма позволит минимизировать время простоя и при установке с одним контейнером. Если я прав, то нужно сделать следующее:
- добавить
SKIP_POST_DEPLOYMENT_MIGRATIONS=1в вашapp.yml - ./launcher rebuild app
- ./launcher enter app
- SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate
- отменить изменения в
app.yml, если только вы не планируете помнить о необходимости выполнять миграции после каждого обновления - возможно, снова выполнить rebuild, чтобы убедиться, что у вас не возникнет проблем, пока вы ещё помните, что могло сломать ваш сайт. Иначе, например, через 4 месяца, когда вы снова попробуете, вы не будете знать, что случилось, и кому-то будет трудно догадаться, в чём проблема.
Если бы существовал способ передавать SKIP_POST_DEPLOYMENT_MIGRATIONS=1 через ./launcher без необходимости редактировать app.yml, это сделало бы процесс менее неудобным для тех, кто испытывает трудности с редактированием.
Если мне удастся выполнить эту работу, о которой я думаю, я создам новую тему и сообщу о своих находках. Хотя дым загнал меня в комнату, где у меня нет большого монитора. (Пандемии было недостаточно?! Нам ещё и дым нужен? И я даже не особенно близко к этому проклятому огню.)