Создавать ресурсы кликами в портале удобно ровно до второго раза. Дальше начинаются вопросы: как воспроизвести то же самое в другой подписке? как понять, что вообще создано? как откатить изменение? Ответ — инфраструктура как код (IaC): инфраструктуру описывают текстовыми файлами, которые хранят в git, ревьюят и применяют. В Azure для этого есть три инструмента. Общие принципы IaC, не привязанные к облаку, разбирает статья про основы infrastructure as code; здесь — как это устроено в Azure.

ARM-шаблоны: родной формат

ARM-шаблоны (Azure Resource Manager) — «родной» способ описания ресурсов в Azure, документы в формате JSON. Всё, что вы создаёте в Azure, в итоге проходит через Resource Manager, поэтому ARM — фундамент. Минус в том, что JSON-шаблоны многословны и тяжело читаются: на реальную инфраструктуру получаются сотни строк со скобками.

Bicep: тот же ARM, но по-человечески

Bicep — это язык поверх ARM: он компилируется в те же ARM-шаблоны, но пишется в разы компактнее и читаемее. Это рекомендованный Microsoft способ для проектов, живущих только в Azure.

resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorage${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

Один короткий блок Bicep разворачивается в объёмный ARM-шаблон, но вам работать с читаемой версией. Ресурсы могут ссылаться друг на друга, и Bicep сам вычисляет порядок создания.

Terraform: когда не только Azure

Terraform — независимый от вендора инструмент, который управляет ресурсами десятков платформ на одном языке (HCL) через провайдеры; для Azure это провайдер azurerm. Его берут, когда инфраструктура не только в Azure (мультиоблако) или в компании уже стандартизирован Terraform. Знание переносимо: тот же Terraform описывает и AWS, и Kubernetes.

Правило выбора простое: только Azure — берите Bicep (нативно, без лишних слоёв); несколько облаков или уже есть Terraform — берите Terraform. ARM в чистом виде сегодня пишут редко — обычно через Bicep.

Состояние и как это применяют

У Terraform есть состояние (state) — карта соответствия «описание ↔ реальные ресурсы». Его нельзя терять и нельзя держать локально при командной работе, иначе двое применят изменения поверх друг друга. Хранят его в общем месте — например, в Blob Storage с блокировкой. У Bicep/ARM отдельного файла состояния нет: Resource Manager сам знает, что развёрнуто, и сравнивает с шаблоном.

Идея у всех одна — декларативная: вы пишете, что должно существовать, а инструмент вычисляет, что создать, изменить или удалить. Перед применением всегда смотрят предпросмотр изменений (what-if у Bicep, plan у Terraform) — это стоит делать всегда, чтобы случайно не снести лишнее.

Где это применяется

IaC — стандартный способ управлять инфраструктурой Azure в любом серьёзном проекте: инфраструктура лежит в git рядом с кодом, изменения проходят ревью в pull request, а применяет их конвейер доставки, а не человек руками в портале. Это убирает «а кто и что там накликал» и делает инфраструктуру воспроизводимой.

Типичные ошибки новичков:

  • пишут сырой ARM-JSON руками вместо Bicep — тонут в многословии;
  • держат Terraform state локально в командной работе — рассинхрон и затёртые изменения;
  • применяют изменения не глядя в предпросмотр — и удаляют лишнее;
  • кладут секреты прямо в шаблоны и коммитят в git — секреты берут из Key Vault, а не из кода.

Что учить дальше: общие концепции IaC — в основах infrastructure as code; как устроена доставка через конвейер — в принципах CI/CD; что именно вы описываете — сеть, вычисления, данные. Тот же Terraform для AWS разобран в статье про Terraform в AWS.