【免费下载链接】autoskillsOne command. Your entire AI skill stack. Installed.项目地址https://gitcode.com/gh_mirrors/au/autoskills点击查看免费下载本指南围绕 autoskills 仓库中 azure-deploy 技能的强制规则文件 global-rules.md 展开系统讲解 Azure 部署过程中两条不可逾越的安全红线——危险操作必须经用户确认、订阅与区域不得擅自假设——并深入结合 pre-deploy-checklist.md 的完整部署前检查流程。读者将掌握一套可直接落地的 Azure 安全部署规范何时必须调用ask_user、如何正确确认订阅与区域、如何规避资源组冲突、RBAC 传播延迟与标签冲突等高频故障。为什么 Azure 部署需要“全局强制规则”在 azure-deploy 技能体系中global-rules.md不是普通建议而是对所有相关技能一律适用、违反即不可接受的强制性约束原文以MANDATORY标注。它的定位非常明确azure-deploy 只负责执行已经准备好的应用的部署azd up、azd deploy、terraform apply、az deployment不负责创建应用或生成基础设施代码在执行这些命令前必须满足两个前置条件azure-prepare已生成.azure/deployment-plan.md且azure-validate已将其状态置为Validated任何部署动作都可能带来删除、覆盖、不可逆、成本、安全五类风险因此必须有统一的确认机制兜底。该文件与技能主文档的 Rules 一节SKILL.md互相引用构成了“先确认、再检查、后执行”的完整安全闭环。Rule 1一切危险操作必须经过ask_user确认第一条红线在任何危险操作之前必须无条件使用ask_user征求用户明确同意。什么算“危险操作”global-rules.md 用一张表划定了危险操作的边界凡落入以下类别的动作都属于必须确认的范围类别典型示例删除Deleteaz group delete、azd down、rm -rf、删除资源覆盖Overwrite替换已有文件、覆盖配置、重置设置不可逆Irreversible清除 Key Vault、删除存储账户、删除数据库成本影响Cost Impact预配昂贵资源、大规模扩容安全Security暴露机密、变更访问策略、修改 RBAC确认方式示例规则给出了标准化的ask_user调用模板——问题必须具体描述后果选项必须明确且可执行ask_user( question: This will permanently delete resource group rg-myapp. Continue?, choices: [Yes, delete it, No, cancel] )没有例外global-rules.md 明确列举了三条“不得”不得假设用户想要删除或覆盖——即使任务描述听起来像是要清理旧环境不得基于“用户要求部署”就继续——部署deploy不等于删除旧资源delete old不得批量执行危险操作而不逐个确认——每个破坏性动作都必须单独征求同意。Rule 2永远不要假设订阅或区域第二条红线必须使用ask_user确认两件事Azure 订阅必须展示真实的订阅名称和 IDAzure 区域/位置location。规则明确指出“永远不要假设”Never Assume并指向 pre-deploy-checklist.md 作为落地指南。这条规则在实践中往往是被忽视的高频事故源部署到了错误的订阅或把资源创建到了不支持某服务的区域都会造成资源浪费与返工。部署前检查清单Rule 2 的九步落地pre-deploy-checklist.md 将 Rule 2 扩展为一条必须按顺序完成、缺一不可的检查链。它开宗明义地警告在完成所有步骤之前禁止运行azd up——试错不仅浪费时间还会产生孤立资源orphan resources。Step 1–2确认当前订阅并征求用户选择先用 Azure MCP 工具列出订阅或使用 CLI 回退方案az account show --query {name:name, id:id} -o json然后必须用ask_user确认且选项要展示真实名称与 IDask_user( question: Which Azure subscription would you like to deploy to?, choices: [ Use current: subscription-name (subscription-id) (Recommended), Let me specify a different subscription ] )清单特别强调了一个反模式永远不要用自由输入框让用户填订阅❌ Wrong 示例因为自由输入极易拼错也无法校验权限。Step 3先创建 AZD 环境再谈其他这是“先有环境、后有部署”的强制顺序# 新项目尚无 azure.yaml azd init -e environment-name --no-prompt # 已有项目azure.yaml 已存在 azd env new environment-name --no-prompt两条命令都会创建.azure/env-name/配置目录并将其设为默认环境环境名会直接成为资源组名的一部分rg-env-name。注意严禁手动mkdir创建.azure/目录必须让 azd 自己生成否则环境结构会损坏。Step 4检查资源组是否已存在跳过这一步会直接撞上 “Invalid resource group location” 错误。先列出资源组mcp_azure_mcp_group_list subscription: subscription-idCLI 回退az group show --name rg-env-name --query {location:location} -o json 21如果rg-env-name已存在必须用ask_user提供三个选项复用现有 RG 的位置、换一个环境名、删除旧 RG 重新开始删除属于危险操作按 Rule 1 必须确认。Step 5检查标签冲突仅 AZDAZD 依靠azd-service-name标签在目标资源组内定位部署目标同一 RG 内出现同标签的多个资源会导致部署失败az resource list --resource-group rg-env-name --tag azd-service-nameservice-name --query [].name -o table若发现冲突优先推荐新建环境azd env new new-name --no-prompt非破坏性、无需确认只有删除旧资源才需要ask_user。Step 5a检查既有 Container Apps 环境仅 Container Apps这是容易造成环境漂移的隐藏陷阱跳过此步azd up可能静默创建一个名称意外的 Container Apps 环境例如deployment-prod导致部署时间大幅拉长。只有当资源组已存在时才需检查az containerapp env list \ --resource-group rg-env-name \ --query [].{name:name, location:location, provisioningState:properties.provisioningState} \ -o table处理策略Failed/Deleting状态的环境视为无冲突Succeeded的环境需ask_user三选一——复用现有环境用azd env select matching-env-name或重建并azd env set AZURE_SUBSCRIPTION_ID/AZURE_LOCATION指向既有资源组、换个新环境名、或删除重建危险操作需确认。Step 6征求区域选择必须用ask_user提供支持架构中全部服务的区域列表服务级限制见 region-availability.md。Step 7设置环境变量所有变量必须在azd up之前设置完毕而不是在错误恢复阶段补azd env get-values # 确认 AZURE_SUBSCRIPTION_ID / AZURE_LOCATION 已配置Step 8此时才允许部署azd up --no-promptStep 9Terraform 变量解析校验仅 AZD Terraform对 azdTerraform 项目强制Terraform 文件与main.tfvars.json中禁止残留 Go 风格模板变量{{ .Env.VAR }}必须使用${VAR}语法否则部署会因未解析变量失败。校验脚本与修复步骤改用TF_VAR_*环境变量、重跑 azure-validate均已写入清单。正确序列速查# 1. 先建环境 azd env new myapp-dev --no-prompt # 2. 设置订阅 azd env set AZURE_SUBSCRIPTION_ID 25fd0362-... # 3. 确认 RG 无冲突后设置区域 azd env set AZURE_LOCATION westus2 # 4. 验证 azd env get-values # 5. 部署 azd up --no-prompt高频错误对照规则背后的“为什么”清单和 troubleshooting.md 给出了常见误区的正反对照这也解释了规则如此强硬的根源❌ 错误做法✅ 正确做法azd up --location eastus2azd env set AZURE_LOCATION eastus2后再azd up--location不是azd up的合法参数无环境直接azd up先azd env new name --no-prompt不查 RG 就假设区域先用az group show核实忽略目标 RG 内标签冲突部署前az resource list --resource-group rg-env-name检查跳过 Container Apps 环境检查部署前az containerapp env list --resource-group rg-env-nameStep 5aContainer Apps ACR必做 RBAC 传播健康检查这是 checklist 中最关键的专项检查之一当 Container Apps 通过托管身份从 ACR 拉取镜像时必须采用两阶段流程并在“预配”与“镜像部署”之间插入AcrPull角色传播闸门。原因是 Azure RBAC 传播存在 1–5 分钟延迟若跳过闸门Container App 修订版会因等待拉取权限而超时约 900 秒。BicepAZD路径的正确顺序是azd provision→ RBAC 健康检查 →azd deploy --no-promptTerraform 路径则是terraform apply→ 健康检查 →az acr buildaz containerapp registry setaz containerapp update。两阶段模式使用公共占位镜像mcr.microsoft.com/azuredocs/containerapps-helloworld:latest先完成预配再用真实镜像切换。健康检查三步两种路径通用取 Container App 托管身份的principalIdaz containerapp identity show、取 ACR 的idaz acr show、轮询az role assignment list直到出现AcrPull最多 5 次、每次间隔 60 秒。轮询脚本bash 与 PowerShell 双版本完整收录于 pre-deploy-checklist.md。部署后的活体角色验证部署成功后live-role-verification.md 要求对线上 Azure 状态做一次角色核对与 azure-validate 的静态代码检查互补——因为 Bicep/Terraform 正确不代表预配成功策略强制或人工修改也可能改变角色分配。验证流程先从.azure/deployment-plan.md找出所有带托管身份的服务查询 principal ID再按principalId查询角色分配最后按业务需要交叉核对应用操作期望角色作用范围读写 BlobStorage Blob Data Contributor存储账户生成用户委托 SASStorage Blob Delegator存储账户读取机密Key Vault Secrets UserKey Vault发送消息Azure Service Bus Data SenderService Bus 命名空间读写文档Cosmos DB Built-in Data ContributorCosmos DB 账户常见问题包括角色作用域错误分配到资源组而非具体资源、用Contributor替代数据面角色无数据面权限、角色完全缺失、上次部署残留的陈旧 principal ID。结果需记录进.azure/deployment-plan.md的部署验证日志。部署执行的完整工作流按 recipes/azd/README.md一次合规的 AZD 部署应走azd env get-values验证环境 →azd provision --no-prompt预配 → Container Apps ACR 时RBAC 健康检查 →azd deploy --no-prompt部署 → 后置部署步骤 → 验证 → 汇报。其中 verify.md 特别强调汇报端点时必须是带https://的完整 URL很多 Azure CLI 命令只返回裸主机名且必须以azd show的输出为准解析Endpoint:行因为azd deploy的输出经常在端点出现前就被截断。涉及 Azure SQL 托管身份的应用还需在部署后完成 post-deployment.md 描述的 SQL 授权与 EF Core 迁移。总结azure-deploy 的全局规则看似只有两条却贯穿了整个部署生命周期Rule 1 通过ask_user把“删除、覆盖、不可逆、成本、安全”五类风险全部纳入人类确认范围Rule 2 通过强制确认订阅与区域杜绝了部署到错误租户或不可用区域的事故。而 pre-deploy-checklist.md 的九步流程、RBAC 传播闸门、活体角色验证则把这两条红线变成了可操作、可验证、可回滚的工程规范。这套规则的直接价值在于把 Azure 部署中最昂贵的三类失败——错误订阅、资源组位置冲突、ACR 拉取权限超时——从“事后救火”变成了“事前拦截”。赞分享【免费下载链接】autoskillsOne command. Your entire AI skill stack. Installed.项目地址https://gitcode.com/gh_mirrors/au/autoskills点击查看免费下载相关推荐Qwen3-Omni-30B-A3B-Instruct性能基准测试36项音视频任务指标公布Qwen3 Omni 30B A3B Instruct性能基准测试36项音视频任务指标公布 Qwen3 Omni 30B A3B Instruct作为多语言全基础模型大模型多模态QwenWebGoat云安全Azure部署与防护全攻略WebGoat云安全Azure部署与防护全攻略 前言云环境下的Web安全痛点与解决方案 你是否正面临这些挑战在Azure云环境部署Web应用时如何确保故网络安全应用安全渗透测试教育chat0开发者指南贡献代码与扩展功能完全教程chat0开发者指南贡献代码与扩展功能完全教程 chat0是一款闪电般快速、完全免费且开源的AI聊天应用为开发者提供了丰富的定制和扩展可能性。本教程将引导你上一篇从源码到部署3d-vehicle-tracking全流程开发详解下一篇设计提效与创意解放Illustrator自动化工具的实践革命创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考