文档/教程【免费下载链接】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 学习计划 2022 年专题第 33 天聚焦两大主题Azure 网络模型虚拟网络、网络安全组、负载均衡与Azure 管理工具Portal、PowerShell、VS Code、Cloud Shell、Azure CLI。对于 DevOps 工程师而言理解这些网络原语与自动化管理工具链是把 Azure 环境从门户点击走向代码化、自动化供给的必经之路。读完本文你将掌握虚拟网络/子网的地址规划与对等连接原理、网络安全组NSG与应用程序安全组ASG的规则设计、负载均衡方案选型以及五大管理工具的组合用法并能对照仓库中真实的 ARM 模板与 PowerShell 脚本理解其落地形态。Azure 网络模型概览Microsoft Azure 的网络体系以**虚拟网络Virtual Network**为核心围绕地址规划、子网划分、安全控制与流量分发展开。与 AWS VPC 相比两者概念相似但在默认行为、子网语义与安全模型上存在显著差异下文逐一拆解。虚拟网络Virtual Networks核心特征Azure 虚拟网络是订阅内、区域内的逻辑隔离网络构造核心要点如下虚拟网络是 Azure 中创建的构造construct承载一个或多个 IP 地址范围address space虚拟网络位于**某个订阅subscription内的某个区域region**中子网subnet在虚拟网络内创建用于切分网络地址范围虚拟机放置在子网中同一虚拟网络内的所有虚拟机默认可以互相通信每个虚拟网络最多支持65,536 个私有 IP计费只针对离开区域的出站流量egress入站流量与区域内流量不收费同时支持IPv4 与 IPv6IPv6 既可用于面向公网的场景也可用于虚拟网络内部。与 AWS VPC 的关键差异从源码结构看90DaysOfDevOps 仓库的 01VirtualNetworking 模块提供了完整的多虚拟机部署模板其中虚拟网络地址空间被规划为10.40.0.0/22详见 Mod04_90DaysOfDevOps-vms-loop-template.json两个子网分别为10.40.0.0/24与10.40.1.0/24对应文档中虚拟网络含一个或多个 IP 范围、子网用于切分范围的描述。在此基础上理解 Azure 与 AWS 的差异有助于避免迁移时的思维惯性AWS 会自动创建默认 VPCAzure 不会在 Azure 中你必须按自身需求创建第一个虚拟网络不存在开箱即用的默认 VNet默认出网能力不同Azure 中所有虚拟机默认通过 NAT 具备访问互联网的能力无需像 AWS 那样单独配置 NAT 网关没有公有/私有子网概念Azure 不区分 Private/Public 子网子网本身不直接决定公网可达性公网 IP 是独立资源Public IP 作为一种可分配的资源挂载到虚拟网卡vNIC或负载均衡器上ACL 的粒度不同虚拟网络与子网各自拥有 ACL支持子网级委派subnet level delegation子网与可用区的对应关系Azure 的子网可以跨越可用区Availability Zones而 AWS 中每个子网归属于单个可用区。虚拟网络对等Virtual Network Peering虚拟网络对等连接VNet Peering允许跨租户、跨区域的虚拟网络通过Azure 骨干网互联。需要注意两点约束不传递性Not TransitiveA 与 B 对等、B 与 C 对等并不代表 A 能直接访问 C要打通传递路径可在中心hub虚拟网络中使用Azure Firewall充当路由中枢网关传递Gateway Transit通过网关传递可以使已对等的虚拟网络获得对连接网络connected network的访问能力典型案例是将ExpressRoute延伸到本地数据中心On-Premises。访问控制NSG 与 ASG网络安全组Network Security GroupNSGAzure 使用**有状态stateful**的网络安全组来控制流量先创建规则再将其赋予某个网络安全组NSG 可关联到子网或虚拟机网卡关键认知当 NSG 关联到子网时实际强制点仍是虚拟机的 NIC 层面它并非边界设备Edge device这一点区别于传统的防火墙/边缘网关模型。规则在 NSG 中按**优先级priority**合并执行优先级数值越低优先级越高。大多数规则逻辑基于 IP 地址构建同时也支持使用服务标签service tags等标记。文档给出的典型规则集如下DescriptionPrioritySource AddressSource PortDestination AddressDestination PortActionInbound 4431005***443AllowILB1010Azure LoadBalancer**10000AllowDeny All Inbound4000****DENY该表展示了三条典型规则放行任意来源的 443 入站流量、放行来自Azure LoadBalancer服务标签到端口 10000 的流量、以及兜底拒绝DENY所有入站。最后一条通常作为最低优先级存在形成默认拒绝 白名单放行的安全模型。仓库中的 Mod06_90DaysOfDevOps-vms-loop-template.json 给出了 NSG 在 ARM 模板中的真实落地形态模板为 NIC 关联了网络安全组networkSecurityGroup属性并内置两条安全规则——default-allow-rdp优先级 1000放行 TCP 3389 入站与default-allow-http优先级 1100放行 TCP 80 入站且每条规则显式声明direction: Inbound与access: Allow。这印证了规则按优先级合并、低数值高优先级的机制RDP1000先于 HTTP1100评估但两者均为 Allow最终共同生效。应用程序安全组Application Security GroupASGNSG 面向 IP 地址范围在环境规模增长时维护成本很高。ASG 的价值在于引入业务语义命名为不同应用角色定义真实名称Monikers如 Webservers、DB servers、WebApp1 等将虚拟机的NIC 加入一个或多个 ASGASG 可作为 NSG 规则中的源或目的使用控制通信流向同时仍可享受 NSG 的服务标签等能力。文档给出的 ASG 规则示例清晰地展示了三层 Web 架构的流量编排ActionNameSourceDestinationPortAllowAllowInternettoWebInternetWebServers443(HTTPS)AllowAllowWebToAppWebServersAppServers443(HTTPS)AllowAllowAppToDBAppServersDbServers1443 (MSSQL)DenyDenyAllinboundAnyAnyAny这样安全规则从记住哪个网段是 Web 层演进为WebServers 允许来自 Internet 的 443 流量、AppServers 只接受 WebServers 访问、DbServers 只接受 AppServers 的 1443MSSQL访问配合兜底DenyAllinbound安全边界清晰且随业务演进易于维护。负载均衡Layer 4 与 Layer 7Azure 提供两类第一方first-party负载均衡解决方案第三方方案可通过 Azure Marketplace 获取两者均可面向外部externally facing或内部internally facing端点运行Load Balancer第 4 层L4基于哈希hash-based的流量分发支持端口转发port-forwarding适用于 TCP/UDP 流量分发场景Application Gateway第 7 层L7支持SSL 卸载SSL offload、**基于 Cookie 的会话保持session affinity与基于 URL 的内容路由URL-based content routing**等高级功能在 Application Gateway 之上还可以**可选启用 Web 应用防火墙WAF**组件为 Web 流量增加应用层防护。结合仓库的 02TrafficManagement 模块可以进一步看到流量管理的工程化实践该模块的 PowerShell 脚本 Mod06_90DaysOfDevOps.ps1 在完成 ARM 模板部署后通过Get-AzVM枚举全部虚拟机并循环调用Set-AzVMExtension为每台 VM 安装Network Watcher AgentNetworkWatcherAgentWindowsTypeHandlerVersion 1.4。这意味着无论选择哪种负载均衡方案可观测性Network Watcher 流量诊断都是验证规则与分发效果的重要一环——这也与文档强调的自动化供给主题一脉相承。Azure 管理工具全景从 DevOps 文化与实践角度Azure 资源的供给provisioning大多应通过API 或命令行工具完成而不是依赖门户点击。文档依次介绍了五类管理工具构成完整的人机协作工具链。Azure Portal门户Azure Portal 是基于 Web 的控制台是命令行工具的补充可在门户中管理订阅从简单 Web 应用到复杂云部署均可完成构建、管理与监控门户中的**面包屑导航breadcrumbs**背后对应的是资源的层级结构关键洞察JSON 是所有 Azure 资源的底层承载语言。最佳实践是先在门户中理解功能与结构再回看其背后的 JSON 定义将其纳入自动化工作流另提供Azure Preview 门户用于预览和测试新上线服务与功能增强。PowerShell / Azure PowerShellPowerShell 本质上是任务自动化与配置管理框架兼具命令行 Shell 与脚本语言双重身份可类比本学习计划 Linux 章节中的 Shell 脚本它最初面向 Windows如今已跨平台运行。Azure PowerShell是一组 cmdlet命令集用于直接从 PowerShell 命令行管理 Azure 资源连接订阅Connect-AzAccount查找某类资源的专用命令如 Azure 虚拟机相关 cmdlet可借助Get-Command等 PowerShell 语言能力持续深入学习。仓库中 03Storage 与 04Serverless 模块给出了真实的 PowerShell 用法例如 Mod07_90DaysOfDevOps.ps1 通过New-AzResourceGroupDeployment -AsJob以**异步作业AsJob**方式提交模板部署Mod09a_90DaysOfDevOps.ps1 则通过Get-AzWebApp获取 Web 应用后循环Invoke-WebRequest对其发起 HTTP 压测请求。这些脚本展示了连接订阅 → 部署模板 → 操作资源的完整 PowerShell 自动化路径。Visual Studio CodeVisual Studio Code 是微软出品的免费源代码编辑器支持 Windows、Linux 与 macOS。文档强调VS Code 内置了大量与 Azure 交互的集成与工具Azure 扩展、资源管理、终端内嵌 Azure CLI 等是许多开发者的首选 IDE也是门户之外撰写 ARM 模板、PowerShell 脚本与 IaC 代码的主要阵地。Cloud Shell云 ShellAzure Cloud Shell 是交互式、已认证、浏览器可访问的 Shell用于管理 Azure 资源并允许按需在Bash 与 PowerShell两种体验之间选择。首次启动时需要在订阅中提供少量存储。其运行机制要点如下使用 Cloud Shell 时会临时拉起一台机器这些机器是临时的但文件通过两种方式持久化磁盘镜像与挂载的文件共享file share按每会话、每用户提供临时主机空闲 20 分钟无交互活动即超时需要挂载 Azure 文件共享Bash 与 PowerShell共用同一个文件共享每个用户账户对应一台机器$HOME通过文件共享中的5-GB 镜像持久化Bash 环境下权限按普通 Linux 用户设置。Cloud Shell 的价值在于无需本地安装任何工具打开浏览器即可获得已认证authenticated的 Azure 管理环境非常适合快速验证命令与脚本。Azure CLIAzure 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。总结如下工具类型运行平台/宿主典型命令Azure CLI跨平台命令行接口Windows、macOS、Linux可运行于 PowerShell、Cmd、Bash 及其他 Unix Shellaz vm createAzure PowerShell跨平台 PowerShell 模块Windows、macOS、Linux需要 Windows PowerShell 或 PowerShellNew-AzVM选型建议如果环境中无法使用 PowerShell但可以使用cmd或 bash那么Azure CLI 是更合适的选择。核心结论选择正确的工具拥抱自动化本文最核心的 DevOps 启示是Azure 建立在自动化之上。你在门户中执行的每一个操作在底层都会翻译为一段对资源进行读取、创建、修改或删除的代码。因此学习路径建议先在 Portal 中理解服务与功能并观察其 JSON 底层再迁移到 PowerShell / Azure CLI / ARM 模板等自动化手段按环境选型Windows/PowerShell 环境优先 Azure PowerShell非 PowerShell 或追求跨平台一致性则选 Azure CLI快速验证可用 Cloud Shell编写与调试脚本则以 VS Code 为阵地网络先行所有自动化供给都落在虚拟网络、子网、NSG/ASG 与负载均衡这些基础构造之上网络模型的正确规划是自动化环境稳定运行的先决条件。深入仓库继续学习关联文档2022/zh_cn/Days/day33.md本文主题原文另有英文版 2022/Days/day33.md虚拟网络与多 VM 部署模板Mod04_90DaysOfDevOps-vms-loop-template.json 及参数文件 Mod04_90DaysOfDevOps-vms-loop-parameters.json多虚拟网络 NSG 扩展脚本部署Mod06_90DaysOfDevOps-vms-loop-template.jsonPowerShell 自动化示例Module4_90DaysOfDevOps.ps1、Mod06_90DaysOfDevOps.ps1、Mod07_90DaysOfDevOps.ps1、Mod09a_90DaysOfDevOps.ps1下一步本学习计划将把这些理论转化为实战场景在 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 管理工具实战解析90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析 本篇指南基于 90DaysOfDevOps 项文档/教程90DaysOfDevOps 第 33 天Microsoft Azure 网络模型与 Azure 管理工具全解析90DaysOfDevOps 第 33 天Microsoft Azure 网络模型与 Azure 管理工具全解析 本文是 90DaysOfDevOps 挑战中文档/教程90DaysOfDevOps Day 33Microsoft Azure 网络模型与 Azure 管理工具实战指南90DaysOfDevOps Day 33Microsoft Azure 网络模型与 Azure 管理工具实战指南 本文是 90DaysOfDevOps 学习文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考