云原生【免费下载链接】kubevirtKubernetes Virtualization API and runtime in order to define and manage virtual machines.项目地址https://gitcode.com/gh_mirrors/ku/kubevirt点击查看免费下载本指南以 KubeVirt 仓库的 docs/updating-dependencies.md 为主体系统讲解项目依赖维护的两大主线基于 Go Modules 的 Go 语言依赖更新以及基于bazeldnf的 RPM 测试镜像依赖管理。读者将掌握make deps-update、make rpm-deps、make verify-rpm-deps等命令的完整用法理解repo.yaml仓库配置、hack/rpm-deps.sh打包清单的组织方式并学会如何为 KubeVirt 接入新的 CPU 架构。一、总体概览KubeVirt 的双轨依赖体系KubeVirt 的依赖管理分为两条独立轨道Go 依赖通过 Go Modules 管理涉及主 go.mod 与staging目录下的多个子模块RPM 系统依赖通过bazeldnfbazel 版 DNF 解析器解析 RPM 仓库生成 bazelrpmtree目标最终构建出 virt-launcher、virt-handler 等组件的基础容器镜像。两条轨道互不干扰Go 依赖服务于编译期RPM 依赖服务于运行期容器镜像与测试基座。所有更新操作统一收敛到 Makefile 中的deps-update、rpm-deps、verify-rpm-deps三个目标。二、更新 Go 依赖2.1 一键更新到最新状态运行如下命令即可将全部 Go 依赖提升到各自的最新版本make deps-update该命令在 Makefile 中被定义为在 dockerized 沙箱中依次执行hack/dep-update.sh与hack/bazel-generate.shdeps-update: SYNC_VENDORtrue hack/dockerized ./hack/dep-update.sh ./hack/bazel-generate.shhack/dep-update.sh的实际逻辑是源码对staging/src/kubevirt.io/api、staging/src/kubevirt.io/client-go两个子模块执行go get $ ./...与go mod tidy随后在主模块执行go mod tidy、go work vendor与go work sync从而让主 go.mod、go.work、vendor 目录与各 staging 子模块保持一致。2.2 定点修改特定依赖如果只需要针对某个依赖做定点升级应先直接编辑主 go.mod再执行make deps-update。staging 目录下的子模块依赖分别位于staging/src/kubevirt.io/api/go.modstaging/src/kubevirt.io/client-go/go.mod在 staging 区域内所做的变更会在make deps-update时被主 go.mod 继承——这是 Kubevirt 刻意设计的依赖冒泡机制先改子模块再统一收敛到主模块。2.3 仅同步不升级如果只想把 vendor 目录与子模块同步到当前 go.mod 声明的版本而不触发任何升级可使用make deps-sync对应 Makefile 中带--sync-only参数的调用适合在 CI 校验前重置依赖树。2.4 更新 Kubernetes 依赖的特殊流程K8s 依赖不能简单执行make deps-update了事必须遵循 docs/update-k8s-dependencies.md 的流程先依次提升以下三个文件中所有k8s.io/*的replace指令版本go.modstaging/src/kubevirt.io/client-go/go.modstaging/src/kubevirt.io/api/go.mod如有必要删除引用了被废弃 API 的生成代码如 mock client这些代码随后会被重新生成删除并不造成损失运行make deps-update更新依赖运行make make generate重新生成代码不要忘记恢复第 2 步中手动编辑过的受影响文件需要 revert 以还原。三、更新 RPM 测试依赖3.1 依赖的流转路径KubeVirt 的测试容器基础镜像定义在 images/BUILD.bazel 的kubevirt-testing-base目标中其镜像层直接引用//rpm:testimage_*目标。整个依赖流如下hack/rpm-deps.sh 中的包清单 ↓ bazeldnf rpmtree 解析 rpm/BUILD.bazel 中的 rpmtree 目标 WORKSPACE 中的 RPM 定义 ↓ 镜像层引用 images/BUILD.bazel → kubevirt-testing-base 测试镜像make rpm-deps的核心执行体是 hack/rpm-deps.sh它先通过bazel run //:bazeldnf -- fetch拉取仓库元数据再为每个目标调用bazeldnf rpmtree生成依赖树最后执行bazeldnf prune清理 WORKSPACE 中不再被任何 rpmtree 引用的过期 RPM 定义。命令定义见 Makefile。3.2 向测试镜像新增 RPM如果需要向测试基础镜像加入新的 RPM 包只需两步将包名添加到 hack/rpm-deps.sh 中对应的包清单变量如testimage_main、testimage_x86_64、testimage_aarch64执行make rpm-deps重新生成依赖。make rpm-deps也可定期运行仅用于把已有包升级到仓库中的最新版本。解析完成后WORKSPACE 会写入解析出的 RPM 及其 SHA256 校验值rpm/BUILD.bazel中的rpmtree目标同步更新不再需要的 RPM 定义会被自动移除。从源码结构看hack/rpm-deps.sh包清单变量有一套约定俗成的组织规范$foo_main镜像中必须存在的包$foo_ARCH如_x86_64、_aarch64、_s390x仅针对特定架构的包$foo_extra可由多个包满足的间接依赖显式列出可保证bazeldnf每次都收敛到相同的解析结果从而保持可复现性。例如测试镜像的清单源码testimage_main device-mapper e2fsprogs iputils nmap-ncat procps-ng qemu-img-${QEMU_VERSION} tar targetcli util-linux kmod which # sevctl 仅 x86_64 可用CS10CS9 下所有架构可用 testimage_x86_64 sevctl 3.3 配置 RPM 仓库需要增删或替换 RPM 源时直接编辑 rpm/repo.yaml。该文件使用repositories列表声明各架构可用的仓库每个条目通过arch、baseurl、name、gpgkey描述一个源。当前仓库已为 x86_64、aarch64、s390x 三个架构分别配置了 CentOS Stream 9 的 BaseOS、AppStream、CRB 三个源。当文档仍以 Fedora 32 为例说明条目格式时对应的两种写法分别是使用metalink自动选择最近的镜像节点的 Fedora 源aarch64示例- arch: aarch64 metalink: https://mirrors.fedoraproject.org/metalink?repofedora-32archaarch64 name: 32-aarch64-primary-repo对应x86_64的条目- arch: x86_64 metalink: https://mirrors.fedoraproject.org/metalink?repofedora-32archx86_64 name: 32-x86_64-primary-repo也可以使用baseurl直接指向任意第三方 RPM 仓库例如 Fedora COPR 构建源- arch: x86_64 baseurl: https://download.copr.fedorainfracloud.org/results/kubevirt/libvirt-6.6.0-8.el8/fedora-32-x86_64/ name: kubevirt/libvirt-copr-x86_64注意文档示例中的 Fedora 32 仓库属于历史背景当前 rpm/repo.yaml 实际使用的是 CentOS Stream 9/10 源由 rpm/repo-cs9.yaml、rpm/repo-cs10.yaml 按KUBEVIRT_CENTOS_STREAM_VERSION环境变量切换。字段语义arch/metalink/baseurl/name完全一致可参照套用。3.4 版本化的包清单变量从 hack/rpm-deps.sh 可以看出包清单中的关键运行时组件采用版本锁定策略LIBVIRT_VERSION、QEMU_VERSION、SEABIOS_VERSION、EDK2_VERSION、PASST_VERSION、SWTPM_VERSION、LIBNBD_VERSION等变量均有默认值并在包名中以内嵌版本号的形式参与解析如qemu-kvm-core-${QEMU_VERSION}。这些变量可通过环境变量覆盖并会透传进make rpm-deps的 dockerized 调用见 Makefile。当前默认目标为 CentOS Stream 9KUBEVIRT_CENTOS_STREAM_VERSION ? 9见 Makefile也可通过make rpm-deps-cs10切换到 Stream 10 版本线。3.5 更新 libvirt 与 libvirt-devel 依赖libvirt 与 libvirt-devel 的 RPM 依赖更新方式与测试依赖完全一致在 hack/rpm-deps.sh 的libvirtdevel_main/libvirtdevel_extra等清单中调整libvirt-devel-${LIBVIRT_VERSION}等条目再运行make rpm-deps。其中 libvirt-devel 面向编译与单元测试场景供 virt-launcher、virt-handler 链接libguestfs-tools 镜像还依赖 libguestfs、guestfs-tools、libvirt-daemon-driver-qemu 等包源码。四、校验 RPM 依赖bazeldnf在每次make rpm-deps时都会基于 SHA256 对metalink、repomd.xml与包元数据 XML 做初步校验。但由于后续运行时无法保证仓库中仍是同一批 RPM仅靠 SHA256 无法在 CI 中可靠验证内容有效性因此 RPM 仓库采用GPG 签名来证明内容来源。本地与 CI 均可通过如下命令完成基于 GPG 密钥的校验make verify-rpm-deps该命令执行 hack/verify-rpm-deps.sh核心调用为bazel run \ --config${ARCHITECTURE} \ //:bazeldnf -- verify \ --repofile rpm/repo.yaml即验证 WORKSPACE 中记录的 RPM含 SHA256 值均由 rpm/repo.yaml 中登记的 GPG 密钥签署。因此新增仓库源时务必在repo.yaml条目中提供对应的gpgkey地址否则校验将无法通过。五、接入新架构OnboardingKubeVirt 目前已在 x86_64、aarch64、s390x 三个架构上落地rpm/repo.yaml 与 hack/rpm-deps.sh 均按架构分块组织。接入新架构需要完成以下步骤创建架构专属条目在 rpm/repo.yaml仓库源与 hack/rpm-deps.sh包清单中新增对应arch的条目调整容器目标的 select 子句为所有容器条目补充新的架构分支让 bazel 为不同目标平台选择正确的架构与基础镜像可参考 images/BUILD.bazel 中基于io_bazel_rules_go//go/platform:linux_*的select写法扩展 .bazelrc为新的架构添加架构相关的配置项生成沙箱sandboxmake rpm-deps的运行环境依赖沙箱镜像。如果新架构尚未 onboard则无法直接在新架构上运行该命令需要先通过两种方式之一解决在已 onboard 的架构上运行make rpm-deps沙箱会随之更新手动生成沙箱从 hack/rpm-deps.sh 中 source 所需变量后直接调用bazeldnf rpmtree命令。文档给出的 s390x 沙箱手动生成示例为bazeldnf rpmtree \ --public --nobest \ --name sandboxroot_s390x --arch s390x \ --basesystem ${BASESYSTEM} \ ${bazeldnf_repos} \ $centos_main \ $centos_extra \ $sandboxroot_main其中--basesystem默认值为centos-stream-release见 hack/rpm-deps.sh${BASESYSTEM}等变量来自 hack/config.sh。另外注意架构差异化的两个细节libvirt-devel 仅在 x86_64 提供它用于链接与单元测试。其他架构只有在计划于目标平台运行单元测试时才需要更新或新增对应的 libvirt-devel 目标否则只需为目标平台创建带 libvirt 依赖的镜像即可架构专属包要放入对应变量如launcherbase_x86_64中的edk2-ovmf、seabioslauncherbase_aarch64中的edk2-aarch64等源码。六、当前仓库的版本线与验证要点默认版本线当前 Makefile 默认KUBEVIRT_CENTOS_STREAM_VERSION ? 9可运行make rpm-deps-cs9/make rpm-deps-cs10/make rpm-deps-all分别刷新各版本线Makefile跨架构模拟设置KUBEVIRT_CROSS_ARCH_EMULATION环境变量后hack/rpm-deps.sh 会追加rpm/repo-virt-preview.yaml仓库并为 launcherbase 补充交叉架构的 qemu 系统镜像与 EFI 固件包源码端到端流程改完依赖后建议依次执行make rpm-deps、make verify-rpm-deps、make deps-update再运行make make generate完成生成物刷新确保 WORKSPACE、rpm/BUILD.bazel、vendor 与生成代码完全一致。七、常见问题速查场景操作涉及文件Go 依赖全部升级到最新make deps-updatego.mod、staging 子模块、go.work定点升级某个 Go 依赖编辑 go.mod 后make deps-updatego.mod只同步不升级make deps-syncvendor 目录、staging 子模块升级 k8s 依赖三处 replace 指令 →make deps-update→make make generatego.mod、staging/src/kubevirt.io/client-go/go.mod、staging/src/kubevirt.io/api/go.mod测试镜像加包 / 升级 RPM修改包清单 →make rpm-depshack/rpm-deps.sh、rpm/BUILD.bazel、WORKSPACE、images/BUILD.bazel增删 RPM 仓库源编辑条目arch/baseurl/metalink/name/gpgkeyrpm/repo.yaml校验 RPM 来源make verify-rpm-depshack/verify-rpm-deps.sh、rpm/repo.yaml接入新架构repo.yaml rpm-deps.sh .bazelrc 沙箱rpm/repo.yaml、hack/rpm-deps.sh、.bazelrc掌握以上流程后无论是常规的依赖升级、定点版本修正还是为 KubeVirt 添加新的 CPU 架构支持都能在一条清晰的命令链路内完成并可通过 GPG 校验保证依赖供应链的可信性。赞分享云原生【免费下载链接】kubevirtKubernetes Virtualization API and runtime in order to define and manage virtual machines.项目地址https://gitcode.com/gh_mirrors/ku/kubevirt点击查看免费下载相关推荐KubeVirt 自定义 Builder 镜像构建全指南从多架构工具链、RPM 依赖更新到镜像发布KubeVirt 自定义 Builder 镜像构建全指南从多架构工具链、RPM 依赖更新到镜像发布 KubeVirt 的整个构建体系始于一个 builder云原生Better BibTeX子模块管理依赖库更新与维护终极指南Better BibTeX子模块管理依赖库更新与维护终极指南 Better BibTeX作为Zotero的强大插件为LaTeX用户提供了无缝的文献管理体验。科研terraform-provider-aws 依赖更新指南Go 版本升级、AWS SDK 与工具链维护实战terraform provider aws 依赖更新指南Go 版本升级、AWS SDK 与工具链维护实战 导读 本文基于 docs/dependency uIaC云原生基础设施上一篇PowerSploit Privesc 模块 Get-ApplicationHost从 IIS applicationHost.config 解密恢复应用池与虚拟目录密码下一篇ZCode 最小受管理模块Golden Module契约规范manifest 窄端口 示例驱动的架构治理实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
