1. 为什么我把Docker定义为“软件交付的集装箱”1.1 环境不一致是团队协作里最隐蔽的杀手我在好几家公司都见过同一个场面开发说“我本地跑得好好的”测试说“到我这儿就是起不来”运维说“上服务器直接崩了”。三方来回扯皮半天最后发现是MySQL版本差了0.x、Redis的配置项不一样、某个系统依赖没装全。这种问题最磨人因为每个人的环境都是“真实”的只是它们长得不一样。Docker解决的就是这个问题。它把“应用程序”和“应用程序需要的运行环境”一起打包成镜像镜像跑到哪里都是同一套操作系统底座、同一套依赖、同一个启动命令。你可以把它理解成搬家时用的集装箱——不是只把电视搬过去而是把电视、遥控器、电源线、说明书全部装进同一个箱子里到新家开箱就能用而不是到了才发现“哎呀遥控器落在旧房子了”。我第一次用Docker跑一个旧版Node项目时体验非常直接项目里有十几个依赖包还有两个版本不一致的底层库以前新同事入职光配环境就得花半天。后来我把整个运行环境做成了镜像新同事拉下来直接跑全程不超过十分钟。这就是容器化最朴素的收益。1.2 容器和虚拟机的本质区别共享内核与完整模拟很多刚接触Docker的同学会把它和虚拟机搞混。虚拟机做的事情是模拟一套完整的硬件然后在上面装一个完整的操作系统每个虚拟机都有自己独立的OS内核。这就意味着三台虚拟机就是三个完整系统占用的磁盘和内存都非常可观。容器不一样。容器共享宿主机内核它只是把进程、文件系统、网络空间做了隔离。你可以把容器想象成一座大楼里不同的房间——水管、电路、承重墙都是公用的但每个房间有独立的门锁和装修。因为不需要各自带一套内核容器起步快、体积小、密度高一台机器能跑的容器数量远多于虚拟机。这里有个关键概念要记住镜像Image是只读的模板容器Container是镜像运行起来的实例。镜像分层叠加每一层都可能被多个镜像共用所以拉取新镜像时如果底层已经存在通常只需要下载增量部分。这也是Docker镜像能比虚拟机镜像小一个数量级的原因之一。2. 安装DockerWindows和Linux两条路线都要会2.1 Windows上用Docker Desktop先过WSL2这一关大多数Windows用户接触Docker都是从Docker Desktop开始的。但Docker Desktop在Windows上不是直接跑的它依赖WSL2Windows Subsystem for Linux 2或者老式的Hyper-V方案。WSL2可以理解成Windows里内置了一个轻量级Linux虚拟机环境Docker引擎就跑在这个Linux环境里和Windows桌面通过一种高效的通信机制对接。安装顺序建议这样来先启用Windows功能里的“适用于Linux的Windows子系统”和“虚拟机平台”重启然后安装WSL2的内核更新包打开命令行执行wsl --set-default-version 2最后再装Docker Desktop。Win11用户通常省事很多因为系统默认支持WSL2少了几个手动步骤。装完之后打开Docker Desktop等托盘里的鲸鱼图标稳定下来在终端里执行docker version。重点是看Server那一段能不能正常输出——哪怕Client正常只要Server报错就说明引擎没起来。很多人以为Docker装好了其实只是装了个“客户端壳子”后面所有命令都会卡在连接不到引擎这一步。2.2 Linux服务器安装Docker Engine用官方源最省心生产环境或自己买的云服务器装的是Linux系统这时候不需要Docker Desktop直接装Docker Engine。以Ubuntu为例最推荐的方式是走官方apt仓库而不是用系统自带的旧版本包。先把老版本清干净如果以前装过然后安装依赖包再添加Docker官方GPG密钥和仓库地址最后apt update apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin。这套流程看起来步骤多但每一步都重要GPG密钥是防止仓库被篡改的校验机制跳过它的确能装但安全上不值得。CentOS/RHEL系的话命令换成yum或dnf同样添加官方仓库再安装docker-ce。装完后执行systemctl enable --now dockerenable是设置开机自启--now是立刻启动一条命令解决两个需求。docker run hello-world跑通了就说明引擎、网络、镜像拉取整个链路都正常。2.3 启动第一个容器验证安装是否真的可用装好之后我很习惯先跑一个docker run hello-world。这个镜像极小主要作用是验证Docker能否正常从仓库拉镜像、能否创建容器、能否执行默认命令。如果这条命令跑完下方出现一段英文说明就表示整个Docker链路是通的。有个细节容易踩坑Linux下如果安装完直接敲docker命令可能提示权限不足解决办法是把当前用户加入docker组这个在下一节详细说。还有一点docker version看到Server是OK的但docker run却报错先别怀疑Docker坏了多半是镜像拉不下来或磁盘满了顺着报错提示去查别急着重装。3. 安装后高频报错三个典型问题一次说透3.1 virtualization support not detected虚拟化没开或虚拟化软件打架Docker Desktop启动时偶尔会弹出一整段英文报错其中非常经典的一句是“virtualization support not detected, docker desktop failed to start”。这段报错的字面意思是“检测不到虚拟化支持”但实际原因通常有两类。第一类是BIOS里的虚拟化开关没打开。Intel的VT-x、AMD的SVM默认在某些主板上是关闭的需要进BIOS把“Intel Virtualization Technology”或“SVM Mode”设为Enabled。很多品牌机出厂默认关闭装Docker Desktop之前不会有人专门去开。第二类是电脑上装了VMware、VirtualBox等虚拟机软件它们和Docker Desktop争抢虚拟化资源尤其是VMware和Docker Desktop的Hyper-V/WSL2特性同时启用时冲突非常明显。排查链路我建议按顺序走先确认BIOS虚拟化开关已开再确认Windows功能里的“虚拟机平台”和“Windows Hypervisor Platform”都已勾选最后检查是否有第三方虚拟机软件正在运行。如果VMware和Docker Desktop都要用可以尝试调整VMware的配置或者干脆二选一不要在开发机上同时跑两套虚拟化方案省下的时间远大于折腾的收益。3.2 failed to connect to the Docker API at npipe引擎没起来或管道断了Windows上另一个高频报错是“failed to connect to the Docker API at npipe:////./pipe/dockerDesktopLinuxEngine”。npipe是Windows的命名管道可以理解成Docker Desktop的引擎和命令行客户端之间的一条专用通讯管道客户端通过它把指令传给引擎。这条报错出现时优先检查三件事。第一Docker Desktop是否还在Starting状态启动过程没完成客户端就去连自然连不上等几秒重试即可。第二WSL2是否正常执行wsl --status看看有没有报错如果WSL2发行版坏了引擎起不来管道也不存在。第三Docker Desktop是否处于某种异常状态彻底退出托盘图标再重新打开很多时候能解决这种“假死”问题。遇到这种报错我一般不会直接重装而是先跑一遍wsl --shutdown把WSL2整个重启一次再启动Docker Desktop。理由是Docker引擎跑在WSL2里WSL2卡住时外部怎么点启动都没用必须先把它彻底停掉再拉起。3.3 Permission deniedLinux下docker命令权限不够Linux环境初次安装Docker后执行任何docker命令都可能遇到“permission denied while trying to connect to the Docker daemon socket”。这个报错的机理很明确Docker守护进程的socket文件/var/run/docker.sock默认属于root用户普通用户没有访问权限命令自然被拒。常规解法是把当前用户加入docker组sudo usermod -aG docker $USER然后重新登录会话让组权限生效。这里要提醒一句能访问docker.sock就等同于能对系统做很多接近root的操作因为你可以用docker run -v /:/host把整个宿主机目录挂进容器随便读写。所以这个操作只建议在自己的开发机上做服务器上要严格控制谁能加入docker组不要图方便给所有账户都开这个权限。4. 镜像管理解决下载慢、认不清镜像、乱用latest的问题4.1 镜像、容器、仓库一组容易混淆的概念把Docker用熟三个概念必须分清楚。镜像是打包好的只读模板它包含代码、运行时、系统库、配置等一切运行所需容器是镜像运行后的实例在镜像只读层之上加了一个可写层你往容器里写文件写的是可写层仓库是存放镜像的地方Docker Hub是默认的公共仓库公司内部通常还会自建私有仓库。镜像分层机制是Docker体积控制的精髓。拉镜像时多个镜像如果共用同一个基础层比如都基于某个Linux发行版镜像构建这部分底层只需要下载一次。这也是为什么构建镜像时让你尽量基于官方基础镜像而不是每次从头造一个完整系统——复用的是公共层。另外很多热搜词里会出现“hadoop的docker镜像”、“gerrit镜像”这类具体镜像名。这意味着你想要的软件大概率已经有人构建好了现成镜像不用自己从零写Dockerfile。但用第三方镜像前我强烈建议先看一眼它的Dockerfile一般在仓库的说明页里有链接确认它不是你想象之外的东西。4.2 镜像下载慢配置registry mirror比硬等更靠谱镜像下载慢是新手最直观的痛点。一条docker pull命令卡在等待输出上体验确实糟糕。这个问题最常见的原因是默认的Docker Hub公共仓库在部分网络环境下访问不稳定尤其一些体积动辄几百MB甚至几个GB的镜像。解决办法是配置registry mirror也就是给Docker守护进程指定一个优先访问的镜像源。Docker Desktop用户可以在Settings里的Docker Engine配置区编辑JSONLinux用户修改/etc/docker/daemon.json例如{ registry-mirrors: [ https://mirror.example.com ] }保存后执行systemctl restart docker重启守护进程。需要说明的是registry mirror只是把下载请求代理到另一个镜像仓库正常做法是选择一个你在当前网络环境下能稳定访问的公共镜像源。不要盲目相信网上随便找的源指定源之后拉一次生产用的镜像测试一下速度不行就换。除了换源还有一个实用技巧先用docker manifest inspect 镜像名:tag查看镜像的架构和层大小避免拉下不需要的版本。比如在x86机器上没必要拉arm64的镜像某些大体积镜像可能还包含完全用不到的历史层。4.3 镜像常用命令先练熟这批高频操作再谈进阶我整理了几个日常几乎每天都要用的镜像命令每一条都标注了使用场景docker pull 镜像名:tag从仓库拉取镜像到本地tag不写时默认latest。docker images列出本地所有镜像注意看SIZE列排查磁盘占用时有用。docker rmi 镜像ID或名字删除本地镜像删不掉时用-f强制但尽量不用先确认没有容器在引用它。docker tag 原镜像 新镜像名:tag给镜像打标签常用于把本地镜像标记后推到私有仓库。docker push 镜像名:tag把本地镜像推送到仓库推送前必须登录对应仓库。docker inspect 镜像名查看镜像的详细元数据包括架构、层、环境变量、暴露端口排查问题时很好用。docker history 镜像名查看镜像构建的每一层执行了什么命令能帮你理解别人镜像是怎么做的。其中最有价值的是docker history。有一次我发现某个镜像体积异常大跑完docker history看到构建过程里故意安装了一整套编译工具链运行时根本用不到这就解释了体积异常的原因。另外强烈建议生产环境不要盲用latest标签。latest是一个会漂移的引用——今天拉下来是一个版本三个月后再拉就是另一个版本出问题很难追溯。正确做法是固定到具体版本号比如mysql:8.0.36重要场景甚至锁定镜像的digest直接引用镜像摘要。5. 从跑通到跑好MySQL 8.0与Redis主从的容器化实战5.1 MySQL 8.0最典型的“有状态”容器MySQL这类数据库容器和普通无状态应用最大的区别在于“数据必须持久化”。如果只是跑一个测试实例可以这样快速启动docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDYourPassword \ -e TZAsia/Shanghai \ -v mysql-data:/var/lib/mysql \ mysql:8.0参数逐个解释-d表示后台运行--name指定容器名后面进容器都要靠它-p 3306:3306把宿主机的3306端口映射到容器内的3306端口这样客户端连接宿主机IP就能访问到容器里的MySQL-e传环境变量设置root密码和时区-v mysql-data:/var/lib/mysql是核心部分它把一个叫mysql-data的命名卷挂载到容器内的MySQL数据目录。启动后用docker exec -it mysql8 mysql -uroot -p进入容器内的MySQL客户端。这里exec是“在运行中的容器里执行命令”-it是“交互式终端”两个参数组合。生产环境建议加一行字符集参数--character-set-serverutf8mb4 \ --collation-serverutf8mb4_unicode_ci不加的话默认字符集可能是latin1存中文会乱码或报错这个坑我帮别人排查过好几次都是从“数据库建好了但写中文乱码”开始最后发现是容器默认字符集问题。5.2 Redis主从多容器协同的第一课Redis主从部署是理解Docker网络模型的绝佳案例。手写三条docker run命令太重更推荐先建一个自定义网络再启动主从三个容器docker network create redis-net docker run -d --name redis-master --network redis-net -p 6379:6379 redis:7 redis-server --appendonly yes docker run -d --name redis-slave1 --network redis-net redis:7 redis-server --replicaof redis-master 6379 docker run -d --name redis-slave2 --network redis-net redis:7 redis-server --replicaof redis-master 6379注意两条从节点命令里的--replicaof redis-master 6379这里填的是redis-master这个容器名而不是IP地址。这是自定义网络的特性容器之间自动有了DNS解析容器名就是主机名。这个机制非常方便——你在配置里写服务名Docker网络会帮你把名字解析成对应的容器IP哪怕容器重启后IP变了服务名也不变。验证主从是否成功执行docker exec -it redis-slave1 redis-cli info replication看role:slave和master_link_status:up两个字段。如果master_link_status是down通常是网络没建对或者replicaof填成了IP但容器IP已经变化。5.3 容器为什么不能随便删数据卷是唯一的安全网新手很容易犯的一个错误用docker rm删了容器再重新启动结果发现之前写入的数据全没了。这是正常的——容器默认的可写层生命周期和容器绑定容器删了写进容器里的文件也就跟着没了。Docker提供的数据持久化方式有三种方式说明适用场景bind mount把宿主机某个目录直接挂进容器路径由你指定配置文件、日志、代码目录需要直接访问文件时named volumeDocker管理的卷路径由Docker分配数据独立于容器数据库数据等推荐首选tmpfs存在内存里容器停止即清空临时缓存、敏感数据不落盘命名卷的好处是即使容器被删只要卷还在新建容器挂载同一个卷数据就恢复。用docker rm -v才会连卷一起删这个-v参数要特别小心。我见过有人图方便把所有容器都docker rm -vf删完才发现数据库卷也没了血泪教训。判断一个容器有没有数据卷用docker inspect 容器名看Mounts部分或者docker volume ls列出所有卷。养成习惯只要是跑数据库、消息队列这类有状态的中间件启动命令里必须带上-v挂载。6. Docker Compose编排从一条命令到一堆服务6.1 什么时候该上Compose命令开始连成串的时候单容器阶段一条docker run足够。但我第一次用Compose是被一连串“还得建网络、还得启动依赖服务、还得设置环境变量”的命令逼的。当你发现要启动一个完整项目需要先docker network create、再按顺序启动数据库、缓存、后端、前端每个参数还很长时就已经到了该上Compose的时候。Compose的核心价值是把整套服务的定义写进一个YAML文件用docker compose up -d一键拉起用docker compose down一键清理。这相当于把“人工按顺序执行的一堆命令”升级成了“用文件描述理想状态交给工具去达成”。团队协作时新人拉下代码和compose文件一条命令就能复现整个环境不需要老人口述“你先跑这个再改那个配置”。6.2 compose文件关键字段version、services、ports、volumes一个最精简的compose文件是长这样的services: db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: YourPassword MYSQL_DATABASE: app volumes: - db-data:/var/lib/mysql ports: - 3306:3306 api: build: ./api ports: - 8080:8080 depends_on: - db environment: DB_HOST: db DB_USER: root DB_PASSWORD: YourPassword volumes: db-data:旧版compose文件开头要求写version: 3.8新版已经不再强制。services下每个一级key就是一个服务名image指定镜像build指定本地Dockerfile构建二者选一或同时存在同时存在时Compose会优先构建构建后按本地镜像运行ports做端口映射environment传环境变量volumes定义数据卷清单depends_on声明服务依赖关系。特别注意depends_on的坑它只控制启动顺序不保证依赖服务“可用”。也就是说api等db容器启动了但MySQL可能还在初始化过程中接口直接连数据库照样失败。真正等依赖就绪要用healthcheck健康检查机制或者让应用启动时自带重试逻辑。这是生产环境踩出来的经验本地开发可以睁一只眼闭一只眼上生产一定要处理。6.3 例用Compose部署一个最小微服务链路微服务项目用Compose编排本质就是把各个服务拆成独立的services条目再通过自定义网络互相访问。下面是一个最小链路示例前端Nginx 后端API MySQL Redis。services: frontend: image: nginx:1.27 ports: - 80:80 volumes: - ./frontend/dist:/usr/share/nginx/html api: image: registry.example.com/api:1.2.0 ports: - 8080:8080 environment: SPRING_DATASOURCE_URL: jdbc:mysql://db:3306/app SPRING_DATA_REDIS_HOST: redis depends_on: - db - redis db: image: mysql:8.0 environment: MYSQL_DATABASE: app MYSQL_ROOT_PASSWORD: YourPassword volumes: - db-data:/var/lib/mysql redis: image: redis:7 volumes: - redis-data:/data volumes: db-data: redis-data:这里的关键点有两个。一个是后端连接数据库DB_HOST或JDBC地址里写的是db这个服务名而不是IP——Compose会为项目创建独立网络所有服务用服务名互相访问。另一个是Nginx挂载本地./frontend/dist目录前端构建产物放进去刷新即生效开发期很方便。管理命令方面最常用是docker compose up -d后台启动整套服务。docker compose ps查看服务状态。docker compose logs -f api跟踪某个服务日志。docker compose restart api重启某个服务。docker compose down停止并删除网络和容器注意它默认不删数据卷。docker compose down -v连命名数据卷一起删数据彻底消失慎用。down -v这个命令我特别提醒因为热词里就有部署微服务项目的场景很多人一条down -v把数据库数据清空比单个docker rm -v更“方便”地摧毁一切。在确认数据已经备份或不需要之前不要加-v。7. 网络排查容器之间“找不到彼此”时的完整定位链路7.1 Docker默认网络模型与自定义网络Docker的容器网络默认有三种驱动bridge、host、none。bridge是默认模式Docker会创建一个虚拟网桥一般是docker0所有默认网络下的容器都接在这个网桥上可以互相通信。host模式容器直接共享宿主机网络栈端口不再做映射性能最好但端口冲突是常态。none就是没有网络只在极特殊的离线场景用。默认bridge网络有个不方便的地方容器间不能用容器名互访只能靠IP。容器重启后IP一般会变配置文件里写死的IP就失效了。这也是我强烈建议业务容器使用自定义network的原因。创建一个自定义网络docker network create app-net启动容器时加--network app-net同网络下的容器马上就能通过容器名互相解析。查看一个容器当前挂在哪个网络下docker inspect 容器名 | grep -A 20 Networks日常使用中把需要互相通信的服务放进同一个自定义网络把对外暴露的服务用-p端口映射到宿主机这样既保留了内部通信的便利又管控了外部访问面。7.2 网络不通的排查步骤从“完全没有头绪”到“精确定位”搜索热词里有“docker网络不通”这个问题的典型场景是服务A要访问服务B但连接超时或被拒。我按自己的排查习惯整理出一条完整链路第一步确认服务B的容器真的在运行。docker ps -a看所有容器注意那些Exited状态——容器可能因启动失败反复退出自然连不上。第二步确认两个容器是否在同一个网络。分别执行docker inspect 容器A和docker inspect 容器B对比Networks部分的网络名。不在同一个网络默认就互不相通这是最常犯的错误。第三步进入容器A里面测试连通性。docker exec -it 容器A bash然后ping 容器B的容器名。如果容器里没有ping命令用docker exec 容器A sh -c cat /etc/hosts看有没有解析到容器B的IP或者直接nc -zv 容器B 端口测试端口。第四步测试端口而不是只测IP。网络通不代表端口通B容器内服务没起、监听地址绑定了127.0.0.1、防火墙拦了端口都能造成“通但连不上”。用curl或nc测端口能得到更准确的结论。第五步如果涉及宿主机外部访问检查端口映射和防火墙。docker ps看端口映射是否生效防火墙规则是否放行了对应端口。这套链路下来大部分“网络不通”都能定位到一个具体环节。我最常遇到的结果是两个容器都在运行但一个在默认bridge网络、一个在自定义网络互相根本不在一个子网解决方式就是把它们放进同一个自定义网络。8. 与Docker“说”同一种语言读懂英文报错和官方文档8.1 高频英文报错词汇表这些词不认识会绕很多弯路标题既然带“In English”这部分我就专门讲讲怎么跨过英文这道坎。Docker的命令本来就是英文报错也是英文如果一看到英文就头大很多问题搜都没法搜。下面整理一份高频报错关键词表按我实际遇到过的频率排序报错关键词中文含义典型场景Cannot connect to the Docker daemon无法连接Docker守护进程daemon没启动或DOCKER_HOST被修改No such image / No such container找不到镜像 / 容器名字拼错或对象已被删除port is already allocated端口已被占用宿主机端口被其他进程占用Mounts denied挂载被拒绝目录权限不足或文件共享未配置OCI runtime exec failedOCI运行时执行失败容器内没有要执行的命令或容器已停止no space left on device磁盘空间不足/var/lib/docker所在分区满了pull access denied拉取被拒绝镜像不存在、标签不对、私有仓库未登录repository does not exist仓库不存在镜像名写错或私有仓库地址不存在This error may indicate that the docker daemon is not runningdaemon可能没运行引擎未启动或异常退出Exited with code 1容器以退出码1结束应用启动失败需看容器内日志看到这些词先不要慌。报错本质上是工具在告诉你“我在哪个环节失败了”关键词提取能力比英文水平更重要。比如“port is already allocated”出来第一件该做的事就是netstat -tlnp | grep 端口找到占用的进程而不是去重装Docker。8.2 处理英文报错的方法用报错原文搜索别翻译后再搜我发现很多人在报错处理上有个低效习惯把英文报错翻译成中文再搜索。这样做一是翻译有损耗二是中文社区关于Docker深坑的资料远不如英文社区全。正确姿势是把报错原文直接复制进搜索引擎一次搜一段保留报错里的容器名、镜像名、端口号这些关键特征。我处理“failed to connect to the Docker API at npipe”时就是这么干的直接复制整句报错搜索结果第一条就是Docker官方Issue区里别人的讨论五分钟定位到是WSL2状态异常。如果当年我翻译成“无法连接到Docker API管道”再搜大概率只能找到一堆转来转去的转载内容。另外从一个完整报错里提取有效信息也有技巧。docker run报错往往是一长串输出要看三处第一行通常在说哪个动作失败、包含Error或failed的行准确的失败原因、最后一段可能是上下文。中间那些日志可以暂时忽略别被满屏英文吓倒。8.3 官方文档结构速览把docs.docker.com当字典用最后分享一个我的使用习惯遇到陌生的Docker概念第一反应是查官方文档而不是先看二手教程。官网的文档虽然全是英文但结构非常固定熟悉之后查起来效率很高。常用入口主要有几个Get started是入门教程适合系统学一遍Reference下的CLI命令文档每个命令的参数都有完整解释Dockerfile reference讲镜像构建文件每个指令的语法和行为Compose file reference是写compose文件时的字典Networking和Storage两个专题把网络模型和数据持久化讲得最清楚。我的使用方式是“需要什么查什么”写compose文件时遇到healthcheck字段不确定直接搜“compose file reference healthcheck”记不清docker run某个参数直接docker run --help。这两个动作比翻书更高效而且每一次查询都在强化对英文术语的印象——日积月累你就不会再觉得“英文文档”是门槛反而会发现它是最准确、最不绕弯的信息来源。说实话Docker的官方文档英文用词并不复杂翻来覆去就是container、image、volume、network、daemon这些词。第一次读可能生疏读上几次就成了肌肉记忆。我自己也是在排查第三次“port is already allocated”之后才彻底记住这个词组后来看到别人遇到这个报错一眼就能说出解决方案换端口或者清掉占用进程。工具用多了语言关自然就过了。
