Moby 中的 hcsshim:Windows 容器 HCS 封装库与 Containerd Shim 的构建实践【免费下载链接】mobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems项目地址: https://gitcode.com/GitHub_Trending/mo/moby本文基于 Moby 仓库 vendor 目录中随依赖一并分发的 hcsshim README 展开,系统讲解 hcsshim 在 Windows 容器生态中的定位、其面向 Host Compute Service (HCS) 的核心 Go 接口、Linux guest agent 与 Containerd Shim(V1/V2) 的构建与验证流程,并结合 Moby 仓库源码说明 hcsshim 如何被 dockerd 实际消费。读完本文,你将能够理解 Windows 容器从运行时到底层 HCS 服务之间的完整调用链,并掌握 hcsshim 各二进制的构建、部署与测试方法。hcsshim 是什么:Moby 依赖树中的 Windows 容器控制面hcsshim 提供了使用 Windows Host Compute Service(HCS)来启动和管理 Windows 容器的 Golang 接口。除 HCS 封装外,它还包含管理 Windows 容器的其他辅助功能:Host Network Service (HNS) 的 Go 接口,即仓库中hcn相关模块;guest agent(代码库中常称 GCS,Guest Compute Service)代码,用于支撑 Linux Hyper-V 容器(LCOW)场景。它主要服务于 Moby 和 Containerd 两大项目,但也供其他项目自由使用。在 Moby 仓库中,可以直接从依赖声明确认其版本:go.mod 中声明github.com/Microsoft/hcsshim v0.15.0-rc.4;vendor/modules.txt 列出了实际 vendor 进来的包,包括hcsshim根包、cmd/containerd-shim-runhcs-v1/options、cmd/containerd-shim-runhcs-v1/stats、computestorage、ext4/...、hcn等。也就是说,Moby 把 hcsshim 作为 Windows 平台下容器生命周期的控制面库引入,dockerd 在 Windows 上的容器创建、网络配置、统计采集都间接依赖它。核心 Go API:Container 与 Process 接口hcsshim 根包提供了两个最核心的抽象:Container(ComputeSystem)与Process,均仅编译于 Windows(//go:build windows约束)。Container 接口从 container.go 可以看到其生命周期 API:// CreateContainer creates a new container with the given configuration but does not start it. func CreateContainer(id string, c *ContainerConfig) (Container, error) // OpenContainer opens an existing container by ID. func OpenContainer(id string) (Container, error) // GetContainers gets a list of the containers on the system that match the query func GetContainers(q ComputeSystemQuery) ([]ContainerProperties, error)每个container实例内部封装一个*hcs.System,并实现了完整的生命周期方法:方法语义Start()同步启动容器Shutdown()/Terminate()请求关机/终止,真正结束以Wait()成功为准Wait()/WaitTimeout(timeout)同步等待容器关闭,WaitTimeout超时返回ErrTimeoutPause()/Resume()暂停/恢复执行Statistics()返回Statistics(内存/CPU/存储/网络统计的 legacy v1 调用)ProcessList()返回容器内进程列表CreateProcess(c *ProcessConfig)/OpenProcess(pid)在容器内创建进程、按 PID 打开已有进程Modify(config)运行时修改资源(支持 Network 类型的 Add/Remove)值得注意的是源码中的一个可观测细节:CreateContainer在init()阶段会读取环境变量HCSSHIM_CREATECONTAINER_ADDITIONALJSON,把其中的额外 JSON 合并进提交给 HCS 的CreateComputeSystem配置。从源码结构看,这是一个供集成方(如测试或上层运行时)在不改代码情况下注入 HCS 配置的逃生口。ContainerProperties、MemoryStats、ProcessorStats、StorageStats、Statistics等类型都是schema1(HCS 1.0 schema)中对应结构的类型别名,意味着 hcsshim 的数据模型与 HCS REST/JSON 文档保持同构。Process 接口process.go 中的process封装对应容器内的一个进程,提供了:Pid()、ExitCode():进程标识与退出码(退出码仅在进程已终止后可用);Kill():请求终止进程但不等待,若进程未找到返回ErrElementNotFound;Wait()/WaitTimeout(timeout):等待退出,与 Container 一样用sync.Once channel 实现可复用的后台等待;ResizeConsole(width, height):调整控制台尺寸;Stdio():返回 stdin/stdout/stderr 三组管道接口,多次调用可获取多组接口,关闭返回的管道不会关闭底层管道;CloseStdin()、Close():关闭 stdin 写端(向进程发 EOF 信号)、清理本地状态而不杀进程。底层的系统调用封装在 hcsshim.go 中,例如通过//sys注释 go generate生成zsyscall_windows.go,并以HcsError作为统一错误类型向外传播。其他被 Moby vendor 的子模块除根包外,vendor/modules.txt显示 Moby 还 vendor 了:hcsshim/hcn:Host Compute Network,即 Windows 网络命名空间/端点的管理接口,daemon/libnetwork/drivers/windows/...中的 overlay 等 Windows 网络驱动依赖它;hcsshim/ext4/...(含tar2ext4、dmverity):Linux 扩展文件系统工具链,服务于 LCOW 的 rootfs 构建;hcsshim/computestorage:Windows 分层存储(CS)接口,与daemon/graphdriver/windows/配合完成 Windows 容器层的挂载;hcsshim/cmd/containerd-shim-runhcs-v1/options与stats:runhcs shim 的 options/stats 数据结构,供 Moby 与 shim 交换配置和统计信息。构建:Linux Guest AgentREADME 说明,除了作为 HCS API 调用库使用,仓库还会产出若干二进制,最主要的是 Linux guest agent 与 containerd 运行时 v2 shim 的实现。构建 Linux guest agent 只需将GOOS设为linux并从./cmd/gcs构建(以下路径均相对 hcsshim 仓库自身根目录):Windows PowerShell 下:C:\ $env:GOOSlinux C:\ go build .\cmd\gcs\或在 Linux 机器上:go build ./cmd/gcs如果想把它打进 rootfs 里随其他工具一起启动,需要提供可打包的 rootfs,最简单的做法是导出一个容器的 rootfs:docker pull busybox docker run --name base_image_container busybox docker export base_image_container | gzip base.tar.gz BASE./base.tar.gz make all构建成功后,./out目录下应能看到:ls ./out/ delta.tar.gz initrd.img rootfs.tar.gz这组产物(LCOW 启动所需的 initrd/rootfs 及 delta)正是 Windows 上以 Hyper-V 方式运行 Linux 容器的引导基础。Containerd Shim V1:runhcs 单体 shim与 Linux 上典型的 shim - runc 架构不同,runhcsshim 既负责启动容器,也负责管理容器的完整生命周期。构建方式(相对 hcsshim 仓库):C:\ $env:GOOSwindows C:\ go build .\cmd\containerd-shim-runhcs-v1然后把二进制放到环境中 containerd 所在目录。可以用 containerd 生成默认配置文件:.\containerd.exe config default | Out-File C:\Program Files\containerd\config.toml -Encoding ascii生成的配置文件中,该 shim 已经作为 CRI 交互的默认运行时。用ctr.exe尝试验证:C:\ ctr.exe run --runtime io.containerd.runhcs.v1 --rm mcr.microsoft.com/windows/nanoserver:2004 windows-test cmd /c echo Hello World!io.containerd.runhcs.v1这个运行时名在 Moby 源码中同样存在对应关系:daemon/internal/libcontainerd/shimopts/convert.go 在case io.containerd.runhcs.v1:分支中把 shim options 解析为runhcsoptions.Options(即上节提到的 vendor 包cmd/containerd-shim-runhcs-v1/options)。而统计信息的消费路径见 daemon/internal/libcontainerd/types/types_windows.go:内置 HCS 运行时输出*hcsshim.Statistics,runhcs shim 则输出 shim 侧的 stats 结构,该文件通过winStatsToHCSStats将其转换为统一的*hcsshim.Statistics形态,供 dockerd 的 stats 接口使用。这说明 README 中描述的 shim 管理容器生命周期 在 Moby 侧有完整的类型映射闭环。Containerd Shim V2:按平台拆分的多 shim 模型README 用相当篇幅描述了 V2 shim 这一 Windows containerd shim 的重写版,其架构信息密度很高,值得完整展开。V1 与 V2 的本质差异V1(containerd-shim-runhcs-v1)是单体二进制,一个 shim 同时处理 LCOW、Hyper-V WCOW、进程隔离 WCOW 和 Host-process 容器四类形态;它只实现了 containerd 的Task API,并通过这一个 API 同时管理 sandbox 生命周期与容器/进程(task)生命周期。V2把单体拆分为聚焦于单一平台的独立 shim,每个 shim 实例与一个 sandbox1:1 对应,并把职责切分到 containerd 提供的两个 API:sandbox 生命周期走Sandbox API,sandbox 内的容器与进程走Task API。每个 V2 shim 内部相应地实现独立的 sandbox service 与 task service,另附一个用于诊断的shimdiag辅助服务。三个 V2 shim 的定位Shim用途Sandbox 的物理含义Build Tag备注containerd-shim-lcow-v2LCOW:在 Linux 工具 VM(UVM)中运行 Linux 容器该 Linux UVM;一个 shim 实例可承载多个 pod(多 pod 共享同一 UVM)lcow需要 Windows Server 2025 (build 26100) 或更新系统;实现在 hcsshim 仓库的./cmd/containerd-shim-lcow-v2containerd-shim-wcow-v2Hyper-V 隔离的 WCOW:Windows UVM 内运行 Process/Host Process 容器该 Windows UVM,shim 与 UVM 1:1wcow实现 coming sooncontainerd-shim-process-v2直接跑在宿主机上的进程隔离 Windows Server 容器与 Host Process 容器,无 UVMpause 容器:一个最小化、长生命周期的容器,持有 pod 的共享资源(如网络命名空间),在兄弟容器启停/替换期间保持其存活process实现 coming soon统一的 CRI pod 模型三个 shim 都遵循相同的 CRI pod 注解约定:带有io.kubernetes.cri.container-type: sandbox注解的 task 被视为 pause/infra 容器,负责创建 pod;工作负载 task 标注io.kubernetes.cri.container-type: container,并通过io.kubernetes.cri.sandbox-id引用其所属 pause 容器。而 sandbox 具体对应什么(一个 UVM 还是一个 pause 容器),取决于所用 shim——这正是 V2 每平台一个 shim 设计的关键:同一套 CRI 语义,在不同隔离模型下映射到不同的物理实体。V2 的构建与测试由于 V2 源码受 build tag 保护,构建与测试都必须显式传 tag。以 LCOW shim 为例(路径相对 hcsshim 仓库):C:\ $env:GOOSwindows C:\ go build -tags lcow .\cmd\containerd-shim-lcow-v2产物containerd-shim-lcow-v2.exe放置方式与 V1 相同:与containerd.exe同目录。单元测试:C:\ go test -tags lcow ./...此外,仓库在./test/parity下提供parity 测试:把相同输入分别喂给 legacy V1 与新 V2 管线,断言两者产出的 HCS ComputeSystem 文档等价。该测试位于独立的testGo 模块中,同样带 tag 运行:C:\ cd test C:\ go test -tags lcow ./parity/...这一设计直接回应了 shim 大重写 的风险:用 V1 行为作为黄金基线,保证 V2 在 HCS 层面上可替换。工程实践:Lint、代码生成与贡献规范README 的 Contributing 部分给出了一套可复现的工程约定:Lint使用golangci-lint,配置在.golangci.yaml。由于./test是独立 Go 模块,lint 需分别从根目录与test目录执行,且GOOS要覆盖windows与linux两种取值。全仓库完整检查示例:foreach ( $goos in (windows, linux) ) { foreach ( $repo in (., test) ) { pwsh -Command cd $repo go env -w GOOS$goos golangci-lint.exe run --verbose } }VSCode 用户可在 workspace/folder 设置中加入go.lintTool: golangci-lint与go.lintOnSave: package实现保存即 lint。代码生成:CI 会校验go generate产物是最新的,同样需要在根模块与test模块分别执行go generate ./...。Moby vendor 目录中的zsyscall_windows.go正是 hcsshim 通过//go:generatemkwinsyscall生成的系统调用桩,属于该机制的直接产物。贡献流程:遵循 Microsoft CLA,提交需用git commit --signoff(或批量git rebase --signoff)签署 DCO,CI 使用 DCO GitHub app 校验 PR 内所有 commit。依赖与系统要求:构建需要 Golang 1.18 或更新版本;运行侧的系统要求以 Microsoft 的 Windows 容器系统要求文档为准。小结hcsshim 是 Windows 容器生态的控制面枢纽:向下封装 HCS/HNS 等 Windows 服务接口,向上以 Go 库、guest agent 与 containerd shim 三种形态服务于 Moby 和 containerd。从 Moby 仓库视角看,v0.15.0-rc.4版本被整体 vendor,go.mod 与 vendor/modules.txt 中的包清单、daemon/internal/libcontainerd/shimopts/convert.go 中的运行时名映射,共同印证了 README 所述的架构;而 V2 shim 以 Sandbox API / Task API 分离、按 lcow/wcow/process 三个 build tag 拆分、并用 parity 测试锚定 V1 行为,构成了一条可验证的演进路线。需要注意的是,V2 中 wcow 与 process 两个 shim 在 README 中标注为 coming soon,且 LCOW shim 要求 Windows Server 2025 及以上系统,实际采用时应以这些前提为准。【免费下载链接】mobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems项目地址: https://gitcode.com/GitHub_Trending/mo/moby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Moby 中的 hcsshim:Windows 容器 HCS 封装库与 Containerd Shim 的构建实践【免费下载链接】mobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems项目地址: https://gitcode.com/GitHub_Trending/mo/moby本文基于 Moby 仓库 vendor 目录中随依赖一并分发的 hcsshim README 展开,系统讲解 hcsshim 在 Windows 容器生态中的定位、其面向 Host Compute Service (HCS) 的核心 Go 接口、Linux guest agent 与 Containerd Shim(V1/V2) 的构建与验证流程,并结合 Moby 仓库源码说明 hcsshim 如何被 dockerd 实际消费。读完本文,你将能够理解 Windows 容器从运行时到底层 HCS 服务之间的完整调用链,并掌握 hcsshim 各二进制的构建、部署与测试方法。hcsshim 是什么:Moby 依赖树中的 Windows 容器控制面hcsshim 提供了使用 Windows Host Compute Service(HCS)来启动和管理 Windows 容器的 Golang 接口。除 HCS 封装外,它还包含管理 Windows 容器的其他辅助功能:Host Network Service (HNS) 的 Go 接口,即仓库中hcn相关模块;guest agent(代码库中常称 GCS,Guest Compute Service)代码,用于支撑 Linux Hyper-V 容器(LCOW)场景。它主要服务于 Moby 和 Containerd 两大项目,但也供其他项目自由使用。在 Moby 仓库中,可以直接从依赖声明确认其版本:go.mod 中声明github.com/Microsoft/hcsshim v0.15.0-rc.4;vendor/modules.txt 列出了实际 vendor 进来的包,包括hcsshim根包、cmd/containerd-shim-runhcs-v1/options、cmd/containerd-shim-runhcs-v1/stats、computestorage、ext4/...、hcn等。也就是说,Moby 把 hcsshim 作为 Windows 平台下容器生命周期的控制面库引入,dockerd 在 Windows 上的容器创建、网络配置、统计采集都间接依赖它。核心 Go API:Container 与 Process 接口hcsshim 根包提供了两个最核心的抽象:Container(ComputeSystem)与Process,均仅编译于 Windows(//go:build windows约束)。Container 接口从 container.go 可以看到其生命周期 API:// CreateContainer creates a new container with the given configuration but does not start it. func CreateContainer(id string, c *ContainerConfig) (Container, error) // OpenContainer opens an existing container by ID. func OpenContainer(id string) (Container, error) // GetContainers gets a list of the containers on the system that match the query func GetContainers(q ComputeSystemQuery) ([]ContainerProperties, error)每个container实例内部封装一个*hcs.System,并实现了完整的生命周期方法:方法语义Start()同步启动容器Shutdown()/Terminate()请求关机/终止,真正结束以Wait()成功为准Wait()/WaitTimeout(timeout)同步等待容器关闭,WaitTimeout超时返回ErrTimeoutPause()/Resume()暂停/恢复执行Statistics()返回Statistics(内存/CPU/存储/网络统计的 legacy v1 调用)ProcessList()返回容器内进程列表CreateProcess(c *ProcessConfig)/OpenProcess(pid)在容器内创建进程、按 PID 打开已有进程Modify(config)运行时修改资源(支持 Network 类型的 Add/Remove)值得注意的是源码中的一个可观测细节:CreateContainer在init()阶段会读取环境变量HCSSHIM_CREATECONTAINER_ADDITIONALJSON,把其中的额外 JSON 合并进提交给 HCS 的CreateComputeSystem配置。从源码结构看,这是一个供集成方(如测试或上层运行时)在不改代码情况下注入 HCS 配置的逃生口。ContainerProperties、MemoryStats、ProcessorStats、StorageStats、Statistics等类型都是schema1(HCS 1.0 schema)中对应结构的类型别名,意味着 hcsshim 的数据模型与 HCS REST/JSON 文档保持同构。Process 接口process.go 中的process封装对应容器内的一个进程,提供了:Pid()、ExitCode():进程标识与退出码(退出码仅在进程已终止后可用);Kill():请求终止进程但不等待,若进程未找到返回ErrElementNotFound;Wait()/WaitTimeout(timeout):等待退出,与 Container 一样用sync.Once channel 实现可复用的后台等待;ResizeConsole(width, height):调整控制台尺寸;Stdio():返回 stdin/stdout/stderr 三组管道接口,多次调用可获取多组接口,关闭返回的管道不会关闭底层管道;CloseStdin()、Close():关闭 stdin 写端(向进程发 EOF 信号)、清理本地状态而不杀进程。底层的系统调用封装在 hcsshim.go 中,例如通过//sys注释 go generate生成zsyscall_windows.go,并以HcsError作为统一错误类型向外传播。其他被 Moby vendor 的子模块除根包外,vendor/modules.txt显示 Moby 还 vendor 了:hcsshim/hcn:Host Compute Network,即 Windows 网络命名空间/端点的管理接口,daemon/libnetwork/drivers/windows/...中的 overlay 等 Windows 网络驱动依赖它;hcsshim/ext4/...(含tar2ext4、dmverity):Linux 扩展文件系统工具链,服务于 LCOW 的 rootfs 构建;hcsshim/computestorage:Windows 分层存储(CS)接口,与daemon/graphdriver/windows/配合完成 Windows 容器层的挂载;hcsshim/cmd/containerd-shim-runhcs-v1/options与stats:runhcs shim 的 options/stats 数据结构,供 Moby 与 shim 交换配置和统计信息。构建:Linux Guest AgentREADME 说明,除了作为 HCS API 调用库使用,仓库还会产出若干二进制,最主要的是 Linux guest agent 与 containerd 运行时 v2 shim 的实现。构建 Linux guest agent 只需将GOOS设为linux并从./cmd/gcs构建(以下路径均相对 hcsshim 仓库自身根目录):Windows PowerShell 下:C:\ $env:GOOSlinux C:\ go build .\cmd\gcs\或在 Linux 机器上:go build ./cmd/gcs如果想把它打进 rootfs 里随其他工具一起启动,需要提供可打包的 rootfs,最简单的做法是导出一个容器的 rootfs:docker pull busybox docker run --name base_image_container busybox docker export base_image_container | gzip base.tar.gz BASE./base.tar.gz make all构建成功后,./out目录下应能看到:ls ./out/ delta.tar.gz initrd.img rootfs.tar.gz这组产物(LCOW 启动所需的 initrd/rootfs 及 delta)正是 Windows 上以 Hyper-V 方式运行 Linux 容器的引导基础。Containerd Shim V1:runhcs 单体 shim与 Linux 上典型的 shim - runc 架构不同,runhcsshim 既负责启动容器,也负责管理容器的完整生命周期。构建方式(相对 hcsshim 仓库):C:\ $env:GOOSwindows C:\ go build .\cmd\containerd-shim-runhcs-v1然后把二进制放到环境中 containerd 所在目录。可以用 containerd 生成默认配置文件:.\containerd.exe config default | Out-File C:\Program Files\containerd\config.toml -Encoding ascii生成的配置文件中,该 shim 已经作为 CRI 交互的默认运行时。用ctr.exe尝试验证:C:\ ctr.exe run --runtime io.containerd.runhcs.v1 --rm mcr.microsoft.com/windows/nanoserver:2004 windows-test cmd /c echo Hello World!io.containerd.runhcs.v1这个运行时名在 Moby 源码中同样存在对应关系:daemon/internal/libcontainerd/shimopts/convert.go 在case io.containerd.runhcs.v1:分支中把 shim options 解析为runhcsoptions.Options(即上节提到的 vendor 包cmd/containerd-shim-runhcs-v1/options)。而统计信息的消费路径见 daemon/internal/libcontainerd/types/types_windows.go:内置 HCS 运行时输出*hcsshim.Statistics,runhcs shim 则输出 shim 侧的 stats 结构,该文件通过winStatsToHCSStats将其转换为统一的*hcsshim.Statistics形态,供 dockerd 的 stats 接口使用。这说明 README 中描述的 shim 管理容器生命周期 在 Moby 侧有完整的类型映射闭环。Containerd Shim V2:按平台拆分的多 shim 模型README 用相当篇幅描述了 V2 shim 这一 Windows containerd shim 的重写版,其架构信息密度很高,值得完整展开。V1 与 V2 的本质差异V1(containerd-shim-runhcs-v1)是单体二进制,一个 shim 同时处理 LCOW、Hyper-V WCOW、进程隔离 WCOW 和 Host-process 容器四类形态;它只实现了 containerd 的Task API,并通过这一个 API 同时管理 sandbox 生命周期与容器/进程(task)生命周期。V2把单体拆分为聚焦于单一平台的独立 shim,每个 shim 实例与一个 sandbox1:1 对应,并把职责切分到 containerd 提供的两个 API:sandbox 生命周期走Sandbox API,sandbox 内的容器与进程走Task API。每个 V2 shim 内部相应地实现独立的 sandbox service 与 task service,另附一个用于诊断的shimdiag辅助服务。三个 V2 shim 的定位Shim用途Sandbox 的物理含义Build Tag备注containerd-shim-lcow-v2LCOW:在 Linux 工具 VM(UVM)中运行 Linux 容器该 Linux UVM;一个 shim 实例可承载多个 pod(多 pod 共享同一 UVM)lcow需要 Windows Server 2025 (build 26100) 或更新系统;实现在 hcsshim 仓库的./cmd/containerd-shim-lcow-v2containerd-shim-wcow-v2Hyper-V 隔离的 WCOW:Windows UVM 内运行 Process/Host Process 容器该 Windows UVM,shim 与 UVM 1:1wcow实现 coming sooncontainerd-shim-process-v2直接跑在宿主机上的进程隔离 Windows Server 容器与 Host Process 容器,无 UVMpause 容器:一个最小化、长生命周期的容器,持有 pod 的共享资源(如网络命名空间),在兄弟容器启停/替换期间保持其存活process实现 coming soon统一的 CRI pod 模型三个 shim 都遵循相同的 CRI pod 注解约定:带有io.kubernetes.cri.container-type: sandbox注解的 task 被视为 pause/infra 容器,负责创建 pod;工作负载 task 标注io.kubernetes.cri.container-type: container,并通过io.kubernetes.cri.sandbox-id引用其所属 pause 容器。而 sandbox 具体对应什么(一个 UVM 还是一个 pause 容器),取决于所用 shim——这正是 V2 每平台一个 shim 设计的关键:同一套 CRI 语义,在不同隔离模型下映射到不同的物理实体。V2 的构建与测试由于 V2 源码受 build tag 保护,构建与测试都必须显式传 tag。以 LCOW shim 为例(路径相对 hcsshim 仓库):C:\ $env:GOOSwindows C:\ go build -tags lcow .\cmd\containerd-shim-lcow-v2产物containerd-shim-lcow-v2.exe放置方式与 V1 相同:与containerd.exe同目录。单元测试:C:\ go test -tags lcow ./...此外,仓库在./test/parity下提供parity 测试:把相同输入分别喂给 legacy V1 与新 V2 管线,断言两者产出的 HCS ComputeSystem 文档等价。该测试位于独立的testGo 模块中,同样带 tag 运行:C:\ cd test C:\ go test -tags lcow ./parity/...这一设计直接回应了 shim 大重写 的风险:用 V1 行为作为黄金基线,保证 V2 在 HCS 层面上可替换。工程实践:Lint、代码生成与贡献规范README 的 Contributing 部分给出了一套可复现的工程约定:Lint使用golangci-lint,配置在.golangci.yaml。由于./test是独立 Go 模块,lint 需分别从根目录与test目录执行,且GOOS要覆盖windows与linux两种取值。全仓库完整检查示例:foreach ( $goos in (windows, linux) ) { foreach ( $repo in (., test) ) { pwsh -Command cd $repo go env -w GOOS$goos golangci-lint.exe run --verbose } }VSCode 用户可在 workspace/folder 设置中加入go.lintTool: golangci-lint与go.lintOnSave: package实现保存即 lint。代码生成:CI 会校验go generate产物是最新的,同样需要在根模块与test模块分别执行go generate ./...。Moby vendor 目录中的zsyscall_windows.go正是 hcsshim 通过//go:generatemkwinsyscall生成的系统调用桩,属于该机制的直接产物。贡献流程:遵循 Microsoft CLA,提交需用git commit --signoff(或批量git rebase --signoff)签署 DCO,CI 使用 DCO GitHub app 校验 PR 内所有 commit。依赖与系统要求:构建需要 Golang 1.18 或更新版本;运行侧的系统要求以 Microsoft 的 Windows 容器系统要求文档为准。小结hcsshim 是 Windows 容器生态的控制面枢纽:向下封装 HCS/HNS 等 Windows 服务接口,向上以 Go 库、guest agent 与 containerd shim 三种形态服务于 Moby 和 containerd。从 Moby 仓库视角看,v0.15.0-rc.4版本被整体 vendor,go.mod 与 vendor/modules.txt 中的包清单、daemon/internal/libcontainerd/shimopts/convert.go 中的运行时名映射,共同印证了 README 所述的架构;而 V2 shim 以 Sandbox API / Task API 分离、按 lcow/wcow/process 三个 build tag 拆分、并用 parity 测试锚定 V1 行为,构成了一条可验证的演进路线。需要注意的是,V2 中 wcow 与 process 两个 shim 在 README 中标注为 coming soon,且 LCOW shim 要求 Windows Server 2025 及以上系统,实际采用时应以这些前提为准。【免费下载链接】mobyThe Moby Project - a collaborative project for the container ecosystem to assemble container-based systems项目地址: https://gitcode.com/GitHub_Trending/mo/moby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
