приложение крутится в контейнере. Есть несколько вариантов:
1. Засовывать python manage.py migrate в docker-entrypoint.sh (используется сейчас). Но тогда возникает проблема со скейлингом контейнеров. Получается, что при увеличении числа контейнеров - каждый раз включается миграция. А если при запуске второго контейнера процесс выполнения миграций в первом контейнере всё еще выполняется - хз что произойдет. lock? error?
2. Отдельный job в CI - перед деплоем запускать в билд-агенте миграции. Но что тогда произойдет с уже работающими контейнерами, при условии изменении таблицы?
3. Отдельный контейнер для выполнения миграций. Грубо говоря, в процессе деплоя рестартить контейнер (из CI), для запуска задачи.
Стек: docker-compose (пока так), gitlab, django.
Есть ли еще какие-то варианты? Какой из будет наиболее безболезненный?
код должен уметь работать с текущей версией структуры базы и с прошлой версией, миграции после обновления отдельно
migrate это операция с бд, зачем мильен раз то запускать? вообще имеет смысл посмотреть в сторону имаджей. выкатил обновление, сбилдил имадж в свой репозитарий и резко поднял инстансы
depends_on
Обсуждают сегодня