Как сделать миграцию
Миграция выполняется главным образом с помощью трех команд, которые заключаются в следующем:
- 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-инфраструктуры. Именно поэтому крупные компании за рубежом и в России уже сделали свой выбор, о чем свидетельствуют как данные анализа рынка ИТ-технологий, так и реальные кейсы.
Процесс переезда в облако может быть осуществлен как собственными силами технических специалистов предприятия, так и при непосредственном участии экспертов со стороны выбранного провайдера. Кроме того, переезд можно организовать, исходя из потребностей бизнеса: частично или целиком, с остановкой рабочих процессов, или не прерывая их.
Читайте также: