文档/教程【免费下载链接】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、VS Code、Cloud Shell、Azure CLI展开。读者将掌握 Azure 虚拟网络的构造逻辑与子网规划原则理解 NSG/ASG 规则的优先级与匹配机制并能根据 DevOps 自动化场景在 PowerShell、Azure CLI 与 Cloud Shell 之间做出正确选型。仓库中 Cloud 模块的 ARM 模板与 PowerShell 脚本 为本篇提供了可直接对照的真实部署示例。开篇为什么第 33 天聚焦 Azure 网络与管理方式本系列在之前的日子里主要借助 Azure Portal 完成资源操作而网络模型是 Azure 平台中看不见但无处不在的骨架任何虚拟机、负载均衡、应用网关都挂在虚拟网络中。与此同时从 DevOps 的视角看Portal 只适合探索与学习真正落地到 CI/CD 流水线时必须使用 API 或命令行工具。因此本篇文章包含两个核心主题Azure Network Models虚拟网络Virtual Network、访问控制NSG/ASG、负载均衡Load Balancer / App GatewayAzure Management ToolsAzure Portal、PowerShell、Visual Studio Code、Cloud Shell、Azure CLI 的定位与选型。Day 33 发布于 2022 年 2 月 1 日恰逢 Microsoft Azure 发布 12 周年本文讨论的网络模型与管理工具至今仍是 Azure 运维的基石。Azure 网络模型Azure Network Models虚拟网络Virtual Networks虚拟网络是 Azure 中最基础的网络构造单元本系列教程对其特性做了如下总结虚拟网络是在 Azure 中创建的构造construct它不是一个物理设备一个虚拟网络会被分配一个或多个 IP 地址范围address space虚拟网络存在于某个订阅subscription内的某个区域region中虚拟子网virtual subnet在虚拟网络中创建用于切分网络地址范围虚拟机被放置到虚拟子网中同一虚拟网络内的所有虚拟机可以互相通信每个虚拟网络最多支持 65,536 个私有 IP 地址即 /16 网段只对离开区域的出站流量egress traffic计费同时支持 IPv4 与 IPv6其中 IPv6 可用于公网面以及虚拟网络内部。可以将 Azure 虚拟网络类比为 AWS VPC但两者存在明显差异对比维度AWS VPCAzure Virtual Network默认网络AWS 会创建默认 VPCAzure 不创建默认虚拟网络必须按需创建第一个公网访问需要 NAT Gateway 等组件虚拟机默认通过 NAT 方式访问互联网无需单独 NAT 网关子网概念区分 Private/Public 子网没有 Private/Public 子网之分公网 IP绑定到实例是独立资源可分配给 vNIC 或负载均衡器网络 ACL独立于安全组虚拟网络与子网各自拥有 ACL支持子网级委托delegation可用区每个可用区一个子网子网可横跨多个可用区Availability Zones在真实部署中虚拟网络的地址空间与子网规划往往通过 ARM 模板固化。仓库中的 Mod04_90DaysOfDevOps-vms-loop-template.json 就是一个典型示例它在资源组90DaysOfDevOps内定义了地址空间为10.40.0.0/22的虚拟网络并划分了两个子网properties: { addressSpace: { addressPrefixes: [ 10.40.0.0/22 ] }, subnets: [ { name: subnet0, properties: { addressPrefix: 10.40.0.0/24 } }, { name: subnet1, properties: { addressPrefix: 10.40.1.0/24 } } ] }模板通过copy循环copy: { name: VMcopy, count: [parameters(vmCount)] }批量创建 NIC 与虚拟机NIC 采用privateIPAllocationMethod: Dynamic动态分配私有 IP这与文档中虚拟机放置在子网中、通过 vNIC 接入虚拟网络的描述完全对应。配套的 Module4_90DaysOfDevOps.ps1 展示了用 Azure PowerShell 的New-AzResourceGroupDeployment结合模板与参数文件一键完成部署的方式。虚拟网络对等Virtual Network Peering虚拟网络对等Peering允许跨租户、跨区域的虚拟网络通过 Azure 骨干网Azure backbone互相连通。需要特别注意Peering 是**不可传递not transitive**的A 与 B 对等、B 与 C 对等并不代表 A 与 C 自动互通不可传递性可以通过在 Hub 虚拟网络中的Azure Firewall来打通即 hub-spoke 模式通过网关传递gateway transit可以让已对等的虚拟网络获得连通网络的连接能力典型场景是ExpressRoute把本地数据中心On-Premises接入云端。访问控制网络安全组NSGAzure 使用**有状态stateful**的网络安全组Network Security Group实现访问控制允许创建规则后将其分配给 NSGNSG 可以应用到子网或虚拟机即使 NSG 被应用到子网其强制点仍在虚拟机 NIC 上它不是边缘Edge设备——这一点与传统的边界防火墙在概念上截然不同。Azure 虚拟网络中子网级 NSG 的拓扑示意前端子网与后端子网分别挂载 NSG外部到前端的流量依据规则被允许或拒绝。NSG 内部组合了多条规则依据**优先级priority**决定生效顺序多条规则组合在一个 NSG 中基于优先级实现灵活配置优先级数字越小优先级越高规则逻辑主要基于 IP 地址构建但也可以使用部分服务标签service tags与标签labels。文档给出的经典 NSG 规则表示例描述优先级源地址源端口目标地址目标端口动作Inbound 4431005***443AllowILB1010AzureLoadBalancer**10000AllowDeny All Inbound4000****DENY注意AzureLoadBalancer是 Azure 内置的服务标签用于放行来自负载均衡健康探测的流量无需手工枚举 IP。优先级 4000 的Deny All Inbound作为兜底规则保证未被显式放行的入站流量一律被拒绝。仓库的流量管理模板 Mod06_90DaysOfDevOps-vms-loop-template.json 给出了 NSG 在 ARM 模板中的真实写法它创建了 3 个 NSG其中包含两条规则——default-allow-rdp优先级 1000TCP 3389与default-allow-http优先级 1100TCP 80并将 NSG 通过networkSecurityGroup.id关联到每块 NIC 上networkSecurityGroup: { id: [resourceId(Microsoft.Network/networkSecurityGroups, variables(nsgNames)[copyIndex()])] }这验证了文档所述规则创建后分配到 NSGNSG 应用到子网或 VMNIC的完整链路也展示了优先级数值越小越先匹配的实际用法RDP 1000 优先于 HTTP 1100。应用安全组ASGNSG 聚焦于 IP 地址范围在大规模、快速变化的业务环境中维护成本很高。**应用安全组Application Security Group, ASG**提供了基于角色的抽象为不同应用角色如 Web 服务器、数据库服务器、WebApp1定义真实名称moniker将虚拟机 NIC 加入一个或多个 ASG 作为成员ASG 可以被 NSG 规则引用用于控制通信流向同时仍可使用 NSG 的特性如服务标签。文档给出的 ASG 规则示例动作名称源目标端口AllowAllowInternettoWebInternetWebServers443 (HTTPS)AllowAllowWebToAppWebServersAppServers443 (HTTPS)AllowAllowAppToDBAppServersDbServers1443 (MSSQL)DenyDenyAllinboundAnyAnyAny在这套规则中规则的主体从 IP 变成了逻辑角色WebServers、AppServers、DbServers新增一台 Web 服务器时只需把它的 NIC 加入WebServers组即可无需修改任何 IP 规则——这正是 ASG 对快速成长环境的价值。负载均衡Load Balancer 与 App GatewayAzure 提供两个第一方负载均衡解决方案Azure Marketplace 中还有第三方方案两者都支持外部公网或内部私有端点Load Balancer第 4 层 / Layer 4基于传输层工作支持哈希分布hash-based distribution与端口转发port-forwardingApp Gateway第 7 层 / Layer 7基于应用层工作支持SSL 卸载SSL offload、基于 Cookie 的会话亲和cookie-based session affinity与基于 URL 的内容路由URL-based content routingApp Gateway 还可以可选启用Web 应用防火墙WAF组件。选型原则很直观需要四层TCP/UDP吞吐与端口转发用 Load Balancer需要七层 HTTP 路由、会话保持与 SSL 终结用 App Gateway若同时有 Web 攻击防护需求则叠加 WAF。Azure 管理工具Azure Management Tools本系列前期大量时间是在 Azure Portal 中做理论演示但作者明确指出在 DevOps 文化与流程下尤其是资源供给provisioning类任务绝大多数将通过 API 或命令行工具完成。下面逐一介绍五大管理工具的定位。Azure PortalAzure Portal 是基于 Web 的控制台是命令行工具的替代方案可在 Portal 中管理订阅从简单 Web 应用到复杂云部署都可完成构建、管理与监控Portal 中存在**面包屑breadcrumbs**导航便于追踪操作路径JSON 是所有 Azure 资源的底层表达。可以在 Portal 中先理解功能与服务再反查其背后的 JSON 定义将其融入自动化工作流。此外还有Azure Preview 门户用于预览和测试即将上线的新服务与增强功能适合早期评估新能力。PowerShell 与 Azure PowerShellPowerShell 是一个任务自动化与配置管理框架既是命令行 shell 也是脚本语言——可以类比本系列 Linux 章节讲过的 shell 脚本。PowerShell 最初主要出现在 Windows 上现在已支持跨平台Windows、macOS、Linux。Azure PowerShell是一组用于从 PowerShell 命令行直接管理 Azure 资源的 cmdlet使用Connect-AzAccount连接到订阅通过Get-Command等命令检索与 Azure VM 相关的 cmdlet例如New-AzVM、Get-AzVM微软官方提供了丰富的快速入门quickstart文档用于从 PowerShell 出发供给各类服务。仓库中 Mod06_90DaysOfDevOps.ps1 就是 Azure PowerShell 的完整实战先New-AzResourceGroupDeployment部署模板再用Get-AzVM获取全部 VM 名称通过foreach循环为每台 VM 安装Microsoft.Azure.NetworkWatcher发布的 NetworkWatcherAgentWindows 扩展最后利用Set-AzVMExtension下发配置——这正是用 PowerShell 自动化管理 Azure 资源的教科书式代码。Visual Studio CodeVisual Studio Code 是微软出品的免费源代码编辑器支持 Windows、Linux 与 macOS也是本系列作者的常用 IDE。VS Code 内置了大量与 Azure 及其中服务交互的集成与工具例如 Azure 扩展、ARM 模板编辑器、远程调试等开发者可以在编辑代码的同时完成资源的查看与操作将写基础设施代码与管理云资源收敛到同一工作流中。Cloud ShellAzure Cloud Shell 是一个经过身份验证、可通过浏览器访问的交互式 shell用于管理 Azure 资源提供选择 shell 体验的灵活性首次启动时可以在Bash 与 PowerShell之间选择使用 Cloud Shell 需要在订阅中提供少量存储选择使用 Cloud Shell 时会拉起一台临时机器但文件通过两种方式持久化磁盘镜像disk image与挂载的文件共享mounted file share。Azure 门户中的 Cloud Shell 欢迎界面可选择 Bash 或 PowerShell 两种 shell 环境。Cloud Shell 的关键行为特征摘自微软官方 Cloud Shell 概览本教程原文引用Cloud Shell 运行在按会话、按用户提供的临时主机上无交互活动20 分钟后 Cloud Shell 超时需要挂载一个Azure 文件共享file shareBash 与 PowerShell 使用同一个 Azure 文件共享每个用户账户被分配一台机器通过文件共享中的5-GB 镜像持久化$HOME目录Bash 中的权限按普通 Linux 用户设置。Azure CLI 与工具选型Azure CLI 可安装在 Windows、Linux 与 macOS 上安装后输入az加子命令即可创建、更新、删除与查看 Azure 资源。作者初学时常困惑于Azure PowerShell 与 Azure CLI 并存Azure PowerShell附加到 Windows PowerShell 或 PowerShell Core 的模块其他系统也可用但不是全部Azure CLI跨平台的命令行程序连接到 Azure 并执行命令。两者语法不同但能完成非常相似的任务。例如创建虚拟机PowerShellNew-AzVMAzure CLIaz vm create作者在自己的 Windows 机器上同时安装了 Azure PowerShell 模块与 Azure CLI并通过 PowerShell 调用az命令在 PowerShell 7 中调用az --version查看 Azure CLI 版本信息验证 CLI 与 PowerShell 可共存使用。官方对两者的能力描述对比如下Azure CLI跨平台命令行接口可在 Windows、macOS、Linux 上安装运行于 Windows PowerShell、Cmd、Bash 及其他 Unix shell 中。Azure PowerShell跨平台 PowerShell 模块运行于 Windows、macOS、Linux需要 Windows PowerShell 或 PowerShellCore环境。选型结论如果环境中无法使用 PowerShell但可以使用.md应为 shell/bash 等脚本环境或 Bash那么Azure CLI 是合适的选择。更重要的理念在于——Azure 运行在自动化之上你在 Portal 中执行的每一次操作底层都对应着某段代码在对资源进行读取、创建、修改或删除。理解 JSON 底层、掌握至少一种命令行工具才是把 Azure 纳入 DevOps 流水线的关键。小结与下一步第 33 天完成了 Azure 网络模型与管理工具的完整理论铺垫虚拟网络地址空间/子网/可用性区域模型与 AWS VPC 的差异Peering 的传递性与 gateway transit访问控制有状态 NSG、优先级机制、服务标签以及面向角色抽象的 ASG负载均衡Layer 4 的 Load Balancer 与 Layer 7 的 App Gateway含可选 WAF管理工具Portal含 Preview 门户用于探索与理解 JSON 底层PowerShell、VS Code、Cloud Shell、Azure CLI 用于脚本化与自动化管理。下一篇Day 34将把所有这些理论投入实际场景在 Azure 中进行动手实验——届时可直接复用仓库 2022/Days/Cloud/ 下的 ARM 模板与 PowerShell 脚本作为实验基础。相关学习资源可继续参考本系列的 Day 33 原文 及其配套图片目录 Images。赞分享文档/教程【免费下载链接】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 33Microsoft Azure 网络模型与 Azure 管理工具实战指南90DaysOfDevOps Day 33Microsoft Azure 网络模型与 Azure 管理工具实战指南 本文是 90DaysOfDevOps 学习文档/教程90DaysOfDevOps Day 33Azure 网络模型与 Azure 管理工具深度解析90DaysOfDevOps Day 33Azure 网络模型与 Azure 管理工具深度解析 本篇技术指南基于 90DaysOfDevOps 项目 2022文档/教程90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析 本篇指南基于 90DaysOfDevOps 项文档/教程上一篇如何用Splatoon插件实现FF14副本导航革命新手5分钟完全指南下一篇终极FFXIV导航指南三步掌握Splatoon插件告别副本迷路焦虑创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 实战笔记：Microsoft Azure 网络模型与 Azure 管理工具全景解析（Day 33）
文档/教程【免费下载链接】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、VS Code、Cloud Shell、Azure CLI展开。读者将掌握 Azure 虚拟网络的构造逻辑与子网规划原则理解 NSG/ASG 规则的优先级与匹配机制并能根据 DevOps 自动化场景在 PowerShell、Azure CLI 与 Cloud Shell 之间做出正确选型。仓库中 Cloud 模块的 ARM 模板与 PowerShell 脚本 为本篇提供了可直接对照的真实部署示例。开篇为什么第 33 天聚焦 Azure 网络与管理方式本系列在之前的日子里主要借助 Azure Portal 完成资源操作而网络模型是 Azure 平台中看不见但无处不在的骨架任何虚拟机、负载均衡、应用网关都挂在虚拟网络中。与此同时从 DevOps 的视角看Portal 只适合探索与学习真正落地到 CI/CD 流水线时必须使用 API 或命令行工具。因此本篇文章包含两个核心主题Azure Network Models虚拟网络Virtual Network、访问控制NSG/ASG、负载均衡Load Balancer / App GatewayAzure Management ToolsAzure Portal、PowerShell、Visual Studio Code、Cloud Shell、Azure CLI 的定位与选型。Day 33 发布于 2022 年 2 月 1 日恰逢 Microsoft Azure 发布 12 周年本文讨论的网络模型与管理工具至今仍是 Azure 运维的基石。Azure 网络模型Azure Network Models虚拟网络Virtual Networks虚拟网络是 Azure 中最基础的网络构造单元本系列教程对其特性做了如下总结虚拟网络是在 Azure 中创建的构造construct它不是一个物理设备一个虚拟网络会被分配一个或多个 IP 地址范围address space虚拟网络存在于某个订阅subscription内的某个区域region中虚拟子网virtual subnet在虚拟网络中创建用于切分网络地址范围虚拟机被放置到虚拟子网中同一虚拟网络内的所有虚拟机可以互相通信每个虚拟网络最多支持 65,536 个私有 IP 地址即 /16 网段只对离开区域的出站流量egress traffic计费同时支持 IPv4 与 IPv6其中 IPv6 可用于公网面以及虚拟网络内部。可以将 Azure 虚拟网络类比为 AWS VPC但两者存在明显差异对比维度AWS VPCAzure Virtual Network默认网络AWS 会创建默认 VPCAzure 不创建默认虚拟网络必须按需创建第一个公网访问需要 NAT Gateway 等组件虚拟机默认通过 NAT 方式访问互联网无需单独 NAT 网关子网概念区分 Private/Public 子网没有 Private/Public 子网之分公网 IP绑定到实例是独立资源可分配给 vNIC 或负载均衡器网络 ACL独立于安全组虚拟网络与子网各自拥有 ACL支持子网级委托delegation可用区每个可用区一个子网子网可横跨多个可用区Availability Zones在真实部署中虚拟网络的地址空间与子网规划往往通过 ARM 模板固化。仓库中的 Mod04_90DaysOfDevOps-vms-loop-template.json 就是一个典型示例它在资源组90DaysOfDevOps内定义了地址空间为10.40.0.0/22的虚拟网络并划分了两个子网properties: { addressSpace: { addressPrefixes: [ 10.40.0.0/22 ] }, subnets: [ { name: subnet0, properties: { addressPrefix: 10.40.0.0/24 } }, { name: subnet1, properties: { addressPrefix: 10.40.1.0/24 } } ] }模板通过copy循环copy: { name: VMcopy, count: [parameters(vmCount)] }批量创建 NIC 与虚拟机NIC 采用privateIPAllocationMethod: Dynamic动态分配私有 IP这与文档中虚拟机放置在子网中、通过 vNIC 接入虚拟网络的描述完全对应。配套的 Module4_90DaysOfDevOps.ps1 展示了用 Azure PowerShell 的New-AzResourceGroupDeployment结合模板与参数文件一键完成部署的方式。虚拟网络对等Virtual Network Peering虚拟网络对等Peering允许跨租户、跨区域的虚拟网络通过 Azure 骨干网Azure backbone互相连通。需要特别注意Peering 是**不可传递not transitive**的A 与 B 对等、B 与 C 对等并不代表 A 与 C 自动互通不可传递性可以通过在 Hub 虚拟网络中的Azure Firewall来打通即 hub-spoke 模式通过网关传递gateway transit可以让已对等的虚拟网络获得连通网络的连接能力典型场景是ExpressRoute把本地数据中心On-Premises接入云端。访问控制网络安全组NSGAzure 使用**有状态stateful**的网络安全组Network Security Group实现访问控制允许创建规则后将其分配给 NSGNSG 可以应用到子网或虚拟机即使 NSG 被应用到子网其强制点仍在虚拟机 NIC 上它不是边缘Edge设备——这一点与传统的边界防火墙在概念上截然不同。Azure 虚拟网络中子网级 NSG 的拓扑示意前端子网与后端子网分别挂载 NSG外部到前端的流量依据规则被允许或拒绝。NSG 内部组合了多条规则依据**优先级priority**决定生效顺序多条规则组合在一个 NSG 中基于优先级实现灵活配置优先级数字越小优先级越高规则逻辑主要基于 IP 地址构建但也可以使用部分服务标签service tags与标签labels。文档给出的经典 NSG 规则表示例描述优先级源地址源端口目标地址目标端口动作Inbound 4431005***443AllowILB1010AzureLoadBalancer**10000AllowDeny All Inbound4000****DENY注意AzureLoadBalancer是 Azure 内置的服务标签用于放行来自负载均衡健康探测的流量无需手工枚举 IP。优先级 4000 的Deny All Inbound作为兜底规则保证未被显式放行的入站流量一律被拒绝。仓库的流量管理模板 Mod06_90DaysOfDevOps-vms-loop-template.json 给出了 NSG 在 ARM 模板中的真实写法它创建了 3 个 NSG其中包含两条规则——default-allow-rdp优先级 1000TCP 3389与default-allow-http优先级 1100TCP 80并将 NSG 通过networkSecurityGroup.id关联到每块 NIC 上networkSecurityGroup: { id: [resourceId(Microsoft.Network/networkSecurityGroups, variables(nsgNames)[copyIndex()])] }这验证了文档所述规则创建后分配到 NSGNSG 应用到子网或 VMNIC的完整链路也展示了优先级数值越小越先匹配的实际用法RDP 1000 优先于 HTTP 1100。应用安全组ASGNSG 聚焦于 IP 地址范围在大规模、快速变化的业务环境中维护成本很高。**应用安全组Application Security Group, ASG**提供了基于角色的抽象为不同应用角色如 Web 服务器、数据库服务器、WebApp1定义真实名称moniker将虚拟机 NIC 加入一个或多个 ASG 作为成员ASG 可以被 NSG 规则引用用于控制通信流向同时仍可使用 NSG 的特性如服务标签。文档给出的 ASG 规则示例动作名称源目标端口AllowAllowInternettoWebInternetWebServers443 (HTTPS)AllowAllowWebToAppWebServersAppServers443 (HTTPS)AllowAllowAppToDBAppServersDbServers1443 (MSSQL)DenyDenyAllinboundAnyAnyAny在这套规则中规则的主体从 IP 变成了逻辑角色WebServers、AppServers、DbServers新增一台 Web 服务器时只需把它的 NIC 加入WebServers组即可无需修改任何 IP 规则——这正是 ASG 对快速成长环境的价值。负载均衡Load Balancer 与 App GatewayAzure 提供两个第一方负载均衡解决方案Azure Marketplace 中还有第三方方案两者都支持外部公网或内部私有端点Load Balancer第 4 层 / Layer 4基于传输层工作支持哈希分布hash-based distribution与端口转发port-forwardingApp Gateway第 7 层 / Layer 7基于应用层工作支持SSL 卸载SSL offload、基于 Cookie 的会话亲和cookie-based session affinity与基于 URL 的内容路由URL-based content routingApp Gateway 还可以可选启用Web 应用防火墙WAF组件。选型原则很直观需要四层TCP/UDP吞吐与端口转发用 Load Balancer需要七层 HTTP 路由、会话保持与 SSL 终结用 App Gateway若同时有 Web 攻击防护需求则叠加 WAF。Azure 管理工具Azure Management Tools本系列前期大量时间是在 Azure Portal 中做理论演示但作者明确指出在 DevOps 文化与流程下尤其是资源供给provisioning类任务绝大多数将通过 API 或命令行工具完成。下面逐一介绍五大管理工具的定位。Azure PortalAzure Portal 是基于 Web 的控制台是命令行工具的替代方案可在 Portal 中管理订阅从简单 Web 应用到复杂云部署都可完成构建、管理与监控Portal 中存在**面包屑breadcrumbs**导航便于追踪操作路径JSON 是所有 Azure 资源的底层表达。可以在 Portal 中先理解功能与服务再反查其背后的 JSON 定义将其融入自动化工作流。此外还有Azure Preview 门户用于预览和测试即将上线的新服务与增强功能适合早期评估新能力。PowerShell 与 Azure PowerShellPowerShell 是一个任务自动化与配置管理框架既是命令行 shell 也是脚本语言——可以类比本系列 Linux 章节讲过的 shell 脚本。PowerShell 最初主要出现在 Windows 上现在已支持跨平台Windows、macOS、Linux。Azure PowerShell是一组用于从 PowerShell 命令行直接管理 Azure 资源的 cmdlet使用Connect-AzAccount连接到订阅通过Get-Command等命令检索与 Azure VM 相关的 cmdlet例如New-AzVM、Get-AzVM微软官方提供了丰富的快速入门quickstart文档用于从 PowerShell 出发供给各类服务。仓库中 Mod06_90DaysOfDevOps.ps1 就是 Azure PowerShell 的完整实战先New-AzResourceGroupDeployment部署模板再用Get-AzVM获取全部 VM 名称通过foreach循环为每台 VM 安装Microsoft.Azure.NetworkWatcher发布的 NetworkWatcherAgentWindows 扩展最后利用Set-AzVMExtension下发配置——这正是用 PowerShell 自动化管理 Azure 资源的教科书式代码。Visual Studio CodeVisual Studio Code 是微软出品的免费源代码编辑器支持 Windows、Linux 与 macOS也是本系列作者的常用 IDE。VS Code 内置了大量与 Azure 及其中服务交互的集成与工具例如 Azure 扩展、ARM 模板编辑器、远程调试等开发者可以在编辑代码的同时完成资源的查看与操作将写基础设施代码与管理云资源收敛到同一工作流中。Cloud ShellAzure Cloud Shell 是一个经过身份验证、可通过浏览器访问的交互式 shell用于管理 Azure 资源提供选择 shell 体验的灵活性首次启动时可以在Bash 与 PowerShell之间选择使用 Cloud Shell 需要在订阅中提供少量存储选择使用 Cloud Shell 时会拉起一台临时机器但文件通过两种方式持久化磁盘镜像disk image与挂载的文件共享mounted file share。Azure 门户中的 Cloud Shell 欢迎界面可选择 Bash 或 PowerShell 两种 shell 环境。Cloud Shell 的关键行为特征摘自微软官方 Cloud Shell 概览本教程原文引用Cloud Shell 运行在按会话、按用户提供的临时主机上无交互活动20 分钟后 Cloud Shell 超时需要挂载一个Azure 文件共享file shareBash 与 PowerShell 使用同一个 Azure 文件共享每个用户账户被分配一台机器通过文件共享中的5-GB 镜像持久化$HOME目录Bash 中的权限按普通 Linux 用户设置。Azure CLI 与工具选型Azure CLI 可安装在 Windows、Linux 与 macOS 上安装后输入az加子命令即可创建、更新、删除与查看 Azure 资源。作者初学时常困惑于Azure PowerShell 与 Azure CLI 并存Azure PowerShell附加到 Windows PowerShell 或 PowerShell Core 的模块其他系统也可用但不是全部Azure CLI跨平台的命令行程序连接到 Azure 并执行命令。两者语法不同但能完成非常相似的任务。例如创建虚拟机PowerShellNew-AzVMAzure CLIaz vm create作者在自己的 Windows 机器上同时安装了 Azure PowerShell 模块与 Azure CLI并通过 PowerShell 调用az命令在 PowerShell 7 中调用az --version查看 Azure CLI 版本信息验证 CLI 与 PowerShell 可共存使用。官方对两者的能力描述对比如下Azure CLI跨平台命令行接口可在 Windows、macOS、Linux 上安装运行于 Windows PowerShell、Cmd、Bash 及其他 Unix shell 中。Azure PowerShell跨平台 PowerShell 模块运行于 Windows、macOS、Linux需要 Windows PowerShell 或 PowerShellCore环境。选型结论如果环境中无法使用 PowerShell但可以使用.md应为 shell/bash 等脚本环境或 Bash那么Azure CLI 是合适的选择。更重要的理念在于——Azure 运行在自动化之上你在 Portal 中执行的每一次操作底层都对应着某段代码在对资源进行读取、创建、修改或删除。理解 JSON 底层、掌握至少一种命令行工具才是把 Azure 纳入 DevOps 流水线的关键。小结与下一步第 33 天完成了 Azure 网络模型与管理工具的完整理论铺垫虚拟网络地址空间/子网/可用性区域模型与 AWS VPC 的差异Peering 的传递性与 gateway transit访问控制有状态 NSG、优先级机制、服务标签以及面向角色抽象的 ASG负载均衡Layer 4 的 Load Balancer 与 Layer 7 的 App Gateway含可选 WAF管理工具Portal含 Preview 门户用于探索与理解 JSON 底层PowerShell、VS Code、Cloud Shell、Azure CLI 用于脚本化与自动化管理。下一篇Day 34将把所有这些理论投入实际场景在 Azure 中进行动手实验——届时可直接复用仓库 2022/Days/Cloud/ 下的 ARM 模板与 PowerShell 脚本作为实验基础。相关学习资源可继续参考本系列的 Day 33 原文 及其配套图片目录 Images。赞分享文档/教程【免费下载链接】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 33Microsoft Azure 网络模型与 Azure 管理工具实战指南90DaysOfDevOps Day 33Microsoft Azure 网络模型与 Azure 管理工具实战指南 本文是 90DaysOfDevOps 学习文档/教程90DaysOfDevOps Day 33Azure 网络模型与 Azure 管理工具深度解析90DaysOfDevOps Day 33Azure 网络模型与 Azure 管理工具深度解析 本篇技术指南基于 90DaysOfDevOps 项目 2022文档/教程90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析 本篇指南基于 90DaysOfDevOps 项文档/教程上一篇如何用Splatoon插件实现FF14副本导航革命新手5分钟完全指南下一篇终极FFXIV导航指南三步掌握Splatoon插件告别副本迷路焦虑创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考