1. 内容整体设计与思路拆解先聊点实在的。我最早接触Docker是大概七八年前在一家做SaaS服务的公司当时最头疼的事就是“在我机器上是好的”。开发环境、测试环境、生产环境三个环境三种脾气同一个代码包部署上去表现经常不一样。后来我们引入了Docker一句话总结就是把应用连同它的运行环境一起打包带走。1.1 容器化到底解决了什么问题传统部署方式里应用直接跑在操作系统上依赖库、运行时版本、配置文件散落在服务器的各个目录里。你换一台机器就要重新装一轮依赖遇到版本冲突更是噩梦。虚拟机解决了一部分隔离问题但虚拟机本身重量不轻——每个虚拟机都包含完整的操作系统启动要几十秒甚至几分钟占用的磁盘空间动辄几个GB。我记得当年搭测试环境一台物理机跑三个虚拟机内存就吃紧得不行。Docker的思路完全不同。它只用一层薄薄的容器运行时把应用和依赖封装在一个镜像里所有容器共享宿主机的操作系统内核。启动一个容器本质上是启动一个进程秒级完成镜像大小从几十MB到几百MB比虚拟机轻了一个量级。这背后的原理是Linux内核的namespace做隔离、cgroup做资源限制这两个机制决定了容器本质上是“加了围栏的进程”而不是“迷你操作系统”。我在实际项目里的体会是Docker带来的最大改变不是技术层面的而是协作方式的改变。以前交付给运维一个部署文档动辄几十页改个环境变量还要电话沟通半天。现在交付一个镜像一个命令拉起来就跑。开发、测试、运维之间少了很多扯皮因为大家面对的是同一个镜像而不是各自理解的“部署步骤”。1.2 为什么是现在这个时机有人会问容器技术其实很早就有了为什么最近几年才火起来这就要说到生态成熟度。早期做容器的人基本是在裸机上手动配置namespace和cgroup门槛极高普通人根本玩不转。Docker的出现把内核底层的复杂度封装成了几个简单命令门槛一下被拉低了。再加上Docker Hub这类公共镜像仓库的成熟分享和分发镜像变得像Git分享代码一样简单整个社区就开始滚雪球了。另一个关键推手是微服务架构的普及。服务拆细了环境差异带来的问题就被放大因为你可能有几十个服务要部署每个服务依赖不同版本的库。用虚拟机跑几十个实例资源消耗扛不住用Docker跑轻量化的优势就体现出来了。加上后来的容器编排工具——比如Kubernetes——把大规模容器的调度、伸缩、容灾管理了起来容器化才真正具备了生产级的能力。2. 核心组件与生态全景说真的很多人以为Docker就是docker run一下完事其实整套体系比我一开始想象的要大得多。要真正理解Docker得把它拆成几个核心组件来看每个组件解决的是不同层面的问题。2.1 镜像、容器、仓库的分工拿一套做饭的流程来类比镜像就是菜谱加预制菜的合体你把它交给任何人都能做出同样味道的菜容器就是按照这份菜谱实际做出来的一盘菜是有状态、正在运行的仓库则是存放菜谱的图书馆。具体来说镜像Image一个只读的模板里面包含了运行应用所需的一切——代码、运行时、系统工具、环境变量和配置文件。镜像由一层一层的只读层叠加而成Docker通过联合文件系统UnionFS把这些层合并成一个完整的视图。这也是为什么Docker镜像可以增量构建——你改了代码只需要重新生成变化的那几层而不是整个镜像。容器Container镜像运行起来之后就是容器。你可以启动、停止、删除容器也可以进入容器内部查看状态。容器层是读写层你在容器里做的任何修改只在容器存活期间有效。这个特性很重要它意味着容器是“一次性”的——删了重建就回到镜像的初始状态。仓库Repository存放和分发镜像的地方。官方的是Docker Hub企业内部的可以用私有仓库比如A公司开源的那个Registry或者Harbor。拉镜像、推镜像都是和仓库打交道。这三者的关系我建议用一条命令来理解docker run 镜像名。这条命令运行时Docker会先从本地找镜像找不到就去仓库拉取拉到之后基于镜像的只读层创建容器读写层然后启动容器里的主进程。整个流程本质上就是一个“从模板实例化出运行实例”的过程。2.2 Dockerfile与镜像构建的黑盒Dockerfile是定义镜像如何构建的脚本文件里面每一条指令都会产生一个新的镜像层。我见过不少新手构建出来的镜像动不动就几个GB原因就是没有理解分层和缓存机制。举一个最常见的例子。很多人的Dockerfile长这样FROM ubuntu:20.04 RUN apt-get update RUN apt-get install -y python3 python3-pip COPY . /app RUN pip install -r /app/requirements.txt CMD [python3, /app/app.py]这样写有个问题RUN pip install每次构建都会重新安装依赖哪怕代码只改了一行。因为COPY . /app这一步已经把代码拷贝进去了这一层的改动导致后续所有层都失效。正确的做法是把依赖安装放在代码拷贝之前FROM ubuntu:20.04 RUN apt-get update apt-get install -y python3 python3-pip WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD [python3, app.py]这样改完之后只要requirements.txt不变代码改动就不会触发重新安装依赖构建速度快了不是一点点。这是我踩坑换来的经验——有一次构建一个Python服务上面那种写法每次要跑七八分钟改成正确的顺序之后依赖没变的情况下十几秒就能构建完。还有一个经验是尽量合并RUN指令。每一条RUN都会产生一个镜像层层多了镜像就大而且中间层如果产生临时文件删除操作也不会减少镜像体积——因为镜像层是不可变的。所以常见的做法是RUN apt-get update apt-get install -y ... apt-get clean rm -rf /var/lib/apt/lists/*把安装、清理一气呵成。2.3 数据卷与容器生命周期的短板容器是临时性的这个是设计使然但也带来了一个问题容器删了里面的数据怎么办答案是数据卷Volume。数据卷是独立于容器生命周期存在的数据存储区域它可以被多个容器共享也可以挂载到宿主机的指定目录。我常用的有两种方式# 命名卷数据由Docker管理宿主机路径由Docker自动分配 docker run -d -v mydata:/app/data myapp # 绑定挂载直接挂载宿主机的某个目录 docker run -d -v /home/user/data:/app/data myapp第一种方式适合生产环境因为数据位置由Docker管理备份和迁移更加规范第二种方式适合开发和调试因为你可以在宿主机上直接修改文件容器里立刻能看到变化。有一个坑要提一下绑定挂载时如果宿主机目录不存在Docker会帮你创建但创建时用的是root权限有时候后面容器里跑的是非root用户就会遇到权限问题。我在一次部署中遇到过MySQL容器起不来的情况排查了半天最后发现就是数据目录权限不对。后来我的习惯是先mkdir -p并chown好目录再挂载。3. 实操过程与核心环节实现光讲概念没意思下面放一些实际用得上的东西。我从零开始走一遍完整的容器化部署流程每一步都说清楚为什么这么做。3.1 安装与基础配置不同系统安装方式不一样但有一个原则要记住尽量不要用系统自带的老旧版本尽量用官方源安装。以Ubuntu为例sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository deb [archamd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable sudo apt-get update sudo apt-get install -y docker-ce安装完成后还有几个我认为很有必要的设置把当前用户加入docker组避免每次都要sudosudo usermod -aG docker $USER然后重新登录。设置镜像加速。国内访问Docker Hub拉取镜像经常超时配置registry mirror能明显改善。在/etc/docker/daemon.json里添加{ registry-mirrors: [https://docker.mirrors.ustc.edu.cn] }改完重启sudo systemctl restart docker。设置日志轮转。这条很多人不知道。Docker默认不限制容器日志文件大小跑上一个月的服务json.log文件能膨胀到好几个GB把磁盘塞满。我的daemon.json里一直有这段{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }设置完之后每个容器最多保留3个10MB的日志文件磁盘安全很多。3.2 容器运行的关键参数解析docker run的参数非常多但真正生产用的就那几个。我以一个Spring Boot应用为例docker run -d \ --name order-service \ -p 8080:8080 \ -e SPRING_PROFILES_ACTIVEprod \ -e DB_HOSTmysql-server \ --restartalways \ -m 512m \ --cpus0.5 \ --networkmy-network \ registry.internal/order-service:1.2.3每个参数背后的考虑-d后台运行。--name给容器起名字方便维护。如果没有名字Docker会随机生成一个管理起来很痛苦。-p 8080:8080宿主机端口映射到容器端口。注意这里第一个8080是宿主机端口要避免冲突第二个8080是容器内应用的端口由应用自己决定。-e注入环境变量。配置信息通过环境变量注入而不是写死在镜像里这样同一个镜像可以在开发、测试、生产三个环境通用——这招在十二要素应用里叫“配置与代码分离”。--restartalways容器异常退出时自动重启服务挂了能自愈。生产环境我一般都会加这个参数。-m 512m --cpus0.5限制内存和CPU。这一点容易被忽视但不限制的话某个容器内存泄漏时可能拖垮整台机器。Docker通过cgroup实现这些限制和进程的资源隔离思路一致。--network加入自定义网络。后面细说。运行起来之后还有一个命令我经常用docker exec -it order-service sh这条命令进入容器内部相当于ssh到了那台机器上排查问题非常有用。注意容器里不一定有bash有些精简镜像里只有sh所以用sh更保险。3.3 网络模式的选型与实操Docker网络有几种模式我按使用场景说bridge默认容器通过NAT访问外部网络对外通过端口映射暴露服务。适合单机部署简单直接。host容器直接使用宿主机的网络栈没有网络隔离性能最好但端口冲突时很麻烦。none容器没有网络适合跑离线任务或者安全要求高的场景。overlay跨主机通信用一般配合编排工具使用。实际开发中我用的最多的还是自定义bridge网络。Docker自定义网络相比默认的bridge有一个很大的好处内嵌DNS解析。同一个网络里的容器可以用服务名互相访问不需要记住IP地址。docker network create my-network docker run -d --networkmy-network --name mysql-server mysql:8.0 docker run -d --networkmy-network --name order-service -e DB_HOSTmysql-server myapp在order-service容器里配置的数据库地址直接写mysql-server就好了Docker会自动解析到那个容器的IP。IP变了也不怕服务名是固定的。这个机制非常方便尤其是服务间调用的场景不用去维护什么IP清单。3.4 可视化界面要不要装有人会问Docker有没有图形界面管理工具有的比如Portainer装上之后可以在网页上管理镜像、容器、网络、数据卷。我的观点是生产环境不依赖图形界面但开发环境装一个Portainer确实省事。特别是有多台机器的时候网页上看一眼哪些容器挂了、哪些镜像占了多少空间比自己敲命令快得多。安装Portainer很简单docker run -d \ -p 9000:9000 \ -v /var/run/docker.sock:/var/run/docker.sock \ --name portainer \ portainer/portainer-ce注意挂载/var/run/docker.sock这个操作等于把Docker的控制权交给了Portainer容器安全性自己要评估。如果在公网环境一定要加TLS或者ACL别裸奔。4. 常见问题与排查技巧实录下面写一些我从实际操作中积累下来的经验很多坑都是踩过之后才学会的。这些内容不是文档里能找到的属于那种“没人提醒你就不知道”的细节。4.1 Exit Code 137 与内存限制容器运行一会儿就退出了docker inspect一看exit code是137很多人一头雾水。这个code应该这样解读137等于128加9对应的信号是SIGKILL也就是进程被强制杀掉了。最常见的场景是容器内存超出了限制。比如你设置了-m 512m应用实际吃掉了600MB内核的OOM Killer就会把这个进程干掉。这种情况日志里通常能看到Killed字样。解决思路有几个确认应用本身的内存配置调低堆内存或高级缓存上限。检查是不是有内存泄漏用docker stats观察内存变化趋势。如果确实是业务高峰需要更多内存适当调大限制但也要考虑宿主机整体容量。有一次我排查一个Java服务频繁挂掉的问题先用docker logs -f看日志没发现明显报错后来用dmesg | tail -20才看到内核的OOM记录。从那之后我养成了习惯容器异常退出先看exit code再看内核日志两个信息合起来才能定位问题。4.2 镜像体积爆炸的真相前面提到过Docker镜像层的机制这里再深入说一个问题构建过程中产生的临时文件不会被删掉。举个例子你在一个RUN层里解压了一个大文件包然后立刻删除了它最后这一层的体积仍然包含解压后的大小。原因是每个镜像层保存的是变化状态删除操作也只是一次“新增一个删除标记”并不会释放底层的空间。解决这个问题有两个思路第一尽量用多阶段构建。以Java项目为例先用一个基础镜像做编译再把编译产物复制到运行时镜像。编译过程中下载的依赖、生成的中间文件都留在第一个阶段里最终镜像只包含运行时需要的内容。两个阶段写在一个Dockerfile里用FROM ... AS builder来区分# 构建阶段 FROM maven:3.8.6-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package # 运行阶段 FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /build/target/app.jar . CMD [java, -jar, app.jar]这个优化前后对比非常直观带Maven和源码的镜像1.2GB多阶段构建出来的运行镜像只有200多MB。第二构建时可以用BuildKit的--mounttypecache来缓存依赖目录既能加快构建又不让缓存文件留在镜像层里。这个需要开启BuildKit配置DOCKER_BUILDKIT1。4.3 容器时间不对遇到过容器时间比宿主机晚8小时的问题吗原因是基础镜像默认的时区是UTC。处理方式很简单在Dockerfile里设置时区RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime echo Asia/Shanghai /etc/timezone如果是运行时的镜像不让你改可以用环境变量注入。Java应用的话-Duser.timezoneGMT08也能解决。这个问题看起来不大但日志时间对不上排查问题时特别容易混淆。4.4 容器内的用户权限Docker官方基础镜像默认以root用户运行这不是一个好习惯。一旦容器被攻破攻击者就拿到了宿主机的root权限这是很危险的事情。安全最佳实践是运行容器时指定非root用户。两种做法镜像内建用户RUN groupadd -r appuser useradd -r -g appuser appuser USER appuser运行时强制指定docker run --user 1000:1000 myapp第二种方式的坑就是容器内进程对挂载进来的数据卷目录可能没有写权限。解决办法是宿主机目录先设置好属主chown -R 1000:1000 /data。我第一次做这个操作时把整个宿主机目录的权限都改掉了还好那是专用数据目录不然后果很麻烦。提醒大家chown之前一定确认目录里没有别人在用的重要数据。4.5 常见问题速查表整理成表格方便大家直接抄问题现象排查命令常见原因解决建议容器秒退docker logs 容器名、docker inspect --format {{.State.ExitCode}}前台进程未启动成功确认CMD是否书写正确应用是否有致命错误端口映射不生效docker port 容器名、ss -tlnpgrep 端口防火墙未放行、端口被占用容器能起但访问不了docker exec 容器名 curl http://localhost:端口应用监听的是容器内地址应用配置监听0.0.0.0镜像拉取超时手动执行docker pull xxx看报错网络问题配置镜像加速换更近的仓库地址磁盘空间不足docker system df悬空镜像、旧容器堆积docker system prune -f定期清理关于最后一行我多说一句。docker system prune会把所有停止的容器、没有被使用的网络、悬空的镜像、构建缓存全部清掉。这个命令很方便但有精神分裂一般的双面性——有时候你以为删的是垃圾结果发现自己刚构建完还没运行的镜像也被带走了。所以我用这个命令之前都会先跑一遍docker system df看看每个环节占了多少确认没问题再删。5. 编排管理的实战经验从单机到集群单机用Docker基本就是上面这些内容。但生产环境里服务一多问题就开始变味了。一台机器上跑十几二十个容器谁来管理它们之间的依赖关系服务挂了怎么重启流量大了怎么扩容这些问题Docker自己解决不了。5.1 Docker Compose的应用在单机环境下最实用的编排工具是Docker Compose。它用YAML文件定义一组服务一个命令就能把这组服务全部拉起来。我一般用来管理一套应用的多个组件比如Web服务加Redis加MySQLversion: 3.8 services: web: build: . ports: - 8080:8080 depends_on: - redis - db environment: - DB_URLjdbc:mysql://db:3306/app - REDIS_HOSTredis restart: always redis: image: redis:7-alpine restart: always db: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORDsecret - MYSQL_DATABASEapp volumes: - db-data:/var/lib/mysql restart: always volumes: db-data:注意几个细节depends_on只控制启动顺序不等待服务真正“就绪”。MySQL启动完成实际上需要几秒到几十秒但Web服务可能在MySQL还accept不了连接时就已经启动了。生产环境里我通常会写一个启动脚本在Web容器启动时循环探测依赖端口等就绪再继续。restart: always配合Compose的docker-compose up -d使用宿主机重启后所有服务都会自动恢复。有次机房断电后来电机器重启后所有服务自动恢复了这功能确实省心。数据卷持久化和网络自动管理。Compose会为这个项目创建独立的网络服务名就是主机名服务之间直接通过YAML里定义的名字互相访问。5.2 为什么最终要走向容器编排平台Docker Compose解决的是单机多容器的问题但一旦服务数量增长到几十个、上百个或者需要多台机器协同工作就超出了Compose的能力范围。这时候需要容器编排平台把多台机器当做一个整体来调度。目前主流的是Kubernetes它解决的核心问题是服务发现与负载均衡新起的容器能自动注册到集群里请求能自动分发到健康的实例上。自动伸缩根据CPU、内存使用率等指标自动增减副本数。滚动更新与回滚新版本发布逐步替换旧版本出问题随时回滚到上一版。存储编排自动挂载存储卷支持云盘、网络文件系统等多种存储后端。学习Kubernetes的曲线确实比Docker陡峭很多但如果你已经在用Docker了很多概念其实是相通的——镜像、容器、网络、存储这些基础没变只是管理粒度从“单个容器”变成了“应用的一组实例”。所以我的建议是先扎实掌握Docker再过渡到编排平台不要一上来就去啃Kubernetes很容易被一堆抽象概念劝退。5.3 踩过的编排平台坑站在过来人的角度我提三条生产中常踩的坑一是镜像tag的管理。我见过有人统一用latest标签到了出问题的时点根本不知道线上跑的是哪个版本。正确做法是镜像tag和代码版本号、构建号关联比如1.2.3、build-1234。这样线上出问题第一个动作就是对比版本号。二是不要在容器生命周期里依赖本地状态。容器随时可能被调度到别的机器上重新创建任何本机文件系统上的数据都有可能丢失。三是资源配额一定要设置。在Kubernetes集群里如果应用的CPU和内存请求没有声明调度器无法合理分配资源一个繁忙的服务可能把整个节点的资源吃掉。6. 一些值得长期坚持的使用习惯前面讲了很多具体操作最后分享几个我认为值得长期坚持的习惯。不夸张地说这些习惯对于容器化系统的稳定运行比掌握某个命令更加重要。第一个习惯是镜像最小化。每次写Dockerfile都问问自己这一层真的需要吗能用Alpine基础镜像就不要用Ubuntu完整版。Alpine基于musl libc对很多编译型语言的静态编译产物很友好镜像体积能控制到几十MB。但要注意如果应用依赖glibc特性别强行用Alpine省体积的代价可能是踩坑。Java和Python应用我一直用的是基于debian的精简镜像体积在150MB左右兼容性很稳定。第二个习惯是日志标准化。容器内的日志输出到stdout或stderrDocker自动收集并转发到宿主机。应用日志不要写到文件里否则容器一删就全没了查问题特别被动。这个和十二要素应用里“日志是事件流”的理念一致。如果确实需要文件日志也要通过数据卷持久化或者直接对接日志收集系统。第三个习惯是安全基线。不光是前面说的不用root还包括镜像别从不明来源拉取尽量用官方镜像或自建私有仓库里的。敏感配置通过环境变量或密钥管理工具注入不要烧进镜像。暴露端口越少越好只开真正需要对外服务的端口。经常检查镜像的漏洞扫描结果及时更新基础镜像。第四个习惯是定期做“演练”。所谓演练就是不定期地主动销毁一个容器看服务能不能自动恢复数据会不会丢。有一次我们模拟数据库容器被删的场景发现由于数据卷没有配置持久化数据库直接恢复到了初始状态。这个险幸亏在演练中暴露了。容器化这条路说难不难说简单也不简单。技术本身的门槛其实不高真正考验人的是对细节的理解和敬畏。镜像越做越小、网络越搭越稳、故障越来越少这些身位的变化才是真正的成长。