Kylin V11 实战：PostgreSQL 18 容器化部署，别再被参数坑了
在信创环境中部署 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:182
验证镜像
下载完成后，通过 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 456MB03
存储准备 (Storage Prep)
为了防止容器删除后数据丢失，我们需要在宿主机上创建持久化目录。
由于 Kylin V11 通常默认开启 SELinux，目录的创建位置和后续的挂载标签（:Z）尤为重要。
[root@pg-prod-db01 ~]# mkdir -p /root/postgresql/data04
容器启动与排错 (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，说明后台启动成功。
3e56b64df92e675a960a1bf7012631646f5827fc48ef0bf32a20723324bae63505
环境验证与验收 (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