Sergey
Не применительно к докеру
Dmitry
ну я так понимаю, все заавтоматизировано аж до не могу, но в этом случае все равно не забудь docker-run manage.py migrate ручками и блаблабла?
Dmitry
Откат на предыдущую версию - это всегда боль, по-моему большинство разработчиков даже не думаю об этом при разработке.
ну допустим думали и в alembic всё нужное прописано, надо просто дернуть. "вверх" - дернуть, "вниз" - дернуть, если предыдущая версия image деплоится.
как делают? руками? в dockerfile?
Dmitry
как это сделает alembic, господи прости, примерно понятно
Sergey
Я не знаю - у меня нет докера в проде)
Danil
как вариант можно в качестве entry point указать скрипт, который будет запускать миграции, собирать статику, а потом uwsgi поднимать
Dmitry
можно просто в vars сунуть номер нужной миграции и при проходе плейбука свериться и накатить/откатить
Danil
хотя может это и так себе идея )
Dmitry
Dmitry
да идея норм, главное, чтобы скрипт у остальных бэкендов базу из-под ног не выбил, сдаунгрейдив, пока они еще работают :)
Sergey
да идея норм, главное, чтобы скрипт у остальных бэкендов базу из-под ног не выбил, сдаунгрейдив, пока они еще работают :)
Сначала надо даунгрейдить скрипты, а потом базу отказывать. Иначе да, может быть конфуз.
Dmitry
то есть вся крутая докер машинерия сваливается обратно в "не забудь руками"
Sergey
Ну со своим lxc и deb-пакетами я тоже буду сидеть и руками базу откатывать, разницы тут не много
Dmitry
ну да, мы и так это делаем
Dmitry
но нам рассказывают кулстори, как у них все крутяшеньки, одной командой обновились, что-то пошло не так, одной командой, не приходя в сознание спросонья откатились обратно :)
Alexander 🐕
Alexander 🐕
Выключай на балансере
Dmitry
это чит :)
Dmitry
вторую базу поднимать, ну
Alexander
вообще лучше делать так, чтобы базу можно было бы не мигрировать назад
Danil
тогда обеспечивай обратную совместимость в рамках одной
Dmitry
на нее запускать миграции, стартовать, проверять, пошло не так, возвращаем sql демон со старой базой :)
Dmitry
это все хоть с докером, хоть без докера
Alexander
то есть можно включать фичи не сразу, а потом
Dmitry
я это все к чему. мир устроен сложнее, чем в "простых примерах", так что когда запеваешь песню про "все просто" и "одной командой", фитиль стоит иногда прикрутить.
вот и все :)
Alexander
и по условию
Alexander
например, включать фичи не всем пользователям
Alexander
а только 10%
Alexander
если что-то не так - отключаем им
Alexander
ну то есть можно писать код так, чтобы новые фичи поступали не сразу после деплоя нового контейнера, а когда менеджер в админке разрешит
Dmitry
фичи тут причем
Alexander
просто такой подход минимизирует ущерб
Dmitry
вообще не про фичи речь
Alexander
ну я к тому, что если баг в новой фиче - просто не включайте её, без отката, и всё
Dmitry
(глубоко вздыхает)
Alexander
и еще - если версии идут часто, частый деплой, то новая структура базы данных вполне может работать со старой версией кода
Alexander
то есть можно в большинстве случаев писать так, чтобы новый код работал как с новой структурой базы, так и со старой
Alexander
но если и это не получается - да, миграции, их можно откатывать
Dmitry
(глубоко вздыхает еще раз)
Alexander
но тут могут потеряться данные
Dmitry
спасибо, достаточно. букварь вслух можно не читать.
Alexander
так а про что вопрос-то?
Alexander
про то, как это руками не делать? при старте контейнера есть скрипт, который в ENTRYPOINT, вы туда можете что угодно написать, в том числе код для отката миграций
Alexander
и там же можно предусмотреть вариант, что делать, если нормально оно не откатилось
Seva
мда)
Alexander
дешевле всего - просто по ночам обновлять, останавливаем трафик на сервис, показываем заглушку "на облсуживании", делаем бэкап базы, перезапускаем сервис, делаем миграции, если фейл - восстанавливаемся из бэкапа, запускаем сервис снова, снова пускаем трафик
Alexander
ну, будет оффлайн 10 минут с сообщением "Технические работы", подождут, ишь, какие господа...
Dmitry
по ночам в каком часовом поясе? (стикер хитрой жопы)
Alexander
это нужно смотреть на статистику посещаемости
Alexander
когда людей меньше заходит - тогда и ночь))
Dmitry
нужно повесить перед собой табличку "докер - не серебряная пуля, одной командой не справишься" и читать ее каждый день. когда захочется написать PR-херню в телеграме :)
Alexander
так а причем тут докер?
Alexander
докер позволяет сделать билд и протестировать его локально, протестировать обновление то же.. и это будет проще, чем тестировать обновление сервера
Sergey
дешевле всего - просто по ночам обновлять, останавливаем трафик на сервис, показываем заглушку "на облсуживании", делаем бэкап базы, перезапускаем сервис, делаем миграции, если фейл - восстанавливаемся из бэкапа, запускаем сервис снова, снова пускаем трафик
В игровых проектах вроде MMO так и делают, в вебе что-то не видел пока. Будет странно если, например, Яндекс или Гугл на 10 минут повесят заглушку "на обслуживании, призодите позже".
Alexander
а не обязательно всё сразу обновлять
Dmitry
"XXX позволяет сделать билд и протестировать его локально, протестировать обновление то же.. и это будет проще, чем тестировать обновление ..."
Alexander
просто иметь две версии сервиса и писать так, чтобы оно не глючило
Seva
ну теперь всё стало просто :)
Alexander
можно фичи от миграции базы отделить
Alexander 🐕
Да просто плохой код не пишите
Alexander
то есть включать фичи, только когда все серверы обновили базу
Alexander 🐕
А пишите хороший
Seva
точняк. Писать плохо - плохо, надо писать хорошо чтобы было хорошо
Dmitry
чтобы писать хороший код, а не писать плохой, всем докер, посоны
Dmitry
(с)
Seva
и вообще не надо делать всё что плохо, надо делать всё что хорошо
Alexander 🐕
Нормально делай - нормально будет
Sergey
Sergey
Простите)
Dmitry
да-да. чтобы ровно всё. чотенько!
Alexander
что такое изменение структуры базы данных? это или создание чего-то нового или изменение чего-то существующего или удаление чего-то старого
Alexander
почему оно вообще должно глючить?
Alexander 🐕
Индекс не навесил
Alexander 🐕
Вот и пипенций настал
Alexander
можно не менять существующее и не удалять старое