尧图网站建设 
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载导读本篇是 90DaysOfDevOps 挑战中 Azure 系列第 2834 天的收官实战篇在前几天掌握公有云基础理论与 Azure 核心概念之后本文以微软 AZ-104Microsoft Azure Administrator官方实验Module 04 / 06 / 07 / 09a为蓝本逐一落地「虚拟网络」「网络流量管理」「Azure 存储」「Serverless Web 应用」四个高频运维场景。读完本文你将能够用 Azure CLI 完成本地登录与认证用 PowerShell ARM 模板一键部署多台虚拟机、VNet、NSG 与负载均衡等资源理解 hub-spoke 网络拓扑与 peering 非传递性掌握存储账户、Blob、文件共享的配置与鉴权以及 Web 应用部署槽Deployment Slot的发布与自动扩缩容验证。仓库中的全部脚本与模板均可在 2022/Days/Cloud 目录中找到并直接复用。实验总览四组实验、一个资源组整个 Azure 实战阶段延续之前 6 天day28day33的学习主线所有实验围绕一个名为90DaysOfDevOps的资源组展开。原文作者采用「一实验一资源组、做完即清」的策略每次实验前删除上一个实验的资源保证环境干净可重复。如果账号没有按作者那样配置“仅能访问单个资源组”的 RBAC 权限也可以直接按官方模块说明删除整个90Days*资源组这会连带删除组内所有资源。实验对应 AZ-104 官方模块仓库脚本/模板目录覆盖任务数虚拟网络Virtual NetworkingModule 042022/Days/Cloud/01VirtualNetworking5 项网络流量管理Network Traffic ManagementModule 062022/Days/Cloud/02TrafficManagement6 项Azure 存储Azure StorageModule 072022/Days/Cloud/03Storage6 项Serverless Web 应用Module 09a2022/Days/Cloud/04Serverless6 项注意原文中 Serverless 实验写为Cloud\05Serverless仓库实际目录名为04Serverless引用时请以仓库实际路径 2022/Days/Cloud/04Serverless 为准。所有脚本均为作者从官方模块改造而来命名统一加入90DaysOfDevOps标识。作者刻意避开了官方示例中尚未学过的容器与 Kubernetes 相关实验保证内容与当前学习进度一致。前置准备az login 与本地 PowerShell 执行与官方实验默认使用 Cloud Shell 不同作者使用前几天创建的新用户在本地 Windows 机器上通过 Azure CLI 登录执行az login执行后浏览器会自动打开完成账号认证即可。随后在 PowerShell 中调用仓库内脚本脚本内部通过New-AzResourceGroupDeployment提交 ARM 模板部署$rgName 90DaysOfDevOps New-AzResourceGroupDeployment -ResourceGroupName $rgName -TemplateFile C:\Users\micha\demo\90DaysOfDevOps\Days\Cloud\01VirtualNetworking\Mod04_90DaysOfDevOps-vms-loop-template.json -TemplateParameterFile C:\Users\micha\demo\90DaysOfDevOps\Days\Cloud\01VirtualNetworking\Mod04_90DaysOfDevOps-vms-loop-parameters.json重要脚本中的-TemplateFile/-TemplateParameterFile路径是作者本机的绝对路径务必改为你本地仓库的实际路径否则部署会因找不到模板文件而失败。这是四个实验脚本共通的调整点。实验一虚拟网络 Virtual NetworkingModule 04本实验对应官方 AZ-104 Module 04「Implement Virtual Networking」目标是构建一套包含虚拟网络、虚拟机、网络安全组与内部 DNS 的基础网络环境。实验开始前环境中既没有 VNet 也没有 VM仅有一个已配置好的 Cloud Shell 存储位于资源组内。作者先运行 PowerShell 脚本 完成环境创建。任务 1创建并配置虚拟网络模板 Mod04_90DaysOfDevOps-vms-loop-template.json 定义了名为90daysofdevops的 VNet地址空间为10.40.0.0/22内含两个子网子网地址前缀用途subnet010.40.0.0/24默认子网subnet110.40.1.0/24附加子网模板同时以 copy 循环方式创建 VM 与 NIC网络接口关键参数与默认值如下参数默认值/示例说明vmSizeStandard_D2s_v3虚拟机规格2 vCPU / 8 GBvmName90day-vmVM 名称前缀与 copyIndex 拼接vmCount2通过 copy 循环创建的 VM 数量adminUsernameStudent来自参数文件管理员用户名adminPasswordPa55w.rd1234来自参数文件管理员密码模板中声明为securestringvirtualNetworkName90daysofdevops虚拟网络名称虚拟机镜像固定为MicrosoftWindowsServer的2019-DatacenterSKUNIC 的私网 IP 使用Dynamic动态分配并开启provisionVmAgent: true以便后续安装扩展。参数文件 Mod04_90DaysOfDevOps-vms-loop-parameters.json 中直接给出了可用的用户名与密码示例仅限实验环境生产环境务必更换强凭据。任务 2将虚拟机部署到虚拟网络NIC 与 VM 均通过 copy 循环创建VM 通过dependsOn依赖对应 NICNIC 又依赖 VNet 创建完成从而保证部署顺序正确。部署完成后即可在门户看到 VNet 内两台 VM。任务 3配置 Azure 虚拟机的私有与公有 IP 地址实验要求掌握两种 IP 的配置方式私有 IP 支持动态/静态切换可通过门户或 CLI 将 NIC 的privateIPAllocationMethod改为 Static 并指定地址公有 IP 负责 VM 对外暴露的入口本例 VM 未显式绑定公有 IP远程访问依赖后续实验中的跳板/负载均衡机制。任务 4配置网络安全组NSGNSG 通过安全规则控制进出 VM 的流量。在本实验中需要验证默认规则与自定义规则的作用确保只有放行端口如 RDP 3389、HTTP 80能被访问。在后续 Module 06 的模板 Mod06_90DaysOfDevOps-vms-loop-template.json 中可以看到这两种规则的完整 JSON 写法default-allow-rdp优先级 1000放行 TCP 3389与default-allow-http优先级 1100放行 TCP 80NSG 通过networkSecurityGroup.id关联到 NIC 的ipConfigurations。任务 5配置 Azure DNS 实现内部名称解析配置私有 DNS 区域或自定义域名解析使 VNet 内的 VM 能通过内部名称互相访问验证从一台 VM 解析另一台 VM 的内部主机名。实验二网络流量管理 Network Traffic ManagementModule 06本实验对应 Module 06「Implement Network Traffic Management」在上一实验的成果之上构建 hub-spoke 拓扑并验证负载均衡能力。开始前同样先清空上一个实验的资源。作者运行 Mod06 脚本 完成环境创建。任务 1创建实验环境Mod06 脚本 比 Module 04 多了两段逻辑一是提交模板部署二是给资源组内所有 VM 循环安装 Network Watcher Agent$location (Get-AzResourceGroup -ResourceGroupName $rgName).location $vmNames (Get-AzVM -ResourceGroupName $rgName).Name foreach ($vmName in $vmNames) { Set-AzVMExtension -ResourceGroupName $rgName -Location $location -VMName $vmName -Name networkWatcherAgent -Publisher Microsoft.Azure.NetworkWatcher -Type NetworkWatcherAgentWindows -TypeHandlerVersion 1.4 }该扩展是后续验证网络连通性Network Watcher 拓扑/连接测试的前提。模板 Mod06_90DaysOfDevOps-vms-loop-template.json 的拓扑如下4 台 VMvmCount: 4名称为90day-vm090day-vm33 个 VNet90day-vm-vnet01含subnet010.60.0.0/24 与额外subnet110.60.1.0/24、90day-vm-vnet210.62.0.0/22、90day-vm-vnet310.63.0.0/22地址前缀通过VNetPrefixes数组动态拼接每个 NIC 关联一个 NSG放行 RDP 与 HTTP每台 VM 通过 CustomScriptExtension 预装 IIS 并写入标识页面命令为powershell.exe Install-WindowsFeature -name Web-Server -IncludeManagementTools powershell.exe remove-item C:\inetpub\wwwroot\iisstart.htm powershell.exe Add-Content -Path C:\inetpub\wwwroot\iisstart.htm -Value $(Hello World from $env:computername)这保证了后续负载均衡/应用网关测试时每台 VM 都能返回“Hello World from 主机名”便于区分流量落在哪台后端。任务 2配置 hub-spoke 网络拓扑将90day-vm-vnet01作为 hub中心90day-vm-vnet2与90day-vm-vnet3作为 spoke辐条通过 VNet Peering 把两个 spoke 分别与 hub 建立对等连接。任务 3验证虚拟网络对等连接的传递性这是本实验最具教学意义的环节虚拟网络对等连接不具传递性——spoke1 与 spoke2 之间即使都连通 hub两者之间仍然不能直接互通。作者在验证时还踩了一个 RBAC 坑90DaysOfDevOps用户组因权限不足无法使用 Network Watcher该服务资源不在其有权限的资源组内解决方法是给该组手动添加East US Network Watcher contributor角色。最终从 spoke 访问另一 spoke 的失败结果是符合预期的正是“peering 不传递”的实证。任务 4在 hub-spoke 拓扑中配置路由需要配置用户定义路由UDR或使用 hub 中的网络虚拟设备NVA作为下一跳让两个 spoke 的流量经 hub 转发。作者在此遇到第二个权限问题90DaysOfDevOps用户组虽是资源组内所有资源的所有者但在 VM 内执行命令仍不成功最后切回主管理员账号完成 VM 内的命令验证随后再切回michael.cade90DaysOfDevOps.com账号继续后续实验此时各项访问已恢复正常。这也说明 RBAC 的“资源组所有者”并不等同于对 VM 内 guest OS 的管理权限。任务 5部署 Azure Load Balancer在 hub-spoke 拓扑上部署标准型 Azure Load Balancer把前端公网流量按负载均衡规则分发到后端池中的多台 VM验证轮询调度下各 VM 的 IIS 页面交替响应。任务 6部署 Azure Application GatewayApplication Gateway 是第 7 层应用层负载均衡器支持基于 URL 路径的路由、SSL 终结与 WAF 等能力。本任务将其部署在 hub VNet 前配置 HTTP 监听器与后端池规则验证按路径分发流量到不同后端。实验三Azure StorageModule 07本实验对应 Module 07「Manage Azure Storage」覆盖存储账户、Blob、文件共享与访问控制。先运行 Mod07 脚本$rgName 90DaysOfDevOps New-AzResourceGroupDeployment -ResourceGroupName $rgName -TemplateFile C:\Users\micha\demo\90DaysOfDevOps\Days\Cloud\03Storage\Mod07_90DaysOfDevOps-vm-template.json -TemplateParameterFile C:\Users\micha\demo\90DaysOfDevOps\Days\Cloud\03Storage\Mod07_90DaysOfDevOps-vm-parameters.json -AsJob注意这里多了-AsJob参数表示部署作为后台任务异步执行避免阻塞 PowerShell 会话。配套的 Mod07 虚拟机模板 与 参数文件 沿用同样的 VM/参数结构Standard_D2s_v3、Student/Pa55w.rd1234为后续挂载文件共享提供 Windows 客户端 VM。任务 1创建实验环境运行脚本创建一台 Windows VM 作为访问存储的客户端等待后台部署完成。任务 2创建并配置 Azure 存储账户在门户或 CLI 中创建存储账户可关注复制策略LRS/GRS/RA-GRS、性能层级Standard/Premium与访问层级热/冷等关键配置项。任务 3管理 Blob 存储创建容器并上传 Blob理解 Blob 的三种访问层级热/冷/归档对成本与延迟的影响以及 SAS共享访问签名临时授权的用法。任务 4管理 Azure 存储的认证与授权实验要求切换 Azure AD 账号与存储账号密钥两种认证方式。作者特别记录了一个细节权限授权RBAC 角色生效需要等待一段时间一开始测试会失败等待后再次验证即成功——这印证了 Azure RBAC 角色分配存在传播延迟。任务 5创建并配置 Azure 文件共享创建 Azure Files 共享并从 Windows VM 中挂载。作者此处再次遇到 RBAC 限制michael.cade90DaysOfDevOps.com账号执行挂载命令不成功需切换管理员账号完成。这也呼应了实验二的结论资源组级 RBAC 无法覆盖 guest OS 内的 SMB 挂载认证。任务 6管理 Azure 存储的网络访问为存储账户配置网络访问控制包括启用“允许选定的网络”、配置服务终结点或私有终结点Private Endpoint把存储访问限制在指定 VNet/子网范围内。实验四Serverless Web 应用Module 09a本实验对应 Module 09a「Implement Web Apps」是 Azure 系列最后一个实验围绕 Web 应用App Service的部署与扩缩容展开共 6 个任务。任务 1创建 Azure Web App在 App Service 计划Plan上创建 Web 应用选择合适的定价层后续自动扩缩容测试需要支持横向扩展的层级。任务 2创建暂存部署槽Staging Deployment Slot创建staging槽位使应用具备“生产 预发布”双环境代码先发布到 staging 验证再通过槽位交换Swap平滑上线实现零停机发布。任务 3配置 Web 应用部署设置在部署设置中配置源代码管理/构建选项、应用设置App Settings与连接字符串确保 staging 与 production 槽位可独立配置。任务 4将代码部署到暂存部署槽把应用代码发布到staging槽位验证其在暂存环境中的行为此时生产槽位不受影响。任务 5交换暂存槽位Slot Swap执行槽位交换让生产环境无缝切换到新版本。交换时源槽位的应用设置会按“槽位设置”规则跟随或保留这是生产发布的标准做法。任务 6配置并测试 Web 应用自动扩缩容配置基于 CPU 百分比等指标的自动缩放规则然后运行 Mod09a 压测脚本 制造流量$rgName 90DaysOfDevOps $webapp Get-AzWebApp -ResourceGroupName $rgName # The following will start an infinite loop that sends the HTTP requests to the web app while ($true) { Invoke-WebRequest -Uri $webapp.DefaultHostName }脚本先通过Get-AzWebApp获取 Web 应用取其DefaultHostName默认域名随后进入无限循环持续发送 HTTP 请求人为抬高 CPU 使用率以触发自动扩缩容。观察实例数随负载自动增加、负载回落后自动缩减从而验证扩缩容规则真实生效。注意该脚本是无限循环测试完毕后需手动中断CtrlC并清除对应资源避免持续产生流量与费用。实验小结与经验沉淀回顾四个实验除了 Azure 本身的技术点还沉淀出几条对任何公有云运维都适用的经验RBAC 粒度意识资源组所有者 ≠ 全部操作权限。Network Watcher、VM 内命令执行、SMB 文件共享挂载都可能超出资源组 RBAC 的边界需要单独授权如East US Network Watcher contributor角色或使用具备更高权限的管理员账号。角色分配有传播延迟新授予的 RBAC 权限不会立即生效测试失败时先等待再重试。模板化与脚本化所有实验均通过 PowerShell ARM 模板一键部署路径参数是唯一需要按环境调整的点-AsJob异步部署、copy 循环批量建 VM、CustomScriptExtension 注入配置都是可复用的工程手法。按实验清空资源每个实验开始前删除上一个资源组既能保证环境隔离也能避免资源闲置产生持续费用。下一步进入版本控制与 Git至此90DaysOfDevOps 挑战的 Microsoft Azure 公有云阶段以及整个公有云主题告一段落。下一阶段将转入版本控制系统VCS核心围绕Git展开并选择 GitHub 作为代码托管平台进行实践。按学习路径接下来是 第 35 天欢迎继续挑战。参考资料学习路径原文献出AZ-104 Microsoft Azure Administrator 官方实验说明Module 04 / 06 / 07 / 09a本仓库实验即基于该官方实验改编混合云与多云Hybrid Cloud MultiCloud公开视频Microsoft Azure Fundamentals 基础公开课Google Cloud Digital Leader 认证课程公开视频AWS 基础入门完整课程公开视频。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐PaddleDetection二次开发指南如何快速新增一个目标检测模型算法PaddleDetection二次开发指南如何快速新增一个目标检测模型算法 本文介绍如何在 PaddleDetection基于 PaddlePaddle 的文档/教程90DaysOfDevOps 实战篇基于 AZ-104 官方实验室的 Microsoft Azure 动手演练虚拟网络、流量管理、存储与 Web 应用90DaysOfDevOps 实战篇基于 AZ 104 官方实验室的 Microsoft Azure 动手演练虚拟网络、流量管理、存储与 Web 应用 在文档/教程90DaysOfDevOps 实战基于 AZ-104 实验的 Azure 虚拟网络、流量管理与存储动手演练90DaysOfDevOps 实战基于 AZ 104 实验的 Azure 虚拟网络、流量管理与存储动手演练 本文是 90DaysOfDevOps 挑战第 34文档/教程上一篇Nintendo Switch游戏文件终极管理指南NSC_BUILDER完全教程下一篇Leantime 部署教程5 步从零搭建自托管项目管理系统创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 第 34 天实战：基于 AZ-104 官方实验的 Microsoft Azure 四大核心场景动手演练
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载导读本篇是 90DaysOfDevOps 挑战中 Azure 系列第 2834 天的收官实战篇在前几天掌握公有云基础理论与 Azure 核心概念之后本文以微软 AZ-104Microsoft Azure Administrator官方实验Module 04 / 06 / 07 / 09a为蓝本逐一落地「虚拟网络」「网络流量管理」「Azure 存储」「Serverless Web 应用」四个高频运维场景。读完本文你将能够用 Azure CLI 完成本地登录与认证用 PowerShell ARM 模板一键部署多台虚拟机、VNet、NSG 与负载均衡等资源理解 hub-spoke 网络拓扑与 peering 非传递性掌握存储账户、Blob、文件共享的配置与鉴权以及 Web 应用部署槽Deployment Slot的发布与自动扩缩容验证。仓库中的全部脚本与模板均可在 2022/Days/Cloud 目录中找到并直接复用。实验总览四组实验、一个资源组整个 Azure 实战阶段延续之前 6 天day28day33的学习主线所有实验围绕一个名为90DaysOfDevOps的资源组展开。原文作者采用「一实验一资源组、做完即清」的策略每次实验前删除上一个实验的资源保证环境干净可重复。如果账号没有按作者那样配置“仅能访问单个资源组”的 RBAC 权限也可以直接按官方模块说明删除整个90Days*资源组这会连带删除组内所有资源。实验对应 AZ-104 官方模块仓库脚本/模板目录覆盖任务数虚拟网络Virtual NetworkingModule 042022/Days/Cloud/01VirtualNetworking5 项网络流量管理Network Traffic ManagementModule 062022/Days/Cloud/02TrafficManagement6 项Azure 存储Azure StorageModule 072022/Days/Cloud/03Storage6 项Serverless Web 应用Module 09a2022/Days/Cloud/04Serverless6 项注意原文中 Serverless 实验写为Cloud\05Serverless仓库实际目录名为04Serverless引用时请以仓库实际路径 2022/Days/Cloud/04Serverless 为准。所有脚本均为作者从官方模块改造而来命名统一加入90DaysOfDevOps标识。作者刻意避开了官方示例中尚未学过的容器与 Kubernetes 相关实验保证内容与当前学习进度一致。前置准备az login 与本地 PowerShell 执行与官方实验默认使用 Cloud Shell 不同作者使用前几天创建的新用户在本地 Windows 机器上通过 Azure CLI 登录执行az login执行后浏览器会自动打开完成账号认证即可。随后在 PowerShell 中调用仓库内脚本脚本内部通过New-AzResourceGroupDeployment提交 ARM 模板部署$rgName 90DaysOfDevOps New-AzResourceGroupDeployment -ResourceGroupName $rgName -TemplateFile C:\Users\micha\demo\90DaysOfDevOps\Days\Cloud\01VirtualNetworking\Mod04_90DaysOfDevOps-vms-loop-template.json -TemplateParameterFile C:\Users\micha\demo\90DaysOfDevOps\Days\Cloud\01VirtualNetworking\Mod04_90DaysOfDevOps-vms-loop-parameters.json重要脚本中的-TemplateFile/-TemplateParameterFile路径是作者本机的绝对路径务必改为你本地仓库的实际路径否则部署会因找不到模板文件而失败。这是四个实验脚本共通的调整点。实验一虚拟网络 Virtual NetworkingModule 04本实验对应官方 AZ-104 Module 04「Implement Virtual Networking」目标是构建一套包含虚拟网络、虚拟机、网络安全组与内部 DNS 的基础网络环境。实验开始前环境中既没有 VNet 也没有 VM仅有一个已配置好的 Cloud Shell 存储位于资源组内。作者先运行 PowerShell 脚本 完成环境创建。任务 1创建并配置虚拟网络模板 Mod04_90DaysOfDevOps-vms-loop-template.json 定义了名为90daysofdevops的 VNet地址空间为10.40.0.0/22内含两个子网子网地址前缀用途subnet010.40.0.0/24默认子网subnet110.40.1.0/24附加子网模板同时以 copy 循环方式创建 VM 与 NIC网络接口关键参数与默认值如下参数默认值/示例说明vmSizeStandard_D2s_v3虚拟机规格2 vCPU / 8 GBvmName90day-vmVM 名称前缀与 copyIndex 拼接vmCount2通过 copy 循环创建的 VM 数量adminUsernameStudent来自参数文件管理员用户名adminPasswordPa55w.rd1234来自参数文件管理员密码模板中声明为securestringvirtualNetworkName90daysofdevops虚拟网络名称虚拟机镜像固定为MicrosoftWindowsServer的2019-DatacenterSKUNIC 的私网 IP 使用Dynamic动态分配并开启provisionVmAgent: true以便后续安装扩展。参数文件 Mod04_90DaysOfDevOps-vms-loop-parameters.json 中直接给出了可用的用户名与密码示例仅限实验环境生产环境务必更换强凭据。任务 2将虚拟机部署到虚拟网络NIC 与 VM 均通过 copy 循环创建VM 通过dependsOn依赖对应 NICNIC 又依赖 VNet 创建完成从而保证部署顺序正确。部署完成后即可在门户看到 VNet 内两台 VM。任务 3配置 Azure 虚拟机的私有与公有 IP 地址实验要求掌握两种 IP 的配置方式私有 IP 支持动态/静态切换可通过门户或 CLI 将 NIC 的privateIPAllocationMethod改为 Static 并指定地址公有 IP 负责 VM 对外暴露的入口本例 VM 未显式绑定公有 IP远程访问依赖后续实验中的跳板/负载均衡机制。任务 4配置网络安全组NSGNSG 通过安全规则控制进出 VM 的流量。在本实验中需要验证默认规则与自定义规则的作用确保只有放行端口如 RDP 3389、HTTP 80能被访问。在后续 Module 06 的模板 Mod06_90DaysOfDevOps-vms-loop-template.json 中可以看到这两种规则的完整 JSON 写法default-allow-rdp优先级 1000放行 TCP 3389与default-allow-http优先级 1100放行 TCP 80NSG 通过networkSecurityGroup.id关联到 NIC 的ipConfigurations。任务 5配置 Azure DNS 实现内部名称解析配置私有 DNS 区域或自定义域名解析使 VNet 内的 VM 能通过内部名称互相访问验证从一台 VM 解析另一台 VM 的内部主机名。实验二网络流量管理 Network Traffic ManagementModule 06本实验对应 Module 06「Implement Network Traffic Management」在上一实验的成果之上构建 hub-spoke 拓扑并验证负载均衡能力。开始前同样先清空上一个实验的资源。作者运行 Mod06 脚本 完成环境创建。任务 1创建实验环境Mod06 脚本 比 Module 04 多了两段逻辑一是提交模板部署二是给资源组内所有 VM 循环安装 Network Watcher Agent$location (Get-AzResourceGroup -ResourceGroupName $rgName).location $vmNames (Get-AzVM -ResourceGroupName $rgName).Name foreach ($vmName in $vmNames) { Set-AzVMExtension -ResourceGroupName $rgName -Location $location -VMName $vmName -Name networkWatcherAgent -Publisher Microsoft.Azure.NetworkWatcher -Type NetworkWatcherAgentWindows -TypeHandlerVersion 1.4 }该扩展是后续验证网络连通性Network Watcher 拓扑/连接测试的前提。模板 Mod06_90DaysOfDevOps-vms-loop-template.json 的拓扑如下4 台 VMvmCount: 4名称为90day-vm090day-vm33 个 VNet90day-vm-vnet01含subnet010.60.0.0/24 与额外subnet110.60.1.0/24、90day-vm-vnet210.62.0.0/22、90day-vm-vnet310.63.0.0/22地址前缀通过VNetPrefixes数组动态拼接每个 NIC 关联一个 NSG放行 RDP 与 HTTP每台 VM 通过 CustomScriptExtension 预装 IIS 并写入标识页面命令为powershell.exe Install-WindowsFeature -name Web-Server -IncludeManagementTools powershell.exe remove-item C:\inetpub\wwwroot\iisstart.htm powershell.exe Add-Content -Path C:\inetpub\wwwroot\iisstart.htm -Value $(Hello World from $env:computername)这保证了后续负载均衡/应用网关测试时每台 VM 都能返回“Hello World from 主机名”便于区分流量落在哪台后端。任务 2配置 hub-spoke 网络拓扑将90day-vm-vnet01作为 hub中心90day-vm-vnet2与90day-vm-vnet3作为 spoke辐条通过 VNet Peering 把两个 spoke 分别与 hub 建立对等连接。任务 3验证虚拟网络对等连接的传递性这是本实验最具教学意义的环节虚拟网络对等连接不具传递性——spoke1 与 spoke2 之间即使都连通 hub两者之间仍然不能直接互通。作者在验证时还踩了一个 RBAC 坑90DaysOfDevOps用户组因权限不足无法使用 Network Watcher该服务资源不在其有权限的资源组内解决方法是给该组手动添加East US Network Watcher contributor角色。最终从 spoke 访问另一 spoke 的失败结果是符合预期的正是“peering 不传递”的实证。任务 4在 hub-spoke 拓扑中配置路由需要配置用户定义路由UDR或使用 hub 中的网络虚拟设备NVA作为下一跳让两个 spoke 的流量经 hub 转发。作者在此遇到第二个权限问题90DaysOfDevOps用户组虽是资源组内所有资源的所有者但在 VM 内执行命令仍不成功最后切回主管理员账号完成 VM 内的命令验证随后再切回michael.cade90DaysOfDevOps.com账号继续后续实验此时各项访问已恢复正常。这也说明 RBAC 的“资源组所有者”并不等同于对 VM 内 guest OS 的管理权限。任务 5部署 Azure Load Balancer在 hub-spoke 拓扑上部署标准型 Azure Load Balancer把前端公网流量按负载均衡规则分发到后端池中的多台 VM验证轮询调度下各 VM 的 IIS 页面交替响应。任务 6部署 Azure Application GatewayApplication Gateway 是第 7 层应用层负载均衡器支持基于 URL 路径的路由、SSL 终结与 WAF 等能力。本任务将其部署在 hub VNet 前配置 HTTP 监听器与后端池规则验证按路径分发流量到不同后端。实验三Azure StorageModule 07本实验对应 Module 07「Manage Azure Storage」覆盖存储账户、Blob、文件共享与访问控制。先运行 Mod07 脚本$rgName 90DaysOfDevOps New-AzResourceGroupDeployment -ResourceGroupName $rgName -TemplateFile C:\Users\micha\demo\90DaysOfDevOps\Days\Cloud\03Storage\Mod07_90DaysOfDevOps-vm-template.json -TemplateParameterFile C:\Users\micha\demo\90DaysOfDevOps\Days\Cloud\03Storage\Mod07_90DaysOfDevOps-vm-parameters.json -AsJob注意这里多了-AsJob参数表示部署作为后台任务异步执行避免阻塞 PowerShell 会话。配套的 Mod07 虚拟机模板 与 参数文件 沿用同样的 VM/参数结构Standard_D2s_v3、Student/Pa55w.rd1234为后续挂载文件共享提供 Windows 客户端 VM。任务 1创建实验环境运行脚本创建一台 Windows VM 作为访问存储的客户端等待后台部署完成。任务 2创建并配置 Azure 存储账户在门户或 CLI 中创建存储账户可关注复制策略LRS/GRS/RA-GRS、性能层级Standard/Premium与访问层级热/冷等关键配置项。任务 3管理 Blob 存储创建容器并上传 Blob理解 Blob 的三种访问层级热/冷/归档对成本与延迟的影响以及 SAS共享访问签名临时授权的用法。任务 4管理 Azure 存储的认证与授权实验要求切换 Azure AD 账号与存储账号密钥两种认证方式。作者特别记录了一个细节权限授权RBAC 角色生效需要等待一段时间一开始测试会失败等待后再次验证即成功——这印证了 Azure RBAC 角色分配存在传播延迟。任务 5创建并配置 Azure 文件共享创建 Azure Files 共享并从 Windows VM 中挂载。作者此处再次遇到 RBAC 限制michael.cade90DaysOfDevOps.com账号执行挂载命令不成功需切换管理员账号完成。这也呼应了实验二的结论资源组级 RBAC 无法覆盖 guest OS 内的 SMB 挂载认证。任务 6管理 Azure 存储的网络访问为存储账户配置网络访问控制包括启用“允许选定的网络”、配置服务终结点或私有终结点Private Endpoint把存储访问限制在指定 VNet/子网范围内。实验四Serverless Web 应用Module 09a本实验对应 Module 09a「Implement Web Apps」是 Azure 系列最后一个实验围绕 Web 应用App Service的部署与扩缩容展开共 6 个任务。任务 1创建 Azure Web App在 App Service 计划Plan上创建 Web 应用选择合适的定价层后续自动扩缩容测试需要支持横向扩展的层级。任务 2创建暂存部署槽Staging Deployment Slot创建staging槽位使应用具备“生产 预发布”双环境代码先发布到 staging 验证再通过槽位交换Swap平滑上线实现零停机发布。任务 3配置 Web 应用部署设置在部署设置中配置源代码管理/构建选项、应用设置App Settings与连接字符串确保 staging 与 production 槽位可独立配置。任务 4将代码部署到暂存部署槽把应用代码发布到staging槽位验证其在暂存环境中的行为此时生产槽位不受影响。任务 5交换暂存槽位Slot Swap执行槽位交换让生产环境无缝切换到新版本。交换时源槽位的应用设置会按“槽位设置”规则跟随或保留这是生产发布的标准做法。任务 6配置并测试 Web 应用自动扩缩容配置基于 CPU 百分比等指标的自动缩放规则然后运行 Mod09a 压测脚本 制造流量$rgName 90DaysOfDevOps $webapp Get-AzWebApp -ResourceGroupName $rgName # The following will start an infinite loop that sends the HTTP requests to the web app while ($true) { Invoke-WebRequest -Uri $webapp.DefaultHostName }脚本先通过Get-AzWebApp获取 Web 应用取其DefaultHostName默认域名随后进入无限循环持续发送 HTTP 请求人为抬高 CPU 使用率以触发自动扩缩容。观察实例数随负载自动增加、负载回落后自动缩减从而验证扩缩容规则真实生效。注意该脚本是无限循环测试完毕后需手动中断CtrlC并清除对应资源避免持续产生流量与费用。实验小结与经验沉淀回顾四个实验除了 Azure 本身的技术点还沉淀出几条对任何公有云运维都适用的经验RBAC 粒度意识资源组所有者 ≠ 全部操作权限。Network Watcher、VM 内命令执行、SMB 文件共享挂载都可能超出资源组 RBAC 的边界需要单独授权如East US Network Watcher contributor角色或使用具备更高权限的管理员账号。角色分配有传播延迟新授予的 RBAC 权限不会立即生效测试失败时先等待再重试。模板化与脚本化所有实验均通过 PowerShell ARM 模板一键部署路径参数是唯一需要按环境调整的点-AsJob异步部署、copy 循环批量建 VM、CustomScriptExtension 注入配置都是可复用的工程手法。按实验清空资源每个实验开始前删除上一个资源组既能保证环境隔离也能避免资源闲置产生持续费用。下一步进入版本控制与 Git至此90DaysOfDevOps 挑战的 Microsoft Azure 公有云阶段以及整个公有云主题告一段落。下一阶段将转入版本控制系统VCS核心围绕Git展开并选择 GitHub 作为代码托管平台进行实践。按学习路径接下来是 第 35 天欢迎继续挑战。参考资料学习路径原文献出AZ-104 Microsoft Azure Administrator 官方实验说明Module 04 / 06 / 07 / 09a本仓库实验即基于该官方实验改编混合云与多云Hybrid Cloud MultiCloud公开视频Microsoft Azure Fundamentals 基础公开课Google Cloud Digital Leader 认证课程公开视频AWS 基础入门完整课程公开视频。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐PaddleDetection二次开发指南如何快速新增一个目标检测模型算法PaddleDetection二次开发指南如何快速新增一个目标检测模型算法 本文介绍如何在 PaddleDetection基于 PaddlePaddle 的文档/教程90DaysOfDevOps 实战篇基于 AZ-104 官方实验室的 Microsoft Azure 动手演练虚拟网络、流量管理、存储与 Web 应用90DaysOfDevOps 实战篇基于 AZ 104 官方实验室的 Microsoft Azure 动手演练虚拟网络、流量管理、存储与 Web 应用 在文档/教程90DaysOfDevOps 实战基于 AZ-104 实验的 Azure 虚拟网络、流量管理与存储动手演练90DaysOfDevOps 实战基于 AZ 104 实验的 Azure 虚拟网络、流量管理与存储动手演练 本文是 90DaysOfDevOps 挑战第 34文档/教程上一篇Nintendo Switch游戏文件终极管理指南NSC_BUILDER完全教程下一篇Leantime 部署教程5 步从零搭建自托管项目管理系统创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考