Azure-zero-to-hero 实战：用 ARM 模板与 Azure CLI 声明式部署 Azure 存储账户

• 教程

本文是 Azure-zero-to-hero 系列 Day-11「Azure Resource Manager」配套文档 Day-11/01-storage-account/02-deploy.md 的深度展开，围绕"创建资源组 + 部署 ARM 模板"这一最小闭环，带你逐字段读懂仓库中的 01-storage-account.json 模板，并完成一次真实的存储账户部署。读完本文，你将掌握 ARM 模板的核心结构、存储账户关键参数（kind/SKU/apiVersion）的取舍逻辑，以及用az group create与az deployment group create组合命令交付基础设施的标准姿势，并能将其迁移到仓库中同级的 VM 部署场景。

为什么用 ARM 模板部署存储账户

在 Day-11 的课程定位中，本目录的主旨就是Azure Resource Manager Templates（见 Day-11/README.md）。而在更早的 Day-03/01-basics.md 中，仓库已经给出 ARM 的核心定义：

Azure Resource Manager (ARM) 是 Azure 的部署与管理服务，它提供一致的管理层，使你能够用声明式模板部署资源。ARM 模板用 JSON 描述所需资源及其配置，从而以可预期的方式部署和更新资源。

这段文字精准解释了为什么我们不用一堆零散命令、而是用一个 JSON 文件去创建存储账户：

• 声明式而非命令式：模板描述"最终状态"（一个什么样的存储账户），部署细节由 ARM 负责落实，天然可重复、可审计；
• 依赖自动管理：ARM 会分析模板中的资源引用关系并按正确顺序部署（下文 VM 模板中的dependsOn就是显式例子）；
• 回滚与一致性：部署失败时 ARM 保持已部署部分的一致状态，方便重试与修复；
• 标签与组织：模板可通过tags给资源打标签，便于按项目、环境分类管理（本模板中就带有displayName标签）。

另外，存储账户是 Azure 云上最基础也最常用的资源之一——Day-09 的四篇文档（Blob、File、Table、Queue）所讲的对象存储、文件共享、NoSQL 表与消息队列，全部承载在存储账户之上。用 IaC 的方式把它纳入 DevOps 交付链路，正是本实战的价值所在。

前置准备：Azure CLI 安装与登录

部署命令全部基于 Azure CLI，安装方式可参考 Day-10/01-install.md（该文档给出了 Windows、Linux、macOS 三个平台的官方安装入口，Linux 推荐 apt 方式）。

安装完成后，先登录并确认当前订阅：

# 交互式登录（会弹出浏览器完成认证） az login # 查看当前生效的订阅与账号 az account show # 如果存在多个订阅，可显式指定目标订阅 az account set --subscription "<订阅名称或ID>"

登录后，后续所有az命令都会作用于你的默认订阅，即可开始部署。整个流程不需要访问 Azure 门户，全部在命令行完成。

拆解模板：01-storage-account.json 逐字段解析

仓库根目录下 Day-11/01-storage-account/01-storage-account.json 是一份最小但完整的 ARM 模板。先看它的顶层骨架：

核心资源块

真正干活的是resources数组中的唯一一项（对应 01-storage-account.json 第 8–21 行）：

{ "name": "abhioshekveeramalla11232", "type": "Microsoft.Storage/storageAccounts", "apiVersion": "2023-01-01", "tags": { "displayName": "abhioshekveeramalla11232" }, "location": "[resourceGroup().location]", "kind": "StorageV2", "sku": { "name": "Premium_LRS", "tier": "Premium" } }

四个关键字段逐一说明：

• type：Azure 资源的类型命名空间，Microsoft.Storage/storageAccounts表示存储账户这一资源类型，是 ARM 路由到正确资源提供者的依据；
• apiVersion：2023-01-01，即该资源类型使用的 API 版本。ARM 模板必须显式声明 apiVersion，版本决定了模板中哪些字段可用、校验规则如何，升级 Azure 平台能力时通常需要同步升级模板中的 apiVersion；
• kind：存储账户种类。这里取StorageV2（通用用途 v2），是当前功能最全的一代——同时支持 Blob、文件、队列、表等全部数据服务（这正是 Day-09 四篇文档讲述的四类服务）；仓库中 VM 模板则用了旧版Storage（v1，见后文对比）；
• sku：性能与冗余层级。name: Premium_LRS、tier: Premium表示 Premium 层级的本地冗余存储——Premium 层面向对 I/O 延迟敏感的工作负载，按冗余维度，LRS表示数据在同一区域内的本地冗余存储（在 Azure 冗余体系中属单区域基础冗余）。日常开发环境常见的还有Standard_LRS、Standard_GRS（异地冗余）、Standard_ZRS（可用区冗余）等组合，成本与容灾能力依次递进。

另外两点值得注意：

• location：使用了模板函数[resourceGroup().location]，含义是"跟随资源组所在区域"。这是 ARM 模板函数（不是静态 JSON），部署时由 ARM 在运行时求值。因为模板中并没有硬编码区域，同一份模板可以部署到任何区域的资源组，这正是声明式模板跨区域复用的精髓；
• name：abhioshekveeramalla11232。存储账户名遵循 Azure 平台约束：全小写字母或数字、长度 3–24 位、且全局唯一（不同订阅之间也不能重名）。本仓库示例名 24 位、全小写字母数字，恰好符合规范。因为全局唯一，模板原样部署到其他订阅时若名称已被占用，会直接部署失败——这也是后面"参数化"一节要把名称抽成参数的直接动因。

实战部署：跟着文档走完两条命令

原文档 Day-11/01-storage-account/02-deploy.md 的完整流程只有两条命令，下面是逐条展开。

第一步：创建资源组

az group create --name vscode --location 'Central US'

参数含义：

• --name vscode：资源组名称。仓库示例用vscode，说明部署者本意是"跟着 VSCode 实操"；实际使用中建议按项目/环境命名（如rg-storage-prod）；
• --location 'Central US'：资源组所在区域。注意此处是显式指定的区域，而模板内部用[resourceGroup().location]自动继承它，两处正好呼应。

资源组是 Azure 资源的逻辑容器（生命周期、权限、策略的边界，详见 Day-03/01-basics.md 的 Resource Groups 小节）。先建资源组，后续所有资源就有了统一归属与管理边界。

第二步：部署存储账户 ARM 模板

按原文档说明，先切换到存放01-storage-account.json的目录（即仓库的Day-11/01-storage-account/），然后执行：

az deployment group create --resource-group vscode --template-file 01-storage-account.json

参数含义：

• --resource-group vscode：部署目标资源组，必须与第一步创建的组一致；
• --template-file 01-storage-account.json：本地模板文件路径。ARM 会把模板上传到 Azure 并执行部署。

该命令还有几个高频可选参数，按需使用：

# 指定部署名称（默认由系统按时间戳生成） --name storage-account-deploy # 传入参数（模板定义了 parameters 时使用，键值对或参数文件皆可） --parameters storageAccountName=myuniquename123 # 部署模式：Incremental（增量，默认）或 Complete（完整） --mode Incremental # 预演模式：不真正部署，仅输出将发生的变更，用于 CI 前置检查 --what-if

第三步：验证部署结果

部署完成后，用以下命令确认资源真实存在：

# 查看资源组内所有部署记录 az deployment group list --resource-group vscode # 按名称查询存储账户详情（名称需替换为实际部署的账户名） az storage account show --name abhioshekveeramalla11232 --resource-group vscode # 列出资源组下的全部存储账户 az storage account list --resource-group vscode

查询返回的 JSON 中，provisioningState为Succeeded即代表部署成功；kind应为StorageV2，sku.name应为Premium_LRS，与模板声明一致。

第四步（可选）：清理资源

实验完毕，删除资源组即可连同组内存储账户一起清理（参考 Day-10/02-create-vm.md 中的同款清理命令）：

az group delete --name vscode

注意该命令会递归删除资源组内所有资源且不可恢复，正式环境请谨慎使用；本仓库的部署实验资源则建议随手清掉，避免 Premium 层存储持续计费。

从仓库看纵深：模板、CLI 与 Terraform 三种姿势对比

Day-11 目录本身就把"ARM 模板 vs Bicep vs Azure CLI vs Terraform"列为学习主线（见 README.md 课程表）。仓库恰好提供了三份可直接对照的素材。

与 VM ARM 模板对比（同目录姊妹篇）

仓库中 Day-11/02-virtual-machine/01-create-vm.json 是一份复杂得多的模板，同样声明了一个存储账户（第 8–20 行），但它被用于 VM 的boot diagnostics（启动诊断日志存储）：

{ "name": "[toLower('ubuntuVM1storageabhi')]", "type": "Microsoft.Storage/storageAccounts", "apiVersion": "2023-01-01", "sku": { "name": "Standard_LRS" }, "kind": "Storage" }

对比本主题模板可以得出几个实战结论：

• kind差异：VM 辅助存储用旧版Storage（v1），主部署用StorageV2——日常新项目一律优先StorageV2，v1 仅见于历史模板或特殊兼容场景；
• name用表达式："[toLower('ubuntuVM1storageabhi')]"是模板表达式在名称上的应用（强制小写），说明名称既可以是字面量也可以是表达式，后者更适合与变量、参数联动；
• dependsOn显式依赖：VM 模板中虚拟网络、网卡、VM 之间用dependsOn/resourceId()声明依赖关系（第 65–66、95–98、124–126 行），存储账户模板虽然只有一个资源无需声明，但当你把多资源写进同一模板时，这套依赖机制就是 ARM"按正确顺序部署"的底层实现；
• 两份模板的部署命令几乎一致，只需换--template-file指向对应 JSON，见 Day-11/02-virtual-machine/02-deploy-vm.md。这也印证了 ARM 模板"同一套部署流程、任意资源类型"的通用性。

与 Azure CLI 命令式创建对比

Day-10/02-create-vm.md 展示的是纯命令式姿势：az group create→az config set defaults.group=...→az vm create。命令式适合一次性、探索性操作；而本主题的模板式适合需要重复执行、多人协作、版本管理的生产链路。同一个存储账户，命令式写法是az storage account create --name ... --resource-group ... --sku Premium_LRS --kind StorageV2，模板式则是"提交 JSON →az deployment group create"。后者的可审计性与可复现性（部署历史、变更记录）是 CI/CD 流水线最看重的。

与 Terraform 声明式 IaC 对比

Day-23 用 Terraform 管理 Azure 资源，仓库提供了 Day-23/main.tf 与 Day-23/backend.tf。从代码结构看，Terraform 与 ARM 模板同属声明式 IaC，但生态差异明显：ARM 模板是 Azure 原生、零额外依赖，az deployment group create一条命令即可运行；Terraform 则需 provider（azurerm）、terraform init/plan/apply三步走，且自带状态文件管理（backend 把terraform.tfstate存进 Azure 存储账户）。选择依据通常是：深度绑定 Azure 且想最快上手选 ARM/Bicep，多云或追求状态管理与生命周期能力选 Terraform——这与 Day-11 README 设定的"Comparison with Terraform"学习目标一致。

让模板更工程化：参数化与复用

原模板的parameters是空的，名称、SKU 全部写死。把模板推向生产级的第一件事就是参数化，让同一份模板适配不同环境。以下给出与本主题直接相关的扩展示意（不在仓库内，仅作演化路径说明）：

{ "parameters": { "storageAccountName": { "type": "string", "minLength": 3, "maxLength": 24, "metadata": { "description": "存储账户全局唯一名称（3-24位小写字母数字）" } }, "skuName": { "type": "string", "defaultValue": "Standard_LRS", "allowedValues": [ "Standard_LRS", "Standard_GRS", "Standard_ZRS", "Premium_LRS", "Premium_ZRS" ], "metadata": { "description": "SKU 冗余与性能层级" } } }, "resources": [ { "name": "[parameters('storageAccountName')]", "type": "Microsoft.Storage/storageAccounts", "apiVersion": "2023-01-01", "location": "[resourceGroup().location]", "kind": "StorageV2", "sku": { "name": "[parameters('skuName')]", "tier": "[startsWith(parameters('skuName'), 'Premium') ? 'Premium' : 'Standard']" } } ] }

部署时通过--parameters注入不同环境的取值（dev用Standard_LRS、prod用Premium_LRS），配合参数文件的minLength/allowedValues校验，可以在部署前就拦截非法输入——这是原文档两条命令走向规模化部署的自然延伸。

小结

本实战以仓库 Day-11/01-storage-account/02-deploy.md 的两条命令为骨架，完成了一次完整的 ARM 声明式部署闭环：az group create建立资源容器 → 读懂 01-storage-account.json 的每个字段（type/apiVersion/kind/sku/location 表达式）→az deployment group create交付资源 → 验证与清理。文中还通过仓库内 VM 模板、CLI 命令与 Terraform 的三组对照，把"为什么用模板、模板比命令好在哪、与 Terraform 怎么取舍"讲透。以此为起点，你可以把同一套流程复用到仓库 Day-11/02-virtual-machine 的 VM 模板部署中，或继续向参数化、--what-if预演、CI 集成方向演进，完成从"手工建资源"到"流水线交付资源"的 DevOps 能力跨越。

• 教程