我第一次真正意识到必须认真学Docker基础是在一次上线前夜。当时本地跑得好好的服务部署到测试服务器上就开始报错缺Python依赖、系统库版本不对、中间件连不上同一份代码在两台机器上的表现完全不一样。后来排查了一晚上定位到的真正原因不是代码逻辑而是运行环境根本没法复现。Docker解决的就是这一件事把程序和它的完整运行环境一起打包、一起分发、一起启动让在我机器上是好的这句话彻底失去意义。如果你也正在被环境问题折磨或者刚接触容器技术不知道从哪里下手这篇文章就是给你准备的。我会从最基础的概念讲起一路带你走到能自己写Dockerfile、能用Compose编排多容器服务中间穿插我在实操中真实踩过、也修复过的坑。内容不绕弯子命令可以直接照敲思路可以直接拿去用。1. 没认真学Docker之前我的部署都是这么翻车的1.1 环境不一致带来的连锁问题先想一个问题一个Web项目从代码仓库clone下来到它在服务器上真正跑起来中间通常要经历几步依赖安装npm install、pip install这类、系统库补齐比如编译某些模块需要的开发工具链、配置文件调整、数据库初始化。这些步骤里任何一步出问题后面的排查都极其耗时。环境不一致的典型表现很常见A机器上依赖装得一路绿灯B机器上因为运行时版本不同直接编译失败C机器上因为缺少某个动态链接库服务启动就崩溃还有更隐蔽的代码明明一样但字符编码、时区、locale不同导致格式化输出对不上。这些症状看起来千奇百怪根子上都是同一个问题——环境没有标准化。团队协作里这个问题更放大。有人用Windows有人用macOS有人用Ubuntu还有人用CentOS同一套代码在不同平台上装依赖的动作都不一样。每次新人入职光配环境就能花掉半天每次部署都要祈祷生产环境和测试环境别出幺蛾子。我见过最夸张的一次是发版前发现生产服务器的系统库版本比测试环境旧被迫临时在大半夜做兼容性修复。这种事经历过一次你就不会再想经历第二次。1.2 容器和虚拟机的本质区别为什么我们要选容器很多人会把容器和虚拟机混为一谈其实两者的隔离层级完全不同。虚拟机在宿主机之上虚拟出一整套硬件再在上面跑完整的客户机操作系统所以隔离得很彻底但代价也很大镜像动辄几个GB启动要几十秒甚至几分钟。容器不一样它直接共享宿主机的操作系统内核只把应用和依赖打包成镜像镜像通常只有几十到几百MB启动是毫秒到秒级。用一个生活化的比喻理解虚拟机像是你租了一整层楼里面水电、装修、家具全都自己配容器像是标准集装箱货物装进统一尺寸的箱子里货轮、卡车、吊车都能直接用同一套机制搬运。隔离的层级不同决定了它们的启动速度、资源占用、分发效率完全不同。但要注意容器并不是没有隔离。它依赖Linux内核的两套机制namespace负责隔离进程、网络、文件系统、用户等视图cgroup负责限制CPU、内存、磁盘等资源用量。正因为有这两套机制每个容器看起来都像一台独立的Linux虚拟机实际却只是宿主机上的一个普通进程集合。在macOS和Windows上Docker会借助系统自带的虚拟化层跑一个轻量Linux环境日常使用层面和Linux上几乎没有差别你需要接触的仍然是一套Linux容器的操作方式。2. 镜像、容器、数据卷把这三个概念先装进脑子里2.1 镜像一个只读的完整运行模板镜像可以理解成应用的安装光盘或母版里面包含了你需要的操作系统基础文件、运行时、依赖库、应用代码和默认配置。镜像本身是只读的永远不会被运行过程修改这保证了每次从同一镜像启动出来的容器环境完全一致。用docker images命令可以看到本机已有镜像列表每个镜像有仓库名、标签和ID。标签很重要nginx:latest和nginx:alpine是两个体积、内容和行为都可能不同的镜像所以日常使用一定要养成写明确标签的习惯不要只依赖latest。镜像还有一个关键特性——分层存储。每一条构建指令都会生成一个只读层多个镜像之间可以共享相同的底层依赖层这也是为什么多个不同应用的基础镜像可以复用同一份底层数据拉取和存储都很省空间。2.2 容器镜像的运行实例也是你真正操作的对象镜像和容器的关系类似程序和进程也类似菜谱和按菜谱做出来的一道菜。你可以用同一个镜像启动多个容器它们彼此独立互不干扰修改其中一个不会影响另一个。容器在镜像只读层之上多了一层可写层运行时的文件创建、修改都发生在这层。这就引出一个新手最容易困惑的点容器里的改动默认不保存。你docker run启动一个容器进去装了个包或者改了配置文件然后docker rm -f把容器删掉改动就全没了。想持久保留改动要么把改动固化进镜像重新build要么把数据写到数据卷里。理解这一点后面所有数据持久化的问题都会迎刃而解。用docker ps可以查看运行中的容器docker ps -a能看所有曾经存在过的容器包括已经退出的。容器退出后并不会自动消失它只是处于停止状态用docker start可以重新启动用docker rm真正删除。刚接触时我经常忘记清理废旧容器导致主机上残留一堆停止状态的容器占着存储后面我会专门讲清理方法。2.3 数据卷让数据跳出容器的生命周期容器被删容器可写层里的数据也跟着没了。想让数据库文件、上传的图片、日志这类数据不随容器消失就得用数据卷。数据卷的本质是宿主机上的一块存储空间挂载进容器的指定目录容器写进这个目录的数据实际落在卷里容器删了数据还在。数据卷有两种常用形态。一种是named volume命名卷由Docker管理存储位置你只需要给卷起个名字比如-v db-data:/var/lib/mysql另一种是bind mount绑定挂载直接把宿主机的某个目录挂进容器比如-v /home/myuser/config:/app/config。bind mount适合挂载配置文件、开发时的源代码因为你能在宿主机直接编辑容器内立即生效named volume适合数据库、缓存这类需要Docker妥善管理生命周期的数据。我刚用Docker时偷懒不挂卷跑了个MySQL容器存测试数据某次清理容器把所有数据删了个干净直接傻眼。自那以后我的原则是任何容器只要产生有价值的数据启动命令里必须带上卷否则宁可不跑。3. 第一次跑通容器安装、拉镜像、启动、进容器3.1 安装与验证Linux发行版上安装Docker通常是用官方提供的软件源安装docker-ceWindows和macOS直接安装Docker Desktop安装完成后它会自动配置好运行环境。装完第一件事不是急着跑容器而是确认自己的客户端和引擎是通的执行docker version能看到客户端和服务端引擎两个版本信息再执行docker info可以查看运行环境的详细信息包括容器数量、镜像数量、存储驱动等。有个很常见的细节Linux下执行docker命令需要权限普通用户会提示权限不足。办法是把当前用户加入docker用户组sudo usermod -aG docker $USER然后重新登录终端。注意不要为了方便直接给docker命令配sudo免密这会在系统上留一个权限过宽的口子相比之下用户组方案更规范。如果你所在网络的公共镜像仓库拉取速度比较慢常规做法是给Docker配置一个镜像加速器地址registry mirror加速器配置可在Docker官方文档或你所处网络环境的公共文档中找到修改后重启Docker即可生效。不要随便使用来路不明的所谓加速脚本尤其不要在服务器上乱改Docker配置之后不做验证。3.2 拉镜像、启动、端口映射接着我们用最经典的nginx镜像走一遍完整流程docker pull nginx:alpine docker run -d --name web-demo -p 8080:80 nginx:alpinedocker pull负责把镜像从仓库拉取到本地。docker run的参数逐个解释-d表示后台运行--name web-demo给容器起名字-p 8080:80是端口映射nginx:alpine是镜像名加标签。端口映射是新手最容易晕的地方。冒号左边8080是宿主机端口冒号右边80是容器内部服务监听的端口。nginx默认监听容器内80端口但容器有自己的网络命名空间宿主机访问不到容器的80端口所以要把宿主机的8080转发到容器的80。你浏览器访问localhost:8080能看到nginx欢迎页就是请求先到了宿主机的8080再由Docker转发进容器内的80端口。左边这个端口可以随便换只要不冲突就行右边这个80必须和容器内进程实际监听的端口一致。如果端口映射没生效先用docker ps确认容器的PORTS列显示的是0.0.0.0:8080-80/tcp。如果看到的是80/tcp没有端口映射说明启动时漏了-p参数。另一个排查点是容器内进程可能没在80端口监听可以用后面的docker exec进容器确认一下。3.3 进入容器、看日志、控制容器生命周期容器运行起来之后我们经常需要进去看状态docker exec -it web-demo sh-i表示保持标准输入打开-t表示分配一个伪终端合起来才能拿到一个可以交互操作的shell。nginx:alpine镜像里没有bash所以用sh。执行exit退出交互终端容器继续后台运行。看日志用docker logs web-demo默认只输出最新的部分可以加-f持续跟随类似tail -f。查进程用docker top web-demo。停止容器用docker stop web-demo停止后可以用docker start web-demo再启动。想彻底删除则先docker stop再docker rm web-demo也可以直接docker rm -f web-demo强制删除运行中的容器。我把这一阶段最常用的命令整理成一个速查表操作命令说明拉取镜像docker pull 镜像名:标签不加标签默认latest查看镜像docker images显示本机镜像列表启动容器docker run -d --name 名字 -p 宿主机:容器 镜像-d后台运行列出容器docker ps / docker ps -a加-a含已停止的进入容器docker exec -it 名字 sh在运行中容器内执行命令查看日志docker logs -f 名字-f持续输出停止/启动docker stop 名字 / docker start 名字不删除容器删除容器docker rm -f 名字强制删除运行中的清理资源docker system prune -af清理所有未使用资源慎用这里要特别提醒docker system prune -af这条命令它会把没在用的镜像、容器、网络和build缓存全部清理掉空间是释放了但如果之前有停止状态还不想删的容器也会一并被清掉。我一般只在确定没有重要东西的时候才执行日常清理还是手动确认更稳妥。4. 用Dockerfile把项目变成可复现的镜像4.1 最小可用Dockerfile每一行都有它的道理用自己的代码构建镜像需要写一个Dockerfile。以一个Node.js项目为例一个最小的Dockerfile长这样FROM node:20-alpineWORKDIR /appCOPY package.json package-lock.json ./ RUN npm install --omitdevCOPY . .EXPOSE 3000CMD [node, server.js]逐行说清楚为什么这么写。FROM指定基础镜像node:20-alpine是带Node 20运行时、基于Alpine精简系统的镜像体积比完整版小很多。WORKDIR /app切换工作目录这样后续所有操作都在这个目录里进行避免路径混乱。接下来两行是精髓先把package.json和package-lock.json复制进去执行npm install再把其余代码复制进去。这样安排是为了利用Docker的层缓存机制——只要依赖清单文件没变npm install这一层就可以直接复用缓存的构建结果改一次代码只需要重新拷贝代码层构建速度会快非常多。而如果把COPY . .放在npm install前面那就意味着任何代码改动都会使得依赖安装那一层缓存全部失效每次构建都要重新联网装一遍依赖项目稍微大一点构建时间就会翻好几倍。这一行顺序是Dockerfile里最值得反复琢磨的细节。EXPOSE 3000只在镜像里做个端口声明方便使用者了解容器内服务监听哪个端口它本身并不自动发布端口真正发布还是靠docker run的-p参数。CMD是容器启动时执行的默认命令写法上要求是JSON数组格式因为这样Docker不会经过shell解析避免引号转义等额外问题。4.2 .dockerignore和构建上下文和.gitignore类似Docker也支持.dockerignore文件写在构建目录下的.dockerignore内容是构建时要排除的文件和目录比如node_modules、.git、dist、.env、*.log这些。为什么必须排除因为执行docker build时Docker会把整个构建上下文打包发送给引擎上下文就是命令最后那个点.指向的目录。如果这个目录里有几个GB的node_modules和一堆日志、缓存文件每次构建前都要把这些全部传输一遍构建自然又慢又占空间。更关键的是某些包含敏感信息的文件比如.env一旦进了构建上下文就可能被误拷进镜像留下安全隐患。所以.dockerignore里至少要放进node_modules、.git、.env、.log文件这样的条目和代码库里的.gitignore配合使用。构建命令是docker build -t my-app:v1 .-t指定镜像名和标签建议统一命名格式为应用名:版本号最后一个.是构建上下文的路径。构建完成后用docker images确认镜像生成然后启动docker run -d -p 3000:3000 --name my-app my-app:v1。4.3 多阶段构建镜像瘦身与安全的双赢很多语言的项目编译过程会用到庞大的工具链但这些工具链在运行阶段完全不需要。多阶段构建的思路就是先用一个大而全的阶段完成编译再把产出的文件复制到一个小而精的运行阶段最终镜像只包含运行时需要的文件。还是用Node项目举例FROM node:20-alpine AS buildWORKDIR /appCOPY . .RUN npm ci npm run buildFROM node:20-alpineWORKDIR /appCOPY package.json package-lock.json ./RUN npm install --omitdevCOPY --frombuild /app/dist ./distCMD [node, dist/index.js]第一个阶段把源代码拷进去安装全部依赖并执行编译产出dist目录第二个阶段只保留依赖清单和运行所需依赖再通过COPY --frombuild从第一个阶段复制编译产物。这样最终镜像里既没有源代码也没有dev依赖体积通常能缩减一半以上同时减少了攻击面。这个写法对后端的Go、Java项目收益更大因为它们编译出来的产物往往就是单个可执行文件或少量jar包。我接手过的历史项目里有直接从编译镜像部署上线的镜像好几个GB换成多阶段构建后缩到几百MB部署速度提升立竿见影。5. 实战里最容易翻车的五个细节5.1 容器时区总是差8小时症状很简单应用日志里的时间戳和本地时间差整整8小时。原因在于很多基础镜像默认时区是UTC容器里执行date看到的是世界标准时间而你的业务期待的是本地时区。解决办法有两种二选一即可。一种是在Dockerfile里设置环境变量ENV TZAsia/Shanghai某些精简镜像没有时区数据需要先安装tzdata再配置另一种是在docker run时加-e TZAsia/Shanghai。需要注意的是Java应用除了操作系统时区还有JVM自身时区最好在启动参数里显式指定。我习惯在Dockerfile里统一设置这样整个镜像的行为是确定性的不依赖宿主机时区。5.2 容器内创建的文件在宿主机上是root属主这种问题在挂载目录时特别常见应用在容器里正常写文件但在宿主机上看到这些文件属主是uid0的root普通用户删不掉、改不了非常被动。根源是容器内进程默认以root身份运行而bind mount只是把宿主机的目录映射进去文件落盘时记录的是容器内进程的uid/gid不是宿主机当前用户的uid/gid。最简单的规避办法是启动时指定用户docker run --user $(id -u):$(id -g)。更规范的做法是在Dockerfile里用USER指令切换到普通用户比如先创建应用用户然后USER appuser之后所有的运行时操作都以非root身份执行。基础镜像里如果提供了非root用户优先使用它。这个坑影响的是部署后的可维护性越早处理越好别等服务上线了才去手动chown。5.3 容器日志无限增长最终撑爆磁盘默认情况下容器日志由json-file驱动记录而且默认不轮转不限制大小。一个日志输出频繁的应用跑上几天就能把磁盘写满服务莫名其妙就挂了排查看日志时又发现日志文件本身都读不动。这是生产环境最常见的故障之一属于可以提前预防的典型问题。预防方案是在Docker引擎配置里设置日志轮转。Linux上编辑/etc/docker/daemon.json{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }改完重启Docker生效。单条容器启动时也可以加--log-opt max-size10m --log-opt max-file3限制。这样每个容器日志超过10MB就自动滚动最多保留3个文件磁盘占用被限制在可控范围。对于重要日志业务建议让应用把日志写到挂载的数据卷里由专门的日志采集方案处理不要依赖容器默认日志作为唯一留存。5.4 容器不限制资源一个容器拖垮整台机器容器虽然共享内核但默认对CPU和内存的使用没有硬性上限。如果某个业务出现内存泄漏或流量暴增它会不断申请宿主机内存最终触发OOM甚至影响到同主机上的其他服务这就是典型的吵闹邻居问题。启动时给出资源上限是基本操作docker run -m 512m --cpus 0.5 my-app:v1-m限制内存--cpus限制CPU核数可以用小数来限制半个核或四分之一核。查看实际占用用docker stats它会实时展示每个容器的CPU、内存、网络和磁盘I/O使用率。我把资源限制当作生产环境的默认要求凡是写进部署脚本的容器都必须带上这两个参数宁可先给足再调低也不能完全不加限制。5.5 构建上下文过大一次构建上传几个GB前面说过构建上下文会被完整发送给引擎很多项目把构建目录和源码目录混在一起导致docker build时上传的上下文巨大构建被卡在发送上下文环节很久。这个坑我已经在4.2里提过这里再补充一个经验准则构建时把上下文控制在必要文件的最小集合可以用单独的构建目录只留下Dockerfile、依赖清单、源码和必要的配置文件像本地临时文件、备份文件、图片资源压缩包这类一律放进.dockerignore。如果构建上下文还是很大先检查是否漏写了.dockerignore再看项目里是不是有人把大体积的二进制文件提交进了仓库。实在没办法缩小的时候折叠进多阶段构建也是个解法至少能让最终镜像保持干净。6. 多容器协作用Compose把数据库和业务串起来6.1 为什么需要Compose而不是写一串docker run一个稍微完整的应用往往同时要跑前端服务、后端API、数据库、缓存。如果全靠docker run一条条敲要记的命令越来越多而且容器之间的网络怎么互通、启动顺序怎么控制、数据卷怎么复用都会变成一场灾难。Compose就是Docker官方提供的多容器编排方案用一个YAML文件描述所有服务然后一条命令把整套服务拉起来。Compose的价值在于把基础设施的定义变成代码。新机器上部署只需要有docker-compose.yml文件执行docker compose up -d环境就绪。团队内部沟通成本也低大家看一个文件就能理解整套服务依赖了哪些镜像、挂了哪些卷、开了哪些端口。6.2 一个实战示例业务服务加MySQL先看一个典型配置services: db: image: mysql:8.0 restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: app volumes: - db-data:/var/lib/mysql web: build: . ports: - 3000:3000 depends_on: - db environment: DB_HOST: db volumes: - ./src:/app/srcvolumes: db-data:这个文件声明了两个服务。db服务直接使用mysql:8.0镜像通过environment传入初始化密码和自动创建的数据库名挂载了db-data这个命名卷保证数据库文件在容器重建后不丢失。web服务用当前目录构建镜像宿主机的3000端口映射到容器内3000通过depends_on声明它依赖db还通过环境变量把数据库主机名传进去。这里有个新手很容易踩的认知坑为什么数据库地址填的是db而不是localhost或127.0.0.1因为每个容器都有自己的网络栈localhost指的是容器自己web容器里并没有运行MySQL。而在Compose创建的默认网络中服务名本身就是可解析的主机名web容器通过db这个名字就能访问到MySQL容器。所以应用代码里数据库连接地址要写成环境变量DB_HOST的值db而不是本地回环地址。mysql:8.0首次启动需要初始化数据库而web服务的启动可能比db的初始化完成得更早。depends_on只保证db容器先启动不保证数据库可用。更严谨的做法是配置healthcheck让web等待db健康后再启动。基础场景下应用代码里做几次数据库连接重试就能覆盖这个问题。启动命令很简单docker compose up -d后台启动整套服务docker compose ps查看状态docker compose logs -f web跟踪指定服务日志docker compose down停止并删除整个环境加上-v参数会连同命名卷一起删掉数据不保留务必想清楚了再用。6.3 Compose文件的版本说明新版本Docker Compose已经不再强制要求写version字段写了也只是个兼容声明没必要再纠结使用哪个版本号。日常只需要关注services、volumes、networks这几个顶层字段即可。7. 我平时常用的Docker命令速查操作命令说明构建镜像docker build -t 应用名:版本号 .注意别遗漏最后的点单容器运行docker run -d --name 名字 -p 端口映射 镜像生产环境记得加-m和--cpus查看资源占用docker stats实时CPU内存镜像详情docker inspect 镜像名或容器名查看配置、环境变量、挂载信息清理未用镜像docker image prune只清理悬空镜像更安全一键清理全部docker system prune -af慎用会删除所有停止容器批量删除容器docker rm -f $(docker ps -aq)开发环境清场用查看网络docker network ls多个容器互联时排查用再说三个我个人的使用习惯。第一所有镜像标签都写明确版本不在生产环境用latest因为latest会漂移某天拉回来一个行为完全不同的镜像服务就莫名奇妙变了。第二容器时区、日志轮转、资源限制这些基础配置能写进Dockerfile和compose文件的绝不靠手工指定否则换台机器就忘了。第三每次修改Dockerfile后构建出的新镜像记得用新的标签别覆盖旧标签万一新版本有问题随时可以回滚到上一个版本继续跑。关于数据安全我再啰嗦一句。Docker基础操作学起来并不难真正决定项目稳定性的往往是卷的规划、日志的限制、权限的处理这些看起来不起眼的细节。刚开始用容器的时候我也觉得挂卷是多余的直到数据丢过一次才养成习惯。如果你能把前面那五个细节在一开始就处理好后面基本不会遇到什么解释不了的诡异故障。