Как сделать миграцию

Добавил пользователь Валентин П.
Обновлено: 05.10.2024

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

makemigrations: Основано на изменениях, внесенных в модели, которая готовит запрос миграции
migrate: Применяет изменения, подготовленные запросом makemigrations и выводит их статус
sqlmigrate: Отображает запрос SQL, который подготовил запрос makemigrations.

Таким образом поток для схемы миграции Django может быть сформулирован следующим образом:

python manage.py makemigrations ‘appname’

Это подготовит файл миграции, который будет выглядеть аналогично следующему:

Затем после того, как файл будет создан, , вы можете проверить структуру каталогов. Вы увидите файл с именем 0003_auto .py в папке миграции; можно применить изменения с помощью следующей команды:

Ниже приведены действия, которые необходимо выполнить:

Synchronize non migrated apps: sessions, admin , messages, auth, staticfiles, contenttypes Apply all migrations: appname Synchronizing apps without migrations:

Чтобы добавить больше понимания миграции можно объяснить с помощью следующей схемы:

Существует три отдельных сущности:

Исходный код
Миграция файлов
База данных

Разработчик вносит изменения в исходный код, главным образом в файл models.py и изменяет ранее определенную схему. Например, когда они создают новое поле в соответствии с требованиями бизнеса, или обновляют поле max_length с 50 до 100.

Мы завершим правильную миграцию нашего проекта, чтобы увидеть, как на самом деле работает эта миграция.

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

Вывод этой команды следующий:

Это показывает, что первоначальная миграция был создана.

Давайте теперь изменим нашу модель tweet , которая в настоящее время выглядит следующим образом:

Мы изменим предыдущую модель tweet на:

Так как мы изменили нашу схему, мы теперь должны сделать миграцию для правильной работы приложения.

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

Вывод этой команды следующий:

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

Для проверки мы откроем нашу базы данных SQL и проверим текущую схему нашей таблицы tweet .

Соединитесь с MySQL с помощью команды::

В консоли MySQL напишите:

Это покажет вам схему таблицы tweet , следующим образом:

Так как мы еще не применили наши миграции, база данных ясно отображает текст в символьном поле в 160 символов:

Мы сделаем именно это, как только применим миграции:

Далее следуют операции , которые нам нужно выполнить:

Наша миграция была успешно применена; давайте проверим то же самое из-под базы данных .

Чтобы выполнить ту же команду desc MySQL в таблице tweet_tweet, используйте следующую команду:

И действительно! Наша миграция была успешно применена:

Как миграции узнают, что требуется подвергнуть миграции

Django никогда не запускает миграцию более чем один раз на одной и той же базе данных, что означает, что она сохраняет эту информацию. Эта информация управляется таблицей под названием django_migrations, которая создается первый раз, когда запускается приложение Django, и для каждой миграции после этого, вставляется новая строка.

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

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

Это означает, что даже если вы измените файл миграции вручную, он будет пропущен.

Это обращает на себя внимание, так как вы не хотите запускать одну и ту же миграцию дважды.

Конечно, если вы действительно хотите запустить одну и ту же миграцию дважды, то вам следует удалить запись таблицы " THIS IS NOT A OFFICIALLY RECOMMENDED WAY" и все будет прекрасно работать.

Продолжая разговор, если вы хотите отменить все миграции для конкретного приложения, вы можете мигрировать в особую миграцию, называемую нулевой.

Например, если вы наберете следующую команду, все ваши миграции для приложения tweet обратятся:

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

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

Изменить такое поведение можно с использованием миграций, которые позволяют хранить различные версии модели в таблице __MigrationHistory. Как мы говорили ранее, для отслеживания состояния модели данных Entity Framework использует автоматически генерируемую таблицу __MigrationHistory, в которой хранится сериализованная в двоичный формат модель данных. (Также, как говорилось в статье “Использование Code-First” вы можете использовать подход Code-Second, при котором такая проблема вообще не возникает.)

Для управления миграциями модели в Code-First используется класс DbMigration из пространства имен System.Data.Entity.Migrations. Миграции позволяют указать текущую версию модели, показав какие должны быть внесены изменения в базу данных. Допустим у вас есть следующая модель данных:

Далее вы какое-то время работаете с приложением и возможно вставляете данные в таблицы Customers и Orders. В какой-то момент вы захотели ввести ограничение на длину для поля FirstName в классе Customer и удалить столбец LastName. Напомню, что для этого можно использовать атрибут MaxLength в классе модели:

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

Поддержка миграций в Entity Framework реализована с помощью пакета EntityFramework.Migrations, который устанавливается автоматически, при установке Entity Framework из диспетчера NuGet. Чтобы включить миграции, нужно выполнить команду Enable-Migrations в консоли диспетчера NuGet (открыть консоль в Visual Studio можно с помощью команды меню Tools --> Library Package Manager --> Package manager Console):

После запуска этой команды, в проекте CodeFirst будет добавлена новая папка Migrations, содержащая два файла:

В файле Configuration.cs настраивается конфигурации миграций. Во втором файле InitialCreate.cs указывается структура первоначальной модели. Далее вы можете использовать в консоли две команды, для управления миграциями:

Add-Migration

Создает шаблон для следующей миграции на основании изменений, произведенных в модели с момента создания последней миграции.

Update-Database

Обновляет базу данных с использованием последних миграций.

Давайте добавим новую миграцию, используя команду Add-Migration SampleMigrations. Если вы используете структуру решения как у меня, то в этой команде также нужно будет явно указать имя проекта CodeFirst, к которому будет добавлена новая миграция:

В результате Visual Studio добавит новый файл миграции в папку Migrations, имеющий в имени строку SampleMigration.cs. Откройте этот файл. Если вы изменили модель, как было показано в пример выше, то вы увидите следующий код:

Здесь, в методе Up() указывается то, как должна выглядеть модель после изменения. Мы используем различные вспомогательные методы класса DbMigration, чтобы указать ограничение на длину поля FirstName (метод AlterColumn()) и удалить столбец LastName (метод DropColumn()).

В этом классе обязательно нужно реализовать метод Down(), в котором указывается то, как модель выглядела до изменений. Это нужно для того, чтобы Code-First понимал, к какой структуре модели можно применять миграцию, описанную в методе Up(). До изменения модели у нас не было ограничения на поле FirstName, поэтому мы вызываем метод AlterColumn() и не передаем никаких параметров в третьем аргументе этого метода, вызвав String() – тем самым указав, что для строкового поля не было никаких ограничений по длине. Также, до изменения модели у нас существовал столбец LastName, поэтому его нужно добавить в методе Down().

Теперь вы можете обновить базу данных на основе данной миграции, использовав команду Update-Database:

После запуска этой команды, пакет Code First Migrations сравнит список миграций в папке Migrations, выберет ту, которая соответствует текущей модели данных и обновит структуру базы без удаления записей из таблиц:

Если в таблице Customers содержались какие-нибудь данные, то они будут сохранены после обновления базы данных.

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

Django ORM пользуется моделями данных для общения с БД. Но что, если модели захотелось поменять? Для этого программисты придумали миграции.

Миграция — это описание изменений, которые вы хотите внести в таблицы базы данных. Например, у вас есть модель поста в блоге. У модели Post есть только поле text :

Теперь вы захотели добавить новое поле title — заголовок поста:

Просто поменять файл models.py недостаточно. Работа с базой данных — тонкое дело. Для того, чтобы в базе данных произошли изменения, нужно её отмигрировать, т.е. создать миграцию, которая объяснит базе данных, как ей измениться.

blank=True мы добавили для того, чтобы не случилось конфликта, о котором мы говорим в этой статье.

Что же это такое

Каждая миграция — это файл с инструкциями для базы данных. Все они пронумерованы по порядку:

Никто эти файлы не писал, они создаются автоматически, когда вы запускаете команду makemigrations (о ней будет ниже). Запустив makemigrations для примера выше, вы получите такую миграцию:

Давайте по кусочкам разберём, что тут написано:

dependencies — это список миграций, которые обязательно нужно провести перед этой. Так как миграции выполняются по порядку, в каждой следующей миграции в поле dependencies будет записана предыдущая. В примере выше показана вторая миграция в проекте, поэтому она зависит от первой. Первая миграция создаёт модель с полем text , а эта прибавила к модели новое поле title . Если мы отмигрируем базу в третий раз, в dependencies окажется ссылка на вторую миграцию:

Второй большой блок — это operations. В нём лежит описание всех изменений, которые нужно провести в БД:

makemigrations

Файлы миграций можно писать вручную, но это долго, сложно и легко ошибиться. Для создания миграций автоматически в Django есть команда python manage.py makemigrations . Если миграций ещё не было, то эта команда создаст файл 0001_initial.py в папке migrations , где она опишет все модели для базы данных.

Если вы уже проводили миграции в своём проекте, то Django сравнит текущий файл models.py с историей миграций. Django сама определит, что нужно убрать из моделей, а что — добавить, чтобы отмигрировать базу данных к новым моделям.

migrate

Команда python manage.py migrate запускает миграции в базе данных. В процессе их исполнения вы увидите такой вывод:

В первый раз миграций будет больше, чем вы создавали. Это связано с тем, что в Django много встроенных моделей, которые тоже мигрируются, когда вы запускаете команду в первый раз.

Что читать

Попробуйте бесплатные уроки по Python

Получите крутое код-ревью от практикующих программистов с разбором ошибок и рекомендациями, на что обратить внимание — бесплатно.

В последние годы цифровая трансформация ускорилась, и использование облачных вычислений стало стандартом не только для крупных компаний: все чаще миграция в облачное хранилище становится базовой технологической стратегией также для средних и малых предприятий. Однако перенос большого количества рабочих нагрузок из локального центра обработки данных и ИТ-инфраструктуры в облако требует тщательного планирования. Рассказываем, какие преимущества от миграции могут получить предприятия и даем простую пошаговую инструкцию по ее реализации.

Что такое миграция в облако и ее преимущества для бизнеса

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

повысить гибкость ИТ-инфраструктуры;
снизить риск ведения бизнеса;
поддерживать высокую производительность услуг;
повысить безопасность данных;
обеспечить соответствие стандартам безопасности;
оптимизировать затраты на обслуживание инфраструктуры.

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

В той или иной степени облачные технологии полезны предприятиям всех сфер экономики. Прежде всего, это компании из сектора электронной коммерции (e-commerce). Онлайн-магазинам порой сложно предсказать пиковую нагрузку: максимум, что можно знать точно — дату распродажи, акции, начала продаж новой коллекции. А вот прогнозы по трафику не всегда оказываются точными. Для хеджирования рисков сбоя, задержек, простоя и повышения уровня качества клиентского сервиса e-commerce переезжает в облако. — это процесс перемещения бизнес-приложений и данных из локальной архитектуры в облако: виртуальный пул масштабируемых вычислительных, сетевых ресурсов и ресурсов хранения. И это — ключ к развитию предприятия, поскольку она позволяет:

Различные онлайн-сервисы — от обучающих платформ до доставки еды — тоже выигрывают от переноса инфраструктуры в облако, поскольку таким образом освобождают ресурсы — финансовые и человеческие, и направляют их на совершенствование и разработку новых продуктов.

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

Ведущий глобальный поставщик рыночной информации, консультационных услуг и мероприятий для рынков информационных технологий, телекоммуникаций и потребительских технологий International Data Corporation (IDC) прогнозирует , что расходы компаний на облачные сервисы в ближайшие пять лет составят 64% от общих расходов на ИТ-инфраструктуру.

Прогноз по изменению расходов на ИТ-инфраструктуру (по версии IDC)

Этапы переезда в облако

Миграцию в облако можно разложить на 6 шагов. Их последовательное выполнение — залог успешного переезда в облако.

Шаг 1. Разработать стратегию миграции

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

Шаг 2. Провести инвентаризацию и анализ существующей инфраструктуры

Проведите коммерческую и техническую оценку ИТ, производственных и бизнес-ресурсов. На основе этого анализа будут определены объемы и сроки миграции, риски, потенциальные затраты и преимущества. Вы поймете, какие приложения адаптированы к миграции, и какие компоненты подходят для нее, а какие требуют реинжиниринга.
Не стремитесь перенести в облако все и сразу. Стандартные бизнес-приложения логично хранить в облаке, а вот уникальные решения, основанные на интеллектуальной собственности компании и являющиеся ключевым фактором преимущества перед конкурентами лучше хранить там, где можно полностью их контролировать — в собственной инфраструктуре.

Примечание
Соотнесите полученные данные с целями и задачами, чтобы убедиться, что они достижимы.

Шаг 3. Составить план миграции

Далее определите стратегию, инструменты и подходящее время для выполнения переноса, расставьте приоритеты для приложений, выявите оптимальный объем облачных ресурсов, протестируйте площадку и выполните тестовую миграцию.

Шаг 4. Разработать дорожную карту миграции

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

Шаг 5. Провести миграцию

Самый очевидный из шагов — сама миграция в соответствии с дорожной картой. При верном выполнении предыдущих шагов этот этап будет прозрачным и максимально комфортным.

Шаг 6. Оптимизация

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

Миграция в облако: краткий чек-лист

Чек-лист по миграции в облако

Трудности перевода: к чему быть готовым при миграции в облако?

Процесс миграции мало чем отличается от реализации любого другого проекта: на этапе планирования риски максимально оцениваются, однако полностью исключить их нереально. Рассмотрим наиболее распространенные проблемы, сопряженные с переездом в облако, подготовиться к которым следует заранее.

Выбор провайдера

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

Взаимодействие

Доступность ресурсов

Даже при наличии четкого плана и дорожной карты, в процессе миграции появится необходимость временного отключения внутренних серверов. Это неминуемо скажется на работоспособности приложений и потенциально может вызвать проблемы с клиентами, особенно в случае, если отключение не предусмотрено заранее. Простой может иметь катастрофические последствия для производительности приложений — а значит, и для лояльности клиентов — если не поддерживается надлежащим планом аварийного восстановления.

Примечание
Страх перемен, вызванных миграцией в облако, уступает страху потери контроля за данными. Бизнесу кажется, что собственные сервера позволяют контролировать местонахождение данных, безопасность и доступность ресурсов. Однако возрастание затрат на поддержку традиционной IT-инфраструктуры (ведь данных, как и бизнес-процессов, становится только больше), отсутствие гибкого масштабирования и, как следствие, утрата конкурентных преимуществ — всего этого способны избежать компании, заранее предусмотревшие возможность перемещения в облако.

Безопасность данных

Заранее поинтересуйтесь у потенциального провайдера наличием необходимых сертификатов и лицензий, стандартами информационной безопасности, уточните, какое используется оборудование и программное обеспечение. Учитывайте, что облачные провайдеры предоставляют инструменты и услуги для защиты инфраструктуры (например, сети и вычислительные машины), в то время как компания несет ответственность за такие вещи, как защита сетевого трафика и безопасность приложений.

Чем управляет облачный провайдер и чем - клиент

Эксплуатация: персонал

Со стороны HR-подразделения потребуется оценка компетенций действующих IT-специалистов компании. В случае выявления недостатка знаний необходимо будет провести обучение работе с новой инфраструктурой, пересмотреть должностные обязанности сотрудников, а при необходимости - ввести в штатное расписание еще одну единицу.

Эксплуатация: затраты

Задуматься о стоимости содержания облачной инфраструктуры на этапе планирования миграции в облако — разумно. Но самостоятельно определить объем необходимых финансовых средств, не имея опыта — сложно. А вот у провайдера, к которому вы планируете переехать, подобные данные должны собираться, и именно он способен проконсультировать вас.

Виды миграции в облако

Миграцию, в зависимости от типа организации и сложности инфраструктуры, можно разделить на два вида, рекомендованных разным предприятиям:

Постепенная миграция. Сначала переносятся некритичные сервисы (чаще всего это тестовые среды и виртуальные машины пользователей), а после них - и все остальное. Частичная миграция подходит крупным компаниям с большим количеством приложений и разветвленной инфраструктурой.
Полная миграция. Полная миграция — это перенос всей инфраструктуры за определенный период времени. Полная миграция подходит предприятиям малого и среднего бизнеса с более простой IT-структурой.

Типы миграции можно также разделить на те, что требуют выключения виртуальных машин и нет.

Миграция физических серверов в виртуальные

Миграция из одного гипервизора в другой

При миграции виртуальной машины с одного узла на другой внутри кластера Hyper-V, конфигурация ВМ копируется с одного узла кластера на другой. Такая миграция позволяет переместить работающие виртуальные машины без лишнего простоя и контролируемо. Основное преимущество динамической миграции — гибкость: работающие виртуальные машины не привязаны к одному хост-компьютеру.

Миграция из одного облака в другое

Для многих компаний в мире облачные стратегии — уже не выбор между развертыванием частного и общедоступного облака. Вместо этого все чаще практикуется работа с несколькими облаками одновременно: так приложения могут переключаться между платформами или даже действовать как сеть систем и сервисов, расположенных в разных облаках.

Онлайн-миграция

В случае, когда полное временное выключение виртуальных машин невозможно, специалисты выбирают онлайн-миграцию. В этом случае данные будут переноситься из локальной системы в облако без паузы в рабочих процессах, а производительность не изменится. Например, без остановки сервера получится перенести: физические сервера Windows и Linux, виртуальные машины на серверах VMware Sphere/ESXi, Red Hat KVM или RHEL XEN Hyper-V Server.

Как изменятся затраты при переходе в облако?

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

Во-первых, затраты на локальную инфраструктуру в основном состоят из капитальных затрат (capital expense, CapEx), а облачная инфраструктура покрывается операционными расходами (operating expense, OpEx). Поэтому стоит соотнести ожидания от перемещения в облако с финансовой стратегией предприятия. Если важна капитализация — больше подходит локальное облако, если же в приоритете снижение налоговой нагрузки и прибыль — публичное облако.

Во-вторых, даже если перенос в облако не позволит сократить издержки, то, как минимум, придаст процессу расходования средств на поддержание инфраструктуры прозрачности - этому способствует оплата по системе Pay-As-You-Go, когда оплачивается только фактическое потребление ресурсов виртуальными машинами.

Резюме

Миграция в облако — вопрос времени для компаний, желающих развиваться в соответствии с требованиями современных реалий.
Миграция предоставляет преимущества бизнесам из разных отраслей экономики (гибкость, снижение рисков, поддержание высокой производительности, обеспечение безопасности данных) и позволяет оптимизировать расходы на поддержание IT-инфраструктуры. Именно поэтому крупные компании за рубежом и в России уже сделали свой выбор, о чем свидетельствуют как данные анализа рынка ИТ-технологий, так и реальные кейсы.
Процесс переезда в облако может быть осуществлен как собственными силами технических специалистов предприятия, так и при непосредственном участии экспертов со стороны выбранного провайдера. Кроме того, переезд можно организовать, исходя из потребностей бизнеса: частично или целиком, с остановкой рабочих процессов, или не прерывая их.

Читайте также: