企业官网建设流程全解析

• 文档/教程

本文是 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 或命令行工具。因此本篇文章包含两个核心主题：

1. Azure Network Models：虚拟网络（Virtual Network）、访问控制（NSG/ASG）、负载均衡（Load Balancer / App Gateway）；
2. Azure Management Tools：Azure 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，但两者存在明显差异：

在真实部署中，虚拟网络的地址空间与子网规划往往通过 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）接入云端。

访问控制：网络安全组（NSG）

Azure 使用**有状态（stateful）**的网络安全组（Network Security Group）实现访问控制：

• 允许创建规则后将其分配给 NSG；
• NSG 可以应用到子网或虚拟机；
• 即使 NSG 被应用到子网，其强制点仍在虚拟机 NIC 上，它不是"边缘（Edge）"设备——这一点与传统的边界防火墙在概念上截然不同。

Azure 虚拟网络中子网级 NSG 的拓扑示意：前端子网与后端子网分别挂载 NSG，外部到前端的流量依据规则被允许或拒绝。

NSG 内部组合了多条规则，依据**优先级（priority）**决定生效顺序：

• 多条规则组合在一个 NSG 中；
• 基于优先级实现灵活配置；
• 优先级数字越小，优先级越高；
• 规则逻辑主要基于 IP 地址构建，但也可以使用部分服务标签（service tags）与标签（labels）。

文档给出的经典 NSG 规则表示例：

注意AzureLoadBalancer是 Azure 内置的服务标签，用于放行来自负载均衡健康探测的流量，无需手工枚举 IP。优先级 4000 的Deny All Inbound作为兜底规则，保证未被显式放行的入站流量一律被拒绝。

仓库的流量管理模板 Mod06_90DaysOfDevOps-vms-loop-template.json 给出了 NSG 在 ARM 模板中的真实写法：它创建了 3 个 NSG，其中包含两条规则——default-allow-rdp（优先级 1000，TCP 3389）与default-allow-http（优先级 1100，TCP 80），并将 NSG 通过networkSecurityGroup.id关联到每块 NIC 上：

"networkSecurityGroup": { "id": "[resourceId('Microsoft.Network/networkSecurityGroups', variables('nsgNames')[copyIndex()])]" }

这验证了文档所述"规则创建后分配到 NSG，NSG 应用到子网或 VM（NIC）"的完整链路，也展示了优先级数值越小越先匹配的实际用法（RDP 1000 优先于 HTTP 1100）。

应用安全组（ASG）

NSG 聚焦于 IP 地址范围，在大规模、快速变化的业务环境中维护成本很高。**应用安全组（Application Security Group, ASG）**提供了基于角色的抽象：

• 为不同应用角色（如 Web 服务器、数据库服务器、WebApp1）定义真实名称（moniker）；
• 将虚拟机 NIC 加入一个或多个 ASG 作为成员；
• ASG 可以被 NSG 规则引用，用于控制通信流向，同时仍可使用 NSG 的特性如服务标签。

文档给出的 ASG 规则示例：

在这套规则中，规则的主体从 IP 变成了逻辑角色（WebServers、AppServers、DbServers），新增一台 Web 服务器时只需把它的 NIC 加入WebServers组即可，无需修改任何 IP 规则——这正是 ASG 对"快速成长环境"的价值。

负载均衡：Load Balancer 与 App Gateway

Azure 提供两个第一方负载均衡解决方案（Azure Marketplace 中还有第三方方案），两者都支持外部（公网）或内部（私有）端点：

• Load Balancer（第 4 层 / Layer 4）：基于传输层工作，支持哈希分布（hash-based distribution）与端口转发（port-forwarding）；
• App Gateway（第 7 层 / Layer 7）：基于应用层工作，支持SSL 卸载（SSL offload）、基于 Cookie 的会话亲和（cookie-based session affinity）与基于 URL 的内容路由（URL-based content routing）；
• App Gateway 还可以可选启用Web 应用防火墙（WAF）组件。

选型原则很直观：需要四层（TCP/UDP）吞吐与端口转发用 Load Balancer；需要七层 HTTP 路由、会话保持与 SSL 终结用 App Gateway，若同时有 Web 攻击防护需求则叠加 WAF。

Azure 管理工具（Azure Management Tools）

本系列前期大量时间是在 Azure Portal 中做理论演示，但作者明确指出：在 DevOps 文化与流程下，尤其是资源供给（provisioning）类任务，绝大多数将通过 API 或命令行工具完成。下面逐一介绍五大管理工具的定位。

Azure Portal

Azure Portal 是基于 Web 的控制台，是命令行工具的替代方案：

• 可在 Portal 中管理订阅；
• 从简单 Web 应用到复杂云部署，都可完成构建、管理与监控；
• Portal 中存在**面包屑（breadcrumbs）**导航，便于追踪操作路径；
• JSON 是所有 Azure 资源的底层表达。可以在 Portal 中先理解功能与服务，再反查其背后的 JSON 定义，将其融入自动化工作流。

此外还有Azure Preview 门户，用于预览和测试即将上线的新服务与增强功能，适合早期评估新能力。

PowerShell 与 Azure PowerShell

PowerShell 是一个任务自动化与配置管理框架，既是命令行 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 Code

Visual Studio Code 是微软出品的免费源代码编辑器，支持 Windows、Linux 与 macOS，也是本系列作者的常用 IDE。VS Code 内置了大量与 Azure 及其中服务交互的集成与工具（例如 Azure 扩展、ARM 模板编辑器、远程调试等），开发者可以在编辑代码的同时完成资源的查看与操作，将"写基础设施代码"与"管理云资源"收敛到同一工作流中。

Cloud Shell

Azure 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 share）；
• Bash 与 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 并执行命令。

两者语法不同，但能完成非常相似的任务。例如创建虚拟机：

• PowerShell：New-AzVM
• Azure CLI：az 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 或 PowerShell（Core）环境。

选型结论：如果环境中无法使用 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。

• 文档/教程