Docker PostgreSQL容器无法启动及镜像重命名删除问题
Docker PostgreSQL 启动与镜像删除问题排查
初始状态
$ docker image ls -a | grep postgres # 无条目 $ docker container ls -a | grep postgres # 无条目
拉取并启动PostgreSQL
拉取最新版镜像:
$ docker pull postgres Using default tag: latest latest: Pulling from library/postgres bd159e379b3b: Pulling fs layer ... c37cbd0077ed: Pull complete Digest: sha256:769422529210357f359e7e5620246028837f84fabe92c838ca2aef75fe2e0741 Status: Downloaded newer image for postgres:latest docker.io/library/postgres:latest
启动容器:
$ docker run -itd -e POSTGRES_USER=sebi -e POSTGRES_PASSWORD=******* -p 5432:5432 -v "C:\Work\postgres":/var/lib/postgresql/data --name postgresql postgres 41d99a1636f9b53ea45f1f90f979b59779fca0a6c42e4f12d84ca430d160b084
容器未正常运行(仅显示其他容器):
$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 92b67a93a739 dpage/pgadmin4 "/entrypoint.sh" 2 days ago Up 2 hours 443/tcp, 0.0.0.0:5051->80/tcp pgadmin-awesome-links
但容器已创建并处于退出状态:
$ docker container ls -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 41d99a1636f9 postgres "docker-entrypoint.s…" 10 minutes ago Exited (1) 10 minutes ago postgresql 92b67a93a739 dpage/pgadmin4 "/entrypoint.sh" 2 days ago Up 2 hours 443/tcp, 0.0.0.0:5051->80/tcp pgadmin-proto
疑问1:为何容器无法启动?
这是PostgreSQL官方镜像的正常启动流程,并非启动失败:
- 容器启动后先执行数据库初始化(修复目录权限、创建集群、生成配置文件等)
- 初始化过程中会临时启动数据库服务完成配置,随后主动关闭服务
- 最后重新启动数据库服务并进入稳定运行状态
你最初看到的Exited (1)是初始化流程中的临时状态,后续容器自动完成了整个初始化流程并恢复运行。
日志验证:
$ docker logs postgresql The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale "en_US.utf8". The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english". Data page checksums are disabled. fixing permissions on existing directory /var/lib/postgresql/data ... ok creating subdirectories ... ok selecting dynamic shared memory implementation ... posix selecting default max_connections ... 100 selecting default shared_buffers ... 128MB selecting default time zone ... Etc/UTC creating configuration files ... ok running bootstrap script ... ok performing post-bootstrap initialization ... ok syncing data to disk ... ok initdb: warning: enabling "trust" authentication for local connections initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb. Success. You can now start the database server using: pg_ctl -D /var/lib/postgresql/data -l logfile start waiting for server to start....2022-10-16 22:57:48.906 UTC [49] LOG: starting PostgreSQL 15.0 (Debian 15.0-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit 2022-10-16 22:57:48.939 UTC [49] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2022-10-16 22:57:49.013 UTC [52] LOG: database system was shut down at 2022-10-16 22:57:45 UTC 2022-10-16 22:57:49.076 UTC [49] LOG: database system is ready to accept connections done server started CREATE DATABASE /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/* 2022-10-16 22:57:51.065 UTC [49] LOG: received fast shutdown request waiting for server to shut down....2022-10-16 22:57:51.074 UTC [49] LOG: aborting any active transactions 2022-10-16 22:57:51.077 UTC [49] LOG: background worker "logical replication launcher" (PID 55) exited with exit code 1 2022-10-16 22:57:51.077 UTC [50] LOG: shutting down 2022-10-16 22:57:51.085 UTC [50] LOG: checkpoint starting: shutdown immediate 2022-10-16 22:57:52.003 UTC [50] LOG: checkpoint complete: wrote 918 buffers (5.6%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.326 s, sync=0.538 s, total=0.926 s; sync files=250, longest=0.006 s, average=0.003 s; distance=4217 kB, estimate=4217 kB 2022-10-16 22:57:52.106 UTC [49] LOG: database system is shut down done server stopped PostgreSQL init process complete; ready for start up. 2022-10-16 22:57:52.171 UTC [1] LOG: starting PostgreSQL 15.0 (Debian 15.0-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit 2022-10-16 22:57:52.171 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2022-10-16 22:57:52.171 UTC [1] LOG: listening on IPv6 address "::", port 5432 2022-10-16 22:57:52.179 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2022-10-16 22:57:52.203 UTC [64] LOG: database system was shut down at 2022-10-16 22:57:51 UTC 2022-10-16 22:57:52.237 UTC [1] LOG: database system is ready to accept connections 2022-10-16 23:02:52.303 UTC [62] LOG: checkpoint starting: time 2022-10-16 23:02:56.345 UTC [62] LOG: checkpoint complete: wrote 42 buffers (0.3%); 0 WAL file(s) added, 0 removed, 0 recycled; write=3.969 s, sync=0.025 s, total=4.043 s; sync files=12, longest=0.004 s, average=0.003 s; distance=241 kB, estimate=241 kB
镜像重命名与删除问题
拉取指定版本镜像:
$ docker pull postgres:14.2 14.2: Pulling from library/postgres 214ca5fb9032: Pulling fs layer ... Digest: sha256:2c954f8c5d03da58f8b82645b783b56c1135df17e650b186b296fa1bb71f9cfd Status: Downloaded newer image for postgres:14.2 docker.io/library/postgres:14.2
为镜像打新标签:
$ docker image tag 9dbc24674f25 postgres-proto/postgres:14.2
查看镜像列表:
$ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE dpage/pgadmin4 latest 94c0924749b6 3 weeks ago 366MB postgres 14.2 9dbc24674f25 5 months ago 376MB postgres-proto/postgres 14.2 9dbc24674f25 5 months ago 376MB
尝试删除镜像失败:
$ docker rmi postgres Error: No such image: postgres $ docker rmi 9dbc24674f25 Error response from daemon: conflict: unable to delete 9dbc24674f25 (must be forced) - image is referenced in multiple repositories
疑问2:为何无法删除该PostgreSQL镜像?该如何解决?
原因分析
docker rmi postgres失败:你本地没有名为postgres的镜像,只有带版本标签的postgres:14.2,直接写镜像名会默认找latest标签,而你没有这个标签的镜像。docker rmi 9dbc24674f25失败:同一个镜像ID被两个标签(postgres:14.2和postgres-proto/postgres:14.2)关联,Docker默认不允许删除有多个引用的镜像,防止误删。
解决方法
方法1:删除单个标签(保留镜像)
如果你只想移除postgres:14.2这个标签,执行:
docker rmi postgres:14.2
执行后,镜像ID9dbc24674f25依然存在,直到所有关联标签都被删除。
方法2:强制删除整个镜像
如果你想彻底删除这个镜像(不管有多少关联标签),添加-f参数强制删除:
docker rmi -f 9dbc24674f25
注意:如果有容器正在使用这个镜像,需要先停止并删除容器,再执行强制删除。
内容的提问来源于stack exchange,提问作者Sebi
相关产品推荐
相关产品推荐

