Контейнерные миграции Django
Каковы лучшие практики управления миграциями схем/данных django в контейнерном развертывании? У нас возникают проблемы с тем, что несколько контейнеров пытаются выполнить команду migrate при развертывании и запускают наши миграции параллельно. Я был удивлен, узнав, что django не координирует это внутренне, чтобы предотвратить одновременный запуск миграций двумя контейнерами. Мы используем AWS ECS и пытаемся автоматически определить один контейнер в качестве главного узла, с которого будут запускаться наши миграции.
Я сталкивался с этой проблемой в прошлом, и я также был удивлен, обнаружив, что Django не использует блокировку базы данных для управления этим, как это делают другие инструменты миграции БД.
Мое решение (вдохновленное механизмом блокировки состояния Terraform) заключалось в создании таблицы DynamoDB для использования распределенных блокировок. Я использую boto3 для выполнения записи в таблицу блокировок, с проверкой ConditionExpression, что блокировка еще не существует, (с циклом while для ожидания, если блокировка существует), затем я вызываю команду Django migrate, затем я удаляю блокировку.
Я включил эту логику в команду управления Django, и сценарий запуска в моем образе докера, который я развертываю на ECS, выполняет эту команду перед запуском приложения Django.
@swinters Мы также столкнулись с той же проблемой в ECS Fargate. Смогли ли вы найти элегантное решение для этого