Build 2026 上,Microsoft 做了一件看起来不太像发布会主菜、但很有分量的事:Azure Linux 4.0 进入 public preview,并且可以直接跑在任意 Azure VM 上。

别误会,这不是微软第一次做 Linux。Azure Linux 源自 CBL-Mariner,2024 年改名,过去已经在 AKS、微软一方服务、WSLg 等底层场景里用了很久。真正变了的是位置:以前它在你选的服务下面;现在它被摆到 Azure Marketplace 上,让你自己选。

这次到底新在哪

Azure Linux 4.0 仍然不是桌面发行版。没有什么“微软版 Ubuntu 桌面”的故事。它是一套面向云和服务器的极简 Linux。

几个关键信息可以压缩成一张表:

项目变化影响
部署范围可跑在 Azure VM、规模集、容器镜像、AKS,未来到 WSL从内部底座变成用户可选 OS
上游路线基于 Fedora 43 快照不再主要靠手工维护 spec 文件
包管理dnf5 替代 tdnf更接近主流 RPM 工具链
内核与安全Kernel 6.18 LTS,FIPS 140-3 认证推进中更适合合规和云工作负载
供应链声明式 overlays、SBOM、签名包和仓库方便审计“微软到底改了什么”
成本Marketplace 可部署,无额外 OS 授权费对大规模 Azure 用户有吸引力

现实采用也不是空白。Databricks 已迁移超过 10 万台 VM、超过 100 万 CPU 核;LinkedIn、AKS、Azure SQL、Cosmos DB 也已经在使用 Azure Linux。

这说明微软不是先画饼再找场景,而是把内部已经跑过一轮的系统推到客户面前。公测不是 GA,FIPS 140-3 也还在认证推进中,这两个边界要说清。但它的方向已经很明确。

微软这步棋,不只是“更爱 Linux”

当年那句 “Microsoft loves Linux” 很适合做姿态。今天更准确的说法是:Microsoft ships Linux。

这个变化有点历史感。微软从反对 Linux,到托管 Linux VM,到 Azure 上大量客户核心跑 Linux,再到自己维护一套云端发行版。其兴也勃焉,背后不是浪漫开源叙事,而是云基础设施的现实账本。

我更在意三件事。

第一,工具链标准化。dnf5 替掉 tdnf,不只是用户体验变好,而是微软减少自造轮子的摩擦。云厂商做发行版,如果每个接口都像孤岛,用户很难迁。现在它往 Fedora/RPM 主流路线靠,至少是在降低心理门槛。

第二,供应链审计。基于 Fedora 快照,再用声明式 overlays 写清楚偏离上游的原因,这件事很关键。企业买的不是“一个 Linux”,而是可追责的构建过程。尤其在合规、安全、AI 基础设施越来越重的环境里,谁能解释每个包从哪里来、为什么被改过,谁就更像可信底座。

第三,控制面延伸。Azure Linux 免费部署,不收额外 OS 授权费,听起来是省钱;但云厂商从来不会只算操作系统那一笔钱。它真正想要的是把内核、镜像、补丁、安全策略、容器基座、合规认证都纳入 Azure 的节奏。Linux 还是 Linux,但运行方式越来越像 Azure 的一部分。

这不是坏事。对长期跑 Azure 的团队,统一底座能减少补丁差异、镜像漂移和安全审计成本。问题在于,一旦你接受云厂商自有 Linux,后面很多“顺手”的选择都会被同一个平台吸走。

云厂商自有 Linux,是新一轮基础设施主权

Amazon 有 Amazon Linux,Google、Oracle、VMware 也都有自己的系统路线。Azure Linux 4.0 加入这个队列,不是微软突然想做发行版情怀,而是云厂商都意识到:操作系统太靠近利润、成本和风险了,不能完全交给别人。

对架构师和运维团队来说,判断标准也别太虚。

如果你的工作负载主要在 Azure,且重视合规、SBOM、统一镜像、安全基线,Azure Linux 值得认真评估。尤其是新建集群、新建 VM 规模集、容器基础镜像统一时,它的吸引力会比较直接。

如果你追求跨云、本地和云之间的最大可迁移性,那就要冷静一点。Azure Linux 4.0 这次强调的是 Azure 计算面,不是“到处通吃”的企业 Linux。它越贴近 Azure,越可能好用;也越可能把一些运维习惯、认证路径和自动化脚本绑到 Azure 生态里。

这就是云时代的老故事。铁路公司铺轨,电力公司定标准,平台公司发 SDK。今天云厂商维护 Linux,本质上也是在重写基础设施的默认值。

微软这次少见地把话做实了:不是说爱 Linux,而是把 Linux 打包、签名、审计、上架,然后让它变成 Azure 的一块地基。真正要看的,不是它能不能跑,而是有多少团队愿意把“默认 Linux”这件事交给云厂商来定义。