企业官网建设流程全解析

• 文档/教程

本文是 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 做了类比，并明确列出以下差异，这些差异直接决定了你在两个云平台上创建网络时的习惯差异：

虚拟网络对等连接（VNet Peering）

Azure 还提供Virtual Network Peering，使跨租户、跨区域的虚拟网络能够通过 Azure 骨干网（backbone）直接相连。需要注意两个关键性质：

• 不具备传递性（not transitive）：A 与 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；
• 内部划分出subnet0（10.40.0.0/24）与subnet1（10.40.1.0/24）两个子网，正是"子网用于细分网络范围"的落地实现；
• 每个子网10.40.x.0/24拥有 256 个地址，合计构成约 1024 个地址的虚拟网络，远小于 65,536 的上限，说明地址空间可按需裁剪；
• 模板通过copy循环批量创建 NIC 与 VM（默认vmCount=2），NIC 使用privateIPAllocationMethod: Dynamic动态分配私有 IP（NIC 定义），虚拟机则通过networkProfile挂载 NIC（VM 定义），体现了"虚拟机放入虚拟子网"的模型。

访问控制：NSG 与 ASG

Network Security Groups（NSG）

Azure 使用**网络安全组（Network Security Groups，NSG）**实现网络层访问控制，其核心机制如下：

• NSG 是**有状态（stateful）**的：允许出站后，回程流量自动放行，无需额外规则；
• 先创建规则，再将规则组合分配给 NSG；
• NSG 可应用在子网或虚拟机级别；
• 当 NSG 应用于子网时，它仍然在虚拟机 NIC 处强制执行，而非作为"边缘（Edge）"设备在网络边界生效——这一点与传统的防火墙/网关设备模型有本质区别；
• 多个规则组合在同一个 NSG 中，优先级数字越小，优先级越高，规则按优先级顺序评估；
• 规则逻辑大多数基于 IP 地址构建，同时也可使用服务标签（Service Tags）、应用安全组等标签类对象。

原文档给出了一个典型的 NSG 入站规则表（可对照仓库中 Mod06 模板的securityRules数组理解）：

优先级 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 3389（RDP）与 TCP 80（HTTP）入站，优先级分别为 1000 与 1100。

Application Security Groups（ASG）

当环境持续扩张时，以 IP 地址段为核心的 NSG 规则会越来越难以维护。**应用安全组（Application Security Groups，ASG）**正是为此而生：

• 为不同的应用角色定义真实名称（Monikers），例如Webservers、DB servers、WebApp1；
• 将虚拟机NIC 加入一个或多个 ASG作为成员；
• ASG 可直接用于 NSG 规则中的源/目标，从而让规则可读性大幅提升，同时仍然保留服务标签等 NSG 能力。

原文档给出了一个"三层应用（Web → App → DB）"的 ASG 规则示例：

相比纯 IP 规则，这套规则表用角色名代替地址段，语义一目了然：互联网 → Web 服务器（443）、Web → App（443）、App → DB（1443），最后 Deny All 兜底。

下图展示了 NSG 在虚拟网络中的工作逻辑：FRONTEND SUBNET与BACKEND SUBNET分别挂载 NSG，外部云与子网之间的访问被标记为 DENY 与 ALLOW，直观体现了"NSG 控制进入子网/VM 的流量"这一核心思想：

负载均衡：Load Balancer 与 App Gateway

Azure 提供两套第一方（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 Firewall（WAF）**组件，为应用层请求提供 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 Portal

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

• 可在 Portal 内管理订阅（Subscriptions）；
• 可构建、管理与监控从简单 Web 应用到复杂云部署的一切资源；
• Portal 内提供面包屑导航（breadcrumbs）；
• JSON 是一切 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（命令）集。基本使用流程如下：

1. 先登录并连接订阅：

Connect-AzAccount

下图展示了在 PowerShell 7 (x64) 中执行Connect-AzAccount的实际交互：登录成功后输出账号、订阅名称、Tenant ID 与环境信息；当租户下有多个活跃订阅时，默认选择第一个，可用Set-AzContext切换订阅：

2. 查找与虚拟机相关的可用命令：

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 形式提供vmSize（Standard_D2s_v3）、adminUsername（Student）、adminPassword等模板入参——模板负责"声明资源"，参数文件负责"注入环境差异"，这正是 IaC（基础设施即代码）在 Azure 上的标准落地姿势。

Visual Studio Code

Visual Studio Code 是微软出品的免费源代码编辑器，支持 Windows、Linux 与 macOS。原文档作者的日常 IDE 即为 VS Code，其中内置了大量可与 Azure 及其服务交互的集成与工具（Azure 扩展、ARM 模板语言支持、终端内嵌 Azure CLI / PowerShell 等），适合作为"编辑代码 + 管理云资源"的一体化入口。

Azure Cloud Shell

Azure Cloud Shell是一个交互式、已认证、可通过浏览器访问的 shell，用于管理 Azure 资源，并允许用户选择最适合自己的 shell 体验：

• 首次在 Portal 中启动时，可在Bash 与 PowerShell之间选择；
• 使用 Cloud Shell 需要在你的订阅中提供少量存储（用于持久化文件）；
• 启动后它会临时拉起一台机器，这些机器是临时的，但你的文件通过两种方式持久化：磁盘镜像（disk image）与挂载的文件共享（mounted file share）。

原文档给出的 Cloud Shell 运行机制要点（引自 Cloud Shell Overview）：

• Cloud Shell 运行在按会话、按用户提供的临时主机上；
• 超过 20 分钟无交互活动会自动超时；
• 需要挂载一个Azure 文件共享（file share）；
• Bash 与 PowerShell共用同一个文件共享；
• 每个用户账户分配一台机器；
• $HOME目录通过文件共享中保存的5 GB 镜像持久化；
• Bash 环境下的权限与普通 Linux 用户一致。

Azure CLI

Azure CLI 可安装于 Windows、Linux 与 macOS，安装后输入az并跟随子命令即可创建、更新、删除与查看Azure 资源。

关于"Azure PowerShell 与 Azure CLI 有何区别"，原文档给出的理解是：Azure PowerShell 是添加到 Windows PowerShell 或 PowerShell Core 之上的模块（跨平台但在部分 OS 上受限），而 Azure CLI 是连接 Azure 并执行命令的跨平台命令行程序。两者语法不同，但能完成的绝大多数任务高度相似。最直观的例子——创建虚拟机：

下图展示了在 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 列表自行检索

• 文档/教程