Блог

Я пытаюсь понять использование слотов развертывания для размещения моего веб-приложения с помощью службы приложений Azure. Меня особенно смущают идеальные способы работы с базой данных во время выполнения подкачки. Хотя поддержка двух версий базы данных кажется решением, это усложняет обслуживание данных в нескольких базах данных, чтобы сделать их согласованными. Какие рекомендуемые способы работы со схемой базы данных и миграциями при использовании синих / зеленых развертываний и, в частности, слотов развертывания?

В идеале вы будете использовать одну и ту же базу данных, поэтому это не будет проблемой.

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

Мы работали над различными решениями этой проблемы в течение нескольких лет. Не существует набора инструментов, который обеспечивал бы волшебную палочку для всех случаев. Существует несколько решений:

Базы данных меньшего размера / тривиальные изменения

Если есть возможность выполнить сценарий миграции в базе данных, который завершится через секунду или две, и у вас может быть простой запасной сценарий, вы можете выполнить сценарий одновременно с обменом. Это также можно автоматизировать. Но это ситуация с более высоким уровнем стресса, и я бы не рекомендовал. Это можно сделать даже с помощью EF-миграции.

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

Поскольку мы имеем дело с несколькими сотнями ГБ данных, которые не могут быть удалены, мы только что установили правило, согласно которому база данных должна работать с обеими версиями нашего приложения. Это не так ужасно или невозможно, как кажется. Например, чистые новые таблицы и поля часто могут быть добавлены еще до выполнения подкачки. Мы тестируем откат между версиями в рамках нашего контроля качества. Если некоторые поля необходимо удалить, мы ждем, пока новая версия не будет развернута и записана, затем запускаем другой скрипт для выполнения удаления после того, как мы будем уверены, что откат не потребуется. Мы создадим новые хранимые процедуры, когда потребуется обновить одну из них, чтобы у новой версии была своя собственная. Пример: sp_foo и sp_foo2.

Мы добились большого успеха благодаря этой стратегии.

Слоты — это функция, предназначенная специально для служб приложений, а не для баз данных, если вы хотите использовать определенную базу данных с определенным слотом, тогда вы настраиваете слот следующим образом: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots

Теперь при использовании слотов и замене он также меняет конфигурации приложения настройки, а в настройках приложения у вас могут быть две строки подключений к БД, но для каждой из них включено собственное имя слота и настройка. Вы можете видеть, что это также было показано в этом примере здесь: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-two-slots