最开始接触Docker的时候我总觉得它就是个升级版虚拟机无非是启动快一点、占得少一点。直到有一次我需要在一台全新的服务器上部署一个老项目的测试环境光是装依赖、调版本就折腾了大半天当时就在想如果有一个工具能把整个运行环境打包带走该多省事。后来真正用上Docker才发现它解决的不只是“安装麻烦”而是整个软件交付方式的问题。Docker是一种容器化技术通过把应用和它的运行环境一起打包成标准化的镜像实现了一次构建、处处运行。这篇文章我会从Docker的核心概念入手把我日常高频使用、实测过的常用命令整理成一份参考清单再分享几个绕不开的坑。适合刚接触容器技术的开发者也适合想系统梳理命令体系的同学参考。1. 先搞清楚Docker是什么容器和虚拟机的区别一次讲明白1.1 容器不是迷你虚拟机它是另一种打包方式很多刚接触Docker的人第一反应都是“这不就是启动特别快的虚拟机吗”。我一开始也是这么理解的结果在实际使用中吃了亏。比如我以为进了容器可以用系统监控命令看每个容器自己的资源占用结果发现返回的是宿主机整体数据我以为每个容器都有一整套操作系统结果发现容器里连系统服务管理工具都没有很多管理命令根本不存在。这些认知偏差都源于同一个误解——把容器当成了虚拟机的简化版。虚拟机虚拟化的是硬件层它需要在物理机上模拟出完整的CPU、内存、网卡再往里面装一个完整的操作系统。每一个虚拟机都自带一个内核占用的磁盘按GB计算启动要几十秒运行期间还有一层的性能损耗。容器则完全不同它虚拟化的是操作系统层多个容器共享宿主机同一个内核容器进程本质上是宿主机上的普通进程只是通过内核的命名空间、控制组等机制做了资源隔离和限制。我把最关键的差异整理成一张对比表配合日常使用场景来看非常直观对比维度虚拟机容器虚拟化层级硬件级虚拟化操作系统层虚拟化内核每个虚拟机独立内核所有容器共享宿主机内核启动速度秒级到分钟级毫秒级磁盘占用GB级别MB级别隔离强度强隔离适合多租户场景进程级隔离资源密度一台物理机通常跑几个到十几个一台机器可以跑几十上百个这张表里最值得反复琢磨的是“共享内核进程级隔离”这一条。它带来了启动快、占用小、密度高的好处但也带来了限制你没法在容器里运行一个和宿主机内核版本差异过大的操作系统比如宿主机的宿主机内核比较新容器里想跑依赖过时内核特性的程序就会出现问题。此外容器隔离不是绝对的安全边界多租户的强隔离场景仍然需要虚拟机来兜底。1.2 Docker真正解决的三个问题抛开术语回到我在实际项目里选Docker的三个真实原因。第一个是环境一致性。“在我电脑上是好的啊”这句话在后端开发里出现频率极高。问题往往出在系统的库版本、环境变量、时钟、编码等细节上。Docker把代码和运行环境锁进同一个镜像构建出来的镜像在任何安装了Docker的机器上表现都保持统一同一个版本就是同一个行为不再受主机环境差异影响。第二个是部署效率。以前上线新服务从申请机器到装好系统、装好依赖、调整配置文件半天的工时是常事。用Docker之后构建好镜像目标机器上直接拉取启动就行。配合私有仓库和自动化发布脚本可以做到代码提交后自动出镜像、自动部署整个发布流程被彻底压缩。第三个是资源密度。同样一台16G内存的服务器跑四个虚拟机可能已经喘不过气但跑三五十个轻量级的容器实例很常见。尤其在公司内部搭测试环境、开发环境时这种高密度特性意味着可以用更少的机器服务更多的项目省下来的资源费用是实打实的。1.3 围绕镜像、容器、仓库的一次完整工作循环Docker的使用流程本质上就是构建、分发、运行三个动作的循环。开发者在项目根目录写一个Dockerfile描述“基于哪个基础镜像、拷贝哪些文件、安装哪些依赖、启动什么命令”然后执行docker build按Dockerfile里的指令逐条执行把每一步产生的中间结果保存为一个只读层最后组装成一个完整镜像镜像构建好之后推到仓库部署机器上拉取镜像再用docker run跑成容器。这个流程里最让我觉得舒服的一点是镜像一旦构建出来就不会变你在开发机上测过的版本和生产上跑的会是完全同一份。容器可以被随意地创建、删除、重建而镜像始终是那个稳定源头。理解了这条主线后面所有命令都可以对号入座。2. 吃透镜像、容器、仓库这三个核心概念命令才有方向2.1 镜像是静态模板分层结构是它的灵魂镜像这个词有点抽象换个说法它就是“应用的完整打包模板”。里面不光有代码还有代码运行所需要的操作系统文件、依赖库、环境变量、默认配置。镜像是只读的不能直接修改一个已经存在的镜像要改变内容只能基于它重新构建一个新镜像。镜像内部是分层存储的。拿一个常见的场景举例假设要做一个基于某个基础镜像构建的应用镜像Dockerfile里通常会有FROM、RUN、COPY、CMD这几类指令。FROM会拉取一个基础镜像层RUN执行命令产生的文件系统变化会记录为新的一层COPY复制文件又是一层。多个镜像之间如果它们基于同一个基础镜像那么基础镜像层在本地只会存一份镜像共享引用不会重复占用磁盘。这种分层设计还带来另一个好处推送和拉取镜像时如果远程仓库已经有相同的层就不需要重复传输只有新增的层才有流量消耗。构建镜像时的缓存机制同样依赖分层——Dockerfile里前面的指令没有变化缓存就会直接复用后面的指令才重新执行。明白这个原理之后写Dockerfile时就会有意识地把“变化频繁”的指令放在后面把“不常变”的依赖安装放在前面这样改一次代码构建速度会快很多。2.2 容器是运行态每个容器都有一层可写层镜像是静态的容器是动态的。你用docker run基于一个镜像启动进程时Docker会在镜像只读层之上再加一个可写层这个可写层记录容器运行期间产生的一切变更新建的文件、修改的配置、产生的临时数据都写在这里。同一个镜像可以启动很多个容器彼此之间互不干扰因为每个容器都有自己独立的可写层和进程空间。可写层是容器灵活性的来源但也是数据耐久性的隐患。容器被删除时它对应的可写层会被一并清理里面写入的所有数据都会消失。很多新手踩的第一个大坑就在这里在容器里创建了数据库容器一删数据没了。这不是Docker的bug而是设计如此——容器本身是“无状态”的需要持久化的数据必须放到数据卷里。后面第四章我会专门展开。容器的生命周期也值得关注。一个容器会经历创建、运行、停止、删除几个阶段docker create是只创建不启动docker start是启动一个已停止的容器docker run相当于create加start。docker ps看运行中的容器docker ps -a能看到所有历史容器包括已经退出的。2.3 仓库是分发枢纽公共仓库加私有仓库的组合拳仓库是存放镜像的地方负责镜像的分发。公共仓库里有大量现成的开源镜像比如各类数据库、Web服务、编程语言运行时等基本覆盖了绝大多数常见软件。工作的时候只需要一条拉取命令就能把这些镜像拿到本地直接使用不用自己从头搭建环境这在很多场景下节省了大量时间。不过在实际企业项目里我极少直接把公共镜像用到生产环境更常见的做法是拿公共镜像做基础层在上面叠加自己的代码和配置构建出私有镜像然后推到公司内部的私有仓库。这样做至少有三个好处第一生产环境的镜像内容可控只包含需要的东西减小被攻击面第二基础层升级、安全补丁可以统一更新然后重新构建相关镜像第三内网拉取速度快得多不受公网网络波动影响。2.4 用一句话串起三者关系镜像、容器、仓库的关系我习惯用“程序、进程、应用商店”来类比。镜像是静态的程序包容器是运行中的进程仓库是获取程序包的渠道。命令操作基本就围绕这三者展开镜像命令负责从仓库拉取镜像、管理本地镜像容器命令负责基于镜像创建、管理容器仓库相关的命令负责登录、推拉镜像。把这些概念理清了后面读命令就不会觉得东一下西一下。3. 高频常用命令实操从拉镜像到跑容器一次过3.1 镜像命令拉取、查看、删除、打标签镜像命令是使用频率最高的一组。先看一下平时最常用的四个操作# 从仓库拉取镜像不写版本标签则默认拉取最新版 docker pull nginx # 拉取指定版本版本号要写具体生产环境最好固定 docker pull mysql:8.0 # 查看本地镜像列表 docker images # 删除本地镜像可以写镜像ID或者名称:标签 docker rmi nginx:latest # 给镜像打一个新标签相当于给同一个镜像起个别名 docker tag nginx:latest my-nginx:v1这里有几个容易忽略的细节。第一docker pull不写版本号时默认拉取的是latest标签但“latest”并不一定等于“最新发布版本”它只是一个约定俗成的标签名镜像制作者想指向哪个版本都可以。生产环境里最好固定写具体的版本号保证每次拉下来的内容可预期。另外可以用docker images命令查看IMAGE ID这个ID才是镜像内容的唯一指纹不同标签名只要指向同一个ID内容就是同一份。第二docker rmi默认只能删除没有被容器引用的镜像。如果有一个停止状态的容器还在引用这个镜像删除时会报错提示需要先删除容器。新手经常遇到这个报错以为镜像被锁住了其实只要用docker rm把对应容器删掉再执行docker rmi就正常了。第三想清理本地无用的镜像一条命令就能删除悬空镜像和未被引用的镜像# 删除所有悬空的镜像没有标签且没有被容器引用的镜像 docker image prune # 删除所有未被容器引用的镜像加 -f 跳过确认 docker image prune -a -f3.2 容器命令run、ps、exec、stop、rm容器命令是真正需要下功夫的部分。先看最核心的一条docker rundocker run -d --name web -p 8080:80 -v /var/www:/usr/share/nginx/html nginx拆开解释一下-d表示后台运行容器启动后不会占据当前终端--name给容器指定一个名字后面管理、查看日志、进入容器都靠这个名字来引用-p 8080:80把宿主机的8080端口映射到容器内的80端口宿主机上访问8080就能访问到容器内服务-v /var/www:/usr/share/nginx/html把宿主机目录挂载到容器内的站点目录直接从宿主机改文件容器内立刻生效。如果只是临时跑个测试任务--rm参数很实用容器退出时自动删除不会留下历史垃圾# 容器退出后自动删除适合一次性任务 docker run --rm -it ubuntu echo hello docker-it则是给容器分配一个交互式终端一般和bash一起配合使用用于进容器里调试docker exec -it web bash注意exec是进入“正在运行中”的容器是Docker官方推荐的方式。网上有些文章教你用docker attach我的建议是尽量避免。attach会把当前终端直接连接到容器的主进程一旦从这个会话退出容器主进程感知到终端关闭容器直接就停了很容易把服务搞挂。查看容器运行状态是每天必做的基本操作# 只看正在运行的容器 docker ps # 查看所有容器包括已退出的 docker ps -a # 查看容器的资源占用情况 docker statsdocker ps的输出里STATUS列会显示容器当前状态比如Up表示运行中Exited表示已停止。容器停止和删除是两个概念docker stop只是让容器进程终止容器本身还在通过docker ps -a能看到可以通过docker start重新启动docker rm才是真正把容器删掉。批量清理多余容器可以用docker rm $(docker ps -aq)。3.3 实战演示5分钟跑起一个静态网站我把上面的命令串成一个完整场景演示从拉镜像到访问网站的全过程。第一步准备一个放网页的目录并创建一个简单的首页文件mkdir -p /opt/site echo h1Docker Demo/h1 /opt/site/index.html第二步启动Nginx容器把目录挂载进去并用只读方式防止容器内误改宿主机文件docker run -d --name demo-web -p 8080:80 -v /opt/site:/usr/share/nginx/html:ro nginx注意:ro这个后缀它表示容器内对这个挂载目录是只读权限是我习惯留的安全余量防止容器内的应用被入侵后篡改宿主机上的静态文件。第三步验证容器状态和端口映射docker ps输出里能看到CONTAINER ID、IMAGE、STATUSUp、PORTS0.0.0.0:8080-80/tcp。本地浏览器直接访问http://localhost:8080如果页面显示“Docker Demo”说明整条链路已经通了。如果访问不了可以先确认容器进程是否正常docker exec -it demo-web bash ps aux exit第四步测试结束后及时收尾避免占资源docker stop demo-web docker rm demo-web整个过程不到五分钟而手动装Nginx、配目录、调权限至少也得半小时。这就是Docker最直观的价值体现。4. 数据卷和网络配置让容器从临时变成正式4.1 数据卷容器数据的唯一出路前面反复强调容器删除时数据会一起消失。真正需要长期使用的服务必须把数据放在容器之外最常用的方式是挂载数据卷。数据卷的本质是把宿主机上的某个目录或文件和容器内的某个路径做关联这样容器内写入的数据实际落在宿主机上容器删了数据依然在。数据卷有两种主要形态。第一种是绑定挂载直接指定宿主机路径docker run -d --name db -v /data/mysql:/var/lib/mysql mysql:8.0这种方式的优点是路径清晰文件直接可见方便备份和排查适合开发、调试以及生产环境的数据库目录。缺点是和宿主机路径强绑定容器跨机器迁移时不那么灵活。第二种是命名卷docker volume create mysql-data docker run -d --name db -v mysql-data:/var/lib/mysql mysql:8.0命名卷由Docker管理实际存储位置在Docker的数据目录下面用户不需要关心具体路径。迁移时只需要备份整个卷或者在新机器上创建同名卷挂回去。它的优点是隔离了宿主机路径细节缺点是排查问题时看不到具体文件位置。查看和管理数据卷的命令docker volume ls docker volume inspect mysql-data docker volume rm mysql-data还有一种tmpfs挂载方式数据只保存在内存中容器停止时数据就没了。它适合放临时缓存、临时文件不适合任何需要持久化的数据。我很少在生产环境用它但做性能敏感型的临时计算任务时内存速度确实快。4.2 端口映射与网络模式让容器对外可用容器有自己独立的网络命名空间默认情况下容器内的端口外面是访问不到的需要通过端口映射暴露。最简单的映射方式就是前面演示过的-p参数把宿主机端口映射到容器端口# 指定宿主机和容器端口 docker run -d --name nginx -p 8080:80 nginx # 随机分配宿主机端口 docker run -d --name nginx -P nginx这里要记牢一个顺序-p 宿主机端口:容器端口。如果你写了-p 80:8080意思就是宿主机的80端口转发到容器的8080端口如果容器内进程监听的是80这个映射就是错的访问会直接失败。多个容器之间需要互相通信时推荐用自定义网络。同一台机器上的多个容器通过同一个网络可以直接用容器名互相访问# 创建一个自定义桥接网络 docker network create my-net # 两个容器都连到同一个网络 docker run -d --name app1 --network my-net redis docker run -d --name app2 --network my-net ubuntu sleep 3600在自定义网络中Docker自带DNS解析app2里可以直接用容器名app1去访问app1的IP端口而不需要关心实际的IP地址和端口映射。很多新手部署整套应用时喜欢把所有端口都映射到宿主机其实完全没必要同一网络内部直接用容器名访问就好端口映射只保留对外需要暴露的服务即可。常用的网络管理命令也一并列出来docker network ls docker network inspect my-net docker network connect my-net app1 docker network disconnect my-net app14.3 环境变量、重启策略与健康检查让容器更稳实际部署时容器不光要能跑起来还要跑得稳。几个常用的配置项值得重点关注。第一个是环境变量。很多官方镜像支持通过环境变量完成初始化配置比如数据库镜像可以通过-e参数指定初始密码docker run -d --name db -e MYSQL_ROOT_PASSWORDroot123 -p 3306:3306 mysql:8.0参数格式是-e KEYVALUE。命令里写密码只适合本地测试真实环境应该通过配置文件、密钥管理等机制传入不要把敏感信息留在可查看的历史记录里。第二个是重启策略。容器进程崩溃或者机器重启后默认不会自动恢复加上--restart参数就能实现自动拉起docker run -d --name app --restart always nginx常用的策略有no默认不自动重启、on-failure非正常退出时重启、unless-stopped除非手动停止否则总是重启、always总是重启。在生产环境我一般用unless-stopped这样既能保证机器重启后服务自动恢复又不会干扰我手动停止某个容器做维护。第三个是健康检查。容器运行中不代表应用可用比如Nginx进程还在但后端接口已经超时了。更稳妥的做法是配置健康检查docker run -d --name app \ --health-cmdcurl -f http://localhost/health || exit 1 \ --health-interval30s \ --health-retries3 \ nginx健康检查由Docker定期在容器内执行指定命令命令返回正常就标记为healthy反之标记为unhealthy。不过要提醒一点很多精简镜像里没有装curl如果镜像里没有curl可以把健康检查命令换成wget或者改用shell内置方式探测否则健康检查会一直失败。5. 常见坑与排查实录这些问题几乎每个人都遇到过5.1 容器一启动就退出多半是前台进程的锅新手最常见的场景docker run一个镜像启动后明明看到了容器ID马上docker ps却看不到容器docker ps -a才看到STATUS列是Exited(0)。原因很简单——容器里没有前台进程在运行。Docker容器不是操作系统它没有系统服务常驻后台。容器的生命周期取决于主进程。当Dockerfile里的启动命令执行完或者启动的命令退出了容器就会随之退出。很多基础镜像默认的启动命令是bash而bash不带-i参数时是非交互式的执行完立刻退出容器自然就停了。解决办法就是让容器保持一个前台进程持续运行。比如启动一个Ubuntu容器想留着待用要加-it参数保持交互终端打开docker run -it --name test ubuntu bash或者在一些无交互场景下给命令加一个sleep让容器保持存活docker run -d --name test ubuntu sleep 3600更符合Docker理念的办法是直接用官方镜像的默认启动命令让应用进程本身做前台进程。比如Nginx镜像的启动命令就是前台运行Nginx所以不需要额外处理。还有一个相关坑用脚本启动应用时脚本里没有用exec接管应用进程。比如一个Java应用启动脚本进程关系是脚本进程作为PID 1Java进程作为它的子进程。容器收到停止信号时脚本没有把信号转发给Java进程导致应用被强制结束前没有机会做优雅退出可能留下未保存的状态。正确做法是在脚本最后用exec启动Java进程让应用进程直接成为PID 1#!/bin/bash exec java -jar app.jar5.2 镜像拉取卡住先检查加速配置在部分网络环境下从默认的公共镜像仓库拉取镜像速度不稳定拉一条小的镜像都要好几分钟大镜像甚至直接超时。解决思路是为Docker配置镜像加速服务让拉取请求走更快的国内镜像源。Linux环境下的配置方法是在/etc/docker/daemon.json里加一段内容然后重启Docker服务{ registry-mirrors: [https://你的加速地址] }执行sudo systemctl restart docker之后重新拉取镜像速度会有肉眼可见的提升。如果是使用桌面版Docker的环境可以在软件设置界面的Docker Engine配置里直接编辑daemon.json效果相同。配置完加速之后如果拉取还是经常失败可以执行docker info查看当前配置是否生效输出里会列出已配置的镜像加速地址。如果返回为空说明配置没有加载成功多半是daemon.json格式有问题检查一下JSON语法即可。5.3 端口被占用的排查思路docker run启动带端口映射的容器时报错提示类似“port is already allocated”说明宿主机的这个端口已经被分配了。排查分两步。第一步看是不是被其他容器占用docker ps -a如果看到别的容器用了这个端口要么改新容器的宿主机端口要么把旧的容器清理掉。这里有一个方便的做法启动容器时先用docker port查看现有容器的端口占用情况再规划新端口。第二步如果docker ps里没有任何容器占用那就是宿主机进程占用了端口用系统命令查ss -tlnp | grep 8080能看到占用进程的PID确认进程用途后再做处理。我的习惯是部署时先做端口规划把每个服务使用的宿主机端口写清楚避免容器之间互相抢端口。5.4 容器一删数据全没了挂载数据卷才是正解这是我在同事那里见过最多的时间黑洞。数据库容器跑得好好的磁盘空间不足需要清理操作者直接docker rm把容器删了然后发现数据库里的表全部消失。原因前面已经说过容器可写层随容器删除而销毁数据没有放进数据卷就没有任何持久化保障。遇到这种情况抢救手段非常有限只能依赖宿主机上的残留文件痕迹或者备份。与其事后抢救不如提前防护凡是需要持久化数据的服务启动时一律挂载数据卷。标准示范# 启动MySQL必须挂数据目录 docker run -d --name mysql-prod \ -v /data/mysql:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD... \ mysql:8.0另外要养成备份习惯。光挂数据卷还不够还要定期把数据卷目录整体备份走因为数据卷只解决“容器删了数据还在”不解决“磁盘坏了数据还在”。生产环境的数据备份是无条件要做的功课。还有权限坑。bind mount挂载的宿主机目录如果归root所有容器内以非root用户运行时可能没权限写入。反过来容器里以root写入的文件在宿主机上所有者也是root普通用户删不掉。我在实际项目里通常会把容器的用户和宿主机的用户UID对齐或者在挂载目录上用chown调整归属避免权限混乱。5.5 容器日志无限制膨胀磁盘被塞满容器运行期间会持续输出日志Docker默认把所有标准输出都收集到宿主机的日志文件里。如果不加限制长时间运行的容器日志文件可以膨胀到几个GB甚至更多最终把宿主机磁盘塞满这是运维事故的常见原因。解决方法是在daemon.json里配置日志轮转{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }含义是每个容器最多保存3个日志文件每个最大10MB超过就滚动覆盖最旧的。配置完之后重启Docker生效注意只对之后新建的容器有效已经存在的容器还是沿用原来的设置需要重建容器才能让新配置生效。对运行中的容器查看日志尾部内容用docker logs --tail 100 web清理日志不能直接删除宿主机上的日志文件因为文件句柄还在容器进程手里删了磁盘空间不会立即释放还可能干扰容器写日志。正确做法是把日志文件截断成空文件或者直接重建容器。5.6 容器内时区不对时间差八小时容器默认使用的时区是UTC不是本地时区。业务代码里记录的日志时间戳比本地时间慢八小时排查线上问题时很容易被误导。解决方案有三个按优先级排。方案一在启动时传时区环境变量适合镜像内置了时区数据的情况docker run -d --name app -e TZAsia/Shanghai nginx方案二挂载宿主机的时区文件做一个只读挂载docker run -d --name app \ -v /etc/localtime:/etc/localtime:ro \ nginx方案三在构建镜像时就写死时区。在Dockerfile里增加时区相关设置任何一次启动镜像都直接使用目标时区不用依赖启动参数。这个方法最彻底推荐在自定义业务镜像里使用。如果应用是Java程序JVM在启动时可能还需要显式指定时区参数否则即使系统里显示的是本地时间JVM内部还是可能读成UTC这类细节排查时也要留意。写在最后最后还是分享几个我在实际操作中摸索出来的小习惯。第一是给每个容器都加--name名字要有含义比如项目名-角色-序号这样docker ps一排出来就知道都是什么服务而不是面对一串自动生成的ID发呆。第二是运行中的容器不要随便commit成镜像很多新手把容器当虚拟机用在里面手动改完配置就commit一个新镜像这种做法会让镜像分层变得混乱、无法复现正确的做法是把变更写进Dockerfile重新构建。第三是复杂的启动参数尽量沉淀成配置文件用编排工具来管理特别是多个容器需要联动时一条命令跑起来远远优于每次敲一长串docker run。Docker这个概念学起来很快真正值钱的经验都在实际操作和踩坑里希望这份总结能帮你少走点弯路。
