Docker容器操作与私有仓库部署实战笔记

1. 实验背景与整体设计思路

最近整理了一份Docker容器常用操作与私有仓库部署的实验笔记，起因是某测试环境需要一套完全内网可控的镜像交付链路：开发机打好的镜像既能随手跑起来验证，又要能推到一台统一管理的私有仓库里，供其他节点拉取使用。整个实验做下来，覆盖了Docker日常使用频率最高的容器操作，也从零搭了一个真正能用的私有仓库，踩了几个坑之后把过程完整记录下来，分享给所有刚接触容器化或者准备做内部镜像管理的人。

先说这套实验到底解决什么问题。平时我们开发容器镜像，最习惯的做法是直接推到公共镜像仓库，或者在本机docker images里堆积一堆副本。前者有安全和网络方面的顾虑，后者在机器一多、部署环境一分散之后就完全不可控了。私有仓库部署的实质，就是在内网里自己架一个类似公共仓库那样的“镜像中转站”，让镜像推送和拉取都不出内网，速度稳定，权限可控。而容器常用操作，则是整个流程里从早上打开终端到晚上收工为止反复在敲的基础命令：拉镜像、跑容器、看日志、进容器排查、挂数据卷、清理垃圾命。这两个主题表面上一个偏日常一个偏架构，实际是一条完整的镜像生命周期链路。

实验环境不复杂，一台普通Linux服务器装好Docker引擎即可完成绝大多数内容，实际验证时我也用的是某虚拟化平台上的测试节点，4核8G内存，系统是常见的Linux发行版，Docker版本为20.10.x。客户端选择上，出于普遍性的考虑，文中所有操作命令默认在Linux Shell里执行，Windows环境只需要把换行和路径符号对应调整，结论完全通用。需要提醒的是，笔者的实验环境没有任何外部网络依赖，所有镜像源均使用本地可访问的加速渠道，这样保证整个流程在内网环境同样可复现。

整个实验笔记分成四个层次：镜像管理操作、容器生命周期操作、私有仓库部署全流程、常见问题与排障速查。四个部分层层递进，前两段建立操作手感，第三段把镜像从本机推到私有仓库再拉取回来，最后一段是实打实的踩坑记录。下面按这个顺序把每个环节的关键点和背后逻辑讲透。

2. Docker镜像管理常用操作与核心原理

2.1 镜像拉取与本地管理三件套

镜像管理是所有容器操作的地基。在Docker的世界里，镜像是容器的模板，容器是镜像运行的实例，这跟面向对象里“类与对象”的关系很像。你不可能脱离镜像直接跑一个容器，所以第一步永远是先把镜像弄到本地。最基础的三条命令就是拉、看、删。

# 拉取镜像 docker pull nginx:1.24 # 查看本地镜像 docker images # 删除镜像 docker rmi nginx:1.24

docker pull是Docker与镜像仓库交互的入口，默认会从配置好的仓库地址拉取。后面的nginx:1.24中，nginx是镜像名，1.24是标签Tag。标签这个东西很容易被忽略，但它非常重要。同一个镜像名可以存在很多不同标签，latest标签很特殊，代表最新版，但实际项目里尽量不要依赖latest，因为时间一长你根本不知道当前拉下来的是什么时候的版本，导致环境复现困难。正确做法是像1.24、1.24-alpine这种固定版本甚至带哈希值的标签。

docker images列出的信息里有IMAGE ID，这个ID是镜像内容的SHA256哈希，只要内容不变，ID就不变。这也意味着，同一份镜像打到不同标签，IMAGE ID是一致的，并不会产生多份存储。Docker的存储驱动会用层级结构管理镜像，所以本地拉取了nginx:1.24和nginx:1.25两个版本，相同层会复用，磁盘浪费并不大。

删除镜像时有个高频坑：容器还在运行的状态下，直接docker rmi会报错，提示“image is being used by running container”。处理思路不是强行删，而是先停容器、再删容器、最后删镜像。如果没有刻意保留容器，直接用docker rm -f把不用的容器连根拔起，再执行删除镜像操作就顺畅了。

日常维护中我给自己定了两条规则：一是所有测试镜像必须打固定标签，不裸用latest；二是一周至少清理一次悬空镜像。所谓悬空镜像指的是那些已经没有任何标签引用的镜像层，反复构建后很容易堆积，使用docker image prune -f一次性清理。这个习惯帮我避免过很多次磁盘被镜像层撑满的状况。

2.2 镜像打标签与离线迁移

环境多了之后，最常做的事就是在不同机器之间搬运镜像。互联网环境用docker pull从仓库拽很简单，内网隔离环境则必须走镜像导出再导入的方式，或者直接对接私有仓库。Docker为此提供了一套非常完整的离线迁移方案，核心就是tag、save、load三个命令的组合。

# 给本地镜像重新打标签 docker tag nginx:1.24 mylab.local/nginx:1.24 # 将镜像保存为tar包 docker save -o nginx-1.24.tar mylab.local/nginx:1.24 # 从tar包导入镜像 docker load -i nginx-1.24.tar

docker tag从操作上看只是改名，实际上是在同一份镜像内容上增加了一个引用入口。我给本地明明叫nginx的镜像打一个mylab.local/nginx的新标签，后续推送到私有仓库或者做离线导出时，都是以这个新标签为准的。很多人会忽略tag这步，直接docker save nginx:1.24，结果导入到目标机器后镜像名还是nginx，一点私有仓库风格都没有，后续管理会混乱。

docker save生成的tar包大小大约等于镜像实际占用大小，打包时间与镜像层数有关。跨机器拷贝时，tar包本身就是普通文件，scp或U盘拷贝都行。收到tar包后docker load -i立即完成导入，不需要其他依赖，这是离线场景最稳的方案。如果在导入时报“archive/tar: invalid tar header”这类错，八成是文件在传输过程中损坏，回去重新拷贝一次即可。

关于save与export的区别，不少新手容易搞混。docker save保存的是镜像，包含完整的历史层和元数据，适合在不同环境间完整迁移；docker export导出的是容器文件系统，相当于把运行中的容器快照成一个扁平的文件系统压缩包，丢失了镜像分层结构，通常用作容器状态的备份。想复现镜像时一定要用save/load，不要用export/import。

2.3 镜像瘦身与日常清理心得

镜像体积直接影响拉取速度和磁盘占用，也是私有仓库部署实验里绕不开的话题。实验过程中我拉了一个mysql:8.0镜像，体积足足600多MB，如果团队里每个人都往私有仓库推这种镜像，仓库的磁盘配额很快会告急。给镜像瘦身有两个最直接的思路：选择更小的基础镜像，以及只安装运行必需依赖。

alpine镜像特别适合做这类实验，它的基础系统非常精简，很多官方镜像都提供了alpine标签，比如nginx:1.24-alpine。对于功能验证型实验，选择alpine版本可以把镜像体积缩小一半以上。构建自定义镜像时，如果只是跑脚本或轻量服务，完全可以从python:3.11-alpine或node:20-alpine起步。

日常清理方面，除了前面提到的docker image prune，还有一套组合拳要掌握。docker system df可以查看镜像、容器、数据卷各自的占用空间，用docker system df -v能精确到每个对象的实际占用，定位到底是谁吃掉了磁盘。docker ps -a里会出现大量已经退出且不再使用的容器，这些容器文件本身并不大，但累积多了也会干扰视线，直接影响是docker ps的时候看不到真正的活跃容器。我习惯每次实验结束后用docker rm -v清理实验容器，并保留一个统一脚本，里面包含三条清理策略：

# 清理所有已退出的容器 docker container prune -f # 清理悬空镜像 docker image prune -f # 清理无主数据卷 docker volume prune -f

清理命令里的-f参数是跳过确认，脚本化时必备。数据卷的清理尤其要谨慎，因为volume里的数据是独立于容器之外持久化的，一旦删除就无法找回。生产环境里执行volume prune之前，必须确认里面的数据确实不需要了。

3. 容器生命周期操作：从创建到销毁的完整拆解

3.1 run命令背后的参数逻辑与端口映射

镜像就绪后，真正高频的是docker run。这条命令参数极多，但最核心的可以收拢到一组常用组合里。拿一个最简单的Nginx容器来说：

docker run -d --name web-demo -p 8080:80 -v web-html:/usr/share/nginx/html --restart=always nginx:1.24

-d表示后台运行，容器启动后不占用当前终端。--name给容器起了一个可识别的名字，否则每次操作都要查那一长串容器ID。前面的实验里我曾忘记加--name，结果容器运行后要用docker ps查ID，多付出不少不必要的操作。习惯上所有实验容器都加名字，能显著提升效率。

-p 8080:80是端口映射的经典写法，意为主机8080端口转发到容器80端口。容器默认处于独立的网络命名空间，外部访问不到容器IP，必须由宿主机做这一层转发。8080是宿主机上用来对外服务的端口，80是容器内Nginx进程监听的端口。如果宿主机8080被其他进程占用，docker run会直接报bind失败，这时候改用一个未占用端口即可，比如-p 8081:80。

-v web-html:/usr/share/nginx/html是数据卷挂载，冒号左边是宿主机上的路径或卷名，右边是容器内路径。这里写web-html会创建一个由Docker管理的命名卷，即使删掉容器，卷里的数据仍然存在，下次用同卷名挂载又能拿到旧数据。如果需要直接修改文件生效，可以把左边换成宿主机绝对路径，比如$(pwd)/html:/usr/share/nginx/html，这样容器启动时直接读取宿主机目录内容，本地改文件后刷新网页就能看到效果，很适合开发联调。

--restart=always表示容器退出时自动重启，对需要长期在线的服务很重要。实验环境一旦重启，没加这个参数的容器会全部变成Exited状态，整个服务链路就断了。参数值还有on-failure，只在非零状态码退出时重启，配合限定重试次数比较合理；always则是无条件拉起，更适用于常驻服务。

3.2 进入容器、查看日志与状态转移

容器起来之后，下一步就是“进去看看”。docker exec是我个人使用频率最高的命令，没有之一。它允许在一个已经运行的容器内执行命令，比如：

docker exec -it web-demo bash

-it两个参数组合后进入交互式终端，相当于打开容器的Shell。如果是alpine镜像，Shell可能是sh而不是bash，直接用sh进入即可。进入容器后，查看进程、检查配置文件、临时改设置都非常方便。需要注意，exec进入的是容器当前运行环境，对容器内文件的修改会写入容器可写层，但容器一旦被删除重建，这些修改会全部丢失，所以必须把持久化数据放到卷里而非容器内部。

日志排查是日常运维的另一大重心。docker logs命令能直接拉出容器的标准输出和标准错误：

docker logs web-demo docker logs --tail 200 -f web-demo

第一条查看全量日志，第二条只看最近200行并且持续跟踪，相当于Linux里的tail -f。调试时配合-f非常高效，控制台打了什么日志，终端实时滚动出来。生产级容器普遍要求应用将日志输出到stdout，而不是写到容器内部磁盘文件，正是因为Docker收集日志的标准路径就是标准输出。那些把日志写到容器内部某个.log文件的应用，会出现容器好好跑着、docker logs却啥也没有的诡异现象，排查起来极其痛苦。

容器状态转移是理解整个生命周期的基础。docker ps -a能看到容器全量状态，包括已经退出的。常见状态有Created、Running、Paused、Exited、Dead。Created只是容器创建但没启动，多见于用docker create准备好参数、稍后启动的场景；Running正常运转；Paused是暂停挂起，进程还在但暂时不受调度；Exited表示容器已退出，可能是正常结束也可能是异常崩溃；Dead是极其异常的终结状态。从一个状态转移到另一个状态，靠的就是start、stop、restart、pause、unpause、kill这些命令。我自己在实验里遇到过容器进Paused状态后忘记恢复，业务流量全部超时的问题，所以状态转移命令里pause/unpause虽然简单，却一定要知道它存在的意义。

3.3 数据卷、资源限制与多容器协作场景

单个容器操作熟练之后，自然会走向多容器协作。实际上日常项目很少只跑一个容器，一个简单的全栈演示往往需要前端、后端、数据库三个容器共同工作。多容器协作最基础的是网络互通。默认情况下Docker会为每个容器分配一个内部IP，但如果两个容器启动时没有指定同一个网络，它们虽然都在宿主机上，彼此之间却不一定能互相通信。解决方案是自定义网络，同一网络下的容器可以用容器名作为主机名互相访问。

docker network create demo-net docker run -d --name mysql --network demo-net -e MYSQL_ROOT_PASSWORD=123456 mysql:8.0 docker run -d --name backend --network demo-net -p 8080:80 myapp:latest

容器backend里直接访问mysql:3306就能连上数据库，这里mysql就是容器名，Docker内置DNS会把它解析为对应容器IP。不同网络之间默认隔离，这是安全上的双刃剑：好处是服务访问可控，坏处是一不小心就连不上。排障时需要先确认两个容器是不是在同一个自定义网络里，这是多容器问题第一排查点。

资源限制最好在容器启动时一并设定。不加限制的容器会默认使用宿主机的全部可用资源，多个容器一起跑会让单机直接卡死。常用的手段是-m限制内存，--cpus限制CPU核数：

docker run -d --name memory-demo -m 512m --cpus 1 nginx:1.24

上面命令限制这个容器最多使用512MB内存和1个CPU核心。实验时我特意跑了一个压力测试程序验证限制生效，程序申请超过限额内存后直接OOM被杀，印证了限制确实在起作用。容器OOM被杀后，通过docker inspect可以查看当时的退出码，OOM通常对应137。加-m参会在大内存应用的场景下导致频繁被杀，这时候不用慌，重新评估实际用量把内存限额调高即可。

4. 私有仓库部署全流程：从registry容器到全链路验证

4.1 一条命令搭建Registry服务

私有仓库的部署远比想象中简单，因为Docker官方维护了一个开箱即用的registry镜像，跑起来就是一个标准的镜像仓库服务。整个部署过程本质上就是“运行一个容器”，核心命令只有一条：

docker run -d \ --name registry \ --restart=always \ -p 5000:5000 \ -v /opt/registry-data:/var/lib/registry \ registry:2

registry:2是当前仓库服务的稳定主版本，2.x已经存在多年，功能稳定，API兼容性很好。端口5000是Registry默认监听端口，与前面Nginx、业务服务不同，这个端口专门用于Docker CLI与仓库之间的API交互。宿主机上映射的5000端口必须是防火墙放行的，客户端才能访问，这一点在内网环境里经常成为问题，因为很多Linux发行版默认防火墙策略很严格，需要在防火墙上放行对应端口。

数据卷挂载是不可省略的一步。-v /opt/registry-data:/var/lib/registry把宿主机目录对接到容器内镜像存储目录。如果不做这一步，registry容器一旦被删除，里面所有推送过的镜像会全部消失，私有仓库就白部署了。换成宿主机挂载后，容器怎么删怎么重建，镜像数据都安全留在宿主机目录里。生产环境建议把这个目录放到独立的数据盘上，避免系统盘被镜像填满后影响整机运行。

部署完成后验证服务是否正常，可以直接看端口监听：

ss -lntp | grep 5000 curl http://127.0.0.1:5000/v2/

registry服务符合Docker Registry HTTP API V2规范，访问/v2/端点会返回一个空JSON对象{}，只要这个响应正常，服务就是活的。这一步验证越早做越好，可以提前排除端口占用、容器启动失败等基础问题，为后续推送镜像省下不必要的排查时间。

4.2 让Docker客户端信任私有仓库

服务起来了，下一步就是让客户端能往里推镜像。这里会遇到一个极其隐蔽的坑：Docker客户端默认只用HTTPS与仓库通信，裸HTTP的私有仓库地址默认不被信任。直接推镜像大概率报错“http: server gave HTTP response to HTTPS client”。解决方案是把私有仓库地址加入Docker客户端的insecure-registries配置中，明确告知Docker：对该地址允许使用HTTP协议。

# 编辑客户端上的Docker守护进程配置 vim /etc/docker/daemon.json

在这个JSON文件里增加一段：

{ "insecure-registries": ["192.168.1.100:5000"] }

把192.168.1.100:5000替换成实际的仓库服务器地址。修改完成后必须执行systemctl restart docker重启Docker守护进程。这一步的坑在于，Docker客户端读取该配置是在守护进程启动阶段，不重启就不生效。重启Docker会让所有运行中的容器停车，所以在生产环境更改配置前务必备份运行状态或选择维护窗口执行。

配置生效后，向私有仓库推送镜像的流程就是标准的“打标签、推送、拉取”三步：

# 给本地镜像打上仓库地址标签 docker tag nginx:1.24 192.168.1.100:5000/nginx:1.24 # 推送到私有仓库 docker push 192.168.1.100:5000/nginx:1.24 # 从私有仓库拉取（在任意已配置信任的客户端上执行） docker pull 192.168.1.100:5000/nginx:1.24

标签规则是镜像名前面加仓库地址/项目名。推送完成后再访问curl http://192.168.1.100:5000/v2/_catalog，可以查看仓库里已有的镜像列表，响应中会有一个repositories数组列出所有镜像名。查看某个镜像的所有标签则访问/v2/nginx/tags/list，这是快速确认推送结果最直接的方式。

4.3 认证与HTTPS：私有仓库的生产级进阶

实验环境里裸HTTP的私有仓库完全够用，但一旦要面对多人协作或真实业务环境，认证和加密传输就是绕不开的话题。Registry本身没有用户体系，但它天然支持基于HTTP Basic Auth的基础认证，配合一个额外的认证文件就能实现最简鉴权。

生成认证文件的自动化步骤如下，依赖htpasswd工具，装过apache2-utils或httpd-tools的系统里都会自带。

# 生成用户名密码文件 mkdir -p /opt/registry-auth htpasswd -Bc /opt/registry-auth/htpasswd admin

-B参数指定bcrypt算法，-c表示创建新文件。执行时会让你输入并确认密码。有了这个文件后，重新部署registry容器，挂载认证目录，加一个REGISTRY_AUTH环境变量即可：

docker run -d \ --name registry \ --restart=always \ -p 5000:5000 \ -e REGISTRY_AUTH_HTPASSWD_REALM="Registry Realm" \ -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \ -v /opt/registry-data:/var/lib/registry \ -v /opt/registry-auth:/auth \ registry:2

启动带认证的registry后，docker login 192.168.1.100:5000先输入用户名密码，然后push和pull操作才会被允许。这个实验数据来得很直观：没有执行login直接push会收到unauthorized错误，login一次之后操作全部正常。认证模式下所有客户端都需要执行login，并且登录凭证缓存在~/.docker/config.json中，有效期较长但不会永久有效，过期后重新login即可。

至于HTTPS，更推荐在生产环境中落实好。实验级别不需要该配置，但至少要知道原理：把自签或受信任的证书文件放到registry容器内，通过环境变量指向证书路径，Registry自动启用HTTPS。证书签发环节本身比较复杂，但基本思路是使用openssl生成自签证书，然后把证书和私钥以卷挂载方式提供给容器，最后配合客户端配置将CA加入系统信任中心。有了HTTPS之后，客户端就不依赖insecure-registries了，通信也更安全可靠。

5. 常见问题与排查技巧实录

这轮实验做完，真正有价值的不是那些成功路径，反而是中间踩过的坑。这里把最有代表性的问题集中整理成速查表，每个问题都来自实际操作，解决方案都经过验证。

排查逻辑先看现象，再顺藤摸瓜。任何连接失败优先查网络和防火墙，其次是认证和仓库信任配置，这两类问题占了实验过程中八成以上的报错。Docker日志本身也是排查利器，比如启动失败的容器用docker logs container_name能看到应用层面的错误信息；如果日志为空，再用docker inspect container_name看详细配置是否有低级错误。

内存泄漏和资源限制也是实验过程中的高频问题。不加-m参数限制的容器，一旦内部应用出现内存泄漏，会把宿主机内存吃穿，表现为整机卡顿、容器大面积无响应。约束资源后，单个应用的内存异常被Docker截断在容器内部，其他服务不受牵连。实验时特意验证过，一个内存限额512M的容器尝试申请超过配额的内存，进程立即被杀，但宿主机其他容器毫发无损，这就是容器化带来的隔离价值。

日志占用空间的问题在长时间运行的容器上尤其突出。默认情况下Docker不限制单个容器的日志大小，一个打印高频率日志的应用几天就能写满几个GB。合理做法是在daemon.json中配置全局日志轮转：

{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

上面的配置表示容器日志单个文件最大10MB，最多保留3个日志文件，超过后自动清理旧文件。这个一个配置改动就能避免日志无限膨胀，实测效果立竿见影，是我在所有Docker部署中必配的项目之一。

6. 实验延伸：从手动操作到自动化交付

私有仓库部署完成后，整个镜像交付链路已经可以跑通。但这套环境只是一个开端，真正让它发挥价值的是往自动化方向延伸。个人经验是，先尝试把Docker容器操作整合到编排工具，再逐步接上持续集成流程，会发现原本手工操作的步骤全部可以被标准化流程覆盖。

实验中最值得优先升级的是引入docker compose。手工执行多个docker run命令不仅繁琐，还容易因为参数不一致导致环境差异。把Nginx、后端应用、数据库三个容器的配置写进一个docker-compose.yml文件，一条docker compose up -d拉起整套环境，一条docker compose down拆掉整套环境，过程中网络自动创建、端口统一编排、卷声明一次定义，省去了大量重复劳动。Compose文件在团队内共享后，新人复现环境的时间从小时级降到分钟级。

另一个方向是让私有仓库成为持续集成管道的终点。某测试团队用了我实验中的registry方案后，用自己的自动化流水线把每次构建产生的镜像自动push到私有仓库，同时打上构建编号标签。后续部署环节直接从私有仓库拉取对应镜像，整个交付过程看不到手工命令，环境一致性大幅提升。这个改进把之前部署时的常见问题几乎都消除了，比如生产环境缺个依赖、版本对不上、镜像从公共仓库拉错版本等问题，回归到私有仓库的既有版本之后都烟消云散了。

值得强调的是，私有仓库服务虽然本身只是一个运行中的容器，但它承担的角色却是整个容器化体系的中枢。给它做好持久化和备份比什么都重要。数据目录的定期备份、仓库服务自身的健康检查、认证文件的保管，这三个方面我不建议省略任何一项。实验环境里也许不够敏感，但一旦让人群、服务、自动化流程依赖上这个仓库，它的稳定性就直接决定了所有发布的稳定性。

最后分享一个实操小技巧，是我做完整套实验后最想建议给所有人的：在每台参与实验的机器上统一设置Docker命令的别名和脚本，比如把“清理悬空镜像、清理废弃卷、重启registry容器”这三件套写成一个自带的维护脚本，每周定时执行一次。实验环境长期保持清爽，排查问题时的噪音会少很多。容器技术不难，难的是把日常操作规范养成肌肉记忆，这套笔记希望帮你少走一些弯路。