尧图网站建设 
文档/教程【免费下载链接】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 学习路线中云计算主题的第 33 天内容聚焦 Microsoft Azure 的两大核心能力网络连接模型虚拟网络、网络安全组、负载均衡与Azure 管理工具链Portal、PowerShell、Cloud Shell、Azure CLI 等。读者将系统掌握 Azure 网络资源的分层设计思路理解 NSG/ASG 规则的优先级与作用机制并学会在 DevOps 自动化实践中选择合适的命令行工具来创建、查询与管理 Azure 资源——文中所有结论都与本仓库2022/Days/Cloud目录下的真实 ARM 模板和 PowerShell 脚本相互印证。Azure 网络模型概述Azure 的网络体系由虚拟网络VNet— 虚拟子网Subnet— 虚拟机VM三级结构构成。VNet 是部署在 Azure 中的网络容器所有网络资源虚拟机、负载均衡器、应用网关等都必须存在于某个虚拟网络内。理解这一分层模型是后续掌握 NSG、对等连接等安全与连通性机制的前提。虚拟网络Virtual Networks的核心特征虚拟网络是 Azure 中创建的网络构造construct一个虚拟网络拥有一个或多个IP 地址段IP ranges虚拟网络存在于某个**订阅Subscription内的某个区域Region**中虚拟子网在虚拟网络内部创建用于进一步细分网络范围虚拟机放置在虚拟子网内同一虚拟网络内的所有虚拟机默认可以互相通信每个虚拟网络最多拥有65,536 个私有 IP即 /16 地址空间规模计费上只为离开区域的数据出站流量付费区域内流量不额外收费同时支持IPv4 与 IPv6其中 IPv6 可用于面向公网的场景以及虚拟网络内部。与 AWS VPC 的对比要点原文档将 Azure 虚拟网络与 AWS VPC 做了类比并明确列出以下差异这些差异直接决定了你在两个云平台上创建网络时的习惯差异对比维度Microsoft AzureAWS默认网络不会自动创建必须按需求手动创建第一个虚拟网络默认创建 VPC公网访问虚拟机默认自带 NAT 访问互联网无 NAT Gateway 概念需配置 NAT Gateway / Internet Gateway子网类型没有 Private / Public 子网之分分为公有子网与私有子网公网 IP是独立资源可分配给 vNIC 或负载均衡器独立弹性 IP 资源访问控制虚拟网络和子网拥有各自 ACL支持子网级委派安全组/网络 ACL 分层可用区子网跨可用区Availability Zones子网归属于单个可用区虚拟网络对等连接VNet PeeringAzure 还提供Virtual Network Peering使跨租户、跨区域的虚拟网络能够通过 Azure 骨干网backbone直接相连。需要注意两个关键性质不具备传递性not transitiveA 与 B 对等、B 与 C 对等并不代表 A 与 C 自动连通传递性可以通过在中心虚拟网络hub VNet中部署 Azure Firewall来间接启用使用**网关传输gateway transit**可让对等的虚拟网络获得已连接网络的连通性典型场景是让对等网络经由 ExpressRoute 访问本地On-Premises数据中心。仓库实证ARM 模板中的虚拟网络与子网本仓库 Mod04 虚拟机批量部署模板 是一个与上述理论一一对应的真实 ARM 模板核心片段如下{ type: Microsoft.Network/virtualNetworks, name: [variables(virtualNetworkName)], apiVersion: [variables(networkApiVersion)], location: [resourceGroup().location], comments: Virtual Network, properties: { addressSpace: { addressPrefixes: [ 10.40.0.0/22 ] }, subnets: [ { name: [variables(subnet0Name)], properties: { addressPrefix: 10.40.0.0/24 } }, { name: [variables(subnet1Name)], properties: { addressPrefix: 10.40.1.0/24 } } ] } }从模板可以看到完整的三级结构模板对应代码虚拟网络90daysofdevops的地址空间为10.40.0.0/22内部划分出subnet010.40.0.0/24与subnet110.40.1.0/24两个子网正是子网用于细分网络范围的落地实现每个子网10.40.x.0/24拥有 256 个地址合计构成约 1024 个地址的虚拟网络远小于 65,536 的上限说明地址空间可按需裁剪模板通过copy循环批量创建 NIC 与 VM默认vmCount2NIC 使用privateIPAllocationMethod: Dynamic动态分配私有 IPNIC 定义虚拟机则通过networkProfile挂载 NICVM 定义体现了虚拟机放入虚拟子网的模型。访问控制NSG 与 ASGNetwork Security GroupsNSGAzure 使用**网络安全组Network Security GroupsNSG**实现网络层访问控制其核心机制如下NSG 是**有状态stateful**的允许出站后回程流量自动放行无需额外规则先创建规则再将规则组合分配给 NSGNSG 可应用在子网或虚拟机级别当 NSG 应用于子网时它仍然在虚拟机 NIC 处强制执行而非作为边缘Edge设备在网络边界生效——这一点与传统的防火墙/网关设备模型有本质区别多个规则组合在同一个 NSG 中优先级数字越小优先级越高规则按优先级顺序评估规则逻辑大多数基于 IP 地址构建同时也可使用服务标签Service Tags、应用安全组等标签类对象。原文档给出了一个典型的 NSG 入站规则表可对照仓库中 Mod06 模板的securityRules数组理解DescriptionPrioritySource AddressSource PortDestination AddressDestination PortActionInbound 4431005***443AllowILB1010Azure LoadBalancer**10000AllowDeny All Inbound4000****DENY优先级 1005 的 443 端口规则最先命中并放行1010 的规则允许来自Azure LoadBalancer服务标签的流量到达 10000 端口最后以优先级 4000 的拒绝所有入站兜底——这就是灵活组合 兜底拒绝的经典设计模式。仓库实证模板中的 NSG 规则Mod06 流量管理模板 中通过copy批量创建了 3 个 NSG并定义了真实的securityRules{ name: default-allow-rdp, properties: { priority: 1000, sourceAddressPrefix: *, protocol: Tcp, destinationPortRange: 3389, access: Allow, direction: Inbound, sourcePortRange: *, destinationAddressPrefix: * } }, { name: default-allow-http, properties: { priority: 1100, sourceAddressPrefix: *, protocol: Tcp, destinationPortRange: 80, access: Allow, direction: Inbound, sourcePortRange: *, destinationAddressPrefix: * } }该模板同时通过 NIC 的networkSecurityGroup属性将 NSG 关联到网络接口关联代码这正是NSG 应用于子网后仍在 NIC 处强制执行的模板化表达规则允许 TCP 3389RDP与 TCP 80HTTP入站优先级分别为 1000 与 1100。Application Security GroupsASG当环境持续扩张时以 IP 地址段为核心的 NSG 规则会越来越难以维护。**应用安全组Application Security GroupsASG**正是为此而生为不同的应用角色定义真实名称Monikers例如Webservers、DB servers、WebApp1将虚拟机NIC 加入一个或多个 ASG作为成员ASG 可直接用于 NSG 规则中的源/目标从而让规则可读性大幅提升同时仍然保留服务标签等 NSG 能力。原文档给出了一个三层应用Web → App → DB的 ASG 规则示例ActionNameSourceDestinationPortAllowAllowInternettoWebInternetWebServers443(HTTPS)AllowAllowWebToAppWebServersAppServers443(HTTPS)AllowAllowAppToDBAppServersDbServers1443 (MSSQL)DenyDenyAllinboundAnyAnyAny相比纯 IP 规则这套规则表用角色名代替地址段语义一目了然互联网 → Web 服务器443、Web → App443、App → DB1443最后 Deny All 兜底。下图展示了 NSG 在虚拟网络中的工作逻辑FRONTEND SUBNET与BACKEND SUBNET分别挂载 NSG外部云与子网之间的访问被标记为 DENY 与 ALLOW直观体现了NSG 控制进入子网/VM 的流量这一核心思想负载均衡Load Balancer 与 App GatewayAzure 提供两套第一方first-party负载均衡方案Azure Marketplace 上还有大量第三方产品可选两者均可服务于**面向内部internal或面向外部external-facing**的端点Load Balancer第 4 层基于哈希hash-based算法做流量分发并支持端口转发port-forwarding适合四层 TCP/UDP 负载均衡场景Application Gateway第 7 层支持SSL 卸载SSL offload、基于 Cookie 的会话保持与基于 URL 的内容路由等应用层能力在 App Gateway 之上还可以**可选启用 Web Application FirewallWAF**组件为应用层请求提供 Web 攻击防护。选型建议需要四层透明分发与端口映射选 Load Balancer需要 HTTP(S) 层路由、卸载与 WAF 防护时选 Application Gateway。Azure 管理工具全景前 32 天的学习主要在 Azure Portal 中进行但遵循 DevOps 文化与流程时资源的初始化与运维应尽可能通过 API 或命令行工具完成。原文档系统梳理了五类管理工具Azure Portal、PowerShell、Visual Studio Code、Cloud Shell 与 Azure CLI。Azure PortalAzure Portal 是基于 Web 的控制台是命令行工具的替代方案可在 Portal 内管理订阅Subscriptions可构建、管理与监控从简单 Web 应用到复杂云部署的一切资源Portal 内提供面包屑导航breadcrumbsJSON 是一切 Azure 资源的底层承载你在 Portal 中的每一次点击操作最终都会转化为对底层 JSON 描述资源的创建、修改或删除。因此合理的进阶路径是先在 Portal 中理解功能与交互再回头读懂底层 JSON/ARM 模板将其融入自动化工作流这正是本仓库2022/Days/Cloud下模板 参数文件 PowerShell 脚本三者结合所演示的方式另有Azure Preview portal可用于预览与试用即将上线的新服务与增强功能。PowerShell 与 Azure PowerShell在介绍 Azure PowerShell 之前需要先认识 PowerShell 本身它是微软推出的任务自动化与配置管理框架既是命令行 shell 也是一种脚本语言最初主要运行于 Windows如今已跨平台可用Windows、Linux、macOS。它与你此前在 Linux 章节学过的 shell 脚本思想类似。Azure PowerShell是一组用于直接从 PowerShell 命令行管理 Azure 资源的cmdlet命令集。基本使用流程如下先登录并连接订阅Connect-AzAccount下图展示了在 PowerShell 7 (x64) 中执行Connect-AzAccount的实际交互登录成功后输出账号、订阅名称、Tenant ID 与环境信息当租户下有多个活跃订阅时默认选择第一个可用Set-AzContext切换订阅查找与虚拟机相关的可用命令Get-Command -Verb Get -Noun AzVM* -Module Az.Compute仓库中的 Module4 PowerShell 脚本 演示了 Azure PowerShell 在自动化中的典型用法——调用New-AzResourceGroupDeployment将 ARM 模板与参数文件组合向90DaysOfDevOps资源组批量下发资源$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对应的 参数文件 以 JSON 形式提供vmSizeStandard_D2s_v3、adminUsernameStudent、adminPassword等模板入参——模板负责声明资源参数文件负责注入环境差异这正是 IaC基础设施即代码在 Azure 上的标准落地姿势。Visual Studio CodeVisual Studio Code 是微软出品的免费源代码编辑器支持 Windows、Linux 与 macOS。原文档作者的日常 IDE 即为 VS Code其中内置了大量可与 Azure 及其服务交互的集成与工具Azure 扩展、ARM 模板语言支持、终端内嵌 Azure CLI / PowerShell 等适合作为编辑代码 管理云资源的一体化入口。Azure Cloud ShellAzure Cloud Shell是一个交互式、已认证、可通过浏览器访问的 shell用于管理 Azure 资源并允许用户选择最适合自己的 shell 体验首次在 Portal 中启动时可在Bash 与 PowerShell之间选择使用 Cloud Shell 需要在你的订阅中提供少量存储用于持久化文件启动后它会临时拉起一台机器这些机器是临时的但你的文件通过两种方式持久化磁盘镜像disk image与挂载的文件共享mounted file share。原文档给出的 Cloud Shell 运行机制要点引自 Cloud Shell OverviewCloud Shell 运行在按会话、按用户提供的临时主机上超过 20 分钟无交互活动会自动超时需要挂载一个Azure 文件共享file shareBash 与 PowerShell共用同一个文件共享每个用户账户分配一台机器$HOME目录通过文件共享中保存的5 GB 镜像持久化Bash 环境下的权限与普通 Linux 用户一致。Azure CLIAzure CLI 可安装于 Windows、Linux 与 macOS安装后输入az并跟随子命令即可创建、更新、删除与查看Azure 资源。关于Azure PowerShell 与 Azure CLI 有何区别原文档给出的理解是Azure PowerShell 是添加到 Windows PowerShell 或 PowerShell Core 之上的模块跨平台但在部分 OS 上受限而 Azure CLI 是连接 Azure 并执行命令的跨平台命令行程序。两者语法不同但能完成的绝大多数任务高度相似。最直观的例子——创建虚拟机工具命令Azure PowerShellNew-AzVMAzure CLIaz vm create下图展示了在 PowerShell 7 终端中直接调用az --version查看 Azure CLI 版本信息的场景azure-cli 2.20.0 及其 core、telemetry 组件说明 CLI 与 PowerShell 可以共存于同一环境并按需调用两者特性速览Azure CLI跨平台命令行界面可安装于 Windows、macOS、Linux可运行于 Windows PowerShell、Cmd、Bash 及其他 Unix shell。Azure PowerShell跨平台 PowerShell 模块运行于 Windows、macOS、Linux需要 Windows PowerShell 或 PowerShell 作为宿主。选型建议如果你的环境无法使用 PowerShell但可以使用 Bash那么 Azure CLI 是更合适的选择。核心原则是选择最适合自己工作方式的工具——因为 Azure 建立在自动化之上你在 Portal 中的每一个动作最终都会翻译成某处执行的一段代码用于读取、创建、修改或删除资源。因此掌握至少一种 CLI/脚本化工具是 DevOps 实践者管理 Azure 的必备技能。仓库实操路径与下一步本仓库2022/Days/Cloud目录提供了与本文主题对应的完整实操素材01VirtualNetworking 目录包含虚拟网络 批量虚拟机部署的 ARM 模板、参数文件与 PowerShell 脚本用于实践VNet → 子网 → VM的模型02TrafficManagement 目录包含带 NSG 安全规则RDP/HTTP与 Network Watcher 扩展安装的流量管理模板及脚本Mod06 脚本 通过Set-AzVMExtension为每台 VM 安装NetworkWatcherAgentWindows代理用于后续网络监控Mod04 参数文件展示模板参数与运行时值分离的 IaC 组织方式。建议按以下顺序练习先用 Portal 观察资源 JSON 结构 → 再用 Cloud Shell / Azure CLI 执行az group create、az vm create等命令 → 最后用 Azure PowerShell 运行仓库脚本完成模板化部署将本文的网络模型与工具链知识串成完整的 DevOps 闭环。下一篇文章Day 34将把这些理论付诸实践在 Azure 上创建真实场景并进行演练。参考资料Azure 虚拟网络与子网理论章节对应的 ARM 模板NSG 安全组规则实践模板Azure PowerShell 自动化部署脚本文中关于混合云/多云、云基础知识的延伸学习可结合 2022/Days/day33.md 原文档的 Resources 列表自行检索赞分享文档/教程【免费下载链接】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 Day 33Azure 网络模型与 Azure 管理工具深度解析90DaysOfDevOps Day 33Azure 网络模型与 Azure 管理工具深度解析 本篇技术指南基于 90DaysOfDevOps 项目 2022文档/教程90DaysOfDevOps 系列Azure 网络模型与 Azure 管理工具深度指南Day 3390DaysOfDevOps 系列Azure 网络模型与 Azure 管理工具深度指南Day 33 导读 本篇是 90DaysOfDevOps 学习路线中文档/教程90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析 本篇指南基于 90DaysOfDevOps 项文档/教程上一篇告别B站会员购抢票焦虑一个开源工具如何改变你的二次元购物体验下一篇ClickHouse v26.1.6.6-stable 版本发布详解五项关键缺陷修复的原理与源码验证创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps Day 33：Microsoft Azure 网络模型与 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 学习路线中云计算主题的第 33 天内容聚焦 Microsoft Azure 的两大核心能力网络连接模型虚拟网络、网络安全组、负载均衡与Azure 管理工具链Portal、PowerShell、Cloud Shell、Azure CLI 等。读者将系统掌握 Azure 网络资源的分层设计思路理解 NSG/ASG 规则的优先级与作用机制并学会在 DevOps 自动化实践中选择合适的命令行工具来创建、查询与管理 Azure 资源——文中所有结论都与本仓库2022/Days/Cloud目录下的真实 ARM 模板和 PowerShell 脚本相互印证。Azure 网络模型概述Azure 的网络体系由虚拟网络VNet— 虚拟子网Subnet— 虚拟机VM三级结构构成。VNet 是部署在 Azure 中的网络容器所有网络资源虚拟机、负载均衡器、应用网关等都必须存在于某个虚拟网络内。理解这一分层模型是后续掌握 NSG、对等连接等安全与连通性机制的前提。虚拟网络Virtual Networks的核心特征虚拟网络是 Azure 中创建的网络构造construct一个虚拟网络拥有一个或多个IP 地址段IP ranges虚拟网络存在于某个**订阅Subscription内的某个区域Region**中虚拟子网在虚拟网络内部创建用于进一步细分网络范围虚拟机放置在虚拟子网内同一虚拟网络内的所有虚拟机默认可以互相通信每个虚拟网络最多拥有65,536 个私有 IP即 /16 地址空间规模计费上只为离开区域的数据出站流量付费区域内流量不额外收费同时支持IPv4 与 IPv6其中 IPv6 可用于面向公网的场景以及虚拟网络内部。与 AWS VPC 的对比要点原文档将 Azure 虚拟网络与 AWS VPC 做了类比并明确列出以下差异这些差异直接决定了你在两个云平台上创建网络时的习惯差异对比维度Microsoft AzureAWS默认网络不会自动创建必须按需求手动创建第一个虚拟网络默认创建 VPC公网访问虚拟机默认自带 NAT 访问互联网无 NAT Gateway 概念需配置 NAT Gateway / Internet Gateway子网类型没有 Private / Public 子网之分分为公有子网与私有子网公网 IP是独立资源可分配给 vNIC 或负载均衡器独立弹性 IP 资源访问控制虚拟网络和子网拥有各自 ACL支持子网级委派安全组/网络 ACL 分层可用区子网跨可用区Availability Zones子网归属于单个可用区虚拟网络对等连接VNet PeeringAzure 还提供Virtual Network Peering使跨租户、跨区域的虚拟网络能够通过 Azure 骨干网backbone直接相连。需要注意两个关键性质不具备传递性not transitiveA 与 B 对等、B 与 C 对等并不代表 A 与 C 自动连通传递性可以通过在中心虚拟网络hub VNet中部署 Azure Firewall来间接启用使用**网关传输gateway transit**可让对等的虚拟网络获得已连接网络的连通性典型场景是让对等网络经由 ExpressRoute 访问本地On-Premises数据中心。仓库实证ARM 模板中的虚拟网络与子网本仓库 Mod04 虚拟机批量部署模板 是一个与上述理论一一对应的真实 ARM 模板核心片段如下{ type: Microsoft.Network/virtualNetworks, name: [variables(virtualNetworkName)], apiVersion: [variables(networkApiVersion)], location: [resourceGroup().location], comments: Virtual Network, properties: { addressSpace: { addressPrefixes: [ 10.40.0.0/22 ] }, subnets: [ { name: [variables(subnet0Name)], properties: { addressPrefix: 10.40.0.0/24 } }, { name: [variables(subnet1Name)], properties: { addressPrefix: 10.40.1.0/24 } } ] } }从模板可以看到完整的三级结构模板对应代码虚拟网络90daysofdevops的地址空间为10.40.0.0/22内部划分出subnet010.40.0.0/24与subnet110.40.1.0/24两个子网正是子网用于细分网络范围的落地实现每个子网10.40.x.0/24拥有 256 个地址合计构成约 1024 个地址的虚拟网络远小于 65,536 的上限说明地址空间可按需裁剪模板通过copy循环批量创建 NIC 与 VM默认vmCount2NIC 使用privateIPAllocationMethod: Dynamic动态分配私有 IPNIC 定义虚拟机则通过networkProfile挂载 NICVM 定义体现了虚拟机放入虚拟子网的模型。访问控制NSG 与 ASGNetwork Security GroupsNSGAzure 使用**网络安全组Network Security GroupsNSG**实现网络层访问控制其核心机制如下NSG 是**有状态stateful**的允许出站后回程流量自动放行无需额外规则先创建规则再将规则组合分配给 NSGNSG 可应用在子网或虚拟机级别当 NSG 应用于子网时它仍然在虚拟机 NIC 处强制执行而非作为边缘Edge设备在网络边界生效——这一点与传统的防火墙/网关设备模型有本质区别多个规则组合在同一个 NSG 中优先级数字越小优先级越高规则按优先级顺序评估规则逻辑大多数基于 IP 地址构建同时也可使用服务标签Service Tags、应用安全组等标签类对象。原文档给出了一个典型的 NSG 入站规则表可对照仓库中 Mod06 模板的securityRules数组理解DescriptionPrioritySource AddressSource PortDestination AddressDestination PortActionInbound 4431005***443AllowILB1010Azure LoadBalancer**10000AllowDeny All Inbound4000****DENY优先级 1005 的 443 端口规则最先命中并放行1010 的规则允许来自Azure LoadBalancer服务标签的流量到达 10000 端口最后以优先级 4000 的拒绝所有入站兜底——这就是灵活组合 兜底拒绝的经典设计模式。仓库实证模板中的 NSG 规则Mod06 流量管理模板 中通过copy批量创建了 3 个 NSG并定义了真实的securityRules{ name: default-allow-rdp, properties: { priority: 1000, sourceAddressPrefix: *, protocol: Tcp, destinationPortRange: 3389, access: Allow, direction: Inbound, sourcePortRange: *, destinationAddressPrefix: * } }, { name: default-allow-http, properties: { priority: 1100, sourceAddressPrefix: *, protocol: Tcp, destinationPortRange: 80, access: Allow, direction: Inbound, sourcePortRange: *, destinationAddressPrefix: * } }该模板同时通过 NIC 的networkSecurityGroup属性将 NSG 关联到网络接口关联代码这正是NSG 应用于子网后仍在 NIC 处强制执行的模板化表达规则允许 TCP 3389RDP与 TCP 80HTTP入站优先级分别为 1000 与 1100。Application Security GroupsASG当环境持续扩张时以 IP 地址段为核心的 NSG 规则会越来越难以维护。**应用安全组Application Security GroupsASG**正是为此而生为不同的应用角色定义真实名称Monikers例如Webservers、DB servers、WebApp1将虚拟机NIC 加入一个或多个 ASG作为成员ASG 可直接用于 NSG 规则中的源/目标从而让规则可读性大幅提升同时仍然保留服务标签等 NSG 能力。原文档给出了一个三层应用Web → App → DB的 ASG 规则示例ActionNameSourceDestinationPortAllowAllowInternettoWebInternetWebServers443(HTTPS)AllowAllowWebToAppWebServersAppServers443(HTTPS)AllowAllowAppToDBAppServersDbServers1443 (MSSQL)DenyDenyAllinboundAnyAnyAny相比纯 IP 规则这套规则表用角色名代替地址段语义一目了然互联网 → Web 服务器443、Web → App443、App → DB1443最后 Deny All 兜底。下图展示了 NSG 在虚拟网络中的工作逻辑FRONTEND SUBNET与BACKEND SUBNET分别挂载 NSG外部云与子网之间的访问被标记为 DENY 与 ALLOW直观体现了NSG 控制进入子网/VM 的流量这一核心思想负载均衡Load Balancer 与 App GatewayAzure 提供两套第一方first-party负载均衡方案Azure Marketplace 上还有大量第三方产品可选两者均可服务于**面向内部internal或面向外部external-facing**的端点Load Balancer第 4 层基于哈希hash-based算法做流量分发并支持端口转发port-forwarding适合四层 TCP/UDP 负载均衡场景Application Gateway第 7 层支持SSL 卸载SSL offload、基于 Cookie 的会话保持与基于 URL 的内容路由等应用层能力在 App Gateway 之上还可以**可选启用 Web Application FirewallWAF**组件为应用层请求提供 Web 攻击防护。选型建议需要四层透明分发与端口映射选 Load Balancer需要 HTTP(S) 层路由、卸载与 WAF 防护时选 Application Gateway。Azure 管理工具全景前 32 天的学习主要在 Azure Portal 中进行但遵循 DevOps 文化与流程时资源的初始化与运维应尽可能通过 API 或命令行工具完成。原文档系统梳理了五类管理工具Azure Portal、PowerShell、Visual Studio Code、Cloud Shell 与 Azure CLI。Azure PortalAzure Portal 是基于 Web 的控制台是命令行工具的替代方案可在 Portal 内管理订阅Subscriptions可构建、管理与监控从简单 Web 应用到复杂云部署的一切资源Portal 内提供面包屑导航breadcrumbsJSON 是一切 Azure 资源的底层承载你在 Portal 中的每一次点击操作最终都会转化为对底层 JSON 描述资源的创建、修改或删除。因此合理的进阶路径是先在 Portal 中理解功能与交互再回头读懂底层 JSON/ARM 模板将其融入自动化工作流这正是本仓库2022/Days/Cloud下模板 参数文件 PowerShell 脚本三者结合所演示的方式另有Azure Preview portal可用于预览与试用即将上线的新服务与增强功能。PowerShell 与 Azure PowerShell在介绍 Azure PowerShell 之前需要先认识 PowerShell 本身它是微软推出的任务自动化与配置管理框架既是命令行 shell 也是一种脚本语言最初主要运行于 Windows如今已跨平台可用Windows、Linux、macOS。它与你此前在 Linux 章节学过的 shell 脚本思想类似。Azure PowerShell是一组用于直接从 PowerShell 命令行管理 Azure 资源的cmdlet命令集。基本使用流程如下先登录并连接订阅Connect-AzAccount下图展示了在 PowerShell 7 (x64) 中执行Connect-AzAccount的实际交互登录成功后输出账号、订阅名称、Tenant ID 与环境信息当租户下有多个活跃订阅时默认选择第一个可用Set-AzContext切换订阅查找与虚拟机相关的可用命令Get-Command -Verb Get -Noun AzVM* -Module Az.Compute仓库中的 Module4 PowerShell 脚本 演示了 Azure PowerShell 在自动化中的典型用法——调用New-AzResourceGroupDeployment将 ARM 模板与参数文件组合向90DaysOfDevOps资源组批量下发资源$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对应的 参数文件 以 JSON 形式提供vmSizeStandard_D2s_v3、adminUsernameStudent、adminPassword等模板入参——模板负责声明资源参数文件负责注入环境差异这正是 IaC基础设施即代码在 Azure 上的标准落地姿势。Visual Studio CodeVisual Studio Code 是微软出品的免费源代码编辑器支持 Windows、Linux 与 macOS。原文档作者的日常 IDE 即为 VS Code其中内置了大量可与 Azure 及其服务交互的集成与工具Azure 扩展、ARM 模板语言支持、终端内嵌 Azure CLI / PowerShell 等适合作为编辑代码 管理云资源的一体化入口。Azure Cloud ShellAzure Cloud Shell是一个交互式、已认证、可通过浏览器访问的 shell用于管理 Azure 资源并允许用户选择最适合自己的 shell 体验首次在 Portal 中启动时可在Bash 与 PowerShell之间选择使用 Cloud Shell 需要在你的订阅中提供少量存储用于持久化文件启动后它会临时拉起一台机器这些机器是临时的但你的文件通过两种方式持久化磁盘镜像disk image与挂载的文件共享mounted file share。原文档给出的 Cloud Shell 运行机制要点引自 Cloud Shell OverviewCloud Shell 运行在按会话、按用户提供的临时主机上超过 20 分钟无交互活动会自动超时需要挂载一个Azure 文件共享file shareBash 与 PowerShell共用同一个文件共享每个用户账户分配一台机器$HOME目录通过文件共享中保存的5 GB 镜像持久化Bash 环境下的权限与普通 Linux 用户一致。Azure CLIAzure CLI 可安装于 Windows、Linux 与 macOS安装后输入az并跟随子命令即可创建、更新、删除与查看Azure 资源。关于Azure PowerShell 与 Azure CLI 有何区别原文档给出的理解是Azure PowerShell 是添加到 Windows PowerShell 或 PowerShell Core 之上的模块跨平台但在部分 OS 上受限而 Azure CLI 是连接 Azure 并执行命令的跨平台命令行程序。两者语法不同但能完成的绝大多数任务高度相似。最直观的例子——创建虚拟机工具命令Azure PowerShellNew-AzVMAzure CLIaz vm create下图展示了在 PowerShell 7 终端中直接调用az --version查看 Azure CLI 版本信息的场景azure-cli 2.20.0 及其 core、telemetry 组件说明 CLI 与 PowerShell 可以共存于同一环境并按需调用两者特性速览Azure CLI跨平台命令行界面可安装于 Windows、macOS、Linux可运行于 Windows PowerShell、Cmd、Bash 及其他 Unix shell。Azure PowerShell跨平台 PowerShell 模块运行于 Windows、macOS、Linux需要 Windows PowerShell 或 PowerShell 作为宿主。选型建议如果你的环境无法使用 PowerShell但可以使用 Bash那么 Azure CLI 是更合适的选择。核心原则是选择最适合自己工作方式的工具——因为 Azure 建立在自动化之上你在 Portal 中的每一个动作最终都会翻译成某处执行的一段代码用于读取、创建、修改或删除资源。因此掌握至少一种 CLI/脚本化工具是 DevOps 实践者管理 Azure 的必备技能。仓库实操路径与下一步本仓库2022/Days/Cloud目录提供了与本文主题对应的完整实操素材01VirtualNetworking 目录包含虚拟网络 批量虚拟机部署的 ARM 模板、参数文件与 PowerShell 脚本用于实践VNet → 子网 → VM的模型02TrafficManagement 目录包含带 NSG 安全规则RDP/HTTP与 Network Watcher 扩展安装的流量管理模板及脚本Mod06 脚本 通过Set-AzVMExtension为每台 VM 安装NetworkWatcherAgentWindows代理用于后续网络监控Mod04 参数文件展示模板参数与运行时值分离的 IaC 组织方式。建议按以下顺序练习先用 Portal 观察资源 JSON 结构 → 再用 Cloud Shell / Azure CLI 执行az group create、az vm create等命令 → 最后用 Azure PowerShell 运行仓库脚本完成模板化部署将本文的网络模型与工具链知识串成完整的 DevOps 闭环。下一篇文章Day 34将把这些理论付诸实践在 Azure 上创建真实场景并进行演练。参考资料Azure 虚拟网络与子网理论章节对应的 ARM 模板NSG 安全组规则实践模板Azure PowerShell 自动化部署脚本文中关于混合云/多云、云基础知识的延伸学习可结合 2022/Days/day33.md 原文档的 Resources 列表自行检索赞分享文档/教程【免费下载链接】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 Day 33Azure 网络模型与 Azure 管理工具深度解析90DaysOfDevOps Day 33Azure 网络模型与 Azure 管理工具深度解析 本篇技术指南基于 90DaysOfDevOps 项目 2022文档/教程90DaysOfDevOps 系列Azure 网络模型与 Azure 管理工具深度指南Day 3390DaysOfDevOps 系列Azure 网络模型与 Azure 管理工具深度指南Day 33 导读 本篇是 90DaysOfDevOps 学习路线中文档/教程90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析 本篇指南基于 90DaysOfDevOps 项文档/教程上一篇告别B站会员购抢票焦虑一个开源工具如何改变你的二次元购物体验下一篇ClickHouse v26.1.6.6-stable 版本发布详解五项关键缺陷修复的原理与源码验证创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考