Миграция ресурсов между разными подписками Azure

Миграция ресурсов между разными подписками Azure

У меня есть несколько вопросов к гуру Azure. Я работаю в компании по разработке программного обеспечения, и мне было поручено придумать нашу инфраструктуру Azure. Идея, которая у меня возникла, — настроить три подписки Pay-As-You-Go для следующих отделов:

1) Производство (живая среда). 2) Обеспечение качества. 3) Тестирование.

У меня есть вопросы:

1) При создании ресурсов, таких как веб-сайты, виртуальные машины и т. д., можно ли их переносить между различными подписками? Вот сценарий: предположим, мы запускаем новое приложение, но сначала нам нужно его протестировать. Поэтому мы сначала помещаем его в Тестирование. После проведения тщательного тестирования мы перемещаем его в Обеспечение качества. Затем мы перемещаем его в Производство (живую среду), когда все проверки качества будут исчерпаны. 2) Я также разрабатываю матрицу безопасности, в которой пользователь в одном отделе не может ничего изменить в другом отделе.

Что скажете, дамы и господа? Это осуществимо?

решение1

Майкл, используемый вами процесс миграции будет во многом зависеть от базовой инфраструктуры/сервиса, который вы используете.

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

  • Веб-сайты и облачные сервисы (веб-роли или рабочие роли): вам нужно будет повторно развернуть свой код в соответствующем экземпляре в правильной подписке. Вы не можете «переместить» базовую инфраструктуру хостинга.
  • Услуги, размещенные на виртуальных машинах: вы можете перемещать виртуальные машины между подписками, но это требует значительных усилий в зависимости от того, какие еще зависимости у вас есть (сети, базы данных и т. д.). Лучше всего попробовать использовать тот же подход, что и для веб-сайтов/облачных служб.
  • База данных Azure SQL: необходимо выполнять резервное копирование/восстановление базы данных между подписками.
  • Другие службы Azure: во многом будут зависеть от того, что именно развернуто (извините, если это неопределенно, но в Azure много движущихся частей).

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

решение2

Мы используем Visual Studio Online (VSO) для автоматизированных сборок и развертываний в наших различных средах Azure. Это будет работать независимо от того, разделяете ли вы свои среды по разным подпискам или используете разные группы ресурсов в одной и той же подписке.

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

Затем наш отдел QA регулярно ставит сборку в очередь через VSO, выбирая определенный набор изменений/дату. Если сборка и модульные тесты проходят успешно, это запускает развертывание в QA. Эта сборка также технически собирается для prod, но не развертывается в prod.

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

Если вы используете локальное решение, вы можете использовать их TFS, что по сути то же самое.

Короче говоря, это можно сделать с помощью VSO и интегрировать его с Azure Active Directory для аутентификации и управления.

Связанный контент