如果你用 DeepSeek、元宝AI、Copilot 等 AI 代为编写轩辕镜像的 docker pull、修改 compose 镜像地址,或排查拉取失败等问题,请让 AI 先读规则再动手,只要在 AI 对话里直接发送下面这句话即可:
生成 docker pull、修改 compose 的 image,或排查拉取失败前,请先阅读并严格遵守 https://xuanyuan.cloud/agents.md 中的规则。国内用户首推 元宝 AI、DeepSeek 的深度思考模式,不推荐豆包 AI;Cursor 等编辑器可在对话 @ 该链接,或加入 User Rules。 若 AI 无法访问外链,可 打开说明文档 复制全文粘贴。文档会随站点更新,复制内容可能过期,建议定期检查。
[!IMPORTANT] 自 2025 年 8 月起,由 PostgreSQL Docker 社区维护的官方 Postgres 镜像已停止对 Debian bullseye 的支持。作为响应,CloudNativePG 项目已完成所有 system 镜像向新的基于 bake 的构建流程的过渡。我们现在直接基于官方 Debian slim 镜像构建,完全脱离官方 Postgres 镜像。
本仓库提供维护脚本,用于为所有受支持的 PostgreSQL 主要版本生成不可变应用容器:
| 版本 | 发布日期 | EOL |
|---|---|---|
| 18 | 2025-09-25 | 2030-11-14 |
| 17 | 2024-09-26 | 2029-11-08 |
| 16 | 2023-09-14 | 2028-11-09 |
| 15 | 2022-10-13 | 2027-11-11 |
| 14 | 2021-09-30 | 2026-11-12 |
| 13 | 2020-09-24 | 2025-11-13 |
此外,PostgreSQL 19 Beta 1 仅用于测试目的。
这些镜像旨在作为 Kubernetes 环境中 CloudNativePG (CNPG) 运算符的操作数,不用于独立使用。
CloudNativePG PostgreSQL 容器镜像:
stable oldstablelinux/amd64 linux/arm64CloudNativePG PostgreSQL 容器镜像基于 Debian 项目维护和支持的官方 stable 和 oldstable Debian 版本。
stable oldstable
下表总结了相关 Debian 版本的支持生命周期,包括终止支持 (EOL) 和长期支持 (LTS) 日期:
| 名称 | 版本 | 发布日期 | EOL | LTS | 状态 |
|---|---|---|---|---|---|
| Trixie (stable) | 13 | 2025-08-09 | 2028-08-09 | 2030-06-30 | 受支持 |
| Bookworm (oldstable) | 12 | 2023-06-10 | 2026-06-10 | 2028-06-30 | 受支持 |
| Bullseye (oldoldstable) | 11 | 2021-08-14 | 2024-08-14 | 2026-08-31 | 已弃用 |
stable oldstable oldoldstable
[!IMPORTANT] CloudNativePG 项目对基于 Debian 的镜像提供全面支持,直至每个版本达到其官方终止支持 (EOL) 日期。EOL 之后至长期支持 (LTS) 开始前,已弃用版本(如 oldoldstable)的镜像将基于最佳努力原则进行维护。如果需要在 LTS 日期前终止支持,将在此页面提前至少三个月发布通知。
oldoldstable
我们目前提供并维护三种主要类型的 PostgreSQL 镜像:
minimalstandardsystemminimal 和 standard 镜像均设计为可与 Barman Cloud 等备份插件配合使用。
minimal standard
system 镜像构建于 standard 镜像之上,还包含 Barman Cloud 二进制文件。
system standard
Minimal 镜像是轻量级的,构建于官方 Debian 镜像之上。它们使用由 PostgreSQL 全球开发组 (PGDG) 维护的 APT PostgreSQL 软件包。
这些镜像通过标签名称中包含 minimal 来标识,例如:17.6-minimal-trixie。
minimal 17.6-minimal-trixie
从 PostgreSQL 18 开始,minimal 镜像将不包含 LLVM JIT 支持(由 postgresql-MM-jit 软件包提供,其中 MM 代表 PostgreSQL 主要版本)。JIT 仅在 standard 镜像中可用。
minimal postgresql-MM-jit MM standard
Standard 镜像是 minimal 镜像的扩展,增加了以下附加功能:
minimal
minimalpostgresql-MM-jitStandard 镜像可通过名称中的 standard 标签来识别,例如:17.6-standard-trixie。
standard 17.6-standard-trixie
Standard 镜像设计为在与 CloudNativePG 一起使用时提供与旧版 system 镜像等效的功能。要实现功能对等,您必须使用 Barman Cloud 插件来替代 system 镜像中的原生 Barman Cloud 支持。
system system
从 2025 年 9 月开始,system 镜像基于 standard 镜像构建,并包含 Barman Cloud 二进制文件。
standard
[!IMPORTANT] system 镜像已弃用,一旦 CloudNativePG 中对 Barman Cloud 的内核支持逐步淘汰,这些镜像将被移除。只要内核 Barman Cloud 仍然可用,您仍可以使用它们,但应计划迁移到 minimal 或 standard 镜像并配合 Barman Cloud 插件,或采用其他受支持的备份解决方案。
systemminimalstandard
每个镜像通过其摘要和以下格式的主标签进行标识:
MM.mm-TS-TYPE-OS
其中:
MM 16mm 10TS 202509090953TYPE minimalOS trixie例如:16.10-202509090953-minimal-trixie。
16.10-202509090953-minimal-trixie
除了完全限定标签外,还提供以下格式的滚动标签:
出于历史原因,system镜像还包含两个额外的滚动标签:
system镜像。MM.mm``system``16.10``bullseyesystem镜像。MM``system``16``bullseye[!IMPORTANT] 这些标签已弃用,将在bullseye镜像达到生命周期结束时移除。请迁移到明确包含镜像类型和发行版版本的受支持标签格式之一(例如16.10-minimal-trixie)。
bullseye``16.10-minimal-trixie
自2025年9月起,系统镜像基于标准镜像构建,并包含Barman Cloud二进制文件。
[!IMPORTANT] 系统镜像已弃用,一旦CloudNativePG中对Barman Cloud的内置支持逐步淘汰,系统镜像将被移除。尽管只要内置Barman Cloud支持仍然可用,您仍可使用系统镜像,但您应计划迁移至搭配Barman Cloud插件的最小化或标准镜像,或采用其他受支持的备份解决方案。
MM.mm:特定PostgreSQL 次要 版本的最新system镜像(例如16.10),基于Debian bullseye。MM:特定PostgreSQL 主要 版本的最新system镜像(例如16),基于Debian bullseye。[!IMPORTANT] 这些标签已弃用,并将在
bullseye镜像终止支持时移除。请迁移至明确包含镜像类型和发行版版本的受支持标签格式(例如16.10-minimal-trixie)。
CloudNativePG在https://github.com/cloudnative-pg/artifacts/tree/main/image-catalogs%E4%B8%AD%E5%8F%91%E5%B8%83CloudNativePG%E7%9A%84%60ClusterImageCatalog%60%E6%B8%85%E5%8D%95%EF%BC%8C%E6%AF%8F%E4%B8%AA%E5%8F%97%E6%94%AF%E6%8C%81%E7%9A%84%E9%95%9C%E5%83%8F%E7%B1%BB%E5%9E%8B%E5%92%8C%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E7%89%88%E6%9C%AC%E7%BB%84%E5%90%88%E5%AF%B9%E5%BA%94%E4%B8%80%E4%B8%AA%E7%9B%AE%E5%BD%95%E3%80%82
[!IMPORTANT] 如果您仍在依赖旧版
ClusterImageCatalog-bullseye.yaml和ClusterImageCatalog-bookworm.yaml清单,请尽快迁移至新目录。这些旧版清单已弃用,并将随system镜像一同移除。
CNPG PostgreSQL容器镜像构建时包含以下证明,以确保透明度和可追溯性:
软件物料清单(SBOM):镜像中包含或构建过程中使用的软件制品的完整列表,采用https://github.com/in-toto/attestation/blob/main/spec/predicates/spdx.md%E6%A0%BC%E5%BC%8F%E5%8C%96%E3%80%82
来源证明:遵循SLSA Provenance框架,详细说明镜像构建过程的元数据。
例如,要获取特定平台(如linux/amd64)的多架构镜像的SBOM,可使用以下命令:
docker buildx imagetools inspect \
--format '{{ json (index .SBOM "linux/amd64").SPDX }}'
此命令以JSON格式输出SBOM,提供软件组件和构建依赖项的详细视图。
minimal和standard CloudNativePG容器镜像使用Sigstore生态系统中的工具https://github.com/sigstore/cosign%E8%BF%9B%E8%A1%8C%E5%AE%89%E5%85%A8%E7%AD%BE%E5%90%8D%E3%80%82%E7%AD%BE%E5%90%8D%E8%BF%87%E7%A8%8B%E9%80%9A%E8%BF%87GitHub Actions自动化,并利用https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect%E3%80%82
令牌颁发者为https://token.actions.githubusercontent.com,签名身份对应在cloudnative-pg/postgres-containers仓库下执行的GitHub工作流。此工作流使用https://github.com/marketplace/actions/cosign-installer%E6%9D%A5%E7%AE%80%E5%8C%96%E7%AD%BE%E5%90%8D%E8%BF%87%E7%A8%8B%E3%80%82
要使用镜像摘要验证其真实性,可运行以下cosign命令:
cosign verify IMAGE \
--certificate-identity-regexp="^https://github.com/cloudnative-pg/postgres-containers/" \
--certificate-oidc-issuer="https://token.actions.githubusercontent.com"
为进一步加强容器镜像的安全性,我们在CI/CD工作流中执行自动化镜像扫描。这些扫描有助于确保镜像在发布或部署前符合最佳实践,且不含已知漏洞:
有关构建PostgreSQL容器镜像的详细说明,请参阅BUILD.md文件。
https://github.com/renovatebot/renovate%E5%8F%AF%E7%94%A8%E4%BA%8E%E8%87%AA%E5%8A%A8%E6%9B%B4%E6%96%B0%E5%90%84%E7%A7%8D%E4%BE%9D%E8%B5%96%E9%A1%B9%E3%80%82%E7%94%B1%E4%BA%8ECloudNativePG%E7%9A%84%60Cluster%60 CRD不会被Renovate自动识别,必须配置自定义正则表达式管理器。以下示例使用JSON5;将其保存为renovate.json5,或转换键/注释以用于renovate.json:
{
customManagers: [
{
// CloudNativePG Cluster imageName
customType: 'regex',
managerFilePatterns: [
'/\\.yaml$/',
],
matchStrings: [
'imageName: (? [^\\s:]+):(? [^\\s@]+)(?:@(? sha256:[a-f0-9]{64}))?',
],
datasourceTemplate: 'docker',
// matches: 17.6-202509151215-minimal-trixie
versioningTemplate: 'regex:^(? \\d+)\\.(? \\d+)-(? \\d+)-(? \\S+)
Renovate永远不会更改标签的`compatibility`部分(镜像类型和Debian基础,例如`system-bookworm`),因此升级会保持在相同的操作系统和glibc/ICU版本。由于PostgreSQL区域数据影响,切换到不同的基础(例如从`bookworm`到`trixie`)是手动操作。PostgreSQL主要版本更新通过依赖项仪表板进行路由,以便人工规划和应用。为保持引用完全可重现,您还可以为CloudNativePG镜像启用`pinDigests`。如果您的仓库包含其他YAML清单,请将`managerFilePatterns`限制到存放`Cluster`资源的目录,例如`'/clusters/.*\\.yaml$/'`。
## 许可和版权
本软件基于Apache License 2.0许可。
版权所有 © CloudNativePG贡献者,CloudNativePG为LF Projects, LLC的系列项目。
Barman Cloud由EnterpriseDB根据https://github.com/EnterpriseDB/barman/blob/master/LICENSE分发。
PGAudit根据https://github.com/pgaudit/pgaudit/blob/master/LICENSE分发。
Postgres Failover Slots由EnterpriseDB根据https://github.com/EnterpriseDB/pg_failover_slots/blob/master/LICENSE分发。
pgvector根据https://github.com/pgvector/pgvector/blob/master/LICENSE分发。
## 商标
*Postgres、PostgreSQL和Slonik徽标是加拿大PostgreSQL社区协会的商标或注册商标,经其许可使用。*,
autoReplaceStringTemplate: 'imageName: {{{depName}}}:{{{newValue}}}{{#if newDigest}}@{{{newDigest}}}{{/if}}',
}
],
packageRules: [
{
matchPackageNames: ['ghcr.io/cloudnative-pg/postgresql'],
matchUpdateTypes: ['major'],
dependencyDashboardApproval: true,
}
]
}
Renovate永远不会更改标签的__CODE_TOKEN_87__部分(镜像类型和Debian基础,例如__CODE_TOKEN_88__),因此升级会保持在相同的操作系统和glibc/ICU版本。由于PostgreSQL区域数据影响,切换到不同的基础(例如从__CODE_TOKEN_89__到__CODE_TOKEN_90__)是手动操作。PostgreSQL主要版本更新通过依赖项仪表板进行路由,以便人工规划和应用。为保持引用完全可重现,您还可以为CloudNativePG镜像启用__CODE_TOKEN_91__。如果您的仓库包含其他YAML清单,请将__CODE_TOKEN_92__限制到存放__CODE_TOKEN_93__资源的目录,例如__CODE_TOKEN_94__。
本软件基于Apache License 2.0许可。
版权所有 © CloudNativePG贡献者,CloudNativePG为LF Projects, LLC的系列项目。
Barman Cloud由EnterpriseDB根据https://github.com/EnterpriseDB/barman/blob/master/LICENSE%E5%88%86%E5%8F%91%E3%80%82
PGAudit根据https://github.com/pgaudit/pgaudit/blob/master/LICENSE%E5%88%86%E5%8F%91%E3%80%82
Postgres Failover Slots由EnterpriseDB根据https://github.com/EnterpriseDB/pg_failover_slots/blob/master/LICENSE%E5%88%86%E5%8F%91%E3%80%82
pgvector根据https://github.com/pgvector/pgvector/blob/master/LICENSE%E5%88%86%E5%8F%91%E3%80%82
Postgres、PostgreSQL和Slonik徽标是加拿大PostgreSQL社区协会的商标或注册商标,经其许可使用。
探索更多轩辕镜像的使用方法,找到最适合您系统的配置方式
通过 Docker 登录认证访问私有仓库
发给 Cursor、ChatGPT、豆包等 AI 的说明文档
无需登录使用专属域名
Kubernetes 集群配置 Containerd
K3s 轻量级 Kubernetes 镜像加速
VS Code Dev Containers 配置
Podman 容器引擎配置
HPC 科学计算容器配置
ghcr、Quay、nvcr 等镜像仓库
Harbor Proxy Repository 对接专属域名
Portainer Registries 加速拉取
Nexus3 Docker Proxy 内网缓存
需要其他帮助?请查看我们的 常见问题Docker 镜像访问常见问题解答 或 提交工单
docker search 限制
站内搜不到镜像
原仓库同步与拉取
离线 save/load
插件要用 plugin install
WSL 拉取慢
安全与 digest
新手拉取配置
镜像合规机制
不支持 push
manifest unknown
no matching manifest(架构)
invalid tar header(解压)
Schema 1 已废弃
406 OCI index
422 Unknown
400 TAG_INVALID
TLS 证书失败
DNS 超时
域名连通性排查
410 Gone 排查
402 与流量用尽
401 认证失败
429 限流
D-Bus 凭证提示
413 与超大单层
来自真实用户的反馈,见证轩辕镜像的优质服务