Azure Linux 4.0 容器化架构与 WSL2 深度集成实践

Azure Linux 4.0 于 2026 年 6 月进入公开预览阶段，标志着微软内部 Linux 发行版从专用容器主机向通用云操作系统的转型。这一版本不仅延续了 CBL-Mariner 在 AKS 节点和 Azure 一阶服务中的基础地位，更通过 Fedora 派生架构和声明式覆盖层设计，为开发者和运维团队提供了可审计、可定制的云原生操作系统选项。

从 CBL-Mariner 到通用发行版的演进

Azure Linux 的前身 CBL-Mariner（Common Base Linux）自 2019 年 9 月启动内部开发，2020 年 11 月开源至 GitHub，历经 2.0（2022 年 4 月）到 3.0 的迭代，始终作为 AKS 容器主机和 Azure 一阶服务的底层基础设施存在。2024 年 3 月，微软将其正式更名为 Azure Linux，但直到 4.0 版本才真正开放为可在任意 Azure VM 上部署的通用发行版。

4.0 版本的核心转变在于构建策略的根本调整。此前版本采用逐包组装的模式，维护团队手工维护每个 RPM spec 文件。4.0 改为从 Fedora 43 快照派生，通过声明式覆盖层管理差异 —— 每一项与上游 Fedora 的偏离都附带书面说明，渲染后的 spec 文件完整提交至仓库。这种设计使供应链审计成为可能，也为企业合规场景提供了可追溯的构建基础。

容器化架构的技术要点

Azure Linux 4.0 的容器化架构体现在三个层面：主机操作系统、容器基础镜像、以及开发环境统一。

在主机层面，4.0 采用 Kernel 6.18 LTS 作为 Azure 调优内核，集成 Hyper-V 虚拟化、GPU 和 AI 加速器支持。内核由微软独立维护并嵌入签名密钥，确保从引导到运行的完整信任链。用户空间组件全面升级：dnf5 替代了原有的 tdnf（微软从 Photon OS 继承的轻量级 C 实现包管理器），带来标准插件生态；glibc 2.42、systemd 258、OpenSSL 3.5（支持后量子密码学）、Python 3.14 和 RPM 6.0 构成现代化基础工具链。FIPS 140-3 认证正在进行中，预计正式发布时完成。

容器镜像层面，微软容器注册表（MCR）提供 base、distroless 和语言运行时三类镜像，与 VM 镜像共享同一供应链。Distroless 镜像将最小化理念推向极致 —— 无 shell、无包管理器、仅包含运行目标应用所需的最小依赖集，显著缩小攻击面。

WSL2 深度集成：System Distro 的工程实践

WSL2 的架构中包含一个隐藏的 "系统发行版"（system distro），这是一个最小化的 Azure Linux 实例，负责托管 WSLg（Wayland/XWayland GUI 栈）等系统组件。通过 wsl --system --user root 命令可进入该环境，它独立于用户安装的 Linux 发行版，使用 tdnf 作为包管理器。

这一设计的工程价值在于提供了一致的构建环境。无论用户主发行版是 Ubuntu、Fedora 还是 openSUSE，内核编译等底层操作都可以在 system distro 中以相同步骤完成，不受主发行版包管理器或库版本差异的影响。

然而，system distro 具有临时性（ephemeral）特征：空闲约一分钟后自动关闭，通过 tdnf 安装的软件包在 wsl --shutdown 后不会保留。针对内核编译等需要持久化存储的场景，微软推荐创建独立的 VHDX 虚拟磁盘作为工作空间。以 40GB 动态扩展磁盘为例，构建目录挂载至 /mnt/build，源码树保存在磁盘文件中而非内存，既规避了 RAM 限制（系统发行版的临时文件系统上限约为分配给 WSL VM 内存的一半），又确保构建结果跨会话可用。

可落地的开发实践

基于 Azure Linux system distro 的自定义内核构建流程已标准化。关键步骤包括：

1. 环境准备：创建并挂载 VHDX 作为持久化工作空间，解决内存限制问题
2. 依赖安装：通过 tdnf 安装编译工具链，注意替换 BusyBox awk 为 gawk 以避免 KDB 命令表生成错误
3. 源码获取：从微软 WSL2-Linux-Kernel 仓库克隆目标标签（如 linux-msft-wsl-6.18.26.3）
4. 配置定制：始终基于 Microsoft/config-wsl 或 Microsoft/config-wsl-arm64 进行修改，保留 Hyper-V 集成选项
5. 模块打包：使用 gen_modules_vhdx.sh 脚本将模块打包为 VHDX 格式，这是 2026 年 WSL 内核的新要求
6. 部署验证：通过 .wslconfig 指定 kernel 和 kernelModules 路径，重启后验证 uname -r 显示自定义版本号

典型应用场景包括启用内核中未默认编译的驱动模块（如 USB-I2C 桥接器驱动 CONFIG_HID_CP2112）、集成 out-of-tree 驱动、或测试上游预发布功能。

统一基础的战略意义

Azure Linux 4.0 的通用化使微软首次具备贯穿云、边、端的统一 Linux 基础。Databricks 已迁移超过 10 万台 VM 和百万级 CPU 核心至 Azure Linux，LinkedIn 完成基础设施迁移，Azure SQL 和 Cosmos DB 等一阶服务均运行于此基础之上。

对于开发者而言，这意味着开发环境与生产环境的一致性 —— 通过 wsl --install -d AzureLinux（即将推出）可在本地运行与 Azure 生产环境相同的操作系统，消除 "在我机器上能跑" 的环境差异问题。Distroless 容器镜像与 VM 镜像的供应链统一，则确保了从构建到部署的依赖一致性。

微软从消费 Linux（2012 年 Azure 首次托管 Linux VM）、到内部发行（2019 CBL-Mariner）、再到开放通用发行版（2024-2026 Azure Linux 4.0）的演进，反映了云原生时代操作系统策略的成熟。对于运维团队，Azure Linux 4.0 提供了经过 Azure 生产环境验证的精简、安全、可审计的 Linux 选项；对于开发者，WSL2 system distro 的开放则提供了深入系统底层的工程能力。

参考来源

• Box of Cables: Azure Linux 4.0 is Microsoft's first general-purpose Linux
• Box of Cables: Build a Custom WSL 2 Kernel in 2026

systems