не троллинг, просто интересно. ни разу не видел

Откат на предыдущую версию - это всегда боль, по-моему большинство разработчиков даже не думаю об этом при разработке.

Не применительно к докеру

ну я так понимаю, все заавтоматизировано аж до не могу, но в этом случае все равно не забудь docker-run manage.py migrate ручками и блаблабла?

Откат на предыдущую версию - это всегда боль, по-моему большинство разработчиков даже не думаю об этом при разработке.

ну допустим думали и в alembic всё нужное прописано, надо просто дернуть. "вверх" - дернуть, "вниз" - дернуть, если предыдущая версия image деплоится. как делают? руками? в dockerfile?

как это сделает alembic, господи прости, примерно понятно

Я не знаю - у меня нет докера в проде)

как вариант можно в качестве entry point указать скрипт, который будет запускать миграции, собирать статику, а потом uwsgi поднимать

можно просто в vars сунуть номер нужной миграции и при проходе плейбука свериться и накатить/откатить

хотя может это и так себе идея )

как вариант можно в качестве entry point указать скрипт, который будет запускать миграции, собирать статику, а потом uwsgi поднимать

хм, ну вариант

да идея норм, главное, чтобы скрипт у остальных бэкендов базу из-под ног не выбил, сдаунгрейдив, пока они еще работают :)

да идея норм, главное, чтобы скрипт у остальных бэкендов базу из-под ног не выбил, сдаунгрейдив, пока они еще работают :)

Сначала надо даунгрейдить скрипты, а потом базу отказывать. Иначе да, может быть конфуз.

то есть вся крутая докер машинерия сваливается обратно в "не забудь руками"

Ну со своим lxc и deb-пакетами я тоже буду сидеть и руками базу откатывать, разницы тут не много

ну да, мы и так это делаем

но нам рассказывают кулстори, как у них все крутяшеньки, одной командой обновились, что-то пошло не так, одной командой, не приходя в сознание спросонья откатились обратно :)

но нам рассказывают кулстори, как у них все крутяшеньки, одной командой обновились, что-то пошло не так, одной командой, не приходя в сознание спросонья откатились обратно :)

Blue/green deployment?

Выключай на балансере

это чит :)

вторую базу поднимать, ну

вообще лучше делать так, чтобы базу можно было бы не мигрировать назад

тогда обеспечивай обратную совместимость в рамках одной

на нее запускать миграции, стартовать, проверять, пошло не так, возвращаем sql демон со старой базой :)

это все хоть с докером, хоть без докера

то есть можно включать фичи не сразу, а потом

я это все к чему. мир устроен сложнее, чем в "простых примерах", так что когда запеваешь песню про "все просто" и "одной командой", фитиль стоит иногда прикрутить. вот и все :)

и по условию

например, включать фичи не всем пользователям

а только 10%

если что-то не так - отключаем им

ну то есть можно писать код так, чтобы новые фичи поступали не сразу после деплоя нового контейнера, а когда менеджер в админке разрешит

фичи тут причем

если что-то не так - отключаем им

Может быть баг в общем коде

просто такой подход минимизирует ущерб

Может быть баг в общем коде

да, тут, видимо, откат

вообще не про фичи речь

ну я к тому, что если баг в новой фиче - просто не включайте её, без отката, и всё

(глубоко вздыхает)

и еще - если версии идут часто, частый деплой, то новая структура базы данных вполне может работать со старой версией кода

то есть можно в большинстве случаев писать так, чтобы новый код работал как с новой структурой базы, так и со старой

но если и это не получается - да, миграции, их можно откатывать

(глубоко вздыхает еще раз)

но тут могут потеряться данные

спасибо, достаточно. букварь вслух можно не читать.

так а про что вопрос-то?

про то, как это руками не делать? при старте контейнера есть скрипт, который в ENTRYPOINT, вы туда можете что угодно написать, в том числе код для отката миграций

и там же можно предусмотреть вариант, что делать, если нормально оно не откатилось

мда)

дешевле всего - просто по ночам обновлять, останавливаем трафик на сервис, показываем заглушку "на облсуживании", делаем бэкап базы, перезапускаем сервис, делаем миграции, если фейл - восстанавливаемся из бэкапа, запускаем сервис снова, снова пускаем трафик

ну, будет оффлайн 10 минут с сообщением "Технические работы", подождут, ишь, какие господа...

по ночам в каком часовом поясе? (стикер хитрой жопы)

это нужно смотреть на статистику посещаемости

когда людей меньше заходит - тогда и ночь))

нужно повесить перед собой табличку "докер - не серебряная пуля, одной командой не справишься" и читать ее каждый день. когда захочется написать PR-херню в телеграме :)

так а причем тут докер?

докер позволяет сделать билд и протестировать его локально, протестировать обновление то же.. и это будет проще, чем тестировать обновление сервера

дешевле всего - просто по ночам обновлять, останавливаем трафик на сервис, показываем заглушку "на облсуживании", делаем бэкап базы, перезапускаем сервис, делаем миграции, если фейл - восстанавливаемся из бэкапа, запускаем сервис снова, снова пускаем трафик

В игровых проектах вроде MMO так и делают, в вебе что-то не видел пока. Будет странно если, например, Яндекс или Гугл на 10 минут повесят заглушку "на обслуживании, призодите позже".

а не обязательно всё сразу обновлять

"XXX позволяет сделать билд и протестировать его локально, протестировать обновление то же.. и это будет проще, чем тестировать обновление ..."

просто иметь две версии сервиса и писать так, чтобы оно не глючило

вторую базу поднимать, ну

Да вот чот нет

просто иметь две версии сервиса и писать так, чтобы оно не глючило

ахаха

ну теперь всё стало просто :)

можно фичи от миграции базы отделить

Да просто плохой код не пишите

то есть включать фичи, только когда все серверы обновили базу

ERROR: S client not available

А пишите хороший

А пишите хороший

Плюс мильён

точняк. Писать плохо - плохо, надо писать хорошо чтобы было хорошо

чтобы писать хороший код, а не писать плохой, всем докер, посоны

(с)

и вообще не надо делать всё что плохо, надо делать всё что хорошо

Нормально делай - нормально будет

Простите)

да-да. чтобы ровно всё. чотенько!

что такое изменение структуры базы данных? это или создание чего-то нового или изменение чего-то существующего или удаление чего-то старого

почему оно вообще должно глючить?

Индекс не навесил

Вот и пипенций настал

можно не менять существующее и не удалять старое

слушай, ты кроме вордпресса ченить запускал? :)

а при добавлении нового глюков не будет

можно не менять существующее и не удалять старое

Так и делаем

а при добавлении нового глюков не будет

Будут

ну, меньше вероятность

слушай, ты кроме вордпресса ченить запускал? :)

вот меня часто тоже такой вопрос интересует когда в этом чатике общаюсь

Ну - меньше вероятность, да

то есть у нас есть версия 1.0, работает на продакшене, потом делаем версию 1.1, добавляем еще табличек, которые будем использовать в версии 1.2

а потом в версии 1.3 удаляем все и делаем по-другому

ох

ненене, дэвид блейн. давай старые таблички менять,

давай у тебя будет база платежей

каждая запись один платёж

вот есть у тебя господи прости ORM, программисты добавили в модель новое поле, сразу поехала миграция с alter table на добавление колонки

вот есть у тебя господи прости ORM, программисты добавили в модель новое поле, сразу поехала миграция с alter table на добавление колонки

вот что б такого не было есть девопс практики :)

ты ненакатил базу, обновляешь первый бэкенд, он сразу падает, потому что не может найти колонку

чешешь репу, накатываешь базу, новый бэкенд начинает работать, старый ломается, потому что в этом релизе была еще одна миграция, не скажу какая :)