Hibernate ORM 数据库容器管理指南基于 Docker Compose 的多数据库测试基础设施【免费下载链接】hibernate-ormIdiomatic persistence for Java and relational databases项目地址: https://gitcode.com/GitHub_Trending/hi/hibernate-orm本文聚焦 Hibernate ORM 仓库中的 docker-compose/README.md 及其背后的完整容器管理实现讲解项目如何通过 Docker或 PodmanCompose 统一管理 17 种数据库的最新版与历史版本镜像、如何通过 healthcheck 保证数据库就绪、以及如何新增数据库或版本。读完本文你将掌握这套多数据库测试基础设施的目录组织、compose 文件编写规范与配套脚本 db.sh 的用法可直接复用到自己的 ORM/持久化框架测试环境中。为什么 Hibernate ORM 需要一套 DB 容器管理方案Hibernate ORM 是面向 Java 与关系数据库的持久化框架其 CI 与本地测试必须覆盖多种主流数据库——包括 PostgreSQL、MySQL、MariaDB、Oracle、SQL Server、DB2、Sybase、HANA、Informix、CockroachDB、TiDB、CUBRID、GaussDB、EDB、Spanner 以及空间数据库扩展 PostGIS 等以验证方言Dialect与 SQL 生成逻辑的兼容性。docker-compose目录即是为这套矩阵化测试提供数据库容器的统一入口。整个方案的核心原则记录在 docker-compose/README.md 中所有数据库的启动均依赖 Docker Compose同时兼容 Podman Compose目录按最新版与历史版本分层组织并配套自定义镜像构建配置每个 compose 文件必须提供 healthcheck确保数据库完全就绪后才开始执行测试。目录结构build-config / latest / versioned 三层体系docker-compose目录下分为三个子目录职责清晰目录作用实际内容docker-compose/build-config存放自定义构建镜像所需的 Dockerfile以及需要挂载进数据库容器的附加配置文件EDB 各版本的 Dockerfile、DB2 的 macOS 覆盖配置、HANA 的密码文件、Informix 的 onconfig 等docker-compose/latest各数据库最新版本的 compose 文件受 Dependabot 监控一旦上游发布新版本会自动开 PRPostgreSQL、MySQL、Oracle、DB2、Sybase、HANA、CockroachDB、TiDB、Spanner 等 17 个目录docker-compose/versioned各数据库历史版本的 compose 文件测试频率低于最新版如mysql-8.0、mariadb-10-6、oracle-18、informix-12.10等 30 个版本目录build-config为自定义镜像准备的构建资产并非所有数据库都有开箱即用的官方镜像build-config目录就是为这类场景准备的。例如 docker-compose/build-config/edb 下为 EDBEnterpriseDB 高级 PostgreSQL准备了edb14.Dockerfile到edb17.Dockerfile四个版本以及自定义的docker-entrypoint.sh入口脚本。以 edb17.Dockerfile 为例可以看到几个关键设计FROM --platformlinux/amd64 quay.io/enterprisedb/edb-postgres-advanced:17.4-3.5-postgissha256:90683b0f... USER root # 运行时该 777 权限会被替换为 700以兼容任意的 --user 值 RUN chown -R postgres:postgres /var/lib/edb chmod 777 /var/lib/edb rm /docker-entrypoint-initdb.d/10_postgis.sh USER postgres ENV PGPORT 5444 ENV PGDATA /var/lib/edb/as$PG_MAJOR/data/ VOLUME /var/lib/edb/as$PG_MAJOR/data/ COPY docker-entrypoint.sh /usr/local/bin/ ENTRYPOINT [docker-entrypoint.sh] STOPSIGNAL SIGINT EXPOSE 5444 CMD [postgres]其中STOPSIGNAL SIGINT对应 PostgreSQL 的 Fast Shutdown 模式禁止新连接、中断进行中的事务让数据库干净落盘这是避免数据损坏的折中方案Dockerfile 注释中对此有详细说明。同样在 docker-compose/build-config 下还能看到 db2 的 osx-override.yml、db2_spatial 的 ewkt.sqlDB2 空间扩展所需的坐标转换组脚本、hana 的 password.json 以及 informix 的 onconfig.mod 等挂载配置文件。latestDependabot 持续监控的最新版镜像latest目录中的 compose 文件全部使用可覆盖的环境变量默认值锁定镜像方便 CI 与本地替换。以 postgresql/docker-compose.yaml 为例services: postgres: image: ${POSTGRESQL_IMAGE:-docker.io/pgvector/pgvector:pg18sha256:2ba9ca5f...} container_name: postgres environment: POSTGRES_USER: hibernate_orm_test POSTGRES_PASSWORD: hibernate_orm_test POSTGRES_DB: hibernate_orm_test ports: - 5432:5432 tmpfs: - /var/lib/postgresql command: - postgres - -c - fsyncoff - -c - synchronous_commitoff ... healthcheck: test: [CMD-SHELL, pg_isready -U hibernate_orm_test] interval: 5s timeout: 5s retries: 10值得注意的细节镜像可覆盖${POSTGRESQL_IMAGE:-...}语法允许通过环境变量替换默认镜像这是 Dependabot 升级镜像版本的基础临时数据tmpfs将数据目录挂载到内存文件系统测试产生的数据不落盘容器销毁即清理显著加快测试数据库的启动与回收性能调优fsyncoff、synchronous_commitoff、full_page_writesoff等参数在测试场景下牺牲一部分崩溃安全换取写入性能统一凭据测试用户、密码、数据库统一使用hibernate_orm_test便于脚本与测试配置引用。MySQL 的 compose 文件latest/mysql/docker-compose.yaml则展示了字符集与大小写敏感设置command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_0900_as_cs - --log-bin-trust-function-creators1 - --lower_case_table_names2 - --innodb_native_foreign_keys healthcheck: test: [CMD, mysqladmin, ping, -u, root, -phibernate_orm_test] interval: 5s timeout: 5s retries: 12healthcheck 是硬性要求确保数据库完全就绪而非容器已启动原文档明确要求每个 compose 文件必须添加 healthcheck且 healthcheck 通过必须意味着数据库已完全就绪、可以接受请求。这背后的原因在于测试执行前必须保证连接可用——如果只是容器进程启动而数据库尚未初始化完成测试会立即失败。从上述示例可以看到三种常见实现原生工具探测PostgreSQL/EDB 使用pg_isreadyMySQL 使用mysqladmin ping直接在容器内执行客户端工具统一参数interval: 5s、timeout: 5s、retries: 10~20即每 5 秒探测一次最长等待约 50~100 秒sidecar 辅助容器当镜像内没有可用的健康检查工具时采用独立 sidecar 容器执行探测。Sidecar 方案以 Spanner 模拟器为例README 特别推荐了 spanner.yml 中应用的 sidecar 方案。Spanner 官方模拟器镜像不包含 curl 等工具因此 compose 文件引入了第二个容器专司健康检查services: spanner: image: ${SPANNER_EMULATOR:-gcr.io/cloud-spanner-emulator/emulator:1.5.57sha256:...} container_name: ${SPANNER_CONTAINER_NAME:-spanner} ports: - ${SPANNER_GRPC_PORT:-9011}:9010 - ${SPANNER_REST_PORT:-9021}:9020 spanner-healthcheck: # Sidecar: spanner emulator image has no tools, so we use UBI to run the healthcheck: image: registry.access.redhat.com/ubi9/ubi-minimal:latestsha256:... container_name: ${SPANNER_CONTAINER_NAME:-spanner}_healthcheck depends_on: spanner: condition: service_started entrypoint: [ tail, -f, /dev/null ] healthcheck: test: [ CMD-SHELL, curl -sf http://spanner:9020/v1/projects/test-project/instanceConfigs || exit 1 ] interval: 5s timeout: 5s retries: 20其核心思路是sidecar 容器基于带 curl 的轻量 UBI 镜像通过depends_on等待模拟器启动再以 HTTP REST 接口探测实例配置端点只有返回成功curl -sf才标记为 healthy。README 中的原话是If you dont have the tools required to make the healthcheck within the image, consider using the sidecar approach applied in spanner.yml——这正是镜像内缺少探测工具时的标准解法。db.sh 中的健康等待兜底逻辑healthcheck 的等待不仅依赖 compose 自身还由仓库根目录的 db.sh 脚本兜底。脚本中的compose_wait()函数会轮询容器健康状态默认最多重试 120 次、每次间隔 5 秒即最长等待 10 分钟Docker 下优先使用compose up --wait脚本会先探测该参数是否被当前 compose 版本支持podman-compose不支持时自动回退为手动轮询# 检测 --wait 支持情况podman-compose 不支持它 if $CONTAINER_CLI compose up --help 21 | grep -q -- --wait; then COMPOSE_WAIT--wait else COMPOSE_WAIT fi添加新数据库或新版本规范的完整步骤README 对如何添加新数据库或新版本给出了明确规则结合 db.sh 与目录现状完整流程如下第一步区分最新版与历史版本新数据库无论版本始终先向 docker-compose/latest 添加一个 compose 文件该目录由 Dependabot 监控上游发布新版本时会自动打开升级 PR需要保留旧版本若希望继续测试某个历史版本在 docker-compose/versioned 创建对应的版本化 compose 文件目录命名形如mysql-8.0、mariadb-11-4、oracle-18、postgis-14。也就是说latest只保留当前最新历史版本一律下沉到versioned二者通过目录名中的版本号区分部分版本还以.yml单文件形式存在如 mysql-8.4.yml、mysql-9.6.yml。第二步编写 compose 文件并遵守健康检查规范必须包含healthcheck且探测成功必须等价于数据库完全就绪优先使用镜像内自带的客户端工具pg_isready、mysqladmin等进行探测镜像内没有可用工具时按 spanner 示例 采用 sidecar 容器方案可参考 postgresql 与 mysql 的写法统一凭据hibernate_orm_test、tmpfs临时数据、ports暴露标准端口。第三步在 db.sh 中注册启动入口新版数据库仅提供 compose 文件还不够实际启动由 db.sh 驱动。脚本为每个数据库/版本定义了形如mysql_8_0()、mariadb_11_4()、oracle_18()的函数统一按先停止旧容器 →compose_up启动 → 执行*_setup初始化的流程工作且脚本末尾会列出全部可用目标供db.sh无参调用时提示。以 mysql_9_7() 为例mysql_9_7() { compose_down mysql compose_up latest/mysql/docker-compose.yaml mysql_post_setup }mysql_post_setup()中还展示了多数据库并行测试的细节脚本按 CPU 核数nprocmacOS 下为hw.physicalcpu核数 ≥16 时减半动态计算数据库数量通过docker exec批量创建hibernate_orm_test_1..N多个测试库并授权用于支撑并行测试for n in $(seq 1 $DB_COUNT) do databases(hibernate_orm_test_${n}) done类似地PostgreSQL/PostGIS/EDB 的 setup 函数还会为每个测试库安装vector、postgis扩展DB2 会创建临时表空间与租户Sybase 则通过isql执行一整套建库与授权 SQL。这些启动后初始化逻辑与 compose 文件共同构成一个数据库环境的完整生命周期。容器运行时的选择Docker 与 Podman 的自动适配虽然 README 的主题是 compose 文件管理但实际运行时由 db.sh 负责选择容器 CLI。脚本开头的检测逻辑值得了解if command -v docker /dev/null; then CONTAINER_CLI$(command -v docker) # 通过 docker version 输出判断是否为 Podman 伪装 elif command -v podman /dev/null; then CONTAINER_CLI$(command -v podman) else echo ERROR: Neither docker nor podman found on PATH exit 1 fi设计要点包括Docker 优先脚本注释说明 Docker 优先是为了让 CI 构建更稳定可预测Jenkins 对 Docker 的配置更完善Podman 兼容Podman 下健康状态检查路径不同{{.State.Healthcheck.Status}}vs{{.State.Health.Status}}需要特权命令时自动加sudomacOS 特殊处理Darwin 下 PostGIS 镜像仅支持 amd64因此强制POSTGRESQL_PLATFORMlinux/amd64DB2 在 Mac M1 上有专门的工作区脚本并自动加载各目录下的osx-override.yml覆盖文件。数据库启动的统一入口是./db.sh dbname其中dbname可以是postgresql、mysql、mysql_8_0、oracle_18、spanner、spanner_pg等脚本支持的任意目标启动时默认携带--remove-orphans清理孤儿容器若想保留旧容器可传入-k/--keep-orphans。CI 侧则由 ci/database-start.sh 读取 ci/db-params.sh 中的参数并转调db.sh完成数据库的自动拉起。小结Hibernate ORM 的docker-compose目录并非简单的容器编排文件集合而是一套面向多数据库、多版本测试矩阵的完整基础设施latest与versioned双层目录兼顾最新版本的持续跟进与历史版本的兼容验证build-config支撑 EDB 等无现成镜像的数据库强制性的 healthcheck 与 sidecar 方案保证了就绪才测试而 db.sh 则把 Docker/Podman 适配、健康等待、多库初始化等运维细节统一封装成一条命令。这套模式对任何需要做数据库兼容性测试的项目都具有直接的可复制价值。如需动手实践可依次查看 docker-compose/README.md规范说明、latest/postgresql/docker-compose.yaml标准 compose 模板、latest/spanner/docker-compose.yamlsidecar 健康检查范例与 db.sh自动化启动脚本再按上文步骤为自己的数据库新增 compose 文件与启动入口。【免费下载链接】hibernate-ormIdiomatic persistence for Java and relational databases项目地址: https://gitcode.com/GitHub_Trending/hi/hibernate-orm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hibernate ORM 数据库容器管理指南：基于 Docker Compose 的多数据库测试基础设施
Hibernate ORM 数据库容器管理指南基于 Docker Compose 的多数据库测试基础设施【免费下载链接】hibernate-ormIdiomatic persistence for Java and relational databases项目地址: https://gitcode.com/GitHub_Trending/hi/hibernate-orm本文聚焦 Hibernate ORM 仓库中的 docker-compose/README.md 及其背后的完整容器管理实现讲解项目如何通过 Docker或 PodmanCompose 统一管理 17 种数据库的最新版与历史版本镜像、如何通过 healthcheck 保证数据库就绪、以及如何新增数据库或版本。读完本文你将掌握这套多数据库测试基础设施的目录组织、compose 文件编写规范与配套脚本 db.sh 的用法可直接复用到自己的 ORM/持久化框架测试环境中。为什么 Hibernate ORM 需要一套 DB 容器管理方案Hibernate ORM 是面向 Java 与关系数据库的持久化框架其 CI 与本地测试必须覆盖多种主流数据库——包括 PostgreSQL、MySQL、MariaDB、Oracle、SQL Server、DB2、Sybase、HANA、Informix、CockroachDB、TiDB、CUBRID、GaussDB、EDB、Spanner 以及空间数据库扩展 PostGIS 等以验证方言Dialect与 SQL 生成逻辑的兼容性。docker-compose目录即是为这套矩阵化测试提供数据库容器的统一入口。整个方案的核心原则记录在 docker-compose/README.md 中所有数据库的启动均依赖 Docker Compose同时兼容 Podman Compose目录按最新版与历史版本分层组织并配套自定义镜像构建配置每个 compose 文件必须提供 healthcheck确保数据库完全就绪后才开始执行测试。目录结构build-config / latest / versioned 三层体系docker-compose目录下分为三个子目录职责清晰目录作用实际内容docker-compose/build-config存放自定义构建镜像所需的 Dockerfile以及需要挂载进数据库容器的附加配置文件EDB 各版本的 Dockerfile、DB2 的 macOS 覆盖配置、HANA 的密码文件、Informix 的 onconfig 等docker-compose/latest各数据库最新版本的 compose 文件受 Dependabot 监控一旦上游发布新版本会自动开 PRPostgreSQL、MySQL、Oracle、DB2、Sybase、HANA、CockroachDB、TiDB、Spanner 等 17 个目录docker-compose/versioned各数据库历史版本的 compose 文件测试频率低于最新版如mysql-8.0、mariadb-10-6、oracle-18、informix-12.10等 30 个版本目录build-config为自定义镜像准备的构建资产并非所有数据库都有开箱即用的官方镜像build-config目录就是为这类场景准备的。例如 docker-compose/build-config/edb 下为 EDBEnterpriseDB 高级 PostgreSQL准备了edb14.Dockerfile到edb17.Dockerfile四个版本以及自定义的docker-entrypoint.sh入口脚本。以 edb17.Dockerfile 为例可以看到几个关键设计FROM --platformlinux/amd64 quay.io/enterprisedb/edb-postgres-advanced:17.4-3.5-postgissha256:90683b0f... USER root # 运行时该 777 权限会被替换为 700以兼容任意的 --user 值 RUN chown -R postgres:postgres /var/lib/edb chmod 777 /var/lib/edb rm /docker-entrypoint-initdb.d/10_postgis.sh USER postgres ENV PGPORT 5444 ENV PGDATA /var/lib/edb/as$PG_MAJOR/data/ VOLUME /var/lib/edb/as$PG_MAJOR/data/ COPY docker-entrypoint.sh /usr/local/bin/ ENTRYPOINT [docker-entrypoint.sh] STOPSIGNAL SIGINT EXPOSE 5444 CMD [postgres]其中STOPSIGNAL SIGINT对应 PostgreSQL 的 Fast Shutdown 模式禁止新连接、中断进行中的事务让数据库干净落盘这是避免数据损坏的折中方案Dockerfile 注释中对此有详细说明。同样在 docker-compose/build-config 下还能看到 db2 的 osx-override.yml、db2_spatial 的 ewkt.sqlDB2 空间扩展所需的坐标转换组脚本、hana 的 password.json 以及 informix 的 onconfig.mod 等挂载配置文件。latestDependabot 持续监控的最新版镜像latest目录中的 compose 文件全部使用可覆盖的环境变量默认值锁定镜像方便 CI 与本地替换。以 postgresql/docker-compose.yaml 为例services: postgres: image: ${POSTGRESQL_IMAGE:-docker.io/pgvector/pgvector:pg18sha256:2ba9ca5f...} container_name: postgres environment: POSTGRES_USER: hibernate_orm_test POSTGRES_PASSWORD: hibernate_orm_test POSTGRES_DB: hibernate_orm_test ports: - 5432:5432 tmpfs: - /var/lib/postgresql command: - postgres - -c - fsyncoff - -c - synchronous_commitoff ... healthcheck: test: [CMD-SHELL, pg_isready -U hibernate_orm_test] interval: 5s timeout: 5s retries: 10值得注意的细节镜像可覆盖${POSTGRESQL_IMAGE:-...}语法允许通过环境变量替换默认镜像这是 Dependabot 升级镜像版本的基础临时数据tmpfs将数据目录挂载到内存文件系统测试产生的数据不落盘容器销毁即清理显著加快测试数据库的启动与回收性能调优fsyncoff、synchronous_commitoff、full_page_writesoff等参数在测试场景下牺牲一部分崩溃安全换取写入性能统一凭据测试用户、密码、数据库统一使用hibernate_orm_test便于脚本与测试配置引用。MySQL 的 compose 文件latest/mysql/docker-compose.yaml则展示了字符集与大小写敏感设置command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_0900_as_cs - --log-bin-trust-function-creators1 - --lower_case_table_names2 - --innodb_native_foreign_keys healthcheck: test: [CMD, mysqladmin, ping, -u, root, -phibernate_orm_test] interval: 5s timeout: 5s retries: 12healthcheck 是硬性要求确保数据库完全就绪而非容器已启动原文档明确要求每个 compose 文件必须添加 healthcheck且 healthcheck 通过必须意味着数据库已完全就绪、可以接受请求。这背后的原因在于测试执行前必须保证连接可用——如果只是容器进程启动而数据库尚未初始化完成测试会立即失败。从上述示例可以看到三种常见实现原生工具探测PostgreSQL/EDB 使用pg_isreadyMySQL 使用mysqladmin ping直接在容器内执行客户端工具统一参数interval: 5s、timeout: 5s、retries: 10~20即每 5 秒探测一次最长等待约 50~100 秒sidecar 辅助容器当镜像内没有可用的健康检查工具时采用独立 sidecar 容器执行探测。Sidecar 方案以 Spanner 模拟器为例README 特别推荐了 spanner.yml 中应用的 sidecar 方案。Spanner 官方模拟器镜像不包含 curl 等工具因此 compose 文件引入了第二个容器专司健康检查services: spanner: image: ${SPANNER_EMULATOR:-gcr.io/cloud-spanner-emulator/emulator:1.5.57sha256:...} container_name: ${SPANNER_CONTAINER_NAME:-spanner} ports: - ${SPANNER_GRPC_PORT:-9011}:9010 - ${SPANNER_REST_PORT:-9021}:9020 spanner-healthcheck: # Sidecar: spanner emulator image has no tools, so we use UBI to run the healthcheck: image: registry.access.redhat.com/ubi9/ubi-minimal:latestsha256:... container_name: ${SPANNER_CONTAINER_NAME:-spanner}_healthcheck depends_on: spanner: condition: service_started entrypoint: [ tail, -f, /dev/null ] healthcheck: test: [ CMD-SHELL, curl -sf http://spanner:9020/v1/projects/test-project/instanceConfigs || exit 1 ] interval: 5s timeout: 5s retries: 20其核心思路是sidecar 容器基于带 curl 的轻量 UBI 镜像通过depends_on等待模拟器启动再以 HTTP REST 接口探测实例配置端点只有返回成功curl -sf才标记为 healthy。README 中的原话是If you dont have the tools required to make the healthcheck within the image, consider using the sidecar approach applied in spanner.yml——这正是镜像内缺少探测工具时的标准解法。db.sh 中的健康等待兜底逻辑healthcheck 的等待不仅依赖 compose 自身还由仓库根目录的 db.sh 脚本兜底。脚本中的compose_wait()函数会轮询容器健康状态默认最多重试 120 次、每次间隔 5 秒即最长等待 10 分钟Docker 下优先使用compose up --wait脚本会先探测该参数是否被当前 compose 版本支持podman-compose不支持时自动回退为手动轮询# 检测 --wait 支持情况podman-compose 不支持它 if $CONTAINER_CLI compose up --help 21 | grep -q -- --wait; then COMPOSE_WAIT--wait else COMPOSE_WAIT fi添加新数据库或新版本规范的完整步骤README 对如何添加新数据库或新版本给出了明确规则结合 db.sh 与目录现状完整流程如下第一步区分最新版与历史版本新数据库无论版本始终先向 docker-compose/latest 添加一个 compose 文件该目录由 Dependabot 监控上游发布新版本时会自动打开升级 PR需要保留旧版本若希望继续测试某个历史版本在 docker-compose/versioned 创建对应的版本化 compose 文件目录命名形如mysql-8.0、mariadb-11-4、oracle-18、postgis-14。也就是说latest只保留当前最新历史版本一律下沉到versioned二者通过目录名中的版本号区分部分版本还以.yml单文件形式存在如 mysql-8.4.yml、mysql-9.6.yml。第二步编写 compose 文件并遵守健康检查规范必须包含healthcheck且探测成功必须等价于数据库完全就绪优先使用镜像内自带的客户端工具pg_isready、mysqladmin等进行探测镜像内没有可用工具时按 spanner 示例 采用 sidecar 容器方案可参考 postgresql 与 mysql 的写法统一凭据hibernate_orm_test、tmpfs临时数据、ports暴露标准端口。第三步在 db.sh 中注册启动入口新版数据库仅提供 compose 文件还不够实际启动由 db.sh 驱动。脚本为每个数据库/版本定义了形如mysql_8_0()、mariadb_11_4()、oracle_18()的函数统一按先停止旧容器 →compose_up启动 → 执行*_setup初始化的流程工作且脚本末尾会列出全部可用目标供db.sh无参调用时提示。以 mysql_9_7() 为例mysql_9_7() { compose_down mysql compose_up latest/mysql/docker-compose.yaml mysql_post_setup }mysql_post_setup()中还展示了多数据库并行测试的细节脚本按 CPU 核数nprocmacOS 下为hw.physicalcpu核数 ≥16 时减半动态计算数据库数量通过docker exec批量创建hibernate_orm_test_1..N多个测试库并授权用于支撑并行测试for n in $(seq 1 $DB_COUNT) do databases(hibernate_orm_test_${n}) done类似地PostgreSQL/PostGIS/EDB 的 setup 函数还会为每个测试库安装vector、postgis扩展DB2 会创建临时表空间与租户Sybase 则通过isql执行一整套建库与授权 SQL。这些启动后初始化逻辑与 compose 文件共同构成一个数据库环境的完整生命周期。容器运行时的选择Docker 与 Podman 的自动适配虽然 README 的主题是 compose 文件管理但实际运行时由 db.sh 负责选择容器 CLI。脚本开头的检测逻辑值得了解if command -v docker /dev/null; then CONTAINER_CLI$(command -v docker) # 通过 docker version 输出判断是否为 Podman 伪装 elif command -v podman /dev/null; then CONTAINER_CLI$(command -v podman) else echo ERROR: Neither docker nor podman found on PATH exit 1 fi设计要点包括Docker 优先脚本注释说明 Docker 优先是为了让 CI 构建更稳定可预测Jenkins 对 Docker 的配置更完善Podman 兼容Podman 下健康状态检查路径不同{{.State.Healthcheck.Status}}vs{{.State.Health.Status}}需要特权命令时自动加sudomacOS 特殊处理Darwin 下 PostGIS 镜像仅支持 amd64因此强制POSTGRESQL_PLATFORMlinux/amd64DB2 在 Mac M1 上有专门的工作区脚本并自动加载各目录下的osx-override.yml覆盖文件。数据库启动的统一入口是./db.sh dbname其中dbname可以是postgresql、mysql、mysql_8_0、oracle_18、spanner、spanner_pg等脚本支持的任意目标启动时默认携带--remove-orphans清理孤儿容器若想保留旧容器可传入-k/--keep-orphans。CI 侧则由 ci/database-start.sh 读取 ci/db-params.sh 中的参数并转调db.sh完成数据库的自动拉起。小结Hibernate ORM 的docker-compose目录并非简单的容器编排文件集合而是一套面向多数据库、多版本测试矩阵的完整基础设施latest与versioned双层目录兼顾最新版本的持续跟进与历史版本的兼容验证build-config支撑 EDB 等无现成镜像的数据库强制性的 healthcheck 与 sidecar 方案保证了就绪才测试而 db.sh 则把 Docker/Podman 适配、健康等待、多库初始化等运维细节统一封装成一条命令。这套模式对任何需要做数据库兼容性测试的项目都具有直接的可复制价值。如需动手实践可依次查看 docker-compose/README.md规范说明、latest/postgresql/docker-compose.yaml标准 compose 模板、latest/spanner/docker-compose.yamlsidecar 健康检查范例与 db.sh自动化启动脚本再按上文步骤为自己的数据库新增 compose 文件与启动入口。【免费下载链接】hibernate-ormIdiomatic persistence for Java and relational databases项目地址: https://gitcode.com/GitHub_Trending/hi/hibernate-orm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考