Docker 常见仓库与镜像使用指南（2026 实战版）

前阵子带一个新人让他用 Docker 起个 MySQL他从某篇博客抄了条命令docker run --name some-mysql --link some-app:app -d mysql跑不通来问我。我一看就知道这教程是七八年前的——--link 这个参数 Docker 官方早就标记废弃了现在推荐用自定义网络。更离谱的是那篇教程里 MySQL 还是 5.6、Node.js 还是 0.10这些版本现在连安全更新都没有了。网上关于 Docker 镜像的教程有个通病抄来抄去越抄越老。很多内容的源头是同一篇十年前的文章命令和版本号一路被复制粘贴到今天早就跟现实脱节了。这篇我按 2026 年的实际情况重新整理一遍覆盖镜像命名规则怎么看懂、基础镜像怎么选、常用中间件MySQL/Redis/MongoDB/Nginx/PostgreSQL的现代正确用法、语言运行时镜像、以及镜像瘦身和版本锁定。所有命令都在 Docker 24 / Compose v2 上实测过。先搞懂镜像名字的结构很多人用了一年 Docker 也说不清 registry/namespace/repository:tag 到底每段是啥。拆开看docker.io/library/mysql:8.4 │ │ │ │ │ │ │ └─ tag版本标签 │ │ └─────── repository镜像名 │ └─────────────── namespace命名空间/组织 └───────────────────────── registry仓库地址几个省略规则docker pull mysql 实际等于 docker pull docker.io/library/mysql:latestDocker Hub 官方镜像的 namespace 是 library可以省略所以 mysql、nginx、redis 这些都是官方镜像第三方镜像必须带 namespace比如 bitnami/redis、grafana/grafanatag 不写默认是 latest——这是个坑后面单独讲官方镜像 vs 第三方镜像怎么分辨类型例子特点Docker Official Imagemysql、nginx、redisDocker Hub 页面有蓝色 ✔ 认证标Docker 官方团队维护安全和更新有保障Verified Publisherbitnami/redis、hashicorp/consul厂商官方发布有认证标普通第三方someuser/mysql任何人可上传质量参差生产环境慎用优先用 Docker Official Image。在 Docker Hub 搜索时勾选 Docker Official Image 过滤器能过滤掉一堆来路不明的镜像。第三方镜像不是不能用比如 Bitnami 的镜像封装得很规范但要先看清楚维护者和更新频率。基础系统镜像选型自己写 Dockerfile 时FROM 后面选什么基础镜像直接决定了最终镜像的体积和安全性。主流选择基础镜像体积适用场景注意ubuntu:24.04~78MB需要完整 Linux 环境、glibc 依赖多体积偏大debian:12-slim~74MB通用比 ubuntu 稍精简平衡之选alpine:3.20~8MB追求极小体积用 musl libc某些依赖 glibc 的程序会有兼容问题distroless~2MB生产环境、安全优先没有 shell调试困难scratch0静态编译的单文件程序Go/Rust什么都没有需自带一切Alpine 的坑体积小是真香但它用的是 musl libc 而不是 glibc。一些依赖 glibc 特性的程序比如某些版本的 Oracle JDK、需要特定 DNS 解析行为的程序在 Alpine 上会出诡异问题。Java 项目建议用基于 Debian 的 eclipse-temurin 而不是 alpine 版。# Ubuntu 起个交互环境 docker run --rm -it ubuntu:24.04 bash # Alpine进去后用 sh默认没有 bash docker run --rm -it alpine:3.20 shCentOS 特别说明CentOS 8 已经在 2021 年底 EOLcentos:7 也在 2024 年 6 月停止维护。现在别再用 CentOS 镜像了社区替代品是Rocky Linux或AlmaLinuxrockylinux:9、almalinux:9或者直接用 Debian/Ubuntu。老教程里那些 centos:5、centos:6 更是彻底不能碰。常用中间件镜像实战下面每个中间件我都给现代正确姿势——自定义网络 命名卷持久化 健康检查 非 root而不是老教程那种一条 docker run 裸奔。先创建网络容器之间通信用自定义网络别再用 --linkdocker network create app-net自定义网络的好处容器之间可以直接用容器名当主机名互相访问内置 DNS 解析而且网络隔离只有同一网络的容器能互通。MySQLdocker run -d \ --name mysql \ --network app-net \ -e MYSQL_ROOT_PASSWORDChangeMe_2026 \ -e MYSQL_DATABASEapp \ -e MYSQL_USERapp \ -e MYSQL_PASSWORDAppPw_2026 \ -e TZAsia/Shanghai \ -v mysql_data:/var/lib/mysql \ -p 3306:3306 \ --health-cmdmysqladmin ping -h localhost -uroot -pChangeMe_2026 \ --health-interval10s \ --health-timeout5s \ --health-retries10 \ mysql:8.4关键点-v mysql_data:/var/lib/mysql必须挂命名卷否则容器删了数据就没了。MySQL 数据目录在 /var/lib/mysqlTZAsia/Shanghai不设时区容器内默认 UTC日志时间差 8 小时mysql:8.4 是当前 LTS 版本别再用 mysql:5.7已 EOL连接测试docker run -it --rm --network app-net mysql:8.4 \ mysql -hmysql -uapp -pAppPw_2026 app注意这里 -hmysql 直接用容器名因为两个容器在同一个 app-net 网络里DNS 能解析。这就是取代 --link 的现代写法。PostgreSQLdocker run -d \ --name postgres \ --network app-net \ -e POSTGRES_PASSWORDChangeMe_2026 \ -e POSTGRES_DBapp \ -e TZAsia/Shanghai \ -v pg_data:/var/lib/postgresql/data \ -p 5432:5432 \ --health-cmdpg_isready -U postgres \ --health-interval10s \ --health-retries5 \ postgres:16PostgreSQL 的数据目录是 /var/lib/postgresql/data别忘了挂卷。Redisdocker run -d \ --name redis \ --network app-net \ -v redis_data:/data \ -p 6379:6379 \ --health-cmdredis-cli ping \ --health-interval10s \ --health-retries5 \ redis:7.4 redis-server --appendonly yes --requirepass ChangeMe_2026关键点--appendonly yes开启 AOF 持久化默认 Redis 重启数据会丢--requirepass设密码。老教程里 Redis 裸奔不设密码是勒索病毒的头号目标生产环境一定要设密码 不暴露公网端口-v redis_data:/dataRedis 数据目录是 /data连接docker run -it --rm --network app-net redis:7.4 \ redis-cli -h redis -a ChangeMe_2026MongoDBdocker run -d \ --name mongo \ --network app-net \ -e MONGO_INITDB_ROOT_USERNAMEadmin \ -e MONGO_INITDB_ROOT_PASSWORDChangeMe_2026 \ -v mongo_data:/data/db \ -p 27017:27017 \ mongo:8.0MongoDB 数据目录 /data/db。老教程里的 mongo:2.6、mongo:2.7 现在完全不能用了当前稳定版是 8.0。新版客户端命令也从 mongo 改成了 mongoshdocker run -it --rm --network app-net mongo:8.0 \ mongosh mongodb://admin:ChangeMe_2026mongo:27017Nginxdocker run -d \ --name nginx \ --network app-net \ -v ./nginx.conf:/etc/nginx/nginx.conf:ro \ -v ./html:/usr/share/nginx/html:ro \ -v ./logs:/var/log/nginx \ -p 80:80 \ -p 443:443 \ nginx:1.27-alpine挂载说明配置文件 :ro 只读挂载防止容器内进程改宿主机文件静态页面目录 /usr/share/nginx/html日志目录 /var/log/nginx挂出来方便查看自定义配置里如果要反向代理到别的容器upstream 直接写容器名server { listen 80; location / { proxy_pass http://app:3000; # app 是同网络里另一个容器的名字 } }nginx:1.27-alpine 用的是 alpine 版体积只有 ~20MBNginx 不涉及 glibc 兼容问题用 alpine 很合适。语言运行时镜像Node.js# 用 LTS 版本2026 年当前 LTS 是 22.x FROM node:22-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --onlyproduction # ci 比 install 更适合生产严格按 lock 文件装 COPY . . EXPOSE 3000 # 用 node 用户跑别用 root USER node CMD [node, server.js]老教程里的 node:0.10-onbuild 早就没了-onbuild 这种变体现在也不推荐用隐式行为太多不好排查。当前 Node LTS 是 22.x选 node:22-alpine 或 node:22-slim。PythonFROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, app.py]--no-cache-dir 不缓存 pip 下载包能减小镜像体积。Python 官方镜像的 slim 版基于 Debian比完整版小一半。JavaEclipse TemurinFROM eclipse-temurin:17-jre-alpine # 或者用 debian 版避免 musl 兼容问题eclipse-temurin:17-jre-jammy WORKDIR /app COPY target/app.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]Java 别再用 openjdk 官方镜像了——它在 Docker Hub 上已经标记 deprecated官方推荐迁移到Eclipse Temurineclipse-temurin、Amazon Correttoamazoncorretto或 Azul Zuluazul/zulu。生产环境用 -jre 变体只含运行时比 -jdk 小 200MB。tag 策略别再无脑用 latestlatest 是个误导性极强的标签两个坑它不保证是最新版——latest 只是镜像维护者手动打的一个 tag可能很久没更新也可能指向某个具体版本完全看维护者心情不可复现——你今天 pull nginx:latest 拿到 1.27下周可能变成 1.28配置不兼容就直接炸正确做法生产环境锁定具体版本号mysql:8.4.2 而不是 mysql:8 或 mysql:latest想跟大版本可以用 mysql:8.4minor 版本但要在 CI 里定期测试追求绝对确定性用digestmysqlsha256:abc123...digest 是内容哈希永远不变# 查看某个 tag 对应的 digest docker inspect --format{{index .RepoDigests 0}} mysql:8.4 # 用 digest 拉取内容锁定 docker pull mysqlsha256:xxxxxxxxxxxx镜像瘦身多阶段构建编译型语言Go/Rust/Java/前端镜像容易臃肿因为构建工具链占大头。多阶段构建能把构建环境和运行环境分离# ---- 构建阶段 ---- FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline -B # 单独一层利用缓存 COPY src ./src RUN mvn package -DskipTests -B # ---- 运行阶段 ---- FROM eclipse-temurin:17-jre-alpine WORKDIR /app COPY --frombuilder /build/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]最终镜像只包含运行阶段的内容Maven 和源码都不在里面。一个 Spring Boot 应用用这种方式能从 ~800MB 压到 ~200MB。前端项目同理# 构建阶段用 node FROM node:22-alpine AS builder WORKDIR /build COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # 运行阶段用 nginx 托管静态文件 FROM nginx:1.27-alpine COPY --frombuilder /build/dist /usr/share/nginx/html EXPOSE 80最终镜像就是个 nginx 静态文件node 和 node_modules 全部丢弃体积从几百 MB 降到 ~25MB。Docker Hub 拉取限制2026 年绕不开的现实Docker Hub 对匿名用户有拉取频率限制大概每 6 小时 100 次登录用户 200 次CI 环境或者团队多人共用一个出口 IP 时很容易触发 toomanyrequests 错误。三个应对办法配置国内镜像加速器这块我上一篇专门写过配置 /etc/docker/daemon.json 的 registry-mirrors搭私有 Registry 或用 Harbor公司内部把常用镜像 pull 下来推到自建 Harbor团队从内网拉又快又不受限制付费 Docker Hub 账号Pro/Team 计划有更高限额企业环境推荐第 2 种。Harbor 还能做镜像扫描Trivy、访问控制、镜像签名比裸用 Docker Hub 安全得多。把它们串起来一份完整的 Compose 编排前面每个中间件都是单独 docker run实际项目里会用 Compose 统一管理。下面这份把 Nginx 应用 MySQL Redis 串起来是前面所有知识点的整合可以直接改改用# compose.yml Compose v2不需要 version 字段 services: nginx: image: nginx:1.27-alpine container_name: nginx ports: - 80:80 - 443:443 volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro - ./nginx/html:/usr/share/nginx/html:ro depends_on: - app restart: unless-stopped networks: [frontend, backend] app: image: registry.company.com/team/myapp:1.4.2 # 从私有仓库拉锁定版本号 container_name: app environment: DB_HOST: mysql REDIS_HOST: redis TZ: Asia/Shanghai depends_on: mysql: condition: service_healthy # 等 MySQL 真正就绪不是只等启动 redis: condition: service_healthy restart: unless-stopped networks: [backend] mysql: image: mysql:8.4 container_name: mysql environment: MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD} MYSQL_DATABASE: app MYSQL_USER: ${DB_USER} MYSQL_PASSWORD: ${DB_PASSWORD} TZ: Asia/Shanghai volumes: - mysql_data:/var/lib/mysql healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -uroot, -p${DB_ROOT_PASSWORD}] interval: 10s timeout: 5s retries: 10 start_period: 30s restart: unless-stopped networks: [backend] redis: image: redis:7.4-alpine container_name: redis command: [redis-server, --appendonly, yes, --requirepass, ${REDIS_PASSWORD}] volumes: - redis_data:/data healthcheck: test: [CMD, redis-cli, -a, ${REDIS_PASSWORD}, ping] interval: 10s timeout: 5s retries: 5 restart: unless-stopped networks: [backend] volumes: mysql_data: redis_data: networks: frontend: backend: internal: true # 后端网络不通外网MySQL/Redis 不暴露公网配套 .env不提交到 GitDB_ROOT_PASSWORDChangeMe_Root_2026 DB_USERapp DB_PASSWORDChangeMe_App_2026 REDIS_PASSWORDChangeMe_Redis_2026这份编排里几个设计值得单独说两个网络隔离frontend 让 Nginx 对外backend 设 internal: trueMySQL 和 Redis 只在内网宿主机端口根本不暴露安全性直接拉满condition: service_healthy应用容器等 MySQL 健康检查通过才启动避免数据库还没初始化完应用就连过去报 Connection refused镜像地址走私有仓库 锁版本号registry.company.com/team/myapp:1.4.2可复现、可回滚启动docker compose up -d # 后台启动全部 docker compose ps # 看状态 docker compose logs -f app # 看某个服务日志 docker compose down # 停止保留数据卷私有镜像仓库团队怎么分发镜像自己构建的镜像要分发给团队不可能都从 Docker Hub 走也不该把公司代码推到公网。常见方案方案适用特点Docker Registry个人/小团队官方开源最轻量docker run -d -p 5000:5000 registry:2 就能起Harbor中大型企业带 Web UI、权限管理、镜像扫描Trivy、复制、签名功能全云厂商 ACR上云的团队阿里云/腾讯云容器镜像服务免运维跟云生态集成好推送流程以 Harbor 为例docker login registry.company.com # 登录 docker tag myapp:1.4.2 registry.company.com/team/myapp:1.4.2 # 打仓库前缀 docker push registry.company.com/team/myapp:1.4.2 # 推送Harbor 相比裸 Registry 最大的价值是镜像安全扫描——推上去自动用 Trivy 扫一遍 CVE 漏洞有问题直接拦住不让部署这在有安全合规要求的团队里基本是刚需。常见坑速查容器一启动就退出多半是主进程跑完就退了。Docker 容器生命周期绑定前台进程CMD 里跑的服务必须在前台比如 nginx 要 daemon off;很多服务有 --foreground 参数。用 docker logs 容器名 看退出原因。数据改了重启就丢没挂卷。写进容器可写层的数据在容器删除后就没了重要数据必须挂 volume 或 bind mount。端口冲突 port is already allocated宿主机端口被占了netstat -tlnp | grep 端口 或 docker ps 看谁占的。容器之间 ping 不通不在同一个网络。老教程用 --link现在用 docker network create --network 把它们放一起然后用容器名互访。镜像越拉越多占满磁盘docker system df 看占用docker system prune -a 清理无用镜像和停止的容器注意 -a 会删所有未被使用的镜像确认后再执行。拉取报 toomanyrequestsDocker Hub 限流见上一节。小结用 Docker 镜像这几年我的经验就三条优先官方镜像锁定具体版本号别碰 latest 和来路不明的第三方镜像中间件一定挂命名卷 配健康检查 设密码老教程那种裸奔的 docker run 在生产环境是灾难自己写的镜像用多阶段构建瘦身构建工具链不要带进运行镜像网上很多 Docker 镜像教程是十年前的内容一路抄下来的--link、centos:6、node:0.10 这些早就该进博物馆了。这篇文章里的命令都是按 2026 年当前的 Docker 24 / Compose v2 写的可以直接抄。有具体镜像使用上的问题评论区聊。