1. 容器技术到底解决什么问题——先把核心理念捋清楚做开发和运维这几年我反复给团队讲过一句话能让你从环境配置的泥潭里真正解脱出来的工具不多Docker绝对算一个。这个系列前两篇聊了容器的基础概念和镜像原理这一篇我们直接上手讲透从安装、部署到排错的完整链路。文章里涉及的操作我都实测过尽量用大白话把原理和步骤讲明白保证你跟着做就能跑起来。先说清楚Docker解决的核心问题。以前部署一个应用最头疼的是环境不一致开发用Windows测试用CentOS生产是Ubuntu同一个代码在不同机器上表现完全不一样光是装依赖就能耗掉半天。最经典的段子就是“在我机器上是好的啊”本质上就是环境差异导致的。Docker把应用连同它的运行环境一起打包成镜像不管是物理机、虚拟机还是云服务器只要内核支持容器就能跑出完全一致的效果。“一次构建处处运行”这句话不是口号是实打实的生产力提升。另外一个痛点在于资源利用。传统虚拟机动辄几个GB的内存开销因为每个虚拟机都要装完整操作系统。而Docker容器直接共享宿主机内核只隔离进程和文件系统启动一个容器往往只需要几百毫秒内存占用可能只有几十MB。换句话说一台8GB内存的服务器跑虚拟机可能只能开两三个实例跑Docker容器能开二三十个。这个系列叫“容器技术3”重点不是再讲一遍“什么是镜像”而是把安装部署、命令使用、典型场景、常见坑位一次讲透。无论你是刚接触容器的新手还是被docker权限、网络不通、MySQL容器连不上折磨过的老手这篇都有对应的解法。你不需要先精通Linux只要会基本的命令行操作就能跟着跑通整个流程。1.1 从“环境地狱”到“一次构建处处运行”环境地狱这个词经历过的人都懂。举个实际场景你要部署一个Java微服务需要JDK 17、Maven、Redis、MySQL还要配一堆环境变量。光这些还不够不同版本的依赖库之间还可能互相冲突升级一个包另一个就崩。这种问题在传统部署方式下几乎无解每次都要花大量时间调环境。Docker的做法很巧妙把环境本身变成了代码。你写一个Dockerfile把基础镜像、依赖安装、环境配置、启动命令全部声明在里面构建出来的镜像就是一台“预装好的机器”。别人拿了这个镜像不需要知道你怎么装的也不需要自己装一遍直接运行就能得到完全一致的环境。这种可复现性对团队协作的改善是巨大的。新同事入职不用再花两天配环境拉下镜像跑起来就能开发。测试环境也不用单独部署一套物理环境直接跑容器就行。我个人的体会是用了Docker之后团队里因为环境问题导致的“这代码在我这跑得好好的”之类的争执几乎绝迹了。1.2 Docker的三大核心概念镜像、容器、仓库这三个概念是整个Docker体系的基石很多人用了一段时间依然混淆有必要先厘清。镜像是一个只读的模板相当于软件安装包。镜像里包含了完整的运行环境和应用代码比如MySQL 8.0的镜像里面就预装了MySQL的二进制文件、配置文件、初始化脚本。镜像采用分层存储多个镜像可以共享底层数据所以拉取新镜像时如果底层已经存在下载量会小很多。容器是镜像的一个运行实例。镜像本身是静态的启动之后就是一个容器容器有独立的文件系统、网络栈和进程空间可以在里面运行命令、读写文件。容器销毁后所有变更会丢失除非你用数据卷把重要数据持久化到宿主机。仓库用来存放和分发镜像类似代码中心的Git仓库。Docker Hub是官方公共仓库国内访问时经常遇到下载慢的问题这个我们后面会在排查章节详细说。企业一般会搭私有的镜像仓库比如Harbor用来存放内部镜像安全性和速度都有保障。1.3 容器和虚拟机有什么区别有人会问虚拟机也能隔离环境为什么非要用容器两者最本质的区别是虚拟化层面不同。虚拟机是硬件级别的虚拟化每个虚拟机都包含完整的操作系统需要Hypervisor来管理和分配硬件资源启动速度、资源开销都比较大。容器则是操作系统级别的虚拟化直接共享宿主机的内核只隔离用户空间。打个比方虚拟机像是把一栋大楼拆成多套独立公寓每套公寓都有自己的基础设施水电表都是独立的容器像是同一套房子里的不同房间墙隔开了但水管、电路都是共用的。隔离性上虚拟机更强但容器更轻量、启动更快、密度更高。还有一个常见的误区是“容器里跑的是轻量级虚拟机”。这句话不准确。容器内的进程本质上是宿主机上的普通进程只是被namespace和cgroups技术隔离和限制了资源并没有完整的操作系统内核。所以容器里不能运行Linux内核模块、不能直接修改内核参数这对绝大多数应用来说是没影响的但涉及底层驱动的项目就要特别留意。2. 环境准备与安装选型——不同系统怎么装才不踩坑安装Docker看似简单但Windows、Ubuntu、CentOS各有各的门道尤其是Docker Desktop在Windows上经常遇到虚拟化相关的报错。这一章把三个主流平台的安装流程和坑位一次讲清楚。2.1 Windows平台Docker Desktop安装指南与虚拟化报错排查Windows上安装Docker首选Docker Desktop它内置了Docker引擎、Compose插件、Kubernetes集群并且提供了图形化界面管理容器。安装包在官网下载即可但有两个前置条件必须满足系统是Windows 10 64位专业版/企业版/教育版20H1及以上版本或者Windows 11必须在BIOS中开启硬件虚拟化Intel VT-x或AMD-V很多人在启动Docker Desktop时遇到这个报错Docker Desktop failed to start because virtualization support is not detected。这句英文翻译过来就是“检测不到虚拟化支持”。排查路径一般是三步先进任务管理器看看“性能”选项卡里虚拟化是否已启用如果显示“已禁用”需要重启电脑进BIOS开启VT-x/AMD-V如果确认已经开启再去“控制面板—程序—启用或关闭Windows功能”里勾选Hyper-V和“适用于Linux的Windows子系统”改完之后重启系统再启动Docker Desktop。这里有个实操细节值得注意如果电脑上同时装了VMware或VirtualBox和Hyper-V可能会冲突。Docker Desktop在Windows上主要依赖WSL2或Hyper-V后端如果你要用VMware跑其他虚拟机建议Docker Desktop选择WSL2作为后端两种虚拟化技术可以共存但Hyper-V和VMware冲突的情况很常见。还有一种情况是Windows系统更新滞后导致WSL组件不完整。启动Docker Desktop时如果提示WSL相关的错误打开命令行执行wsl --update更新内核组件即可。实测下来Windows上车Docker最稳定的路线是确认BIOS虚拟化开启 → 启用WSL2 → 安装Docker Desktop时勾选用WSL2替代Hyper-V → 启动后装一个Ubuntu子系统跑通全流程。2.2 Linux平台Ubuntu和CentOS的安装差异与版本选择Linux下安装Docker最干净的方式是用官方提供的脚本一条命令搞定curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh这个脚本会自动检测系统版本安装对应的Docker引擎和containerd并配置systemd服务。Ubuntu和Debian系列走的是apt源CentOS/RHEL系列走的是yum/dnf源脚本都帮你处理了。Ubuntu用户需要注意的点是老版本Ubuntu 14.04这类系统已经停止维护了如果还在上面装新版Docker需要先升级系统或者找旧版软件源。热搜词里就有“ubuntu 14 安装docker”我的建议是直接用Ubuntu 20.04及以上本身预装的Linux内核就满足Docker的运行要求装完即用。CentOS 7则是另一个故事它自带的docker版本太老如果直接yum install docker装的是1.13版本很多新特性和bug修复都没有。热搜词里有“centos7升级docker”这里给一个典型的升级操作流程# 卸载旧版本 sudo yum remove docker docker-client docker-common docker-engine # 安装yum-utils和配置仓库 sudo yum install -y yum-utils sudo yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo # 安装指定版本的docker-ce sudo yum install -y docker-ce-24.0.9 docker-ce-cli-24.0.9 containerd.io # 启动并设置开机自启 sudo systemctl start docker sudo systemctl enable docker选版本的小技巧是不要盲目追求最新版。Docker官方每个季度发布一个大版本但新版本偶尔会有兼容性问题比如Docker 4.20之后的某个版本在特定内核上有已知bug。生产环境建议选择已发布超过半年的稳定版本既能避免早期版本的大坑又不至于落后太多。2.3 安装后的权限配置与守护进程验证安装完成后第一件事不是急着拉镜像而是验证环境是否正常。执行docker version如果能看到Client和Server两端的信息说明引擎已经跑起来了。如果只有Client的信息而Server端报错通常意味着守护进程没启动或者权限不够。Docker的守护进程以root身份运行普通用户直接执行docker命令会报permission denied while trying to connect to the Docker daemon socket。解决办法有两个一个是每次命令前加sudo另一个是把当前用户加入docker组sudo usermod -aG docker $USER newgrp docker执行完之后重新登录终端docker命令就不用再加sudo了。注意newgrp docker是让当前会话立即生效如果不起作用就退出重开一个终端。还有一个验证命令值得养成习惯docker info。它会输出Docker的系统信息、容器数量、镜像数量、存储驱动、Cgroup驱动等关键指标。如果Storage Driver显示的是overlay2说明用的新版存储驱动性能好且稳定。如果显示的是aufs或devicemapper就要考虑升级内核了。3. 核心实操镜像拉取、容器启停与端口映射这一章聊的都是每天要用的高频命令。别看命令简单里面的参数组合和坑位我在生产环境里都踩过总结出来给你排掉。3.1 常用命令组合——从拉镜像到跑容器的完整流程先看一个最基础的流程拉取Nginx镜像并运行容器。# 拉取镜像 docker pull nginx:latest # 查看本地镜像 docker images # 运行容器宿主机8080端口映射到容器80端口 docker run -d --name my-nginx -p 8080:80 nginx # 查看运行中的容器 docker ps # 查看容器日志 docker logs -f my-nginx # 进入容器内部执行命令 docker exec -it my-nginx bash # 停止并删除容器 docker stop my-nginx docker rm my-nginx这段命令组合涵盖了日常80%的操作场景。-d表示后台运行不加的话容器会占据当前终端并持续输出日志--name给你的容器取名字后续操作都用名字引用不用记一串随机ID-p做端口映射宿主机端口在前、容器端口在后。一个常见的困惑是为什么容器跑起来了但浏览器访问不到大概率是端口映射没配对或者防火墙没放行。-p 8080:80的意思是访问宿主机8080端口会转发到容器内的80端口如果你访问8081那当然不通。防火墙方面CentOS默认开启firewalld需要手动放行端口sudo firewall-cmd --add-port8080/tcp --permanent sudo firewall-cmd --reload3.2 核心参数拆解端口映射、数据卷与环境变量Docker容器的参数设计非常讲究每个参数都有明确的语义。以MySQL为例跑一个容器要传一组参数先看完整命令再逐个解释docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD123456 \ -e MYSQL_DATABASEtestdb \ -v /data/mysql:/var/lib/mysql \ --restartalways \ mysql:8.0-e指定环境变量MySQL镜像启动脚本会读取MYSQL_ROOT_PASSWORD来设置root密码读取MYSQL_DATABASE自动创建数据库。环境变量是镜像和容器交互的主要方式不同的软件镜像有各自约定的环境变量用之前先查官方文档。-v挂载数据卷宿主机/data/mysql目录对应容器内的/var/lib/mysql。MySQL会把数据写到容器内的这个目录挂载之后数据实际保存在宿主机上即使容器删了重建数据还在。这一点极其重要容器是“无状态”的销毁再重建后数据全部清空没有数据卷的数据库容器等于一次性的。--restartalways是另一个容易被忽略但价值巨大的参数。它让容器在崩溃或宿主机重启后自动拉起生产环境必须加。不加这个参数宿主机重启后容器不会自动启动MySQL、Redis这些基础服务就全断了等你发现时可能已经造成事故了。还有一个实用参数是--network。Docker安装时会创建三个默认网络bridge桥接、host主机、none无网络。默认bridge模式下容器有自己的IP地址但容器之间互访不能靠IP直连因为IP可能变。更好的做法是把多个容器加入同一个自定义网络直接靠容器名互相访问docker network create mynet docker run -d --name mysql8 --network mynet mysql:8.0 docker run -d --name app --network mynet myapp:latest这样app容器内可以直接用mysql8:3306作为地址连接MySQL不用关心IP。运维上常说的“服务发现”容器网络的内置DNS就是最小化实现。3.3 数据管理让容器数据不随容器销毁而丢失数据卷理论要说透。容器内所有文件都存在于可写层中容器删除后这个可写层也随之消失。哪怕你在容器里执行了无数次SQL插入了海量数据容器一删全没了。最佳实践是把需要持久化的目录全部用-v挂载出来比如数据库的数据目录、日志目录、上传文件目录。数据卷还有一种玩法是命名卷docker volume create mysql-data docker run -d -v mysql-data:/var/lib/mysql mysql:8.0命名卷由Docker管理路径不用自己指定适合不想关心宿主机具体目录结构的场景。匿名卷则是容器运行时自动创建的卷但容易混淆和堆积不建议使用。另外提一下文件拷贝。容器和宿主机之间传文件用的是docker cp命令docker cp my-nginx:/etc/nginx/nginx.conf ./nginx.conf docker cp ./nginx.conf my-nginx:/etc/nginx/nginx.conf这个方法在小规模修改容器内文件时很好用但不推荐在生产环境这样改配置因为容器重建后改动全丢。配置还是应该走挂载或制作镜像的方式保持容器可重建性。4. 典型场景实战数据库、缓存、代码仓库与微服务理论说再多不如实战跑一遍。这一章从热搜词里挑几个最高频的场景把容器部署MySQL 8.0、Redis主从、GitLab、微服务项目的完整流程走一遍过程中穿插解析关键决策背后的原因。4.1 完整流程解析Docker安装MySQL 8.0并使用搜索引擎里“docker安装mysql”和“docker安装mysql8.0并使用”一直居高不下说明这是最刚需的场景。展开完整流程# 第一步拉取镜像最好指定版本 docker pull mysql:8.0 # 第二步创建挂载目录 mkdir -p /data/mysql/conf /data/mysql/data /data/mysql/logs # 第三步运行容器 docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDStrongAdmin123 \ -e TZAsia/Shanghai \ -v /data/mysql/conf:/etc/mysql/conf.d \ -v /data/mysql/data:/var/lib/mysql \ -v /data/mysql/logs:/var/log/mysql \ --restartalways \ mysql:8.0 # 第四步检查容器状态 docker ps | grep mysql8 docker logs mysql8这里有个高频报错有人用docker run mysql跑起来之后用docker ps查看发现容器一直在重启日志里报mbind: Operation not permitted之类。这个在MySQL 8.0镜像里不算致命错误但不影响正常使用。更需要注意的其实是权限问题挂载的宿主机目录如果权限不对MySQL容器会无法写入数据文件直接退出。宿主机目录权限不够时日志会提示chown: changing ownership of /var/lib/mysql/: Permission denied。解决办法是给目录正确授权chown -R 999:999 /data/mysql镜像内MySQL运行用户的UID是999宿主机的目录必须允许这个UID写入。很多人在这一步卡很久其实思路就是去镜像的Dockerfile或者运行时环境里查一下进程用户UID然后给宿主机目录做出相应授权。连接MySQL容器有两种方式。一种是在宿主机上直接执行mysql -h127.0.0.1 -P3306 -uroot -p另一种是先进容器再连docker exec -it mysql8 mysql -uroot -p“访问docker容器内的mysql”这个热搜词大概率就是连不上的问题。如果宿主机上有mysql客户端但连接时报Access denied先确认密码是否正确再确认root账号允许从哪个主机连接。MySQL 8.0默认的认证插件是caching_sha2_password旧版客户端可能不支持需要指定连接参数或者改用mysql_native_password。专门说一句直接改root的插件有风险更稳的做法是创建专用账号并授权。4.2 Redis主从复制的容器化部署Redis主从是缓存架构的入门配置用Docker部署特别合适因为多个容器跑在同一台机器上版本和配置都是一致的省去了编译安装Redis的麻烦。先创建一个自定义网络然后启动主从两个节点docker network create redis-net docker run -d \ --name redis-master \ --network redis-net \ -p 6379:6379 \ -v /data/redis/master:/data \ redis:7.0 redis-server --appendonly yes docker run -d \ --name redis-slave \ --network redis-net \ -p 6380:6379 \ -v /data/redis/slave:/data \ redis:7.0 redis-server --appendonly yes --replicaof redis-master 6379这里redis-server后面的参数直接传给容器内的Redis服务--replicaof redis-master 6379是把从节点指向主节点注意用的是容器名而不是IP这正是自定义网络的DNS解析能力。--appendonly yes开启AOF持久化数据会写到容器内/data目录再通过数据卷持久化到宿主机。验证主从是否正常进从节点执行docker exec -it redis-slave redis-cli info replication如果master_link_status显示up说明主从同步成功。如果显示down优先检查两个容器是否在同一网络内以及主节点的bind配置是否限制了连接。Redis 7.0默认配置只监听127.0.0.1但镜像内的默认配置是0.0.0.0所以容器间互访一般没问题。这套方案的实际价值在于一条命令就能拉起一套可用的主从集群数据独立持久化节点随时可以重建。生产环境在此基础上再加一个Redis Sentinel或者Cluster模式思路是一样的只是参数更复杂。4.3 Docker部署GitLab代码仓库GitLab算是Docker部署中最吃内存的应用之一官方推荐至少4GB内存单容器部署代码如下sudo docker run -d \ --name gitlab \ -p 8443:443 \ -p 8080:80 \ -p 8022:22 \ --restartalways \ -v /data/gitlab/config:/etc/gitlab \ -v /data/gitlab/logs:/var/log/gitlab \ -v /data/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest注意端口映射上用8080:80是因为宿主机80端口往往被其他Web服务占用。启动GitLab耗时比较长首次启动可能要等两三分钟期间用docker logs -f gitlab观察日志看到gitlab Reconfigured!字样就说明起来了。GitLab容器有几个细节要提醒。一是容器启动后访问页面会提示修改密码默认用户是root二是如果宿主机访问端口不是默认的80需要在/etc/gitlab/gitlab.rb里配置external_url为http://宿主机IP:8080否则页面生成的仓库地址和克隆URL会不正确三是SSH端口映射后克隆地址里的端口要用22对应的宿主机端口比如上面的8022。GitLab这种重量级应用容器方式部署的最大优势就是升级方便。官方每年发N个版本传统方式升级可能要改配置文件、跑迁移容器方式只要换镜像重建就行数据因为挂载在外面不会丢。4.4 微服务项目的镜像打包与Compose编排微服务多容器编排单条docker run已经不够用了Docker Compose是第一步。热搜词里有“docker compose安装”“idea 打包docker镜像”“docker部署微服务项目”这几个连起来正是微服务容器化的一条完整链路。先看Compose文件长什么样。以一个小型电商系统为例包含网关、用户服务和订单服务三个节点外加MySQL和Redisversion: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: 123456 volumes: - mysql-data:/var/lib/mysql networks: - app-net redis: image: redis:7.0 networks: - app-net user-service: build: ./user-service ports: - 8081:8081 environment: SPRING_PROFILES_ACTIVE: docker depends_on: - mysql - redis networks: - app-net order-service: build: ./order-service ports: - 8082:8082 environment: SPRING_PROFILES_ACTIVE: docker depends_on: - mysql - redis networks: - app-net gateway: build: ./gateway ports: - 8080:8080 depends_on: - user-service - order-service networks: - app-net volumes: mysql-data: networks: app-net:这个Compose定义里build指向各个服务的目录目录里有对应的Dockerfile。depends_on控制启动顺序MySQL和Redis先于业务服务启动。注意depends_on只保证启动顺序不保证服务就绪所以业务代码里要加连接重试机制。启动整个编排用一条命令docker compose up -d查看状态docker compose ps停止docker compose down这里说一个新的操作经验Compose文件中的服务名就是容器之间的DNS主机名。比如user-service的配置里把数据库地址写mysql:3306而不是127.0.0.1:3306这就是微服务容器间通信的正确姿势。很多人第一次搞微服务容器化配置数据库地址仍然写localhost结果容器一启动就报“找不到数据库”根因是没有理解容器的网络命名空间彼此独立。再补充一下IDEA里打包Docker镜像的两种方式。一种是项目里写好Dockerfile用Maven插件dockerfile-maven-plugin打包时自动构建镜像另一种是IDEA自带的Docker插件连接远程Docker守护进程后右键Dockerfile直接Build镜像。推荐用前者构建过程纳入CI管线可控性更强。5. 镜像下载慢、权限报错与网络不通的排查实录这一章挑三个高频问题详细讲这些都是实战中每天都会遇到的排查思路比单个命令更重要。5.1 镜像下载慢的解决方案国内直连Docker Hub拉镜像速度一言难尽。几GB的镜像可能要下半小时甚至更久下载到一半断了还要从头再来。解决方案是用镜像加速器。Docker守护进程支持配置多个registry-mirrors配置方法是在/etc/docker/daemon.json里加参数sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.1ms.run, https://docker.xuanyuan.me ] } EOF sudo systemctl daemon-reload sudo systemctl restart docker配置完之后执行docker info在输出里找到Registry Mirrors一节看到配置的加速器地址就说明生效了。此后docker pull会自动走加速器速度会有明显提升。如果加速器也不稳定还有一个替代方案拉镜像时临时指定代理仓库地址。比如原本是docker pull nginx:latest可以改为从某些镜像站拉取后重新打标签docker pull docker.xuanyuan.me/library/nginx:latest docker tag docker.xuanyuan.me/library/nginx:latest nginx:latest但这招比较繁琐而且第三方仓库的安全性需要自行判断。生产环境有条件的话建议搭一套Harbor私有仓库内部网络分发镜像的速度和稳定性都远超公网仓库。这个投入绝对值得。5.2 permission denied与Docker服务启动失败“permission denied while trying to connect to the Docker daemon socket”这个报错出现频率极高。排错思路分三步第一步检查Docker守护进程是否在运行systemctl status docker如果状态不是active (running)启动它sudo systemctl start docker sudo systemctl enable docker第二步确认当前用户是否有权限。执行docker ps报权限错误时看下用户是否在docker组groups $USER如果没有显示docker按前面第二章的方法加入docker组。第三步如果服务启动失败看日志journalctl -u docker -n 100实际排错中经常发现服务启动失败是因为配置文件写坏了比如/etc/docker/daemon.json的JSON格式错误逗号多写了或者大括号不对。这个时候用docker daemon的命令行格式检查或者直接把daemon.json备份后改用最小配置逐渐添加参数定位。还有一个容易忽略的情况磁盘空间满了。Docker的所有镜像、容器、卷都存放在/var/lib/docker目录如果这个分区被写满容器操作同样会报错而且报错信息不一定直说磁盘满。养成习惯先用df -h检查磁盘再排查其他原因。5.3 Docker网络不通的常见根因“docker网络不通”是个大话题但常见的根因就那么几个桥接网络模式导致的容器间互访失败、宿主机防火墙、DNS解析问题。最常见的是容器内访问外网不通。默认bridge模式下容器通过NAT访问外网依赖宿主机IP转发。执行以下两个命令确认开启转发sysctl net.ipv4.ip_forward如果输出是0开启echo 1 /proc/sys/net/ipv4/ip_forward宿主机防火墙如果开了需要让转发流量通过sudo iptables -P FORWARD ACCEPT这个设置重启后恢复默认要持久化的话把配置写进/etc/sysctl.conf或者用firewalld的富规则表示。另一个典型问题是容器内访问宿主机服务。容器内的localhost指的是容器自己不是宿主机。要访问宿主机上的服务需要从容器内访问网关地址也就是host.docker.internal这个特殊主机名。在Docker Desktop的环境里这个域名是天然支持的Linux上手动挂载--add-hosthost.docker.internal:host-gateway即可。我在排障过程中最大的体会是网络问题一定要分层排查先确认宿主机本身网络通不通再确认容器能不能解析DNS再确认容器间能不能互通最后确认端口映射和防火墙。每一步用最简单的方式验证比如在容器内执行ping 8.8.8.8验证基础连通性ping baidu.com验证DNS少了哪一层就锁定哪一层。6. 高频问题速查表——按报错信息直接翻答案报错/问题现象原因分析解决方案Virtualization support not detectedWindowsBIOS未开启硬件虚拟化进BIOS开启VT-x/AMD-V启用WSL2和Hyper-V重启系统permission denied while trying to connect to the Docker daemon socket用户不在docker组sudo usermod -aG docker $USER后重新登录Docker服务启动失败配置文件错误、磁盘满、内核模块缺失journalctl -u docker -n 100查看日志逐一排查docker pull速度极慢默认走Docker Hub公网配置registry-mirrors或使用私有仓库容器启动后立刻退出启动命令错误、环境变量缺失、挂载目录权限不足docker logs 容器名查看退出前的日志MySQL容器起不来日志报Permission denied宿主机挂载目录的属主不匹配容器内用户chown -R 999:999 目录访问不到容器内的MySQL端口映射错误或防火墙未放行检查-p 3306:3306宿主机放行3306端口Redis主从状态显示down两个容器不在同一网络或主节点bind配置将主从容器加入同一自定义网络用容器名代替IPDocker Compose项目启动失败exit status 1build上下文路径写错、端口被占用、环境变量缺失先docker compose config校验配置语法再逐个服务查看日志容器删了数据全没了未挂载数据卷启动容器时用-v或--mount挂载数据目录到宿主机最后分享一个我自己的操作习惯凡是生产环境用的容器启动命令都会写到脚本或者Compose文件里绝不手动一个个敲参数。原因有两个一个是可复用换台机器能直接在相同环境复现另一个是可审计团队成员看得懂这个服务是怎么跑的不会出现“这个容器谁起的”这种黑历史。Docker的核心理念就是基础设施即代码把环境定义变成文件把操作流程变成标准化流程这才是容器技术真正值钱的地方。还有个很小的技巧容器起不来的时候不要急着删了重来先执行docker logs看日志再执行docker inspect看配置。很多问题从日志里一眼就能看出来比盲目重试高效得多。运维的本质是观察和判断不是不断执行命令。
1. 容器技术到底解决什么问题——先把核心理念捋清楚做开发和运维这几年我反复给团队讲过一句话能让你从环境配置的泥潭里真正解脱出来的工具不多Docker绝对算一个。这个系列前两篇聊了容器的基础概念和镜像原理这一篇我们直接上手讲透从安装、部署到排错的完整链路。文章里涉及的操作我都实测过尽量用大白话把原理和步骤讲明白保证你跟着做就能跑起来。先说清楚Docker解决的核心问题。以前部署一个应用最头疼的是环境不一致开发用Windows测试用CentOS生产是Ubuntu同一个代码在不同机器上表现完全不一样光是装依赖就能耗掉半天。最经典的段子就是“在我机器上是好的啊”本质上就是环境差异导致的。Docker把应用连同它的运行环境一起打包成镜像不管是物理机、虚拟机还是云服务器只要内核支持容器就能跑出完全一致的效果。“一次构建处处运行”这句话不是口号是实打实的生产力提升。另外一个痛点在于资源利用。传统虚拟机动辄几个GB的内存开销因为每个虚拟机都要装完整操作系统。而Docker容器直接共享宿主机内核只隔离进程和文件系统启动一个容器往往只需要几百毫秒内存占用可能只有几十MB。换句话说一台8GB内存的服务器跑虚拟机可能只能开两三个实例跑Docker容器能开二三十个。这个系列叫“容器技术3”重点不是再讲一遍“什么是镜像”而是把安装部署、命令使用、典型场景、常见坑位一次讲透。无论你是刚接触容器的新手还是被docker权限、网络不通、MySQL容器连不上折磨过的老手这篇都有对应的解法。你不需要先精通Linux只要会基本的命令行操作就能跟着跑通整个流程。1.1 从“环境地狱”到“一次构建处处运行”环境地狱这个词经历过的人都懂。举个实际场景你要部署一个Java微服务需要JDK 17、Maven、Redis、MySQL还要配一堆环境变量。光这些还不够不同版本的依赖库之间还可能互相冲突升级一个包另一个就崩。这种问题在传统部署方式下几乎无解每次都要花大量时间调环境。Docker的做法很巧妙把环境本身变成了代码。你写一个Dockerfile把基础镜像、依赖安装、环境配置、启动命令全部声明在里面构建出来的镜像就是一台“预装好的机器”。别人拿了这个镜像不需要知道你怎么装的也不需要自己装一遍直接运行就能得到完全一致的环境。这种可复现性对团队协作的改善是巨大的。新同事入职不用再花两天配环境拉下镜像跑起来就能开发。测试环境也不用单独部署一套物理环境直接跑容器就行。我个人的体会是用了Docker之后团队里因为环境问题导致的“这代码在我这跑得好好的”之类的争执几乎绝迹了。1.2 Docker的三大核心概念镜像、容器、仓库这三个概念是整个Docker体系的基石很多人用了一段时间依然混淆有必要先厘清。镜像是一个只读的模板相当于软件安装包。镜像里包含了完整的运行环境和应用代码比如MySQL 8.0的镜像里面就预装了MySQL的二进制文件、配置文件、初始化脚本。镜像采用分层存储多个镜像可以共享底层数据所以拉取新镜像时如果底层已经存在下载量会小很多。容器是镜像的一个运行实例。镜像本身是静态的启动之后就是一个容器容器有独立的文件系统、网络栈和进程空间可以在里面运行命令、读写文件。容器销毁后所有变更会丢失除非你用数据卷把重要数据持久化到宿主机。仓库用来存放和分发镜像类似代码中心的Git仓库。Docker Hub是官方公共仓库国内访问时经常遇到下载慢的问题这个我们后面会在排查章节详细说。企业一般会搭私有的镜像仓库比如Harbor用来存放内部镜像安全性和速度都有保障。1.3 容器和虚拟机有什么区别有人会问虚拟机也能隔离环境为什么非要用容器两者最本质的区别是虚拟化层面不同。虚拟机是硬件级别的虚拟化每个虚拟机都包含完整的操作系统需要Hypervisor来管理和分配硬件资源启动速度、资源开销都比较大。容器则是操作系统级别的虚拟化直接共享宿主机的内核只隔离用户空间。打个比方虚拟机像是把一栋大楼拆成多套独立公寓每套公寓都有自己的基础设施水电表都是独立的容器像是同一套房子里的不同房间墙隔开了但水管、电路都是共用的。隔离性上虚拟机更强但容器更轻量、启动更快、密度更高。还有一个常见的误区是“容器里跑的是轻量级虚拟机”。这句话不准确。容器内的进程本质上是宿主机上的普通进程只是被namespace和cgroups技术隔离和限制了资源并没有完整的操作系统内核。所以容器里不能运行Linux内核模块、不能直接修改内核参数这对绝大多数应用来说是没影响的但涉及底层驱动的项目就要特别留意。2. 环境准备与安装选型——不同系统怎么装才不踩坑安装Docker看似简单但Windows、Ubuntu、CentOS各有各的门道尤其是Docker Desktop在Windows上经常遇到虚拟化相关的报错。这一章把三个主流平台的安装流程和坑位一次讲清楚。2.1 Windows平台Docker Desktop安装指南与虚拟化报错排查Windows上安装Docker首选Docker Desktop它内置了Docker引擎、Compose插件、Kubernetes集群并且提供了图形化界面管理容器。安装包在官网下载即可但有两个前置条件必须满足系统是Windows 10 64位专业版/企业版/教育版20H1及以上版本或者Windows 11必须在BIOS中开启硬件虚拟化Intel VT-x或AMD-V很多人在启动Docker Desktop时遇到这个报错Docker Desktop failed to start because virtualization support is not detected。这句英文翻译过来就是“检测不到虚拟化支持”。排查路径一般是三步先进任务管理器看看“性能”选项卡里虚拟化是否已启用如果显示“已禁用”需要重启电脑进BIOS开启VT-x/AMD-V如果确认已经开启再去“控制面板—程序—启用或关闭Windows功能”里勾选Hyper-V和“适用于Linux的Windows子系统”改完之后重启系统再启动Docker Desktop。这里有个实操细节值得注意如果电脑上同时装了VMware或VirtualBox和Hyper-V可能会冲突。Docker Desktop在Windows上主要依赖WSL2或Hyper-V后端如果你要用VMware跑其他虚拟机建议Docker Desktop选择WSL2作为后端两种虚拟化技术可以共存但Hyper-V和VMware冲突的情况很常见。还有一种情况是Windows系统更新滞后导致WSL组件不完整。启动Docker Desktop时如果提示WSL相关的错误打开命令行执行wsl --update更新内核组件即可。实测下来Windows上车Docker最稳定的路线是确认BIOS虚拟化开启 → 启用WSL2 → 安装Docker Desktop时勾选用WSL2替代Hyper-V → 启动后装一个Ubuntu子系统跑通全流程。2.2 Linux平台Ubuntu和CentOS的安装差异与版本选择Linux下安装Docker最干净的方式是用官方提供的脚本一条命令搞定curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh这个脚本会自动检测系统版本安装对应的Docker引擎和containerd并配置systemd服务。Ubuntu和Debian系列走的是apt源CentOS/RHEL系列走的是yum/dnf源脚本都帮你处理了。Ubuntu用户需要注意的点是老版本Ubuntu 14.04这类系统已经停止维护了如果还在上面装新版Docker需要先升级系统或者找旧版软件源。热搜词里就有“ubuntu 14 安装docker”我的建议是直接用Ubuntu 20.04及以上本身预装的Linux内核就满足Docker的运行要求装完即用。CentOS 7则是另一个故事它自带的docker版本太老如果直接yum install docker装的是1.13版本很多新特性和bug修复都没有。热搜词里有“centos7升级docker”这里给一个典型的升级操作流程# 卸载旧版本 sudo yum remove docker docker-client docker-common docker-engine # 安装yum-utils和配置仓库 sudo yum install -y yum-utils sudo yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo # 安装指定版本的docker-ce sudo yum install -y docker-ce-24.0.9 docker-ce-cli-24.0.9 containerd.io # 启动并设置开机自启 sudo systemctl start docker sudo systemctl enable docker选版本的小技巧是不要盲目追求最新版。Docker官方每个季度发布一个大版本但新版本偶尔会有兼容性问题比如Docker 4.20之后的某个版本在特定内核上有已知bug。生产环境建议选择已发布超过半年的稳定版本既能避免早期版本的大坑又不至于落后太多。2.3 安装后的权限配置与守护进程验证安装完成后第一件事不是急着拉镜像而是验证环境是否正常。执行docker version如果能看到Client和Server两端的信息说明引擎已经跑起来了。如果只有Client的信息而Server端报错通常意味着守护进程没启动或者权限不够。Docker的守护进程以root身份运行普通用户直接执行docker命令会报permission denied while trying to connect to the Docker daemon socket。解决办法有两个一个是每次命令前加sudo另一个是把当前用户加入docker组sudo usermod -aG docker $USER newgrp docker执行完之后重新登录终端docker命令就不用再加sudo了。注意newgrp docker是让当前会话立即生效如果不起作用就退出重开一个终端。还有一个验证命令值得养成习惯docker info。它会输出Docker的系统信息、容器数量、镜像数量、存储驱动、Cgroup驱动等关键指标。如果Storage Driver显示的是overlay2说明用的新版存储驱动性能好且稳定。如果显示的是aufs或devicemapper就要考虑升级内核了。3. 核心实操镜像拉取、容器启停与端口映射这一章聊的都是每天要用的高频命令。别看命令简单里面的参数组合和坑位我在生产环境里都踩过总结出来给你排掉。3.1 常用命令组合——从拉镜像到跑容器的完整流程先看一个最基础的流程拉取Nginx镜像并运行容器。# 拉取镜像 docker pull nginx:latest # 查看本地镜像 docker images # 运行容器宿主机8080端口映射到容器80端口 docker run -d --name my-nginx -p 8080:80 nginx # 查看运行中的容器 docker ps # 查看容器日志 docker logs -f my-nginx # 进入容器内部执行命令 docker exec -it my-nginx bash # 停止并删除容器 docker stop my-nginx docker rm my-nginx这段命令组合涵盖了日常80%的操作场景。-d表示后台运行不加的话容器会占据当前终端并持续输出日志--name给你的容器取名字后续操作都用名字引用不用记一串随机ID-p做端口映射宿主机端口在前、容器端口在后。一个常见的困惑是为什么容器跑起来了但浏览器访问不到大概率是端口映射没配对或者防火墙没放行。-p 8080:80的意思是访问宿主机8080端口会转发到容器内的80端口如果你访问8081那当然不通。防火墙方面CentOS默认开启firewalld需要手动放行端口sudo firewall-cmd --add-port8080/tcp --permanent sudo firewall-cmd --reload3.2 核心参数拆解端口映射、数据卷与环境变量Docker容器的参数设计非常讲究每个参数都有明确的语义。以MySQL为例跑一个容器要传一组参数先看完整命令再逐个解释docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD123456 \ -e MYSQL_DATABASEtestdb \ -v /data/mysql:/var/lib/mysql \ --restartalways \ mysql:8.0-e指定环境变量MySQL镜像启动脚本会读取MYSQL_ROOT_PASSWORD来设置root密码读取MYSQL_DATABASE自动创建数据库。环境变量是镜像和容器交互的主要方式不同的软件镜像有各自约定的环境变量用之前先查官方文档。-v挂载数据卷宿主机/data/mysql目录对应容器内的/var/lib/mysql。MySQL会把数据写到容器内的这个目录挂载之后数据实际保存在宿主机上即使容器删了重建数据还在。这一点极其重要容器是“无状态”的销毁再重建后数据全部清空没有数据卷的数据库容器等于一次性的。--restartalways是另一个容易被忽略但价值巨大的参数。它让容器在崩溃或宿主机重启后自动拉起生产环境必须加。不加这个参数宿主机重启后容器不会自动启动MySQL、Redis这些基础服务就全断了等你发现时可能已经造成事故了。还有一个实用参数是--network。Docker安装时会创建三个默认网络bridge桥接、host主机、none无网络。默认bridge模式下容器有自己的IP地址但容器之间互访不能靠IP直连因为IP可能变。更好的做法是把多个容器加入同一个自定义网络直接靠容器名互相访问docker network create mynet docker run -d --name mysql8 --network mynet mysql:8.0 docker run -d --name app --network mynet myapp:latest这样app容器内可以直接用mysql8:3306作为地址连接MySQL不用关心IP。运维上常说的“服务发现”容器网络的内置DNS就是最小化实现。3.3 数据管理让容器数据不随容器销毁而丢失数据卷理论要说透。容器内所有文件都存在于可写层中容器删除后这个可写层也随之消失。哪怕你在容器里执行了无数次SQL插入了海量数据容器一删全没了。最佳实践是把需要持久化的目录全部用-v挂载出来比如数据库的数据目录、日志目录、上传文件目录。数据卷还有一种玩法是命名卷docker volume create mysql-data docker run -d -v mysql-data:/var/lib/mysql mysql:8.0命名卷由Docker管理路径不用自己指定适合不想关心宿主机具体目录结构的场景。匿名卷则是容器运行时自动创建的卷但容易混淆和堆积不建议使用。另外提一下文件拷贝。容器和宿主机之间传文件用的是docker cp命令docker cp my-nginx:/etc/nginx/nginx.conf ./nginx.conf docker cp ./nginx.conf my-nginx:/etc/nginx/nginx.conf这个方法在小规模修改容器内文件时很好用但不推荐在生产环境这样改配置因为容器重建后改动全丢。配置还是应该走挂载或制作镜像的方式保持容器可重建性。4. 典型场景实战数据库、缓存、代码仓库与微服务理论说再多不如实战跑一遍。这一章从热搜词里挑几个最高频的场景把容器部署MySQL 8.0、Redis主从、GitLab、微服务项目的完整流程走一遍过程中穿插解析关键决策背后的原因。4.1 完整流程解析Docker安装MySQL 8.0并使用搜索引擎里“docker安装mysql”和“docker安装mysql8.0并使用”一直居高不下说明这是最刚需的场景。展开完整流程# 第一步拉取镜像最好指定版本 docker pull mysql:8.0 # 第二步创建挂载目录 mkdir -p /data/mysql/conf /data/mysql/data /data/mysql/logs # 第三步运行容器 docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDStrongAdmin123 \ -e TZAsia/Shanghai \ -v /data/mysql/conf:/etc/mysql/conf.d \ -v /data/mysql/data:/var/lib/mysql \ -v /data/mysql/logs:/var/log/mysql \ --restartalways \ mysql:8.0 # 第四步检查容器状态 docker ps | grep mysql8 docker logs mysql8这里有个高频报错有人用docker run mysql跑起来之后用docker ps查看发现容器一直在重启日志里报mbind: Operation not permitted之类。这个在MySQL 8.0镜像里不算致命错误但不影响正常使用。更需要注意的其实是权限问题挂载的宿主机目录如果权限不对MySQL容器会无法写入数据文件直接退出。宿主机目录权限不够时日志会提示chown: changing ownership of /var/lib/mysql/: Permission denied。解决办法是给目录正确授权chown -R 999:999 /data/mysql镜像内MySQL运行用户的UID是999宿主机的目录必须允许这个UID写入。很多人在这一步卡很久其实思路就是去镜像的Dockerfile或者运行时环境里查一下进程用户UID然后给宿主机目录做出相应授权。连接MySQL容器有两种方式。一种是在宿主机上直接执行mysql -h127.0.0.1 -P3306 -uroot -p另一种是先进容器再连docker exec -it mysql8 mysql -uroot -p“访问docker容器内的mysql”这个热搜词大概率就是连不上的问题。如果宿主机上有mysql客户端但连接时报Access denied先确认密码是否正确再确认root账号允许从哪个主机连接。MySQL 8.0默认的认证插件是caching_sha2_password旧版客户端可能不支持需要指定连接参数或者改用mysql_native_password。专门说一句直接改root的插件有风险更稳的做法是创建专用账号并授权。4.2 Redis主从复制的容器化部署Redis主从是缓存架构的入门配置用Docker部署特别合适因为多个容器跑在同一台机器上版本和配置都是一致的省去了编译安装Redis的麻烦。先创建一个自定义网络然后启动主从两个节点docker network create redis-net docker run -d \ --name redis-master \ --network redis-net \ -p 6379:6379 \ -v /data/redis/master:/data \ redis:7.0 redis-server --appendonly yes docker run -d \ --name redis-slave \ --network redis-net \ -p 6380:6379 \ -v /data/redis/slave:/data \ redis:7.0 redis-server --appendonly yes --replicaof redis-master 6379这里redis-server后面的参数直接传给容器内的Redis服务--replicaof redis-master 6379是把从节点指向主节点注意用的是容器名而不是IP这正是自定义网络的DNS解析能力。--appendonly yes开启AOF持久化数据会写到容器内/data目录再通过数据卷持久化到宿主机。验证主从是否正常进从节点执行docker exec -it redis-slave redis-cli info replication如果master_link_status显示up说明主从同步成功。如果显示down优先检查两个容器是否在同一网络内以及主节点的bind配置是否限制了连接。Redis 7.0默认配置只监听127.0.0.1但镜像内的默认配置是0.0.0.0所以容器间互访一般没问题。这套方案的实际价值在于一条命令就能拉起一套可用的主从集群数据独立持久化节点随时可以重建。生产环境在此基础上再加一个Redis Sentinel或者Cluster模式思路是一样的只是参数更复杂。4.3 Docker部署GitLab代码仓库GitLab算是Docker部署中最吃内存的应用之一官方推荐至少4GB内存单容器部署代码如下sudo docker run -d \ --name gitlab \ -p 8443:443 \ -p 8080:80 \ -p 8022:22 \ --restartalways \ -v /data/gitlab/config:/etc/gitlab \ -v /data/gitlab/logs:/var/log/gitlab \ -v /data/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest注意端口映射上用8080:80是因为宿主机80端口往往被其他Web服务占用。启动GitLab耗时比较长首次启动可能要等两三分钟期间用docker logs -f gitlab观察日志看到gitlab Reconfigured!字样就说明起来了。GitLab容器有几个细节要提醒。一是容器启动后访问页面会提示修改密码默认用户是root二是如果宿主机访问端口不是默认的80需要在/etc/gitlab/gitlab.rb里配置external_url为http://宿主机IP:8080否则页面生成的仓库地址和克隆URL会不正确三是SSH端口映射后克隆地址里的端口要用22对应的宿主机端口比如上面的8022。GitLab这种重量级应用容器方式部署的最大优势就是升级方便。官方每年发N个版本传统方式升级可能要改配置文件、跑迁移容器方式只要换镜像重建就行数据因为挂载在外面不会丢。4.4 微服务项目的镜像打包与Compose编排微服务多容器编排单条docker run已经不够用了Docker Compose是第一步。热搜词里有“docker compose安装”“idea 打包docker镜像”“docker部署微服务项目”这几个连起来正是微服务容器化的一条完整链路。先看Compose文件长什么样。以一个小型电商系统为例包含网关、用户服务和订单服务三个节点外加MySQL和Redisversion: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: 123456 volumes: - mysql-data:/var/lib/mysql networks: - app-net redis: image: redis:7.0 networks: - app-net user-service: build: ./user-service ports: - 8081:8081 environment: SPRING_PROFILES_ACTIVE: docker depends_on: - mysql - redis networks: - app-net order-service: build: ./order-service ports: - 8082:8082 environment: SPRING_PROFILES_ACTIVE: docker depends_on: - mysql - redis networks: - app-net gateway: build: ./gateway ports: - 8080:8080 depends_on: - user-service - order-service networks: - app-net volumes: mysql-data: networks: app-net:这个Compose定义里build指向各个服务的目录目录里有对应的Dockerfile。depends_on控制启动顺序MySQL和Redis先于业务服务启动。注意depends_on只保证启动顺序不保证服务就绪所以业务代码里要加连接重试机制。启动整个编排用一条命令docker compose up -d查看状态docker compose ps停止docker compose down这里说一个新的操作经验Compose文件中的服务名就是容器之间的DNS主机名。比如user-service的配置里把数据库地址写mysql:3306而不是127.0.0.1:3306这就是微服务容器间通信的正确姿势。很多人第一次搞微服务容器化配置数据库地址仍然写localhost结果容器一启动就报“找不到数据库”根因是没有理解容器的网络命名空间彼此独立。再补充一下IDEA里打包Docker镜像的两种方式。一种是项目里写好Dockerfile用Maven插件dockerfile-maven-plugin打包时自动构建镜像另一种是IDEA自带的Docker插件连接远程Docker守护进程后右键Dockerfile直接Build镜像。推荐用前者构建过程纳入CI管线可控性更强。5. 镜像下载慢、权限报错与网络不通的排查实录这一章挑三个高频问题详细讲这些都是实战中每天都会遇到的排查思路比单个命令更重要。5.1 镜像下载慢的解决方案国内直连Docker Hub拉镜像速度一言难尽。几GB的镜像可能要下半小时甚至更久下载到一半断了还要从头再来。解决方案是用镜像加速器。Docker守护进程支持配置多个registry-mirrors配置方法是在/etc/docker/daemon.json里加参数sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.1ms.run, https://docker.xuanyuan.me ] } EOF sudo systemctl daemon-reload sudo systemctl restart docker配置完之后执行docker info在输出里找到Registry Mirrors一节看到配置的加速器地址就说明生效了。此后docker pull会自动走加速器速度会有明显提升。如果加速器也不稳定还有一个替代方案拉镜像时临时指定代理仓库地址。比如原本是docker pull nginx:latest可以改为从某些镜像站拉取后重新打标签docker pull docker.xuanyuan.me/library/nginx:latest docker tag docker.xuanyuan.me/library/nginx:latest nginx:latest但这招比较繁琐而且第三方仓库的安全性需要自行判断。生产环境有条件的话建议搭一套Harbor私有仓库内部网络分发镜像的速度和稳定性都远超公网仓库。这个投入绝对值得。5.2 permission denied与Docker服务启动失败“permission denied while trying to connect to the Docker daemon socket”这个报错出现频率极高。排错思路分三步第一步检查Docker守护进程是否在运行systemctl status docker如果状态不是active (running)启动它sudo systemctl start docker sudo systemctl enable docker第二步确认当前用户是否有权限。执行docker ps报权限错误时看下用户是否在docker组groups $USER如果没有显示docker按前面第二章的方法加入docker组。第三步如果服务启动失败看日志journalctl -u docker -n 100实际排错中经常发现服务启动失败是因为配置文件写坏了比如/etc/docker/daemon.json的JSON格式错误逗号多写了或者大括号不对。这个时候用docker daemon的命令行格式检查或者直接把daemon.json备份后改用最小配置逐渐添加参数定位。还有一个容易忽略的情况磁盘空间满了。Docker的所有镜像、容器、卷都存放在/var/lib/docker目录如果这个分区被写满容器操作同样会报错而且报错信息不一定直说磁盘满。养成习惯先用df -h检查磁盘再排查其他原因。5.3 Docker网络不通的常见根因“docker网络不通”是个大话题但常见的根因就那么几个桥接网络模式导致的容器间互访失败、宿主机防火墙、DNS解析问题。最常见的是容器内访问外网不通。默认bridge模式下容器通过NAT访问外网依赖宿主机IP转发。执行以下两个命令确认开启转发sysctl net.ipv4.ip_forward如果输出是0开启echo 1 /proc/sys/net/ipv4/ip_forward宿主机防火墙如果开了需要让转发流量通过sudo iptables -P FORWARD ACCEPT这个设置重启后恢复默认要持久化的话把配置写进/etc/sysctl.conf或者用firewalld的富规则表示。另一个典型问题是容器内访问宿主机服务。容器内的localhost指的是容器自己不是宿主机。要访问宿主机上的服务需要从容器内访问网关地址也就是host.docker.internal这个特殊主机名。在Docker Desktop的环境里这个域名是天然支持的Linux上手动挂载--add-hosthost.docker.internal:host-gateway即可。我在排障过程中最大的体会是网络问题一定要分层排查先确认宿主机本身网络通不通再确认容器能不能解析DNS再确认容器间能不能互通最后确认端口映射和防火墙。每一步用最简单的方式验证比如在容器内执行ping 8.8.8.8验证基础连通性ping baidu.com验证DNS少了哪一层就锁定哪一层。6. 高频问题速查表——按报错信息直接翻答案报错/问题现象原因分析解决方案Virtualization support not detectedWindowsBIOS未开启硬件虚拟化进BIOS开启VT-x/AMD-V启用WSL2和Hyper-V重启系统permission denied while trying to connect to the Docker daemon socket用户不在docker组sudo usermod -aG docker $USER后重新登录Docker服务启动失败配置文件错误、磁盘满、内核模块缺失journalctl -u docker -n 100查看日志逐一排查docker pull速度极慢默认走Docker Hub公网配置registry-mirrors或使用私有仓库容器启动后立刻退出启动命令错误、环境变量缺失、挂载目录权限不足docker logs 容器名查看退出前的日志MySQL容器起不来日志报Permission denied宿主机挂载目录的属主不匹配容器内用户chown -R 999:999 目录访问不到容器内的MySQL端口映射错误或防火墙未放行检查-p 3306:3306宿主机放行3306端口Redis主从状态显示down两个容器不在同一网络或主节点bind配置将主从容器加入同一自定义网络用容器名代替IPDocker Compose项目启动失败exit status 1build上下文路径写错、端口被占用、环境变量缺失先docker compose config校验配置语法再逐个服务查看日志容器删了数据全没了未挂载数据卷启动容器时用-v或--mount挂载数据目录到宿主机最后分享一个我自己的操作习惯凡是生产环境用的容器启动命令都会写到脚本或者Compose文件里绝不手动一个个敲参数。原因有两个一个是可复用换台机器能直接在相同环境复现另一个是可审计团队成员看得懂这个服务是怎么跑的不会出现“这个容器谁起的”这种黑历史。Docker的核心理念就是基础设施即代码把环境定义变成文件把操作流程变成标准化流程这才是容器技术真正值钱的地方。还有个很小的技巧容器起不来的时候不要急着删了重来先执行docker logs看日志再执行docker inspect看配置。很多问题从日志里一眼就能看出来比盲目重试高效得多。运维的本质是观察和判断不是不断执行命令。
