Vitess Bootstrap 镜像完全指南从构建、测试到发布的 Docker 流水线实战【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitessBootstrap 镜像vitess/bootstrap是 Vitess 整个 Docker 镜像体系的地基它模拟了在源码仓库中成功执行bootstrap.sh与dev.env之后得到的完整依赖环境为后续构建base、lite镜像以及跨 MySQL 版本运行测试提供了稳定的缓存层。本文以仓库中的 docker/bootstrap/README.md 为骨架结合 build.sh、各 flavor 的 Dockerfile、Makefile 与 test.go 等源码系统讲解 Bootstrap 镜像的镜像家族、内部构建过程、构建命令、维护者发布流程与版本管理机制读完即可独立完成镜像的构建、测试与发布。Bootstrap 镜像在 Vitess 镜像体系中的角色Vitess 官方发布的 Docker 镜像按职责可分为三层详见 docker/README.md镜像更新方式说明bootstrap手动仅在bootstrap.sh等发生不兼容变更后代码检出后执行./bootstrap.sh的快照用于缓存依赖避免依赖未变化时的重复编译内部测试运行器test.go使用它针对不同 MySQL 版本测试代码base手动按需包含全部 Vitess 服务端二进制是执行make build之后的快照lite自动每次推送到 main 分支后base 的精简版本运行 Vitess 的推荐镜像Bootstrap 镜像的核心价值在于缓存依赖。Vitess 的构建依赖了 protoc、Zookeeper、etcd、consul 等大量外部工具见 bootstrap.sh如果每次 CI 都从零下载编译成本极高。Bootstrap 镜像将这些依赖连同 Go 模块缓存一并固化后续所有基于它的镜像构建和测试都能直接复用。需要特别强调的一点是与自动重建的lite等镜像不同Bootstrap 镜像不会在每次推送 Vitess main 分支时自动重建。只有当依赖或构建脚本发生不兼容变更时维护者才会手动构建新版本。镜像家族与 Flavor 概念vitess/bootstrap镜像按 common 数据库 flavor 的思路组织。README 中列出的镜像包括vitess/bootstrap:common— 所有 flavor 共享的依赖Go 工具链、编译工具、Zookeeper/etcd 等vitess/bootstrap:mysql80— MySQL 8.0 flavorvitess/bootstrap:mysql84— MySQL 8.4 flavorvitess/bootstrap:percona80— Percona Server 8.0 flavor实际上从 Makefile 可以看到当前完整的构建集合还包含percona84DOCKER_IMAGES_FOR_TEST mysql80 mysql84 percona80 percona84 DOCKER_IMAGES common $(DOCKER_IMAGES_FOR_TEST)test.go中也维护了同样的 flavor 列表test.goflavors mysql80,mysql84,percona80,percona84。也就是说官方为测试维护了 4 个数据库 flavor 加 1 个公共基础镜像。关于镜像命名标签的说明README 中的vitess/bootstrap:common写法是省去版本号的简写。实际构建出的镜像使用带版本号的标签格式为vitess/bootstrap:版本-common与vitess/bootstrap:版本-flavor例如vitess/bootstrap:61-mysql80。这一点在 build.sh 的默认值、docker-bake.hcl 的 tags 定义以及 test.go 的取镜像逻辑中都有明确体现。镜像内部结构common 镜像剖析common 镜像的 Dockerfile 是整个镜像体系的核心它完成四件事1. 安装构建依赖基于golang:1.27.1-bookworm基础镜像安装ant、ca-certificates、curl、default-jre-headless、g、git、gnupg、make、unzip、zip等编译工具链。其中default-jre-headless而非完整 JDK是近期安全加固的结果——从 CHANGELOG.md 可以看到版本 54 起由default-jdk-headless改为default-jre-headless因为构建流程不再需要完整的 Java 开发套件。2. 设置 Vitess 环境变量等价于执行. dev.envENV VTROOT/vt/src/vitess.io/vitess ENV VTDATAROOT/vt/vtdataroot ENV VTPORTSTART15000 ENV PATH$VTROOT/bin:$VTROOT/dist/maven/bin:$PATH ENV USERvitess这些变量与源码根目录下的 dev.env 语义一致dev.env 中VTPORTSTART6700镜像内调整为 15000 以避开宿主机端口冲突。VTROOT指向源码树VTDATAROOT是数据目录同时通过VOLUME /vt/vtdataroot声明为挂载点VTPORTSTART是测试集群端口号的起始值。3. 拷贝构建所需文件并下载 Go 依赖COPY bootstrap.sh dev.env build.env go.mod go.sum /vt/src/vitess.io/vitess/ COPY config /vt/src/vitess.io/vitess/config COPY tools /vt/src/vitess.io/vitess/tools然后以普通用户vitessUID/GID 均为 1000执行go mod download并使用--mounttypecache将 Go 模块缓存挂载为构建缓存既加速后续构建又允许镜像瘦身CHANGELOG 版本 51 明确排除了 Go module cache。此外还做了一个兼容处理/vt/bin符号链接指向$VTROOT/bin让后续 lite 镜像可以直接从/vt/bin拷贝二进制。4. 执行 bootstrap.shUSER vitess RUN BUILD_CONSUL0 ./bootstrap.sh这里以BUILD_CONSUL0跳过 consul 安装consul 已从构建流程移除见 CHANGELOG 版本 51。bootstrap.sh 的核心是install_dep函数它把版本号写入$dist/.installed_version若版本未变化则跳过安装从而实现依赖的幂等安装。当前安装项包括 protoc、Zookeeper通过预编译二进制、etcd 等bootstrap.sh且从版本 51 起所有下载的工具都强制进行 SHA256/SHA512 校验bootstrap.sh。flavor 镜像如何叠加数据库common 镜像只含共享依赖具体数据库 flavor 在各自的 Dockerfile 中叠加安装。以 mysql80 的 Dockerfile 为例其结构为ARG bootstrap_version61 ARG imagevitess/bootstrap:${bootstrap_version}-common FROM $image USER root # 导入 MySQL 与 Percona 的 GPG 公钥带 10 次重试 RUN for i in $(seq 1 10); do apt-key adv --no-tty --recv-keys --keyserver keyserver.ubuntu.com 8C718D3B5072E1F5 break; done \ ... echo deb http://repo.mysql.com/apt/debian/ bookworm mysql-8.0 /etc/apt/sources.list.d/mysql.list \ ... echo deb http://repo.percona.com/apt bookworm main /etc/apt/sources.list.d/percona.list \ ... DEBIAN_FRONTENDnoninteractive apt-get install -y mysql-server libmysqlclient-dev libdbd-mysql-perl rsync libev4 libcurl4-openssl-dev percona-xtrabackup-80 \ rm -rf /var/lib/apt/lists/* USER vitess几个值得注意的实现细节以 ARG 传参的继承机制bootstrap_version与image两个ARG使得同一个 Dockerfile 可以被不同版本号复用FROM $image动态选择基础镜像。GPG 密钥导入带重试由于 apt-key 从 keyserver 拉取公钥偶发失败代码用for i in $(seq 1 10)循环重试直到成功提升了构建的鲁棒性。同时安装 MySQL 服务端与 Percona XtraBackup测试备份/恢复功能需要 XtraBackup而libdbd-mysql-perl、rsync、libev4等是 vttablet 备份与复制相关功能所需。mysql80 使用percona-xtrabackup-80。debconf 预置 root 密码通过debconf-set-selections预设unused作为 MySQL root 密码保证非交互式安装不中断。安装完成后切回vitess用户避免容器默认以 root 运行测试。对比其他 flavormysql84 使用mysql-8.4-lts软件源与percona-xtrabackup-84Dockerfile.mysql84percona80 以 Percona Server 为主并额外安装percona-server-rocksdb还会删除percona-telemetry-agent以规避 CVE-2025-22871Dockerfile.percona80。使用 build.sh 构建 Bootstrap 镜像构建 Bootstrap 镜像的入口脚本是 docker/bootstrap/build.sh。必须先构建common镜像再构建各 flavor第二个参数是 Bootstrap 版本号当前版本见 CHANGELOG.md截至最新记录为61。vitess$ docker/bootstrap/build.sh common 61 vitess$ docker/bootstrap/build.sh mysql80 61脚本的默认逻辑为build.sh默认镜像名为vitess/bootstrap:版本-common和vitess/bootstrap:版本-flavor强制指定--platformlinux/amd64保证构建产物架构一致使用--build-arg将bootstrap_version传给 Dockerfile非 common 镜像还会传入基础镜像image参数构建前会对仓库文件递归修正权限chmod -R orx *以规避 AUFS 文件系统的权限问题。自定义镜像名称与基础镜像也可以通过--image参数指定最终镜像名vitess$ docker/bootstrap/build.sh common --image my-common-image如果指定了自定义镜像名构建 flavor 时通常需要同步指定基础镜像名vitess$ docker/bootstrap/build.sh mysql80 --base_image my-common-image两个参数可以组合使用vitess$ docker/bootstrap/build.sh mysql80 --base_image my-common-image --image my-mysql-image脚本通过遍历参数将--xxx形式转换为同名 shell 变量build.sh因此--base_image与--image会覆盖前面计算出的默认值。使用 docker buildx bake 批量构建仓库还提供了 docker-bake.hcl 支持docker buildx bake的声明式构建docker buildx bake -f docker/bootstrap/docker-bake.hcl默认会构建common和mysql84两个 target并自动把 common 作为 flavor 的构建上下文contexts { vitess/bootstrap:...-common target:common }。版本与 flavor 可通过变量覆盖docker buildx bake -f docker/bootstrap/docker-bake.hcl --set *.tagsmyregistry/bootstrap:mytag维护者发布流程Makefile 目标对于 Vitess 项目维护者更新 Docker Hub 上的全部 Bootstrap 镜像可以使用 Makefile 提供的三个目标流程如下1. 构建全部 flavorvitess$ make docker_bootstrap该目标遍历DOCKER_IMAGEScommon mysql80 mysql84 percona80 percona84逐个调用docker/bootstrap/build.sh flavor ${BOOTSTRAP_VERSION}。2. 逐个 flavor 运行全部测试vitess$ make docker_bootstrap_test该目标本质上执行./test.go -pullfalse -parallel2 -bootstrap-version${BOOTSTRAP_VERSION} -flavormysql80,mysql84,percona80,percona84即用 test.go 的 Docker 测试模式以 2 路并行对每个 flavor 跑一遍完整测试套件。test.go会据此选择对应镜像vitess/bootstrap:版本-flavor见 test.go并在容器内先执行make build再运行测试test.go。3. 全部通过后推送到 Docker Hubvitess$ make docker_bootstrap_push逐个执行docker push vitess/bootstrap:${BOOTSTRAP_VERSION}-flavor。此外还有make docker_bootstrap_pull用于把本机镜像更新为 Docker Hub 上的最新版本。版本号同步机制BOOTSTRAP_VERSION与源码中的版本号通过ensure_bootstrap_version目标保持同步Makefile它会把所有Dockerfile中的ARG bootstrap_version以及 test.go 中bootstrap-versionflag 的默认值统一替换为最新版本号。也就是说版本号是镜像与测试运行器之间的契约——如果构建了新镜像但未更新test.go中的版本号测试仍会命中旧镜像CHANGELOG 版本 7 就因该问题被跳过。版本管理CHANGELOG 揭示的演进脉络CHANGELOG.md 记录了从 1 到 61 的每次镜像版本变更从中可以清晰地看到镜像体系的演进思路Go 版本跟随绝大多数版本变更只是跟随 Vitess 使用的 Go 工具链升级如 1.15 → 1.27.1基础镜像升级版本 20 起迁移到 Debian bullseye版本 41 迁移到 bookworm并新增 MySQL 8.4 镜像安全加固常态化移除 chromium/xvfb、consul、toxiproxy、Maven删除percona-telemetry-agentCVE-2025-22871用default-jre-headless替换完整 JDK 以减少 CVE 面版本 51/54依赖方式改进版本 30 将 bootstrap 阶段移入 common 镜像使其他 Dockerfile 不再依赖按版本区分的标签Zookeeper 改用预编译二进制并升级到 3.9.4etcd 升级到 3.6.7版本 51。常见问题与实践建议构建顺序必须先构建common再构建 flavor否则 flavor 的FROM找不到基础镜像。版本号选择本地测试建议使用与当前test.go中bootstrap-version当前默认61一致的版本号确保测试命中刚构建的镜像。网络与密钥问题flavor 构建需要访问 MySQL/Percona 官方 APT 源并导入 GPG 公钥密钥导入脚本已内置 10 次重试但网络环境受限时仍可能失败可考虑提前缓存。架构一致性build.sh强制--platformlinux/amd64在 ARM 开发机上构建时注意交叉构建与 QEMU 模拟的开销。何时需要重建只有当 bootstrap.sh、Go 模块依赖或基础工具链发生变化时才需要手动重建并推送普通 Vitess 代码变更不需要动 Bootstrap 镜像。通过本文你已经掌握了vitess/bootstrap镜像的完整生命周期理解它在bootstrap/base/lite三层镜像中的地基地位能够用build.sh或docker buildx bake构建任意 flavor并能按照维护者流程用三个make目标完成从构建、全量测试到发布的全过程。【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitess创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考