Size: a a a

Django [ru] #STAY HOME

2019 February 14

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Jango Fett
Всем привет!
Изучаю вопрос накатывания миграций, с учетом того, что приложение крутится в контейнере. Есть несколько вариантов:
1. Засовывать python manage.py migrate в docker-entrypoint.sh (используется сейчас). Но тогда возникает проблема со скейлингом контейнеров. Получается, что при увеличении числа контейнеров - каждый раз включается миграция. А если при запуске второго контейнера процесс выполнения миграций в первом контейнере всё еще выполняется - хз что произойдет. lock? error?
2. Отдельный job в CI - перед деплоем запускать в билд-агенте миграции. Но что тогда произойдет с уже работающими контейнерами, при условии изменении таблицы?
3. Отдельный контейнер для выполнения миграций. Грубо говоря, в процессе деплоя рестартить контейнер (из CI), для запуска задачи.
Стек: docker-compose (пока так), gitlab, django.
Есть ли еще какие-то варианты? Какой из будет наиболее безболезненный?
код должен уметь работать с текущей версией структуры базы и с прошлой версией, миграции после обновления отдельно
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
и изменения структуры растянуты на несколько апдейтов
источник

АТ

Андрей Тихий in Django [ru] #STAY HOME
Народ привет. Очень срочно нужна помощь в Джанго. Я новичок поэтому для меня сложно, речь идёт о замене хтмл шаблонана 2х страницах на новый. Взялся за заказ, но понял что зелёный, неосилил половину, а именно - эту часть. То есть нужно просто правильно посадить новый шаблон на уже имеющуюся страницу. Если кому интересно, или кто-то согласится помочь, прошу напишите в личку. Естественно не бесплатно. Возможно пишу не в соответствии с правилами, прошу прощения, просто малость отчаяние.
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Alexander Ovchinnikov 🦁
код должен уметь работать с текущей версией структуры базы и с прошлой версией, миграции после обновления отдельно
в общем-то тесты на CI тоже можно запускать на двух версиях структуры базы
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Андрей Тихий
Народ привет. Очень срочно нужна помощь в Джанго. Я новичок поэтому для меня сложно, речь идёт о замене хтмл шаблонана 2х страницах на новый. Взялся за заказ, но понял что зелёный, неосилил половину, а именно - эту часть. То есть нужно просто правильно посадить новый шаблон на уже имеющуюся страницу. Если кому интересно, или кто-то согласится помочь, прошу напишите в личку. Естественно не бесплатно. Возможно пишу не в соответствии с правилами, прошу прощения, просто малость отчаяние.
попробуй спросить тут @django_jobs
источник

АТ

Андрей Тихий in Django [ru] #STAY HOME
Alexander Ovchinnikov 🦁
попробуй спросить тут @django_jobs
Попробовал, спасибо..
источник

JF

Jango Fett in Django [ru] #STAY HOME
Alexander Ovchinnikov 🦁
в общем-то тесты на CI тоже можно запускать на двух версиях структуры базы
Ну а какой из предложенных вариантов лучше использовать?
источник

vc

vadim chin in Django [ru] #STAY HOME
Jango Fett
Всем привет!
Изучаю вопрос накатывания миграций, с учетом того, что приложение крутится в контейнере. Есть несколько вариантов:
1. Засовывать python manage.py migrate в docker-entrypoint.sh (используется сейчас). Но тогда возникает проблема со скейлингом контейнеров. Получается, что при увеличении числа контейнеров - каждый раз включается миграция. А если при запуске второго контейнера процесс выполнения миграций в первом контейнере всё еще выполняется - хз что произойдет. lock? error?
2. Отдельный job в CI - перед деплоем запускать в билд-агенте миграции. Но что тогда произойдет с уже работающими контейнерами, при условии изменении таблицы?
3. Отдельный контейнер для выполнения миграций. Грубо говоря, в процессе деплоя рестартить контейнер (из CI), для запуска задачи.
Стек: docker-compose (пока так), gitlab, django.
Есть ли еще какие-то варианты? Какой из будет наиболее безболезненный?
migrate это операция с бд, зачем мильен раз то запускать? вообще имеет смысл посмотреть в сторону имаджей. выкатил обновление, сбилдил имадж в свой репозитарий и резко поднял инстансы
источник

Н

Никита in Django [ru] #STAY HOME
vadim chin
migrate это операция с бд, зачем мильен раз то запускать? вообще имеет смысл посмотреть в сторону имаджей. выкатил обновление, сбилдил имадж в свой репозитарий и резко поднял инстансы
её только при обновлении моделей делать надо?
источник

DT

Dan Tyan in Django [ru] #STAY HOME
Никита
её только при обновлении моделей делать надо?
да
источник

Н

Никита in Django [ru] #STAY HOME
а что makemigrations делает?
и какое вообще обслуживание работающего проекта нужно?
источник

JF

Jango Fett in Django [ru] #STAY HOME
vadim chin
migrate это операция с бд, зачем мильен раз то запускать? вообще имеет смысл посмотреть в сторону имаджей. выкатил обновление, сбилдил имадж в свой репозитарий и резко поднял инстансы
Так я и хочу один раз всего запускать. Вопрос только когда?
источник

JF

Jango Fett in Django [ru] #STAY HOME
Jango Fett
Так я и хочу один раз всего запускать. Вопрос только когда?
И каким способом
источник

vc

vadim chin in Django [ru] #STAY HOME
Jango Fett
И каким способом
написали выше CI - например см bitbucket или gitlab pipelines
источник

vc

vadim chin in Django [ru] #STAY HOME
или олдскульно ansible
источник

vc

vadim chin in Django [ru] #STAY HOME
ну или совсем лайтово fabric
источник

vc

vadim chin in Django [ru] #STAY HOME
источник

vc

vadim chin in Django [ru] #STAY HOME
источник

MM

Maksym Mospanenko in Django [ru] #STAY HOME
Спасибо за ссылки, если есть еще что-то подобное в загашнике - делитесь плз, я какраз на этом этапе)
источник

JF

Jango Fett in Django [ru] #STAY HOME
vadim chin
написали выше CI - например см bitbucket или gitlab pipelines
Ну то есть если накатываю миграции перед деплоем из CI - это ок?
источник