容器运行时虚拟化云原生【免费下载链接】containerizationContainerization is a Swift package for running Linux containers on macOS.项目地址https://gitcode.com/gh_mirrors/cont/containerization点击查看免费下载Containerization 是一个纯 Swift 编写的开源包让 macOS 应用可以直接运行 Linux 容器并同时提供面向 Linux 主机的 cloud-hypervisor KVM 后端。它以“每容器一个轻量虚拟机”为核心设计借助优化的 Linux 内核、极简 init 系统vminitd与 vsock 通道实现亚秒级启动。读完本文你将掌握 Containerization 的架构原理、双后端抽象、内核定制策略以及从构建、测试到用cctl实操运行容器的完整链路。项目定位与能力全景Containerization 在 Package.swift 中声明为一个 Swift 包swift-tools-version 6.2平台最低 macOS 15.0基于 Apple 的 Virtualization.framework 在 Apple silicon 上运行 Linux 容器。它对外暴露的核心能力包括OCI 镜像管理管理 OCI 镜像对应 Sources/ContainerizationOCI远程仓库交互与容器注册表进行认证、拉取、推送对应 Sources/ContainerizationOCI/Clientext4 文件系统创建并填充 ext4 文件系统对应 Sources/ContainerizationEXT4Netlink 套接字与 Netlink 套接字家族交互对应 Sources/ContainerizationNetlink优化内核为快速启动定制 Linux 内核对应 kernel 目录容器生命周期派生轻量虚拟机并管理运行时环境LinuxContainer.swift进程管理派生并交互容器内进程LinuxProcess.swiftRosetta 2 支持在 Apple silicon 上运行 linux/amd64 容器。仓库同时发布了命令行二进制属于单独的 apple/container 项目不在本仓库内本仓库中的cctl可执行文件则作为库 API 的实操演练场。设计核心每容器一个轻量虚拟机Containerization 的设计基石是每个 Linux 容器运行在属于自己的轻量虚拟机中。这一模型带来两个关键收益免端口转发客户端可以为每个容器分配专属 IP 地址彻底消除逐容器端口转发port forwarding的负担亚秒级启动通过 kernel 中优化的 Linux 内核配置、极简 rootfs 和轻量 init 系统容器可实现 sub-second 启动时间。vminitd虚拟机内的极简 init 系统vminitd 是 Containerization 的子项目作为虚拟机内初始进程被派生对外提供GRPC over vsock的 API。其职责包括配置运行时环境启动容器化进程为被调用的进程提供 I/O、信号signals与事件events转发。从源码结构看vminitd的核心逻辑位于 vminitd/Sources/VminitdCore其中 Server.swift 与 ServerGRPC.swift 负责 GRPC 服务端实现而容器侧的规格定义在 SandboxContext.proto生成的 Swift 绑定为 SandboxContext.pb.swift 与 SandboxContext.grpc.swift。客户端侧的 I/O 模型在 LinuxProcess.swift 中有完整体现进程的 stdin/stdout/stderr 各自对应一个 vsock 端口宿主端先建立监听guest 内进程创建后回拨dial back连接。源码中特别注释了一个实用细节等待 guest 回拨的超时时间默认为30 秒可通过环境变量CONTAINERIZATION_STDIO_TIMEOUT覆盖因为忙碌主机上同时运行多个 VM 时guest 从收到createProcessRPC 到发起connect(2)的时间远不止空闲时的几百毫秒。LinuxContainer容器生命周期的门面LinuxContainer.swift 是“在虚拟机中启动并管理 Linux 容器完整生命周期”的易用类型其Configuration结构体集中了运行时配置项配置项类型默认值说明processLinuxProcessConfiguration空容器 init 进程配置cpusInt4容器分配的 CPU 数memoryInBytesUInt641024 MiB容器内存字节hostnameString?nil容器主机名sysctl[String: String]空系统控制选项interfaces[any Interface]空网络接口sockets[UnixSocketConfiguration]空待建立的 Unix 域套接字中继mounts[Mount]defaultMounts()容器挂载maskedPaths[String]OCI 标准集合对负载隐藏的路径[]表示不隐藏Configuration还定义了 seccomp 配置模型SeccompProfileunconfined不安装过滤器、default来自 containerd 的 syscall 白名单按容器进程 capabilities 解析、profile(LinuxSeccomp)调用方提供、原样应用的 profile。源码注释明确指出只有 OCI runtime 才应用 seccompvmexec会忽略spec.linux.seccomp因此任何非unconfined的选项都要求提供ociRuntimePath。双后端架构VMM 抽象与两种实现Containerization 将虚拟机监视器VMM抽象为VirtualMachineManager/VirtualMachineInstance协议并内置两种实现。协议定义见 VirtualMachineInstance.swift包括start/stop/pause/resume生命周期操作、dialAgent()拨号到 guest agent、dial/listenvsock 端口通信、块设备与 virtio-fs 的 hotplug 系列操作等VirtiofsLayout枚举则区分了 virtio-fs 设备的两种暴露方式.unified单一设备、.perTag按源哈希标签各挂载一个设备。macOS 后端Virtualization.framework默认路径VZVirtualMachineManager是 Apple silicon 上的正式发布路径直接使用 Apple 的 Virtualization 框架无需额外二进制。对应实现为 VZVirtualMachineManager.swift 与 VZVirtualMachineInstance.swift。ContainerManager.swift 在 macOS 上默认构造这一后端并接受kernel、initfs、imageStore、network、rosetta、nestedVirtualization、logger等参数。Linux 后端cloud-hypervisor KVMCHVirtualMachineManager面向 Linux 主机每个 VM 对应一个cloud-hypervisor子进程通过其REST-on-UDSAPI 由独立的 CloudHypervisor Swift 包控制。该后端的设备与通道约定块存储virtio-blk共享目录virtio-fs每个共享对应一个virtiofsd进程网络TAP 设备Guest agent通过 cloud-hypervisor 的 hybrid vsock 访问——与 macOS 路径使用相同的vminitd契约因此 guest 侧语义完全一致。从 Makefile 可以还原该后端的部署细节make fetch-cloud-hypervisor会下载固定版本v52.0 aarch64 静态二进制并校验 SHA256make build-virtiofsd则在 Linux dev 容器内从源码编译virtiofsd并应用 scripts/patches/virtiofsd-skip-cap-drop-with-sandbox-none.patch。Linux 后端的环境要求README 明确列出宿主需要cloud-hypervisor与virtiofsd两者默认按PATH查找CHVirtualMachineManager.init接受显式 URL 覆盖virtiofsd是惰性解析的——只使用块设备挂载的 VM 完全可以不安装它KVM 访问/dev/kvm需对调用用户可读可写预布置的网络管线若容器需要网络TAPInterface按名称消费一个已存在的 TAP 设备将其拉起、挂到 bridge、配置 NAT 或路由是调用方的职责。Linux 集成测试的特殊性集成测试套件make linux-integration运行在 apple/container 的 Linux VM 内启用嵌套虚拟化container run --virtualization。README 特别指出make fetch-default-kernel拉取的 kata 内核未启用 KVM因此集成套件改用仓库内自带内核kernel/vmlinux-arm64x86_64 主机为kernel/vmlinuz-x86_64需先执行make -C kernel构建。在 Linux 上套件只运行不依赖 macOS 专有类型的跨平台场景完整套件目前仍以 macOS 为主。构建要求与构建前准备硬性要求Apple silicon 的 MacmacOS 26Xcode 26更旧的 macOS 版本不被支持。构建二进制无需额外的 Swift 工具链、Swiftly 或 Static Linux SDK——Linux guest initvminitd/vmexec是在 Linux 容器内编译为静态二进制而非在 Mac 上交叉编译。准备步骤安装推荐版本的 Xcode并将活跃开发者目录指向它sudo xcode-select -s PATH_TO_XCODE安装containerCLI构建过程用它编译 guest然后验证其在 PATH 上container --version首次构建会自动构建用于编译 guest 的 Linux dev 镜像containerization-dev:swift-version见根 Makefile可能需要几分钟。构建、测试与默认内核获取构建包make allmake all依赖containerization与init两个目标前者执行 Swift 构建并把cctl、containerization-integration安装到bin/macOS 上还会用 signing/vz.entitlements 签名后者编译 guest 并构建 initfsbin/initfs.ext4及vminit:latestOCI 镜像。测试构建后运行基础测试与集成测试make test integration集成测试需要内核本地没有内核时用make fetch-default-kernel获取默认内核。该目标只需在初次构建后或make clean后执行一次make fetch-default-kernel make all test integration从根 Makefile 看fetch-default-kernel会从 Kata Containers 的二进制包下载并解包把vmlinux.container复制为bin/vmlinux-archintegration目标则按bin/vmlinuz-x86_64→bin/vmlinux-x86_64x86_64或bin/vmlinux-arm64的顺序寻找内核并运行./bin/containerization-integration --kernel path。Protobuf 重新生成Containerization 依赖特定版本的grpc-swift与swift-protobuf见 Package.swift 中 grpc-swift-2、grpc-swift-nio-transport、grpc-swift-protobuf 等依赖安装后可用以下命令重新生成 RPC 接口make protosLinux 内核优化配置、版本支持与预构建内核macOS 上派生轻量虚拟机必须提供 Linux 内核。Containerization 在 kernel 目录提供了一套优化内核配置其目标是以最精简的特性集合换取快速启动与轻量环境。kernel 目录结构config-arm64与config-x86_64按架构划分的CONFIG_选项Makefile内核版本与源码包 URL当前指向linux-6.18.5build.sh脚本化内核构建流程image/带构建工具链的镜像配置。按容器定制内核的一等 API尽管默认配置覆盖大多数工作负载官方也理解部分场景需要额外特性。为此 Containerization 提供一等 API 支持按容器使用不同的内核配置与版本使容器可以在多个内核版本之间开发与验证。这在架构层面意味着内核作为Kernel类型传入ContainerManager见 ContainerManager.swift 初始化参数运行时可自由替换。内核支持范围Containerization 允许用户自带内核但从内核版本6.14.9起测试功能。使用预构建内核若使用预构建内核务必确保VIRTIO驱动已编译进内核本体而非仅作为模块。Kata Containers 项目提供的容器优化内核已启用全部必需配置是可行的来源其发布页包含可下载产物vmlinux.container镜像本体位于/opt/kata/share/kata-containers/目录。自己编译内核按 kernel/README.md 的说明构建依赖container工具在 kernel 目录执行make先创建构建内核所需的镜像再以该镜像运行容器执行内核构建。目标架构由TARGET_ARCHmake 变量控制取值arm64或x86_64未设置时回退到构建宿主架构uname -maarch64/amd64归一化为arm64/x86_64make # 默认 → 构建宿主架构 make TARGET_ARCHarm64 # → vmlinux-arm64未压缩 Image make TARGET_ARCHx86_64 # → vmlinuz-x86_64压缩 bzImage在 arm64 容器内交叉编译 make x86_64 # 等价于 make TARGET_ARCHx86_64x86_64名称的z后缀遵循 Linux 压缩内核镜像的命名约定构建产物会复制到仓库的bin/目录。内核构建流程kernel/Makefile在容器内以 8 CPU、16G 内存执行并通过LOCALVERSION-cz-git-sha注入版本字符串。cctl探索 API 的实操入口要快速上手库的 API 表面cctl可执行文件是最佳起点。它由 Sources/cctl/cctl.swift 定义注册了rootfs、images、run三个通用子命令macOS 追加login、Linux 追加bridge。核心功能与源码对应操作 OCI 镜像ImageCommand.swiftimages子命令list/get/delete/pull/tag/push/save/load登录容器注册表LoginCommand.swiftlogin仅 macOS使用 Keychain 保存凭据创建 rootfs 块RootfsCommand.swiftrootfs create从预构建的 gzip rootfs tar 生成 init 镜像运行简单 Linux 容器RunCommand.swiftrun。run 命令参数详解RunCommand.swift 展示了cctl run的完整参数面这些参数与LinuxContainer.Configuration一一对应参数默认值说明-i/--imagedocker.io/library/alpine:3.16容器所基于的镜像引用--idcctl容器标识-c/--cpus2分配 CPU 数-m/--memory1024MB内存大小兆字节--fs-size2048MB块文件系统大小--rosetta关闭启用 Rosetta x64 模拟--mount—共享进容器的目录/foo:/bar形式可重复--block—附加块设备如srcnbd://127.0.0.1:10809,dst/data,fmtext4可选fmt/timeout/ro/raw--ns—nameserver 地址可重复--cap-add—追加 Linux capability如--cap-add CAP_SYS_ADMIN供 mkfs.xfs 等特权 ioctl 工具使用--oci-runtime-path—用于派生容器的 OCI runtime 路径--seccomp关闭应用来自 containerd 的默认 seccomp profile需--oci-runtime-path--seccomp-profile—应用自定义 seccomp profile需 OCI runtime-spec JSON 格式Docker 格式会被拒绝--read-only关闭rootfs 只读--init关闭以 init 进程运行负责信号转发与僵尸回收-k/--kernel必填内核二进制路径--cwd/工作目录--entrypoint—覆盖镜像 ENTRYPOINT镜像 CMD 仍会追加run的运行时行为源码可验证在 macOS 26 上自动选择VmnetNetwork网络实现通过ContainerManager创建容器时会为配置设置 CPU、内存、终端 I/O、进程参数并支持块设备挂载与目录共享。seccomp 相关 flag 有严格校验--seccomp与--seccomp-profile互斥且两者都必须搭配--oci-runtime-path因为 seccomp 由 OCI runtime 安装默认的vmexec启动路径会忽略spec.linux.seccomp。面向开发者的配套工具Pre-commit hook运行make pre-commit安装 pre-commit hook在git commit时自动校验格式与 license 头格式规则见 scripts/pre-commit.fmt、license 模板见 scripts/license-header.txt生成 API 文档make docs make serve-docs然后在另一个终端打开http://localhost:8000/containerization/documentation/预览贡献指南参见 CONTRIBUTING.md。项目状态与版本稳定性版本 0.1.0 是 Containerization 的首个正式发布版本此前的版本不提供源码稳定性保证。由于库处于活跃开发中源码稳定性仅在小版本内保证例如 0.1.1 与 0.1.2 之间。若不想承受潜在的源码破坏性更新推荐用.upToNextMinorVersion(from: 0.1.0)指定包依赖未来的小版本可能视需要调整这些规则。结语从整体架构看Containerization 的核心价值在于把“每容器一 VM”的隔离模型做得足够轻优化内核 极简 init vsock 控制面让 Swift 开发者能在 Apple silicon 上获得亚秒级启动的 Linux 容器体验同时通过协议抽象保持 Linux 宿主机cloud-hypervisor KVM上语义一致的运行路径。想要深入实践可以从 Sources/Containerization 的协议与实现入手或直接用cctl run跑通第一个容器再按需定制自己的内核与配置。赞分享容器运行时虚拟化云原生【免费下载链接】containerizationContainerization is a Swift package for running Linux containers on macOS.项目地址https://gitcode.com/gh_mirrors/cont/containerization点击查看免费下载相关推荐container在 Apple Silicon Mac 上运行 Linux 容器的完整实战指南container在 Apple Silicon Mac 上运行 Linux 容器的完整实战指南 本文基于 container 项目的 README 与仓库源CLI虚拟化容器运行时云原生Whisky终极指南在Apple Silicon上轻松运行Windows应用Whisky终极指南在Apple Silicon上轻松运行Windows应用 想在Mac上运行Windows软件 Whisky为Apple Silico桌面应用vphone-cli 使用指南在 Apple Silicon 上通过 Virtualization.framework 启动虚拟 iPhonevphone cli 使用指南在 Apple Silicon 上通过 Virtualization.framework 启动虚拟 iPhone 导读 vpho虚拟化逆向工程CLIAI 技能/插件上一篇F3D入门指南5个技巧让你快速掌握专业级3D模型查看下一篇Harbor UI 前端开发环境搭建与构建流程完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
