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

  1. Последовательность обновления Azure производится по принципу «сначала «облако»». Постоянно добавляются новые свойства, а их подключение обычно производится сначала через REST API, затем через модуль PowerShell и командный интерфейс Azure CLI и, наконец, через портал. Это означает, что, если вы хотите получить самые интересные возможности, вам придется выйти за пределы портала.
  2. Задумайтесь над созданием одной виртуальной машины. Я могу воспользоваться мастером установки и создать ее довольно быстро. А если требуется организовать 10 или 100 виртуальных машин? Время на это, если использовать портал, будет увеличиваться пропорционально количеству копий, которые вы хотите создать. Подготовка 100 виртуальных машин займет в 100 раз больше времени. Если вы используете шаблоны PowerShell, Azure CLI или JSON, то времени на создание 100 машин уйдет почти столько же, сколько на создание одной.
  3. Работая с порталом, я не могу что-либо автоматизировать. Когда я использую командную среду, я могу автоматизировать свои действия. Это означает, что, основываясь на программе, которую можно запустить, я могу исполнять команды и выполнять соответствующие действия.
  4. Использование портала подразумевает нажатие человеком кнопок, прокручивание экрана и сворачивание окна. Можно надеяться, что пользователи каждый раз делают все правильно, но может сказаться усталость или невнимательность, и ресурсы будут развернуты в самом несуразном виде, что может привести к производственным проблемам.
  5. Если обнаружены неполадки и мне надо снова создать весь набор ресурсов, это очень трудно сделать, если они были созданы через портал. Зато очень легко, если используются другие доступные варианты.

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

  • PowerShell. Это великолепная многогранная среда для управления ресурсами и даже их создания. Преимущество PowerShell также в том, что его можно использовать непосредственно из компонента Azure Automation, перечень параметров машины Azure указать прямо в Azure, а сам процесс инициировать и запрограммировать.
  • Azure CLI. Это интерфейс командной строки, основанный на Bash, который может запускаться на macOS, Linux и Windows. Интерфейс хорош для тех, кто знаком со средами Linux. И опять-таки он подходит для создания ресурсов и управления ими.
  • Шаблоны JSON. Azure построен на языке JSON (менеджер ресурсов Azure Resource Manager как минимум). Шаблоны JSON предоставляют неизменяемый путь для развертывания ресурсов в регламентированной манере. Это лучший способ развертывания ресурсов, но он не подходит для общих операций по эксплуатации типа остановки и запуска виртуальных машин.

Я советую использовать комбинацию всего перечисленного. Можно, например, выбрать PowerShell или CLI в качестве основного способа взаимодействия с Azure. На чем именно остановиться, зависит от личных предпочтений. PowerShell располагает модулями практически для всего, а также имеет платформу управления PowerShell Desire State Configuration (DSC), которая позволяет применять разные настройки к экземплярам операционной системы. Для развертывания ресурсов опишите эти экземпляры, используя JSON, а затем реализуйте их с помощью PowerShell или CLI.

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