Azure CLI 2.89：用命令行的方式管理 Azure，值不值得接手

它解决什么问题，谁该用它

Azure CLI 解决的核心问题是用命令行管理 Azure 资源，替代或补充网页控制台。它面向的是需要重复创建、查询、删除资源的工程师，尤其是要在脚本或 CI/CD 流水线里自动化操作的场景。README 明确展示了它的基本调用语法：az 后跟组、子组、命令和参数，例如 az vm create -h 查看虚拟机创建帮助。这意味着它不是一个图形工具，而是把 Azure 的 REST API 封装成一组可预测的命令。适用人群很明确：使用 Azure 的开发运维人员、基础设施工程师，以及任何需要在终端里完成云资源操作的人。它不适合只偶尔登录 Azure 门户点几下按钮的普通用户，那类用户用网页控制台更直接。

工作机制：从命令到 REST API 的封装

Azure CLI 本质上是一个 Python 程序，它将 Azure 的 REST API 映射为命令行结构。你输入 az vm list，CLI 会构造对应的 HTTP 请求，发送到 Azure 控制平面，然后格式化返回的 JSON。README 中展示的查询功能直接基于 JMESPath 语法，例如 az vm list --query "[?provisioningState=='Succeeded'].{ name: name, os: storageProfile.osDisk.osType }"，这说明 CLI 在客户端做了结果过滤和投影，而不是把原始 JSON 一股脑丢给你。另一个关键机制是退出码，README 列出了四种：0 表示成功，1 表示一般错误，2 表示解析错误，3 表示 ARM 资源不存在。这个设计对脚本非常重要，因为你可以根据退出码判断资源是否存在，而不必解析输出文本。这种封装方式意味着 CLI 的行为会随着 Azure API 的演进而变化，版本更新可能引入新的命令或改变现有命令的默认行为。

安装与启动：三条路，各有取舍

README 提供了多种安装途径，但没有给出具体的 pip install 命令，而是指向了官方安装指南。不过它明确列出了几种方式：Docker 镜像、Edge 构建和开发者安装。Docker 方式很直接，命令是 docker run -u $(id -u):$(id -g) -v ${HOME}:/home/az -e HOME=/home/az --rm -it mcr.microsoft.com/azure-cli:<version>，注意它用 -u 参数映射当前用户 ID，避免容器内文件权限问题，还挂载了主目录用于保存配置和凭据。Edge 构建从 dev 分支产生，适合想提前体验新功能的人，但稳定性没有保障。开发者安装需要从源码构建，适合要修改 CLI 本身的贡献者。对普通用户来说，最稳妥的路径是跟随官方安装指南，但 README 没有提供具体的包管理器命令，比如 apt 或 brew，这点需要去文档里查。如果你追求可重复的环境，Docker 是最省心的选择，但每次运行都要拉取镜像，网络开销不小。

脚本化的关键特性：输出格式、查询与退出码

Azure CLI 在脚本化方面的设计明显下了功夫。README 提到可以用 --output table 改变显示格式，但默认输出是 JSON，这适合程序解析。更关键的是 --query 参数配合 JMESPath，让你在客户端就完成数据筛选，减少网络传输和后续处理。例如，你可以用 az vm list --query "[?provisioningState=='Succeeded']" 只列出成功的虚拟机。退出码机制是另一个脚本利器，特别是 3 表示资源不存在，你可以直接用它做存在性检查，而不需要 grep 输出。这些特性组合起来，让 Azure CLI 可以在 bash 或 PowerShell 里与其他命令拼接，实现复杂的自动化流程。但要注意，查询语法有学习曲线，JMESPath 对新手并不友好，写错表达式时错误信息可能不够直观。另外，README 没有提及并发执行时的行为，比如多个 az 命令同时运行是否会有锁冲突，这点在 CI 环境里值得验证。

扩展与集成：VS Code 插件和通用命令

Azure CLI 不止是终端工具，README 提到了 Visual Studio Code 的 Azure CLI Tools 扩展，你可以创建 .azcli 文件，获得命令补全、参数提示、在集成终端运行命令、并排显示输出等功能。这降低了记忆命令参数的成本。更重要的是，CLI 提供了 az resource 和 az rest 这类通用命令，前者允许你操作任意 ARM 资源，不限于预定义的高层命令；后者直接发送 REST 请求，这意味着即使某个资源没有专门命令，你也能通过 az rest 调用底层 API。这种设计让 CLI 的覆盖面远超预设命令集，但代价是你需要理解 ARM 的 REST API 结构，学习曲线更陡。如果你只需要管理常见的虚拟机、存储账户，直接用专用命令就好；但如果是冷门服务，可能就得求助于 az rest。

限制与失败模式：什么时候它不适用

Azure CLI 并不是万能的。首先，它绑定在 Azure 生态上，如果你是多云环境，它无法管理 AWS 或 GCP 资源，你需要额外工具。其次，README 明确说明 telemetry 默认开启，虽然可以用 az config set core.collect_telemetry=no 关闭，但这意味着默认情况下，你的使用数据会发送给微软，对某些组织来说这是合规问题。第三，CLI 的更新节奏很快，最近发布记录显示 2.88.0 和 2.89.1 之间只隔了一个多月，这意味着你需要频繁跟进版本，否则可能错过修复或遇到兼容性问题。第四，CLI 的查询语法和退出码虽然强大，但在复杂管道中，错误处理仍然依赖你对 ARM API 的理解，比如 1 号错误只告诉你“服务器返回了坏状态码”，具体原因还得看输出信息。最后，CLI 是 Python 写的，虽然跨平台，但在资源受限的嵌入式环境里，安装 Python 运行时可能不现实。

替代方案：Azure PowerShell 与 REST API 的取舍

与 Azure CLI 最直接的替代是 Azure PowerShell 模块，它同样官方支持，但使用 PowerShell 语法而非 Bash 风格。区别在于：Azure CLI 的命令结构是 az group create，而 PowerShell 是 New-AzResourceGroup，这影响你在现有脚本生态中的集成方式。如果你已经在用 PowerShell 管理 Windows 服务器，Azure PowerShell 可能更自然；但如果你在 Linux 或 macOS 上做自动化，Azure CLI 更轻量。另一个替代是直接调用 Azure REST API，用 curl 或 Python requests，这样你可以完全控制请求细节，但需要自己处理认证、分页和错误重试，工作量大得多。Azure CLI 的价值在于它把这些封装好了，但代价是你必须接受它的命令设计和版本变化。还有一个非官方途径是使用 Terraform 等基础设施即代码工具，它用声明式配置管理 Azure 资源，与 CLI 的命令式风格完全不同，适合需要版本化基础设施的场景。

维护成本与许可证：你需要知道的

Azure CLI 以 MIT 许可证发布，这意味着你可以自由使用、修改和分发，包括商业用途，这比一些带有更严格条款的云厂商工具更友好。但维护成本不容忽视：项目默认分支是 dev，更新频繁，最近一次发布 2.89.1 在 2026 年 8 月，距离上一个版本仅 8 天，说明补丁迭代很快。你需要在 CI 中固定版本，比如使用 Docker 镜像标签指定版本号，避免意外升级导致脚本行为变化。README 还提到数据收集政策，这不仅是隐私问题，也意味着如果你在合规敏感环境（如医疗或金融）工作，你可能需要明确关闭 telemetry，并确保所有使用该 CLI 的机器都执行了 az config set core.collect_telemetry=no。另外，CLI 依赖 Python 环境，你需要管理 Python 版本和依赖冲突，尤其是如果你在同一台机器上运行多个 Python 工具。长期来看，微软对 Azure CLI 的支持是持续的，但你需要跟上其发布节奏，否则可能遇到 API 兼容性问题。

编辑结论

Azure CLI 适合那些已经深度使用 Azure、需要跨平台脚本化管理的工程师和 DevOps 团队，尤其是愿意接受微软生态绑定、且能容忍频繁版本更新的用户。如果你的工作负载主要在 AWS 或 GCP，或者你只需要偶尔通过网页控制台操作，那么 Azure CLI 不是必要的工具。在采用前，建议先确认你的 Azure 订阅权限模型与 CLI 的默认认证方式是否匹配，并检查 telemetry 默认开启是否符合你所在组织的数据合规要求。最终判断：Azure CLI 是 Azure 官方支持的命令行入口，但它不是中立的云管理工具，选择它意味着接受微软的发布节奏和数据收集策略。

官方来源

1. Official README
2. Project repository
3. Release notes