ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

90DaysOfDevOps 第 31 天:深入理解 Microsoft Azure 计算模型(虚拟机、VMSS、容器与 Serverless)

90DaysOfDevOps 第 31 天:深入理解 Microsoft Azure 计算模型(虚拟机、VMSS、容器与 Serverless) 文档/教程【免费下载链接】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 开源学习计划中 Microsoft Azure 章节的第三站。在 第 30 天 掌握 Azure 安全模型之后本篇文章将系统梳理 Azure 的计算服务全景从服务可用性选项、虚拟机选型到 JSON 模板化部署、VMSS 弹性伸缩再到容器服务、应用服务与 Serverless 计算。读完本文你将能够根据可用性、成本、运维抽象层级等维度在 IaaS、PaaS、容器与 Serverless 之间做出合理的 Azure 计算选型并为后续动手部署打好理论地基。从安全模型到计算模型Azure 资源选型的起点在 Day 30 中我们讨论了 Azure 的身份、权限与安全治理模型今天的话题则转向“跑在哪里”。计算服务是任何云上工作负载的底座Azure 提供了一条从“完全自管的虚拟机”到“只写代码的 Serverless 函数”的完整抽象光谱。理解这条光谱上的每一个层次是后续在 Day 32 存储模型 与 Day 33 网络模型与管理工具 中把这些“积木”拼装成真实场景的前提。服务可用性选项高可用、灾备与备份在数据中心时代保证服务可用性就是运维的生命线在云上这一诉求同样关键。Azure 将可用性拆解为三个层次高可用High Availability在同一个区域内提供保护对抗单机或单数据中心故障灾难恢复Disaster Recovery在区域与区域之间提供保护对抗整个区域级别的故障备份Backup提供某个时间点point-in-time的恢复能力。为了实现上述目标Microsoft 在一个地理政治边界geopolitical boundary内会部署多个区域region。围绕服务可用性Azure 引入了两个关键概念——集合与区域可用性集Availability Sets在单个数据中心内部提供弹性resiliency。将多个 VM 放入同一可用性集Azure 会确保它们分布在不同的容错域与更新域上避免硬件维护或故障时全部实例同时不可用可用性区域Availability Zones在区域内多个数据中心之间提供弹性。将实例分布到不同 Zone可抵御单数据中心级别的故障。一句话区分可用性集管的是“机房内的分散”可用性区域管的是“机房之间的分散”。两者也可以结合使用以实现更高等级的可用性。选择哪一级冗余本质上是在可用性、成本与复杂度之间做权衡。虚拟机Virtual Machines公有云的第一站虚拟机通常是大多数人进入公有云的第一站Azure 对 VM 的支持非常丰富丰富的系列与规格Azure 提供多种系列的 VM各有不同的计算能力侧重例如面向高性能、低延迟场景的系列以及面向大内存场景的系列型号之多有时会让人眼花缭乱B 系列可突发burstableVM这是专为“大部分时间 CPU 需求很低但偶尔例如每月一次需要性能尖峰”的工作负载设计的型号非常适合低成本运行后台任务、开发测试环境等场景虚拟网络接入VM 会放置在一个虚拟网络Virtual Network上从而获得与任意网络的连通能力双操作系统支持同时支持 Windows 与 Linux 来宾操作系统Azure 调优内核Azure-tuned kernels针对特定 Linux 发行版Azure 还提供经过专门调优的内核版本以获得更好的平台兼容性与性能。模板化部署Azure 背后的 JSON 与声明式 IaC贯穿整个 Azure 的一个基本事实是Azure 表面之下的每一种资源本质上都是 JSON。无论是 Azure 门户Portal、CLI 还是 PowerShell最终都会转化为对资源定义 JSON 的操作。创建资源有若干种入口——门户、控制台等但首选路径是基于 JSON 模板的部署因为它是可重复、可审计的声明式方式。核心特性包括幂等部署Idempotent deployments支持 **incremental增量**与 **complete完整**两种模式即“重复执行同样模板最终状态一致”这正是基础设施即代码IaC所追求的 desired state期望状态可导出的模板库Azure 提供了大量可导出的模板能把已部署资源的定义导出来复用。这种模板化思路与 AWS CloudFormation 非常类似而如果你需要多云multi-cloud方案则可以使用Terraform。在本仓库中Terraform 的手把手内容属于后续“基础设施即代码IaC”章节仓库里已经留下了可运行的示例最简的 Hello-world 模块 只需一个output块即可输出Hello, 90DaysOfDevOps from Terraform完整展示了“用代码描述期望状态、由工具负责幂等落地”的 IaC 心智模型。弹性伸缩VMSS 与自动缩放自动缩放是公有云最大的卖点之一用不到的资源自动缩减需要时自动拉起让成本与实际负载对齐。在 IaaS 层面Azure 提供虚拟机规模集Virtual Machine Scale SetsVMSS。它能够基于调度计划schedules和指标metrics从一个黄金镜像gold standard image自动创建并扩展实例。典型价值场景是更新窗口先更新黄金镜像再以最小影响的方式滚动发布到现有实例避免大面积停机。在 PaaS 层面Azure 应用服务App Services自带自动缩放能力无需像 IaaS 那样自己管理伸缩逻辑。选型要点是需要细粒度控制底层 OS 与镜像选 VMSS只想让平台替你处理伸缩选 App Service。容器服务AKS、ACI、Service Fabric 与容器注册表容器在 DevOps 学习路线中占有核心地位后续章节会专门展开“容器”这个用例这里先梳理 Azure 上几个容器专项服务Azure Kubernetes ServiceAKS托管的 Kubernetes 解决方案控制平面与底层集群管理都不需要你操心开箱即用Azure Container InstancesACI容器即服务Containers as a Service按秒计费。直接运行一个镜像并接入你的虚拟网络即可无需引入容器编排器Service Fabric能力非常广泛其中包含对容器实例的编排能力Azure Container RegistryACR提供私有镜像仓库支持 Docker 镜像、Helm Chart、OCI 制品与镜像的托管。值得注意的是许多容器服务内部很可能也在大量使用容器只是这些细节被抽象掉了你无需直接管理。上述容器服务在其他主流公有云中也能找到对等物——这一模式具有普遍性。仓库也为容器旅程备好了实操素材IaC 层面有通过 Terraform 拉起 nginx 镜像与容器的 docker.tf以及用 Kubernetes provider 创建命名空间、Deployment 与 NodePort Service 的 kubernetes.tf原生 Kubernetes 清单则可参考 nginx-stateless-demo.yaml。应用服务Application Services面向应用的托管方案Azure 应用服务App Services是一个应用托管解决方案提供建立服务的简便途径核心能力如下自动部署与自动伸缩应用发布与扩容流程高度自动化Windows 与 Linux 双支持两种平台的应用均可托管运行于应用服务计划App Service Plan计划本身有**类型type与大小size**之分决定了底层资源规模与定价多种应用形态覆盖 Web App、API App、移动 App 等多种服务类型部署槽位Deployment slots支持通过槽位进行可靠的测试与发布升级promotion让“先验证、再切换”成为标准动作。对于“不想管服务器但希望保留对运行环境的较大掌控权”的工作负载App Service 是 IaaS虚拟机与 Serverless 之间的理想中间层。Serverless 计算只为运行时长付费Serverless 的核心理念是只为函数的实际运行时长付费——不再需要常驻的虚拟机或 PaaS 应用需要时运行函数运行完它就“消失”。Azure 在这一领域的主要组件包括Azure Functions函数即服务提供 Serverless 代码执行。回顾 Day 30 关于云抽象层的讨论——在 Serverless 模式下你只管理代码本身。特性包括事件驱动Event-Driven具备大规模并发能力支持输入/输出绑定bindings可无缝对接众多 Azure 服务与第三方服务多语言支持C#、NodeJS、Python、PHP、Batch、Bash、Golang、Rust乃至任何可执行文件Azure Event Grid负责把服务与事件触发的逻辑串联起来实现事件路由Azure Logic Apps提供基于图形化界面的工作流与集成编排Azure Batch可在 Windows 与 Linux 节点上运行大规模批处理作业并提供一致的管理与调度能力。选型建议纯事件驱动的单段逻辑用 Azure Functions需要可视化编排多个系统间的集成流程用 Logic Apps大批量、可并行的计算任务用 Azure Batch。与后续章节的衔接本篇完成了 Azure 计算模型的“理论拼图”接下来的两天将补齐另外两块积木Day 32 的 Azure 存储模型存储账户、托管磁盘、冗余选项与数据库模型与Day 33 的 Azure 网络模型与管理工具虚拟网络、NSG/ASG、负载均衡以及 Azure CLI、PowerShell、Cloud Shell 等自动化入口。理论积累完成后第 34 天起将进入场景化动手部署届时计算、存储、网络三大模型将真正拼装成可运行的应用——而无论是门户点击、PowerShell 命令还是 JSON 模板最终都归结为一件事在声明式代码中描述并落地你的 Azure 期望状态。继续学习下一站Day 32 - Microsoft 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 第 31 天Microsoft Azure 计算模型Compute Models全景解析90DaysOfDevOps 第 31 天Microsoft Azure 计算模型Compute Models全景解析 本文是 90DaysOfDevOp文档/教程90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析 本篇指南基于 90DaysOfDevOps 项文档/教程90DaysOfDevOps 第 32 天Microsoft Azure 存储模型与数据库模型全解析90DaysOfDevOps 第 32 天Microsoft Azure 存储模型与数据库模型全解析 本篇文章整理自 2022/Days/day32.md h文档/教程创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表