VeleroHeptio Ark从源码构建全指南下载、编译、镜像构建与运行部署【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文基于仓库内 site/content/docs/v0.8.0/build-from-scratch.md 展开完整梳理 Velero 前身 Heptio Ark 从源码获取、本地构建、交叉编译、生成文件更新、单元测试到集群内运行的完整链路。读完本文你将掌握如何用make系列目标产出ark/velero二进制与容器镜像并把自建镜像替换进 Kubernetes 集群同时理解该流程在后续版本中的演进。前置条件Prerequisites在开始构建之前需要准备以下环境以 v0.8.0 时代的要求为准一个可访问的 Kubernetes 集群版本1.7 或更高若要运行ark backup delete则要求1.7.5 或更高该命令依赖较新的 API 能力。集群内可用且配置正确的DNS 服务器。已安装kubectl用于与集群交互及后续更新部署镜像。已安装Go最低版本1.8go get获取源码与go build编译均依赖 Go 工具链。从当前仓库的构建产物看这一源码构建能力在后续版本中一直被保留并强化最新版构建文档 site/content/docs/v1.18/build-from-source.md 仍然把「访问 Kubernetes 集群 DNS kubectl Go」列为前置条件说明这套构建与部署模型自 Ark 时代起就是项目的基础设施之一。获取源码Downloadv0.8.0 文档推荐的获取方式是 Go 标准导入go get github.com/heptio/ark源码会被安装到$GOPATH/src/github.com/heptio/ark目录下。注意本项目在 v0.8.0 时代名为Heptio Ark仓库路径为github.com/heptio/ark随后迁移至 VMware 并被更名为Velero。当前仓库根目录的 Makefile 中包导入路径已经变为PKG : github.com/vmware-tanzu/velero因此如果你要基于当前仓库的代码构建应使用go get github.com/vmware-tanzu/velero而新版本文档 site/content/docs/v1.18/build-from-source.md 给出了两种获取方式推荐直接go get拉取最新源码或者从 release 页面下载名为Source code的归档解压到 Go 导入路径下的src/github.com/velero-io/velero。同时该文档明确指出Makefile 的众多目标假设你是在一个 git 仓库内构建需要读取 git 提交哈希来拼接版本信息若使用归档解压的方式则只能使用go build直接编译。构建Buildv0.8.0 文档提供了两种镜像构建工作流在运行集群的机器上本地构建镜像或者推送到私有镜像仓库。核心是设置$REGISTRY环境变量Makefile 中使用让集群内任意节点都能拉取你本地构建的镜像。在 Ark 根目录下使用以下命令构建容器镜像标签为$REGISTRY/ark:$VERSIONmake container推送到镜像仓库使用make push对照当前仓库的 Makefile这套变量体系仍然存在只是默认值发生了变化# Where to push the docker image. REGISTRY ? velero # Image name IMAGE ? $(REGISTRY)/$(BIN) ... VERSION ? main也就是说若未显式设置$REGISTRY当前版本默认以velero作为镜像名前缀例如velero/velero:main设置REGISTRYgcr.io/my-registry则可构建出gcr.io/my-registry/velero:main。镜像 tag 默认使用VERSION变量未设置时取main也支持TAG_LATESTtrue时额外打上latest标签。镜像构建机制的演进需要特别说明的是v0.8.0 时代的make container直接调用 docker build而当前仓库的make container目标已经改为基于Docker Buildx的多架构构建见 Makefile 中container/container-linux/container-windows目标构建前会检查BUILDX_ENABLED未启用 buildx 时直接拒绝执行并提示阅读build-from-source文档BUILDX_ERROR定义见 Makefile。可通过BUILD_OUTPUT_TYPEdocker|registry|tar控制输出方式设置为registry时make container会自动调用push-manifest目标推送多架构 manifestLinux 各架构 windows/amd64/ltsc2022。跨平台编译 Linux 容器时需要先做一次性准备运行docker run --rm --privileged multiarch/qemu-user-static --reset -p yes并创建 bootstrap 一个docker-container驱动的 buildx builderdocker buildx create --use --name builderdocker buildx inspect --bootstrap。若使用默认的 docker driverREGISTRYmyrepo BUILDX_OUTPUT_TYPEregistry make container会以auto-push is currently not implemented for docker driver报错。一个值得注意的细节未修改镜像名的情况下Kubernetes 不会自动拉取新镜像需要删除 Velero 相关 Pod 触发重新创建例如kubectl -n velero delete pods -l deployvelero。更新生成文件Update generated filesv0.8.0 文档强调以下文件是由源码自动生成的修改源码后必须重新生成Clientsetclient-go 生成的客户端集合ListersShared informers文档Protobuf/gRPC 类型如果做了以下改动必须运行make update重新生成新增/编辑/删除命令行 flag 或其 help 文本新增/编辑/删除命令或子命令新增 API 类型如果修改了 protobuf message 或 service 定义则必须运行generate-proto.sh重新生成并且该场景额外依赖 proto 编译器Protocol Buffers v3。在当前仓库中这一流程被拆分成更细粒度的脚本并统一由make update编排见 Makefile 中update: ## Run all update scripts目标调用hack/update-all.shhack/update-1fmt.sh——格式化hack/update-2proto.sh——重新生成 protobuf/gRPC 类型对应 v0.8.0 文档中的generate-proto.shhack/update-3generated-crd-code.sh——重新生成 CRD 代码hack/update-4generated-issue-template.sh——重新生成 issue 模板此外还提供了开发期专用的快捷目标make update-crd只跑 CRD 代码生成比完整的make update更快。配套的 hack/verify-all.sh 与 hack/verify-fmt.sh 则用于校验生成文件是否与源码一致CI 中通过make verify调用。交叉编译Cross compilingv0.8.0 文档说明默认make构建的是宿主机操作系统与架构下的ark二进制要为其他平台构建运行make build-GOOS-GOARCH。例如为 macOS 构建make build-darwin-amd64所有二进制输出到_output/bin/GOOS/GOARCH例如_output/bin/darwin/amd64/ark。Makefile 提供了便捷目标all-build一次性构建以下平台linux-amd64linux-armlinux-arm64darwin-amd64windows-amd64对照当前仓库的 Makefile这套机制的实现方式为make build-os-arch将ARCH透传给build目标再经build-dirs与_output/bin/$(GOOS)/$(GOARCH)/$(BIN)规则产出二进制local目标则直接检测go env GOOS/GOARCH并在本机构建无需容器。同时all-build的CLI_PLATFORMS已扩展为CLI_PLATFORMS ? linux-amd64 linux-arm linux-arm64 darwin-amd64 darwin-arm64 windows-amd64 linux-ppc64le linux-s390x相比 v0.8.0 增加了 darwin-arm64、linux-ppc64le、linux-s390x 等平台与 site/content/docs/v1.18/build-from-source.md 中列出的平台一致。关于编译产物还需注意两点见 v1.18 构建文档make在编译时会拼接版本与 git commit 信息使velero version输出正确结果而velero install也会根据版本信息决定部署哪个 tag 的镜像如需覆盖部署的镜像请使用image参数。直接使用 go build若只想在本机构建二进制可以不依赖 Makefile直接go build ./cmd/velero或运行make local。当前仓库的 CLI 入口位于 cmd/velero/velero.go二进制默认名为veleroMakefile 中BIN ? velero。测试Testv0.8.0 文档给出两类验证手段make test运行单元测试。make verify确保所有生成文件clientset、listers、shared informers、docs都是最新的。在当前仓库中make test会进入构建容器执行 hack/test.sh也提供make test-local在本机直接跑make verify调用hack/verify-all.sh。还新增了make lint/make local-linthack/lint.sh以及端到端测试目标make test-e2e调用 test/Makefile 中的run-e2ee2e 测试源码位于 test/e2e。CI 一站式入口为make ci依次执行verify-modules、verify、all、test。运行Run构建完成并部署后在集群中运行 Ark 需要考虑以下几类事项v0.8.0 的 examples 目录中的 manifest 已涵盖这些内容合适的 RBAC 权限对源集群与源命名空间的所有数据有读取权限对目标集群与目标命名空间有写入权限。云厂商凭证Cloud provider credentials对存储卷的读/写权限对对象存储存放备份数据的读/写权限。为 Ark server 定义 Config 对象详见同版本文档 config-definition.md。更完整的云厂商接入说明参见同版本文档 cloud-common.md。当前仓库在 examples/ 下提供了可直接参考的部署样例例如 examples/minio/00-minio-deployment.yaml 用于搭建本地对象存储examples/nginx-app/base.yaml 与 examples/nginx-app/with-pv.yaml 演示备份应用。RBAC 的最小角色定义可参考 config/rbac/role.yaml安装用 Deployment 的完整资源可在 pkg/install 中查看生成逻辑。指定你构建的镜像当 Ark deployment 启动运行后必须把 Heptio 官方镜像替换为你自己构建的镜像执行kubectl set image deployment/ark ark$REGISTRY/ark:$VERSION其中$REGISTRY与$VERSION必须与构建时使用的值一致即make container产出的$REGISTRY/ark:$VERSION。在 Velero 时代对应的命令为镜像 tag 规则同前文所述deployment 位于velero命名空间kubectl -n velero set image deploy/velero veleromyimagerepo/velero:$VERSION如果后续只更新了代码而没有改镜像名需要强制 Kubernetes 重新拉取新镜像可通过删除 Pod 触发kubectl -n velero delete pods -l deployvelero依赖 vendoringVendoring dependencies如果需要新增或更新 vendored 依赖请参考 v0.8.0 同版本文档 vendoring-dependencies.md。v0.8.0 时代项目使用 vendor 目录管理第三方依赖当前仓库已切换到 Go Modules见根目录 go.mod 与 go.sum对应的维护目标为make modules执行go mod tidy整理依赖make verify-modules校验 go.mod/go.sum 是否与代码一致有改动则 CI 失败。版本演进小结本文所讲解的 v0.8.0 文档记录的是项目在Heptio Ark阶段的构建流程其核心链路go get获取源码 →make container构建镜像 →kubectl set image替换部署镜像 →make update重新生成代码 → 交叉编译与all-build多平台打包在 Velero 时期被完整继承并持续演进二进制名从ark变为velero包路径从github.com/heptio/ark变为github.com/vmware-tanzu/velero镜像构建从普通 docker build 升级为 buildx 多架构构建生成文件从单一的make update拆分为 hack 下多个update-*脚本构建文档最新版本位于 site/content/docs/v1.18/build-from-source.md。对于希望在自定义代码基础上搭建备份/恢复环境的开发者而言掌握这套从源码到集群部署的完整流程是进行二次开发与私有化交付的基础。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Velero（Heptio Ark）从源码构建全指南：下载、编译、镜像构建与运行部署
VeleroHeptio Ark从源码构建全指南下载、编译、镜像构建与运行部署【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文基于仓库内 site/content/docs/v0.8.0/build-from-scratch.md 展开完整梳理 Velero 前身 Heptio Ark 从源码获取、本地构建、交叉编译、生成文件更新、单元测试到集群内运行的完整链路。读完本文你将掌握如何用make系列目标产出ark/velero二进制与容器镜像并把自建镜像替换进 Kubernetes 集群同时理解该流程在后续版本中的演进。前置条件Prerequisites在开始构建之前需要准备以下环境以 v0.8.0 时代的要求为准一个可访问的 Kubernetes 集群版本1.7 或更高若要运行ark backup delete则要求1.7.5 或更高该命令依赖较新的 API 能力。集群内可用且配置正确的DNS 服务器。已安装kubectl用于与集群交互及后续更新部署镜像。已安装Go最低版本1.8go get获取源码与go build编译均依赖 Go 工具链。从当前仓库的构建产物看这一源码构建能力在后续版本中一直被保留并强化最新版构建文档 site/content/docs/v1.18/build-from-source.md 仍然把「访问 Kubernetes 集群 DNS kubectl Go」列为前置条件说明这套构建与部署模型自 Ark 时代起就是项目的基础设施之一。获取源码Downloadv0.8.0 文档推荐的获取方式是 Go 标准导入go get github.com/heptio/ark源码会被安装到$GOPATH/src/github.com/heptio/ark目录下。注意本项目在 v0.8.0 时代名为Heptio Ark仓库路径为github.com/heptio/ark随后迁移至 VMware 并被更名为Velero。当前仓库根目录的 Makefile 中包导入路径已经变为PKG : github.com/vmware-tanzu/velero因此如果你要基于当前仓库的代码构建应使用go get github.com/vmware-tanzu/velero而新版本文档 site/content/docs/v1.18/build-from-source.md 给出了两种获取方式推荐直接go get拉取最新源码或者从 release 页面下载名为Source code的归档解压到 Go 导入路径下的src/github.com/velero-io/velero。同时该文档明确指出Makefile 的众多目标假设你是在一个 git 仓库内构建需要读取 git 提交哈希来拼接版本信息若使用归档解压的方式则只能使用go build直接编译。构建Buildv0.8.0 文档提供了两种镜像构建工作流在运行集群的机器上本地构建镜像或者推送到私有镜像仓库。核心是设置$REGISTRY环境变量Makefile 中使用让集群内任意节点都能拉取你本地构建的镜像。在 Ark 根目录下使用以下命令构建容器镜像标签为$REGISTRY/ark:$VERSIONmake container推送到镜像仓库使用make push对照当前仓库的 Makefile这套变量体系仍然存在只是默认值发生了变化# Where to push the docker image. REGISTRY ? velero # Image name IMAGE ? $(REGISTRY)/$(BIN) ... VERSION ? main也就是说若未显式设置$REGISTRY当前版本默认以velero作为镜像名前缀例如velero/velero:main设置REGISTRYgcr.io/my-registry则可构建出gcr.io/my-registry/velero:main。镜像 tag 默认使用VERSION变量未设置时取main也支持TAG_LATESTtrue时额外打上latest标签。镜像构建机制的演进需要特别说明的是v0.8.0 时代的make container直接调用 docker build而当前仓库的make container目标已经改为基于Docker Buildx的多架构构建见 Makefile 中container/container-linux/container-windows目标构建前会检查BUILDX_ENABLED未启用 buildx 时直接拒绝执行并提示阅读build-from-source文档BUILDX_ERROR定义见 Makefile。可通过BUILD_OUTPUT_TYPEdocker|registry|tar控制输出方式设置为registry时make container会自动调用push-manifest目标推送多架构 manifestLinux 各架构 windows/amd64/ltsc2022。跨平台编译 Linux 容器时需要先做一次性准备运行docker run --rm --privileged multiarch/qemu-user-static --reset -p yes并创建 bootstrap 一个docker-container驱动的 buildx builderdocker buildx create --use --name builderdocker buildx inspect --bootstrap。若使用默认的 docker driverREGISTRYmyrepo BUILDX_OUTPUT_TYPEregistry make container会以auto-push is currently not implemented for docker driver报错。一个值得注意的细节未修改镜像名的情况下Kubernetes 不会自动拉取新镜像需要删除 Velero 相关 Pod 触发重新创建例如kubectl -n velero delete pods -l deployvelero。更新生成文件Update generated filesv0.8.0 文档强调以下文件是由源码自动生成的修改源码后必须重新生成Clientsetclient-go 生成的客户端集合ListersShared informers文档Protobuf/gRPC 类型如果做了以下改动必须运行make update重新生成新增/编辑/删除命令行 flag 或其 help 文本新增/编辑/删除命令或子命令新增 API 类型如果修改了 protobuf message 或 service 定义则必须运行generate-proto.sh重新生成并且该场景额外依赖 proto 编译器Protocol Buffers v3。在当前仓库中这一流程被拆分成更细粒度的脚本并统一由make update编排见 Makefile 中update: ## Run all update scripts目标调用hack/update-all.shhack/update-1fmt.sh——格式化hack/update-2proto.sh——重新生成 protobuf/gRPC 类型对应 v0.8.0 文档中的generate-proto.shhack/update-3generated-crd-code.sh——重新生成 CRD 代码hack/update-4generated-issue-template.sh——重新生成 issue 模板此外还提供了开发期专用的快捷目标make update-crd只跑 CRD 代码生成比完整的make update更快。配套的 hack/verify-all.sh 与 hack/verify-fmt.sh 则用于校验生成文件是否与源码一致CI 中通过make verify调用。交叉编译Cross compilingv0.8.0 文档说明默认make构建的是宿主机操作系统与架构下的ark二进制要为其他平台构建运行make build-GOOS-GOARCH。例如为 macOS 构建make build-darwin-amd64所有二进制输出到_output/bin/GOOS/GOARCH例如_output/bin/darwin/amd64/ark。Makefile 提供了便捷目标all-build一次性构建以下平台linux-amd64linux-armlinux-arm64darwin-amd64windows-amd64对照当前仓库的 Makefile这套机制的实现方式为make build-os-arch将ARCH透传给build目标再经build-dirs与_output/bin/$(GOOS)/$(GOARCH)/$(BIN)规则产出二进制local目标则直接检测go env GOOS/GOARCH并在本机构建无需容器。同时all-build的CLI_PLATFORMS已扩展为CLI_PLATFORMS ? linux-amd64 linux-arm linux-arm64 darwin-amd64 darwin-arm64 windows-amd64 linux-ppc64le linux-s390x相比 v0.8.0 增加了 darwin-arm64、linux-ppc64le、linux-s390x 等平台与 site/content/docs/v1.18/build-from-source.md 中列出的平台一致。关于编译产物还需注意两点见 v1.18 构建文档make在编译时会拼接版本与 git commit 信息使velero version输出正确结果而velero install也会根据版本信息决定部署哪个 tag 的镜像如需覆盖部署的镜像请使用image参数。直接使用 go build若只想在本机构建二进制可以不依赖 Makefile直接go build ./cmd/velero或运行make local。当前仓库的 CLI 入口位于 cmd/velero/velero.go二进制默认名为veleroMakefile 中BIN ? velero。测试Testv0.8.0 文档给出两类验证手段make test运行单元测试。make verify确保所有生成文件clientset、listers、shared informers、docs都是最新的。在当前仓库中make test会进入构建容器执行 hack/test.sh也提供make test-local在本机直接跑make verify调用hack/verify-all.sh。还新增了make lint/make local-linthack/lint.sh以及端到端测试目标make test-e2e调用 test/Makefile 中的run-e2ee2e 测试源码位于 test/e2e。CI 一站式入口为make ci依次执行verify-modules、verify、all、test。运行Run构建完成并部署后在集群中运行 Ark 需要考虑以下几类事项v0.8.0 的 examples 目录中的 manifest 已涵盖这些内容合适的 RBAC 权限对源集群与源命名空间的所有数据有读取权限对目标集群与目标命名空间有写入权限。云厂商凭证Cloud provider credentials对存储卷的读/写权限对对象存储存放备份数据的读/写权限。为 Ark server 定义 Config 对象详见同版本文档 config-definition.md。更完整的云厂商接入说明参见同版本文档 cloud-common.md。当前仓库在 examples/ 下提供了可直接参考的部署样例例如 examples/minio/00-minio-deployment.yaml 用于搭建本地对象存储examples/nginx-app/base.yaml 与 examples/nginx-app/with-pv.yaml 演示备份应用。RBAC 的最小角色定义可参考 config/rbac/role.yaml安装用 Deployment 的完整资源可在 pkg/install 中查看生成逻辑。指定你构建的镜像当 Ark deployment 启动运行后必须把 Heptio 官方镜像替换为你自己构建的镜像执行kubectl set image deployment/ark ark$REGISTRY/ark:$VERSION其中$REGISTRY与$VERSION必须与构建时使用的值一致即make container产出的$REGISTRY/ark:$VERSION。在 Velero 时代对应的命令为镜像 tag 规则同前文所述deployment 位于velero命名空间kubectl -n velero set image deploy/velero veleromyimagerepo/velero:$VERSION如果后续只更新了代码而没有改镜像名需要强制 Kubernetes 重新拉取新镜像可通过删除 Pod 触发kubectl -n velero delete pods -l deployvelero依赖 vendoringVendoring dependencies如果需要新增或更新 vendored 依赖请参考 v0.8.0 同版本文档 vendoring-dependencies.md。v0.8.0 时代项目使用 vendor 目录管理第三方依赖当前仓库已切换到 Go Modules见根目录 go.mod 与 go.sum对应的维护目标为make modules执行go mod tidy整理依赖make verify-modules校验 go.mod/go.sum 是否与代码一致有改动则 CI 失败。版本演进小结本文所讲解的 v0.8.0 文档记录的是项目在Heptio Ark阶段的构建流程其核心链路go get获取源码 →make container构建镜像 →kubectl set image替换部署镜像 →make update重新生成代码 → 交叉编译与all-build多平台打包在 Velero 时期被完整继承并持续演进二进制名从ark变为velero包路径从github.com/heptio/ark变为github.com/vmware-tanzu/velero镜像构建从普通 docker build 升级为 buildx 多架构构建生成文件从单一的make update拆分为 hack 下多个update-*脚本构建文档最新版本位于 site/content/docs/v1.18/build-from-source.md。对于希望在自定义代码基础上搭建备份/恢复环境的开发者而言掌握这套从源码到集群部署的完整流程是进行二次开发与私有化交付的基础。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考