В этой книге приводится наиболее важная информация о ключевых службах платформы Azure для разработчиков и ИТ-специалистов без опыта работы с облачными технологиями. Приведены подробные пошаговые инструкции, которые помогут читателю изучить основы работы со всеми важными службами.
Материал будет полезен не только для начинающих освоение Azure, но и для специалистов, которым требуется восстановить материал в памяти, а также для людей, знакомых лишь с некоторыми из рассматриваемых тем. Главы книги являются независимыми: чтобы понять содержимое какой-либо главы, изучать примеры из предыдущих глав не требуется.
Сегодня мы публикуем часть первой главы этой книги. Полную версию вы можете скачать бесплатно по ссылке.
Оглавление
- Знакомство с Azure — 1;
- Служба приложений Azure и веб-приложения — 32;
- Виртуальные машины — 70;
- Служба хранилища — 101;
- Виртуальные сети Azure — 133;
- Базы данных — 157;
- Azure Active Directory — 181;
- Средства управления — 206;
- Дополнительные службы Azure — 231;
- Сценарии использования — 238.
Знакомство с Azure
Что такое Azure?
Azure — это облачная платформа Microsoft.
Облачные технологии — общие сведения
Облачные техно логии — это современная альтернатива привычным локальным центрам обработки данных. Все задачи по закупке и обслуживанию оборудования находятся полностью в ведении поставщика услуг публичного облака. Он предоставляет клиентам доступ к различным службам платформы. Клиенты арендуют аппаратные и программные ресурсы, которые требуются им лишь время от времени. Так они преобразуют капитальные расходы на закупку оборудования в операционные издержки. Кроме того, такой подход позволяет клиентам получать в аренду доступ к аппаратным и программным ресурсам, покупка которых была бы слишком дорогостоящей. Клиентам доступны лишь те устройства, которые предлагает поставщик облачной платформы, но платят они только по мере их использования.
Для управления облачными средами (их вычислительными ресурсами, хранилищами, сетями и приложениями) используются веб-порталы. Например, на портале Azure пользователь может создать конфигурацию виртуальной машины (ВМ), в которой будут определены следующие характеристики: конфигурация виртуальной машины (процессор, оперативная память и локальные диски), операционная система, предварительно развернутое программное обеспечение, сетевая конфигурация и расположение виртуальной машины. После этого пользователь может развернуть виртуальную машину на основе этой конфигурации и начать работу с ней уже через несколько минут. Раньше потребовалось бы развертывать физическую машину, одна только закупка которой могла бы занять несколько недель, поэтому возможность быстрого развертывания выглядит очень привлекательно.
Мы рассказали о публичных облаках. Существуют еще частные и гибридные облака. Частное облако — это облачная среда, которая создается в собственном центре обработки данных компании, а пользователям (сотрудникам компании) предоставляются инструменты для самостоятельного использования ее ресурсов. Пользователи работают с такой средой практически так же, как с публичным облаком, но все задачи по закупке и обслуживанию оборудования, выбору аппаратных и программных ресурсов полностью находятся в ведении компании. Гибридное облако — это среда, сочетающая в себе публичное и частное облако. Такой подход позволяет выбирать наиболее подходящий вариант размещения рабочих нагрузок. Например, если нагрузка на веб-сайт колеблется в широких пределах, его можно разместить в публичном облаке и подключить к защищенной базе данных в своем частном облаке (или в локальном центре обработки данных).
Решения Microsoft поддерживают публичные, частные и гибридные облака. Платформа Microsoft Azure, которой посвящена эта книга, представляет собой публичное облако. Microsoft Azure Stack является расширением для Windows Server 2016, которое позволяет развернуть множество базовых служб Azure в локальном центре обработки данных и предоставить пользователям портал самообслуживания. Эти компоненты можно интегрировать с гибридным облаком посредством виртуальной частной сети (VPN).
Локальная среда и Azure — сравнение
При использовании локальной инфраструктуры аппаратные и программные компоненты, которые вы развертываете, находятся полностью под вашим управлением. Поэтому раньше при закупке оборудования обычно стремились к вертикальному масштабированию (т. е. старались приобрести сервер с большим количеством ядер, чтобы обеспечить требуемую производительность). Если же вы используете Azure, вы можете использовать только те устройства, которые предлагает Microsoft. В этом случае для того, чтобы повысить производительность, используется горизонтальное масштабирование: вы просто развертываете дополнительные вычислительные узлы. Эту особенность приходится учитывать при проектировании архитектуры программных систем, однако, как показала практика, горизонтальное масштабирование (развертывание недорогих устройств) гораздо более экономически эффективно, нежели вертикальное (закупка высокопроизводительных устройств).
На момент написания данной книги, центры обработки данных Microsoft Azure открыты более чем в 22 регионах мира: от Мельбурна до Амстердама, от Сан-Паулу до Сингапура. Кроме того, корпорация Microsoft заключила соглашение с компанией 21Vianet, и теперь платформа Azure доступна в двух регионах Китая. Корпорация Microsoft объявила о развертывании Azure еще в восьми регионах. Открывать центры обработки данных с таким размахом могут только крупнейшие корпорации мира. Поэтому с помощью Azure компании любого масштаба могут развертывать свои службы в местах концентрации своих клиентов в любых регионах Земли. И все это — даже не выходя из офиса!
Azure позволяет молодым компаниям начать с очень небольших затрат и быстро масштабировать инфраструктуру по мере появления новых клиентов. Запуск одной или нескольких новых виртуальных машин не требует больших предварительных платежей. Современные молодые компании обычно быстро масштабируются и быстро учатся на своих ошибках. Использование облачных технологий полностью соответствует этим принципам.
Azure помогает быстро и гибко запускать новые среды для разработки и тестирования. Для развертывания таких сред можно использовать сценарии. Так вы сможете при необходимости запустить среду разработки или тестирования, провести тестирование и удалить ее. В результате компания сильно экономит и почти не тратит денег на поддержку инфраструктуры.
Еще одно преимущество Azure — возможность тестировать новые версии программного обеспечения, не заменяя локальное оборудование. Предположим, вам нужно узнать, как изменится работа вашего приложения при переходе с Microsoft SQL Server 2014 на Microsoft SQL Server 2016. Для этого вы просто создаете экземпляр SQL Server 2016 и запускаете копию ваших служб, подключив ее к новой базе данных — не нужно ни выделять оборудование, ни протягивать провода. Или вы можете запустить виртуальную машину под управлением Microsoft Windows Server 2012 R2 вместо Microsoft Windows Server 2008 R2.
Облачное предложение
Облачные службы обычно относятся к одной из трех категорий: SaaS, PaaS или IaaS. Однако с развитием облачных технологий граница между ними становится все менее четкой.
SaaS: программное обеспечение как услуга
Программное обеспечение, которое размещается в централизованной среде и управляется по поручению клиента, называется SaaS (программное обеспечение как услуга). Обычно при таком подходе используется мультитенантная архитектура, т. е. всем клиентам предоставляется приложение одной и той же версии. Его можно масштабировать на несколько экземпляров, чтобы обеспечить оптимальную производительность вне зависимости от местоположения. Для лицензирования SaaS обычно используются подписки с ежемесячными или ежегодными платежами.
Один из примеров SaaS — Microsoft Office 365. Пользователи оплачивают месячную или годовую подписку и получают доступ к нескольким продуктам: Exchange как услуга (веб-клиент и (или) настольное приложение Outlook), служба хранения как услуга (OneDrive) и другие компоненты пакета Microsoft Office (настольные и (или) веб-версии). При этом подписчикам всегда предоставляется наиболее актуальная версия продукта. Так вы можете, по сути, получить в свое распоряжение сервер Microsoft Exchange без необходимости его покупки, установки и поддержки — управлением сервером Exchange, в том числе установкой исправлений и обновлений, займутся другие. Такой вариант гораздо дешевле и проще с точки зрения обслуживания, нежели установка программного пакета Microsoft Office и его ежегодное обновление.
Другие примеры продуктов SaaS — Dropbox, WordPress и Amazon Kindle.
PaaS: платформа как услуга
В рамках подхода PaaS вы развертываете свое приложение в специальной среде размещения приложений, которая находится у поставщика облачных служб. Разработчик создает приложение, а поставщик PaaS предоставляет возможность развернуть и запустить его. В результате разработчикам нет необходимости заниматься обслуживанием инфраструктуры, а значит, они могут посвятить все свое время разработке.
В рамках Azure доступно несколько предложений PaaS, к которым относится компонент «веб-приложения» службы приложений Azure, а также облачные службы Azure (веб-роль и рабочая роль). Во всех случаях разработчикам доступно множество способов развернуть приложение без необходимости разбираться в деталях работы вспомогательной инфраструктуры. Разработчикам не придется ни создавать виртуальные машины, ни подключаться к ним по протоколу удаленного рабочего стола (RDP), ни устанавливать приложение. Им достаточно просто нажать на кнопку (или совершить другое столь же простое действие), и инструменты Microsoft подготовят виртуальные машины, развернут и установят на них приложение.
IaaS: инфраструктура как услуга
Поставщик облачных служб IaaS контролирует и обслуживает серверные фермы, на которых выполняются программные системы виртуализации. В этих системах клиенты создают виртуальные машины, которые функционируют в инфраструктуре поставщика. Клиент создает виртуальную машину под управлением Windows или Linux (доступные варианты зависят от поставщика услуг) и устанавливает на ней все необходимое. Azure позволяет конфигурировать виртуальные сети, балансировщики нагрузки и хранилища, а также использовать многие другие службы, которые работают в этой среде. Клиент не может управлять устройствами или программными системами виртуализации, но почти все остальное находится в его полном
распоряжении. При таком подходе (в отличие от PaaS) программное обеспечение контролирует заказчик.
Виртуальные машины Azure (IaaS-предложение Azure) — очень популярный инструмент для миграции служб в Azure, поскольку он, по сути, позволяет просто перенести нужные решения. Вы можете создать виртуальную машину, аналогичную инфраструктуре вашего центра обработки данных, в которой службы работают сейчас, и перенести свои приложения на нее. В некоторых случаях могут потребоваться дополнительные действия (например, изменение URL-адресов таким образом, чтобы они указывали на новые службы или хранилища), однако такой подход позволяет переместить очень многие приложения.
Масштабируемые наборы виртуальных машин Azure (VMSS), основанные на виртуальных машинах Azure, позволяют быстро создать кластер идентичных виртуальных машин. Кроме того, VMSS поддерживает автоматическое масштабирование (автоматическое развертывание новых виртуальных машин по необходимости). Благодаря этому VMSS представляет собой идеальную платформу для размещения вычислительных кластеров на основе микрослужб более высокого уровня: например, для Azure Service Fabric и службы контейнеров Azure.
Службы Azure
В состав облачной платформы Azure входит множество служб. Рассмотрим некоторые из них.
- Службы вычислений. К этой категории относятся виртуальные машины Azure (под управлением Linux и Windows), облачные службы, службы приложений (веб-приложения, мобильные приложения, Logic Apps, приложения API и приложения-функции), пакетная служба (для выполнения больших параллельных и пакетных вычислительных заданий), RemoteApp, Service Fabric и служба контейнеров Azure.
- Службы данных. Сюда входят хранилище Microsoft Azure (которое включает в себя службы BLOBобъектов, очередей, таблиц и файлов Azure), база данных SQL Azure, DocumentDB, StorSimple и кэш Redis.
- Службы приложений. К этой категории относятся службы, используемые для создания и выполнения приложений, в том числе Azure Active Directory (Azure AD), служебная шина для подключения распределенных систем, HDInsight для обработки больших данных, планировщик Azure и службы мультимедиа Azure.
- Сетевые службы. К этой группе относятся такие службы Azure, как виртуальные сети, ExpressRoute, Azure DNS, диспетчер трафика Azure и сеть доставки содержимого Azure.
При миграции приложения важно понимать, какие службы доступны в составе Azure, поскольку это знание поможет упростить миграцию приложения и повысить его гибкость. Подробно рассказать обо всех доступных службах в рамках этой книги невозможно, поэтому мы выбрали несколько наиболее интересных. В главе 9 («Дополнительные службы Azure») приводится список этих служб и краткое объяснение их возможностей.
Новый мир: Диспетчер Ресурсов Azure
Диспетчер Ресурсов Azure — это новый подход к развертыванию ресурсов.
Что это такое?
Модель развертывания с использованием управления службами Azure (Azure Service Management, ASM) использовалась для развертывания служб с момента запуска общедоступной ознакомительной версии. Службы, для управления которыми используется ASM, на портале Azure называются классическими. В 2015 году Microsoft представила модель развертывания с помощью Диспетчера Ресурсов Azure (современную и более функциональную замену ASM), которую рекомендуется использовать для управления новыми рабочими нагрузками.
Эти режимы развертывания часто называют «плоскостями управления» (control plane), потому что они используются не только для развертывания служб, но и для управления ими. Не следует путать их с «плоскостями данных» (data plane) — средствами управления данными, которые используются службой.
Функционирующая в Azure инфраструктура, как правило, содержит множество ресурсов, некоторые из которых связаны между собой: например, для запуска веб-приложения требуются службы компонентов. Предположим, вам нужны две виртуальные машины, на которых будет работать веб-приложение. Для хранения данных будет использоваться база данных, размещенная в той же виртуальной сети. Диспетчер ресурсов позволяет развернуть все это в рамках одной группы ресурсов, которыми можно управлять как одним целым. Развертывание, обновление и удаление всех ресурсов, которые относятся к одной группе, выполняется одним действием.
В рассматриваемом примере группа ресурсов будет содержать следующее:
- Виртуальная машина 1
- Виртуальная машина 2
- Виртуальная сеть
- Учетная запись хранения
- База данных SQL Azure
Кроме того, можно создать шаблон с точным описанием всех ресурсов Диспетчера Ресурсов, которые относятся к развертыванию. После этого достаточно выполнить одну операцию в плоскости управления (control plane), чтобы развернуть этот шаблон Диспетчера Ресурсов в виде группы ресурсов. При этом Диспетчер Ресурсов Azure сам позаботится о том, чтобы все ресурсы были развернуты корректно. Кроме того, Диспетчер Ресурсов поддерживает различные возможности работы с развернутыми ресурсами: обеспечение безопасности, аудит и добавление тегов.
В чем преимущества Диспетчера Ресурсов?
Использование Диспетчера Ресурсов открывает ряд преимуществ. Он позволяет развертывать ресурсы быстрее, так как выполняет операции не последовательно (как ASM), а параллельно. Модель развертывания с помощью Диспетчера Ресурсов Azure позволяет каждой службе работать со своим поставщиком службы и при необходимости обновлять его независимо от других служб. У хранилища Azure — один поставщик службы, у виртуальных машин — другой, и так далее. При использовании модели ASM все службы должны были обновляться одновременно, поэтому если одна служба заканчивала обновление раньше остальных, ей все равно потребовалось бы дождаться других перед выпуском. Вот еще несколько важных преимуществ модели развертывания с помощью Диспетчера Ресурсов Azure:
Возможность развертывания с использованием шаблонов
- Вы можете создать шаблон JSON и многократно использовать его для развертывания всех ресурсов для некоторого решения одним действием. Больше не нужно запускать создание одной виртуальной машины через портал, дожидаться завершения процесса, запускать создание следующей и так далее.
- Вы можете повторно развертывать одинаковые наборы ресурсов с помощью шаблона. Предположим, вы настроили ресурсы в тестовой среде и поняли, что они не соответствуют вашим потребностям. Вы можете удалить эту группу ресурсов (при этом автоматически будут удалены все ресурсы, которые в нее входят), изменить шаблон и попробовать снова. Чтобы модифицировать набор развернутых ресурсов, достаточно изменить шаблон и вновь запустить его развертывание: Диспетчер Ресурсов изменит ресурсы так, чтобы они соответствовали новому шаблону.
- С помощью шаблона можно быстро создать несколько версий инфраструктуры: например, промежуточную и рабочую среды. Различные поля (например, имя виртуальной машины, имя сети, учетной записи хранения и т. п.) можно параметризовать, а затем загрузить шаблон несколько раз с различными значениями параметров.
Диспетчер Ресурсов способен обнаруживать зависимости в шаблонах и позволяет указывать дополнительные зависимости. Например, развертывать виртуальную машину перед созданием учетной записи хранения для файлов VHD, в которых хранятся диски с операционной системой и данными, — плохая идея.
Безопасность
- Для управления доступом к ресурсам группы можно использовать новый механизм, который называется «управление доступом на основе ролей» (Role-Based Access Control, RBAC). Например, вы можете назначить пользователю роль «владелец», и тогда у него будут полные права администратора в отношении ресурсов данной группы — но не других ресурсов подписки. Предусмотрены и другие роли, например, «читатель» (позволяет читать все, кроме секретных данных) и «участник» (позволяет выполнять практически любые операции, кроме добавления и снятия доступа).
Выставление счетов
- Чтобы упорядочить все ресурсы группы для удобного выставления счетов, вы можете назначить каждому ресурсу теги, а затем получить данные о платежах за использование ресурсов с определенным тегом.
Если, например, веб-приложением и несколькими связанными ресурсами занимается один отдел, вы можете назначить всем этим ресурсам один тег. После этого вы сможете получать по указанному тегу информацию о платежах, связанных с этим отделом.
Примечание. Ресурсы в составе группы не наследуют тег, установленный для группы в целом. Теги нужно будет назначить каждому отдельному ресурсу.
Используйте Диспетчер Ресурсов максимально эффективно
Корпорация Microsoft подготовила несколько советов по эффективной работе с приложениями и компонентами с помощью Диспетчера Ресурсов.
- Вместо сценариев PowerShell или интерфейса командной строки (CLI) рекомендуется использовать шаблоны. Команды сценария выполняются последовательно, а ресурсы, указанные в шаблоне, могут развертываться параллельно, что гораздо быстрее.
- Автоматизируйте как можно больше операций с помощью шаблонов. Вы можете указать конфигурации для различных расширений, например, PowerShell DSC и веб-развертывание. Тогда при создании и конфигурировании ресурсов никакие действия не потребуется выполнять вручную.
- Используйте PowerShell или Azure CLI для управления ресурсами (например, чтобы запустить или остановить виртуальную машину или приложение).
- Поместите ресурсы с одинаковыми жизненными циклами в одну группу ресурсов. Вернемся к примеру выше. Что если база данных используется для нескольких приложений или требуется, чтобы она продолжала работать даже после отключения или удаления приложения? Не очень удобно создавать базу данных каждый раз при повторном развертывании приложения и его компонентов. В этом случае можно поместить базу данных в отдельную группу ресурсов.
Советы по использованию групп ресурсов
При разделении ресурсов по группам руководствуйтесь соображениями целесообразности в конкретной ситуации. Группа ресурсов представляет собой логический контейнер, в котором содержатся связанные между собой ресурсы для приложения или группы приложений. При принятии решений относительно группы ресурсов стоит учитывать следующее:
- Как уже упоминалось, в одну группу следует помещать ресурсы с общим жизненным циклом.
- Ресурс нельзя добавить одновременно в несколько групп.
- Ресурс может быть добавлен в группу ресурсов или удален из нее в любое время. Обратите внимание: каждый ресурс должен относиться к какой-либо группе, поэтому при удалении ресурса из одной группы необходимо добавить его в другую.
- Ресурс почти любого типа можно переместить в другую группу ресурсов в любое время.
- Ресурсы, которые относятся к одной группе, могут размещаться в различных регионах.
- Группа ресурсов позволяет контролировать доступ к ресурсам, которые в нее входят.
Советы по использованию шаблонов Диспетчера Ресурсов
Шаблоны Диспетчера Ресурсов, по сути, представляют собой инструкции по развертыванию и конфигурированию приложения. Они используются для многократного развертывания приложения и всех ресурсов, которые для него требуются.
Вы можете разделить развертывание на несколько шаблонов и создать главный шаблон, в котором будут содержаться ссылки на все другие необходимые шаблоны.
Шаблоны можно изменять. Измененные шаблоны можно развертывать снова. Например, можно добавить в шаблон запись о новом ресурсе или обновить данные о конфигурации ресурса. При повторном развертывании шаблона Диспетчер Ресурсов создает все необходимые новые ресурсы и применяет обновленные параметры. Пример использования этой возможности рассматривается в главе 5 («Виртуальные сети Azure») при развертывании шаблона Vnet с двумя подсетями. После этого добавляется третья подсеть и повторно разворачивается шаблон, после чего эта подсеть появляется на портале Azure.
Шаблоны можно параметризовать, чтобы более гибко управлять процессом развертывания. Параметризация позволяет использовать шаблон повторно, но при этом присваивать другие значения параметрам, таким как имя виртуальной машины, имя виртуальной сети, имя учетной записи хранения, регион и т. п.
Данные о текущем состоянии ресурсов в группе ресурсов можно экспортировать в виде шаблона. Затем его можно использовать в качестве макета для других развертываний или изменить и развернуть повторно, чтобы модифицировать свойства текущих ресурсов в составе группы.
Ниже приведен пример шаблона JSON. При развертывании этого шаблона создается учетная запись с именем «mystorage» в регионе «западная часть США» (West US). Шаблон является параметризованным; вы можете создать файл с параметрами и указать в нем значения параметров newStorageAccountName (имя новой учетной записи хранения) и location (местоположение). Если такого файла нет, используются стандартные параметры.
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"newStorageAccountName": {
"type": "string",
"defaultValue": "mystorage",
"metadata": {
"description": "Уникальное DNS-имя учетной записи хранения, в которой будут размещаться диски виртуальной машины."
}
},
"location": {
"type": "string", "defaultValue": "West US", "allowedValues": [ "West US", "East US" ],
"metadata": {
"description": "Ограничивает варианты выбора регионами США, в которых доступно хранилище класса Premium."
}
}
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts", "name": "[parameters('newStorageAccountName')]", "apiVersion": "2015-06-15", "location": "[parameters('location')]", "properties": { "accountType": "Standard_LRS"
}
}
]
} Классическая модель развертывания
Поговорим немного о том, что было до появления Диспетчера Ресурсов. Теперь такие ресурсы называют классическими. Например, у клиента могут быть учетные записи хранения, виртуальные машины и виртуальные сети, для управления которыми используется классическая модель развертывания. Классическая модель и модель развертывания с помощью Диспетчера Ресурсов Azure несовместимы — ресурсы Диспетчера Ресурсов не могут взаимодействовать с классическими ресурсами и наоборот. Например, компонент «Облачные службы PaaS Azure» является классическим, поэтому работать с ним можно только посредством классических учетных записей хранения. Из этого правила есть одно исключение: в классических учетных записях хранения можно размещать виртуальные машины Диспетчера Ресурсов. Эта возможность упрощает миграцию виртуальных машин из классической модели развертывания в модель развертывания с помощью Диспетчера Ресурсов Azure.
Обратите внимание: в ходе такой миграции может потребоваться войти на классический портал Azure, в котором отображаются классические ресурсы, но отсутствуют ресурсы Диспетчера Ресурсов, и наоборот.
Примечание. Есть две версии портала. Актуальным является портал Azure, доступный по адресу portal.azure.com. Большая часть возможностей была перемещена на портал Azure, но есть несколько исключений, например, Azure Active Directory (Azure AD). Предыдущая версия портала называется «классический портал Azure» (https://manage.windowsazure.com). Сейчас его можно использовать для управления службами Azure AD, а также для конфигурирования и масштабирования классических ресурсов (например, облачных служб).
Вы можете перенести свои ресурсы с классической модели развертывания на модель развертывания с помощью Диспетчера Ресурсов Azure.
- Файлы, таблицы и BLOB-объекты можно перенести из классической учетной записи хранения в новую учетную запись хранения Диспетчера Ресурсов с помощью AzCopy. Обратите внимание: таблицы необходимо экспортировать из классической учетной записи, а затем импортировать в учетную запись Диспетчера Ресурсов.
- Виртуальные машины можно перенести следующим образом: отключить их, скопировать файл VHD в новую учетную запись хранения Диспетчера Ресурсов, а затем заново создать виртуальную машину, используя файл VHD.
- Виртуальные сети можно создать как объекты Vnet в Диспетчере Ресурсов.
- Кроме того, запущена служба миграции (сейчас она находится в стадии общедоступной ознакомительной версии). На текущий момент не рекомендуется использовать ее для производственных нагрузок. Более подробная информация приведена в статье.
Учет модели развертывания в сценариях PowerShell
В главе 8 («Средства управления») рассматриваются некоторые инструменты работы с Azure, в том числе командлеты Azure PowerShell и Azure CLI.
При разработке модели развертывания с помощью Диспетчера Ресурсов специалисты Azure стремились создать командлеты PowerShell, которые работали бы только для модели развертывания с помощью Диспетчера Ресурсов. В имени таких командлетов вместо слова Azure указывается слово AzureRm. Например, для создания классической учетной записи хранения можно воспользоваться командлетом New-AzureStorageAccount. Для того чтобы создать учетную запись хранения в Диспетчере Ресурсов, нужно запустить командлет New-AzureRmStorageAccount.
Это сделано для того, чтобы пользователь мог сразу понять, ресурс какого типа он создает. Кроме того, таким образом обеспечивается возможность корректного исполнения созданных ранее сценариев. При каждом развертывании ресурса Диспетчера Ресурсов необходимо указать группу ресурсов, в которую его требуется поместить. Кроме того, некоторые командлеты Диспетчера Ресурсов (например, командлет для создания виртуальной машины) поддерживают более подробные параметры, чем командлеты классической модели.
И последнее замечание: изменения затрагивают только те командлеты PowerShell, связанные с учетными записями хранения, которые относятся к плоскости управления (например, командлеты для создания, удаления и вывода списка учетных записей хранения). Для командлетов PowerShell, которые служат для доступа к содержимому хранилищ (BLOB-объектам, таблицам, очередям и файлам), ничего не изменилось. Достаточно передать им ссылку на нужную учетную запись хранения, и они готовы к использованию.
Бесплатно скачать полную версию книги и изучить ее вы можете по ссылке ниже.
→ Скачать
Автор: Александр Гуреев
