在信创环境中部署 PostgreSQL，很多人以为只要 “系统能装 Docker，一切就和CentOS 一样”。

但真正动手后，问题往往来得非常快：命令明明没写错，却提示 unknown flag容器能起，数据却写不进去教程照着敲，在国产系统上却频频翻车。

这并不是 PostgreSQL 的问题，也不完全是 Docker 的锅，而是国产操作系统 + 容器工具链差异叠加后，暴露出的那些“平时不显眼、上线就致命”的细节。

本文基于 银河麒麟 Kylin V11 的真实部署过程，记录 PostgreSQL 18 容器化落地时遇到的关键问题，尤其是 Docker 与 Podman 参数差异、SELinux 挂载限制 这两个高频雷区。

如果你希望在国产环境中一次性跑通、可复用、可交付 PostgreSQL 容器部署，这篇实战笔记，值得你完整看完。

01

背景与环境

随着信创产业的发展，银河麒麟 (Kylin V11) 已成为国产化替代的主流操作系统之一。

作为一款基于 Linux 内核（通常兼容RHEL/CentOS 体系）的系统，它对 Docker 容器技术有着良好的支持。

本文将记录如何在 Kylin V11 环境下，使用Docker 快速部署最新的 PostgreSQL 18 数据库，并重点复盘在实验过程中遇到的 Docker 与 Podman 参数差异问题。

• 操作系统

Kylin V11

• 容器引擎

Docker CE

• 数据库镜像

PostgreSQL 18 (通过镜像加速器拉取)

02

镜像获取 (Image Pull)

由于 Docker Hub 官方源在网络上的不确定性，本次实验使用了镜像加速地址 docker.1ms.run 进行拉取。

1

拉取镜像

执行拉取命令，可以看到分层下载的过程非常顺畅：

[root@pg-prod-db01 ~]# docker pull docker.1ms.run/postgres:18
18: Pulling from postgres
119d43eec815: Pull complete 
e086e98b1962: Pull complete 
d3b2038f0307: Pull complete 
ade980a94d87: Pull complete 
dcc21a450f56: Pull complete 
617e7a31540f: Pull complete 
7029853d8f47: Pull complete 
05c02d5e0a60: Pull complete 
2cb1625cf212: Pull complete 
97457a8dcb7d: Pull complete 
b5e23963a3cd: Pull complete 
c1bb9e333b95: Pull complete 
fdfe2104fb23: Pull complete 
Digest: sha256:5773fe724c49c42a7a9ca70202e11e1dff21fb7235b335a73f39297d200b73a2
Status: Downloaded newer image for docker.1ms.run/postgres:18
docker.1ms.run/postgres:18

2

验证镜像

下载完成后，通过 docker images 确认镜像已正确落地，镜像 ID 为 019965b81888，大小约为 456MB。

[root@pg-prod-db01 ~]# docker images
REPOSITORY                TAG       IMAGE ID       CREATED      SIZE
docker.1ms.run/postgres   18        019965b81888   8 days ago   456MB

03

存储准备 (Storage Prep)

为了防止容器删除后数据丢失，我们需要在宿主机上创建持久化目录。

由于 Kylin V11 通常默认开启 SELinux，目录的创建位置和后续的挂载标签（:Z）尤为重要。

[root@pg-prod-db01 ~]# mkdir -p /root/postgresql/data

04

容器启动与排错 (Deploy &

Troubleshooting)

在启动环节，我们遇到了一个典型的参数兼容性问题，这是从 RHEL/Podman 环境迁移到标准 Docker 环境时常见的“坑”。

1

首次尝试（失败：参数不兼容）

最初我们尝试使用带有 --replace 参数的命令，该参数在 Podman 中用于自动替换同名容器。

执行命令：

docker run -d \
  --name pg18 \
  --replace \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=123456 \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_DB=testdb \
  -v /root/postgresql/data:/var/lib/postgresql:Z \
  docker.1ms.run/postgres:18

报错信息

unknown flag: --replace
See 'docker run --help'.

问题分析

--replace 是 Podman 的特有参数。在 Kylin V11 上安装的标准 Docker CE 无法识别此参数。

在 Docker 中，如果容器名冲突，必须先手动 rm。

2

修正后再次尝试（成功）

去掉 --replace 参数后，再次执行命令。

特别注意保留了 :Z 参数，这对 Kylin V11 的 SELinux 权限放行至关重要。

修正后的命令：

[root@pg-prod-db01 ~]# docker run -d \
  --name pg18 \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=123456 \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_DB=testdb \
  -v /root/postgresql/data:/var/lib/postgresql:Z \
  docker.1ms.run/postgres:18

执行结果

返回了一串容器 ID，说明后台启动成功。

3e56b64df92e675a960a1bf7012631646f5827fc48ef0bf32a20723324bae635

05

环境验证与验收 (Verification)

容器启动后，我们需要确认数据库进程是否稳定，以及版本是否正确。

1

进程状态检查

使用 docker ps 查看容器状态。

[root@pg-prod-db01 ~]# docker ps
CONTAINER ID   IMAGE                        COMMAND                  CREATED          STATUS          PORTS                                       NAMES
3e56b64df92e   docker.1ms.run/postgres:18   "docker-entrypoint.s…"   31 seconds ago   Up 24 seconds   0.0.0.0:5432->5432/tcp, :::5432->5432/tcp   pg18

关键指标解读

• STATUS: Up 24 seconds。状态正常，未出现 Restarting 或 Exited。

• PORTS: 0.0.0.0:5432->5432/tcp。

说明 IPv4 和 IPv6 的 5432 端口均已正确映射，外部可连接。

2

数据库内部连接测试

我们使用 docker exec 直接进入容器内部，使用自带的 psql 客户端连接刚创建的 testdb 数据库。

执行命令：

docker exec -it -u postgres pg18 psql -d testdb

输出验证：

psql (18.1 (Debian 18.1-1.pgdg13+2))
Type "help" for help.

testdb=# \l

验收结论

• 版本确认

输出显示 psql (18.1 ...)，证明 PostgreSQL 18.1 已成功运行。

• 业务库就绪

提示符为 testdb=#，说明初始化参数 -e POSTGRES_DB=testdb 生效。

• 权限正常

能够执行 \l 查看数据库列表，说明 postgres 超级用户权限正常。

写在最后

在国产操作系统上跑 PostgreSQL，真正的难点，从来不是数据库版本够不够新。

而是你是否清楚：

• 你用的是 Docker，还是 Podman？

• SELinux 是否在悄悄拦截你的数据目录？

• 教程里的参数，是否真的适配当前环境？

本次在银河麒麟 Kylin V11 下的实践再次印证了一点：容器化降低了部署门槛，但并没有消灭系统差异。

尤其是在信创环境中，每一个“看似无关紧要”的参数，都可能成为上线时的阻断点。

好消息是，只要认清工具边界、尊重系统安全机制，PostgreSQL 18 在国产操作系统上的运行，完全可以做到稳定、持久、可复用。

当你把这些坑提前踩完，剩下的，就只是一次标准、健康的数据库交付流程了。

原文链接：https://mp.weixin.qq.com/s/oDoloejpUBw-AaZydhycgg