Миграция ресурсов между различными подписками Azure
У меня есть несколько вопросов для гуру Azure там. Я работаю на дом разработки программного обеспечения, и меня спросили с предложением нашей инфраструктуры Azure. Идея, которую я имел, состоит в том, чтобы настроить три подписки С оплатой по мере использования для следующих отделов:
1) Производство (продуктивная среда). 2) Гарантия качества. 3) Тестирование.
Мои вопросы:
1) При создании ресурсов, таких как веб-сайты; виртуальные машины и др., они могут быть перемещены между различными подписками? Вот сценарий: скажем, мы запускаем новое приложение, но сначала мы должны протестировать его. Так мы первое место это в Тестировании. После того как строгое тестирование было выполнено, мы перемещаем его в Гарантию качества. Впоследствии, мы перемещаем его в Производство (продуктивная среда), когда все проверки качества были исчерпаны. 2) я также разрабатываю матрицу настроек безопасности, где пользователь в одном отделе ничего не может изменить в другом отделе.
Что говорит Вас леди и джентльмены? Действительно ли это выполнимо?
Майкл - используемый вами процесс миграции будет во многом зависеть от базовой инфраструктуры / службы, которую вы используете.
В качестве отправной точки я бы посоветовал посмотреть, как вы можете использовать службы сборки для автоматического развертывания созданного вами программного обеспечения. Документация MSDN является хорошей отправной точкой.
- Веб-сайты и облачные службы (веб- или рабочие роли): вам нужно будет повторно развернуть свой код в соответствующем экземпляре в правильной подписке. Вы не можете «переместить» базовую инфраструктуру хостинга.
- Услуги, размещенные на виртуальных машинах: вы можете перемещать виртуальные машины между подписками, но это требует значительных усилий в зависимости от того, какие у вас есть другие зависимости (сети, базы данных и т. Д.). Лучше всего попытаться применить тот же подход, что и для веб-сайтов / облачных служб.
- База данных SQL Azure: вам необходимо выполнять резервное копирование / восстановление базы данных между подписками.
- Другие службы Azure: будут во многом зависеть от что развернуто (извините, если это расплывчато, но в Azure много движущихся частей).
Обычно поиск способов сценария или автоматизации развертывания / повторного развертывания любых решений, которые вы создаете, будет потраченным временем в вашем сценарии.
Мы используем Visual Studio Online (VSO) для автоматизированных сборок и развертываний в различных средах Azure. Это будет работать независимо от того, разделяете ли вы свои среды по разным подпискам или используете разные группы ресурсов в одной подписке.
Наша установка такова, что каждая проверка кода запускает сборку, запускает модульные тесты и, в случае успеха, запускает развертывание в тестовой среде.
Затем наш отдел QA обычно ставит в очередь сборку через VSO, выбирая конкретный набор изменений / свидание. Если сборка и модульные тесты успешны, запускается развертывание в QA. Эта сборка также технически предназначена для prod, но не развертывается для prod.
Они выполняют всю свою работу по обеспечению качества, и если все в порядке, они подтверждают свою сторону логики привратника, встроенной в VSO. Затем мы настроили его, так что еще 2 человека должны подписать, что сборка будет запущена в производство (что может быть немедленным или запланированным).
Если вы работаете в локальной среде, вы можете вместо этого использовать их TFS, которая, по сути, такая же вещь.
TL; DR; Это можно сделать с помощью VSO и интегрировать с Azure Active Directory для проверки подлинности и управления.