你在Windows上兴冲冲装完Docker Desktop双击打开图标转了几圈后弹出一行英文Virtualization support not detected然后Docker Desktop直接启动失败。我当时第一次遇到这个报错也有点懵后来发现周围不少同事、网友在安装Docker时都卡在类似的地方——不是虚拟化没开就是WSL2没装好再不就是网络拉镜像慢到怀疑人生。这篇文章不打算写成一本Docker手册而是把我实际用下来的安装步骤、报错排查思路、常用命令以及MySQL、Redis主从、GitLab这几个常见部署场景整理成一篇可以直接照着操作的笔记。不管你是在Windows笔记本上跑Docker Desktop还是在Ubuntu、CentOS服务器上部署容器或是准备用Docker Compose编排多服务都能在里面找到对应的处理思路。1. 开始之前镜像、容器、仓库到底是啥关系很多人第一次接触Docker时会被这三个名词绕晕镜像Image、容器Container、仓库Repository。我习惯用一个类比来理解镜像就是一张“刻录好系统的光盘”里面包含了完整的操作系统、运行环境、应用代码和依赖容器就是你把这张光盘放进一台“虚拟光驱”里跑起来的实例可以随时启动、停止、删除仓库则是存放光盘的地方需要的时候从里面拉一张到本地。关键点在于镜像是只读的而容器在镜像之上多了一层可写层。你往容器里写文件、装东西改动只存在当前容器里一旦容器删了改动就没了。所以部署MySQL这类有状态服务时我通常会把数据目录挂载到宿主机或数据卷Volume里否则容器一删数据也跟着消失这个坑后面会专门说。那Docker到底解决什么问题最常见的一句话是“我本地跑得好好的怎么到你机器上就报错”。因为应用运行依赖操作系统版本、依赖库、配置文件、环境变量任何一个环节不对都可能起不来。而Docker把整个运行环境打包成镜像只要镜像能跑不管是在你的笔记本、测试机还是生产服务器上运行结果基本一致。这也是容器技术在开发和运维里越来越普及的核心原因——环境一致性和交付标准化。你还会听到“容器”和“虚拟机”的比较。虚拟机通常要模拟整个硬件占用的CPU、内存和磁盘空间很大启动要几十秒甚至几分钟容器则直接共享宿主机的内核只包含应用和它需要的依赖启动通常只要几秒钟资源占用也小很多。可以理解成虚拟机是“租了一整间毛坯房自己搬家具、自己装修”容器是“拎包入住的标准间装修效果完全一样代价是大家共用同一栋楼的管线系统”。2. 安装最劝退的一步Windows上Docker Desktop的虚拟化问题Windows用户安装Docker Desktop遇到最多的报错就是Virtualization support not detected还有一些人是安装完成后提示需要WSL2或Hyper-V。这些问题的根源几乎都指向同一个点系统的虚拟化功能没有正确开启。2.1 先确认虚拟化到底开没开打开任务管理器切到“性能”标签页看“CPU”那一项右下角会显示“虚拟化已启用”或“虚拟化已禁用”。如果显示已禁用那就得进BIOS开启。不同品牌主板进入BIOS的按键不太一样常见的是开机时按F2、Delete、F10具体看你电脑型号。进入BIOS后要找的关键词一般是Intel平台Intel Virtualization Technology通常简称VT-x或VT-dAMD平台SVM Mode也叫AMD-V把这一项从Disabled改成Enabled保存退出重新进系统再看任务管理器。这个操作很基础但很多人第一次就是卡在这里因为你装再多次Docker Desktop也没用底层虚拟化能力压根是关着的。2.2 Windows功能勾选和WSL2安装如果虚拟化显示已启用Docker Desktop还是起不来那多半是Windows功能没勾全。按WinR输入optionalfeatures打开“启用或关闭Windows功能”需要确保下面这几项处于勾选状态适用于Linux的Windows子系统WSL虚拟机平台Virtual Machine Platform在Windows 11上通常还需要勾选“Hyper-V”或至少保证虚拟化相关的底层组件存在。Win10和Win11默认没有开启WSL2内核需要执行一次内核更新。打开PowerShell管理员模式执行wsl --update wsl --set-default-version 2然后装一个Linux发行版直接在Microsoft Store里搜“Ubuntu”就能装。装完启动一次Ubuntu让它完成初始化用户配置Docker Desktop会对接WSL2后端。这里我建议优先用WSL2而不是Hyper-V作为Docker Desktop的后端因为WSL2的资源占用更小启动速度也更快日常开发体感更流畅。2.3 启动失败的高频报错npipe连接不上安装完成后打开Docker Desktop界面可能一直显示“Docker Engine stopping”或者“Failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen”。这个报错的意思很直白客户端程序连不上Docker引擎。我遇到过的原因主要有三种第一种是Docker引擎根本没启动起来。这时候先看右下角托盘的鲸鱼图标是什么状态点图标选“Restart”重新启动等待左侧显示“Engine running”再执行命令。第二种是Docker Desktop没有切到Linux容器模式。右键托盘鲸鱼图标确认“Switch to Linux containers”没有选中如果当前选中的是Windows容器模式大部分Linux镜像会无法使用甚至引擎都起不来。第三种是WSL2内核太旧或者没设置默认版本。回到PowerShell执行wsl --status看下内核版本如果不是最新就执行一次wsl --update然后重启Docker Desktop。我建议按这个顺序排查先看虚拟化状态再检查Windows功能然后更新WSL2内核和发行版最后才重装Docker Desktop。别一上来就卸载重装多半白折腾。3. Linux服务器安装与启动失败排查Ubuntu、CentOS 7升级生产环境里大部分Docker都跑在Linux服务器上。不同发行版的安装方式有差异我分别在Ubuntu和CentOS上部署过踩过的坑也集中在权限和启动失败这两块。3.1 Ubuntu上的安装流程Ubuntu安装Docker有很多种方式最简单的是直接用官方源安装Docker Enginesudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin装完执行systemctl status docker看下状态。如果显示active (running)就说明起来了。有些云服务器的Ubuntu镜像自带了旧版docker.io如果发现命令冲突或版本太老可以先卸载旧包再装新版本sudo apt remove -y docker docker-engine docker.io containerd runc3.2 CentOS 7升级DockerCentOS 7自带源里的docker版本极老很多新镜像都无法正常运行。我遇到过用户直接用yum install docker装上老版本结果跑MySQL 8.0镜像直接起不来。CentOS 7上升级Docker可以参考sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum install -y docker-ce docker-ce-cli containerd.io其中yum-utils是为了提供yum-config-manager命令也可以直接手动写repo文件。安装完成后启动并设置开机自启sudo systemctl start docker sudo systemctl enable docker注意CentOS 7上如果内核版本偏低某些Docker功能可能受限。比如老内核上的overlay2存储驱动可能出现稳定性问题碰到这种情况可以先yum update升级内核再继续。3.3 服务启动失败和权限错误的处理docker服务启动失败是Linux部署里非常常见的报错。排查时别只看systemctl的状态要去看真正的日志sudo journalctl -u docker --no-pager -n 100或者sudo dockerd --debug我看到过的启动失败原因里最多的是daemon.json配置写错比如JSON语法错误或者把镜像加速器地址拼错了。Docker守护进程启动时会读取/etc/docker/daemon.json只要文件有问题整个服务都起不来。修复后执行sudo systemctl daemon-reload sudo systemctl restart docker。另一个高频问题是权限错误。刚装完Docker时普通用户执行docker ps会看到docker: permission denied while trying to connect to the Docker daemon socket这是因为Docker的socket文件默认属于root用户和docker组。解决办法是把自己加入docker用户组sudo usermod -aG docker $USER newgrp docker重新登录终端后就能直接执行docker命令不需要每一条都加sudo。这里要提醒一句加入docker组后这个用户的权限几乎等同于root因为docker组可以管理宿主机上的容器和镜像生产环境要谨慎管理成员。4. 镜像下载慢、网络不通、权限错误的实战排查清单安装完Docker之后“镜像下载慢”基本是所有人都会遇到的下一个难题。默认镜像源在国外国内网络拉取一个几百MB的镜像动辄十几分钟甚至直接超时。解决办法是配置镜像加速器。在Linux上编辑/etc/docker/daemon.json改成类似下面的内容示例地址需要根据你实际可用的服务填写{ registry-mirrors: [https://docker.mirrors.example.com] }保存后执行sudo systemctl daemon-reload sudo systemctl restart docker配置后可以用docker info查看Registry Mirrors一栏确认是否生效。Windows版Docker Desktop则在设置界面Settings - Docker Engine里直接编辑该配置。配置加速器不是必须的但实测能极大缩短镜像拉取时间尤其是初次构建基础环境时体验完全不同。再说“docker网络不通”这个搜索热词。我见过不少新手启动容器后在宿主机上访问不了容器内的服务。排查思路按照下面几步走第一检查端口映射。运行容器时如果没有加-p 宿主机端口:容器端口外部就访问不了容器内的服务。比如docker run -d --name web -p 8080:80 nginx这样宿主机8080端口才会转发到容器80端口访问http://宿主机IP:8080才能看到页面。第二检查容器网络模式。默认的bridge网络下容器和宿主机之间通过NAT通信如果容器需要和宿主机上其他服务互通要注意网络隔离。可以用docker network ls查看当前网络用docker inspect 容器名查看容器所在网络和IP。第三在容器内部试一下网络到底通不通。进入容器的命令docker exec -it web curl http://容器IP如果容器里没装curl可以用wget或先执行apt update apt install -y curl临时装一个仅限调试容器重建后会丢失。这种先内部测、再外部测的方法是我最常用的排查手段能快速定位问题是出在容器内部还是宿主机防火墙。第四检查宿主机防火墙。有些云服务器默认安全组没放行端口或者firewalld/iptables把端口挡住了容器本身映射正常也访问不了。Linux上可以先sudo firewall-cmd --list-ports如果端口没放行执行sudo firewall-cmd --zonepublic --add-port8080/tcp --permanent sudo firewall-cmd --reload权限错误的处理前面说过这里不再重复。真正想提醒的是遇到任何容器异常先看日志再动手docker logs -f --tail 200 容器名能省掉一大半盲目排查的时间。5. 常用命令从跑起来到用明白命令这块我按镜像、容器、数据管理三类整理每一条都标了实际用途方便你当成速查表用。5.1 镜像相关命令docker pull nginx:latest # 拉取镜像 docker images # 查看本地镜像列表 docker rmi nginx # 删除镜像前提是没有容器在使用 docker tag nginx mynginx:1.0 # 给镜像打标签 docker build -t myapp:1.0 . # 根据Dockerfile构建镜像用docker images看镜像时重点关注REPOSITORY、TAG和SIZE三列。同一个镜像如果标签是latest每次拉取时会自动获取最新版本但要注意镜像更新后已经创建的容器不会跟着更新必须基于新镜像重新创建容器。5.2 容器生命周期命令docker run -d --name web -p 8080:80 nginx # 后台运行挂端口命名 docker ps # 查看运行中的容器 docker ps -a # 查看所有容器含已停止 docker start web # 启动已存在的容器 docker stop web # 停止容器 docker restart web # 重启容器 docker rm web # 删除容器docker run有几个关键参数可以说一下。-d是后台运行-it是交互式终端通常用于调试--name给容器起名后续操作直接用这个名字引用比记一长串容器ID方便-p做端口映射格式是“宿主机端口:容器端口”--restart设置重启策略比如--restartalways可以保证Docker服务重启或宿主机重启后容器自动拉起对常驻服务很有用。5.3 进入容器、查看日志、拷文件docker exec -it web bash # 进入容器内部容器里需要有bash docker logs -f --tail 200 web # 持续输出最近200行日志 docker cp 本地文件 web:/data # 把文件拷入容器 docker cp web:/data/文件 本地路径 # 从容器拷出文件 docker inspect web # 查看容器详细信息网络、挂载、状态都在这 docker stats # 查看容器CPU和内存占用进入容器后你会发现它的文件系统是独立于宿主机的但数据卷挂载的目录会同步所以“拷入拷出”操作在生产环境里尽量少用维护数据还是交给卷或挂载目录更规范。5.4 一个最基础的示例跑Nginx装好Docker不知道跑什么实验合适那就先跑一次Nginxdocker run -d --name web -p 8080:80 nginx浏览器访问http://localhost:8080看到Nginx欢迎页说明Docker安装成功容器网络和端口映射都正常。测试完用docker stop web docker rm web把它清理掉。这个流程是我检测一台新机器Docker环境是否完好的标准动作比直接跑业务镜像快得多。data和日志相关的参数也顺便提一下参数作用推荐场景-v 卷名:容器路径数据卷持久化MySQL、PostgreSQL等有状态服务--restartalways容器退出后自动重启常驻服务、定时任务--network 自定义网络接入指定容器网络多容器互相通信、主从复制-e KEYVALUE设置容器内环境变量数据库初始密码、应用配置6. 三个高频实战场景MySQL 8.0、Redis主从、GitLab安装和命令跑通了接下来是真正让Docker产生价值的部分——用容器部署常用软件。我挑三个大家搜索频率最高的场景来展开MySQL 8.0、Redis主从、GitLab社区版。6.1 MySQL 8.0的容器化部署部署MySQL 8.0我推荐直接用官方镜像核心命令docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDYourPassword \ -e TZAsia/Shanghai \ -v mysql-data:/var/lib/mysql \ -v mysql-config:/etc/mysql/conf.d \ --restartalways \ mysql:8.0 \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_unicode_ci这里几个参数为什么重要我拆开说MYSQL_ROOT_PASSWORD首次初始化时设置root密码只在数据目录为空时生效。如果后面想改密码不要直接改这个变量然后重建容器正确做法是登录MySQL执行ALTER USER。-v mysql-data:/var/lib/mysql这是最关键的一行。MySQL实际数据存在这个目录不挂载的话容器一删数据全部丢失。使用具名卷named volume比绑定宿主机目录更省心数据由Docker统一管理。TZAsia/Shanghai时区不配置的话默认可能是UTC数据库里存的当前时间会比北京时间慢8个小时。这个问题在联调时特别容易踩。--character-set-server和--collation-serverMySQL 8.0默认字符集其实已经是utf8mb4但显式指定一下更稳妥避免连接参数不同导致中文乱码。验证是否正常docker ps docker logs mysql8 docker exec -it mysql8 mysql -uroot -p外部连接时注意云服务器要放行3306端口且root账号默认可能只允许localhost连接。如果要从别的机器连需要自己建一个带远程访问权限的用户又或者用-e MYSQL_ROOT_HOST%允许root远程登录。6.2 Redis主从复制容器化Redis主从这套我在测试环境搭过很多次用Docker比手工编译安装省事太多。思路是先建一个自定义网络让主从容器可以通过容器名相互访问因为容器IP会变依赖IP写配置的话总容易断。第一步创建网络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-slave \ --network redis-net \ -p 6380:6379 \ redis:7 \ redis-server --slaveof redis-master 6379注意容器内Redis默认监听6379端口第二个容器的-p 6380:6379只是把宿主机的6380映射到容器的6379对外提供从库端口。第三步里--slaveof redis-master 6379利用了自定义网络的DNS解析功能容器名redis-master会被解析成它的容器IP。验证主从是否建立成功docker exec -it redis-slave redis-cli INFO replication如果看到role:slave并且master_link_status:up说明主从连接正常。想要更保险一点可以写一个简单的健康检查脚本每秒检查一次主从连接状态失败时向告警通道发消息。这里有个容易让人困惑的地方新版Redis命令行里slaveof已经倾向于改成replicaof两个命令在7.x版本里都能用功能一样。写脚本或配置时我建议直接用replicaof跟上官方新版本的命名习惯。6.3 GitLab社区版部署GitLab在Docker里跑其实是有些重的它依赖的组件很多内存占用也大。官方要求至少4G内存我在低配机器上强行跑过一次卡到连网页都打不开后来直接放弃了建议先看看机器配置再动工。部署命令可以参考docker run -d \ --name gitlab \ --hostname gitlab.example.com \ -p 8929:8929 \ -p 2222:22 \ -e GITLAB_ROOT_PASSWORDSetYourPassword \ -v gitlab-config:/etc/gitlab \ -v gitlab-logs:/var/log/gitlab \ -v gitlab-data:/var/opt/gitlab \ --restartalways \ gitlab/gitlab-ce:latest几个容易出问题的点--hostname要和将来访问GitLab的地址一致不然克隆仓库时生成的地址会不对。-p 8929:8929是把Web界面映射到宿主机8929端口避免和已有的80端口冲突-p 2222:22是SSH端口后续git clone ssh://git地址:2222/...会用到。首次启动后容器要执行初始化任务大概需要3到5分钟甚至更久这段时间网页会显示502别急着重启容器先等日志出现gitlab Rails boot is ready字样。root初始密码如果你没有通过GITLAB_ROOT_PASSWORD指定会生成一个随机密码存放在容器内/etc/gitlab/initial_root_password文件中24小时后自动删除。查询命令docker exec gitlab cat /etc/gitlab/initial_root_password有人图省事内存不够也硬上GitLab然后发现容器总是OOM被杀。这种情况我建议先考虑Gitea它的资源占用比GitLab小一个量级功能和轻量团队协作完全够用。如果确实必须用GitLab就得给服务器加内存到8G以上才靠谱。7. Docker Compose多服务编排的基本用法容器化单个服务很简单但真实项目很少只有一个服务。以前端项目为例既要MySQL又要Redis还要Nginx反向代理手动一个个docker run虽然能跑通但每次搭建环境都要敲十几条命令而且容易漏参数。Docker Compose就是解决这个问题的——用一个YAML文件描述一组服务及其依赖关系一条命令全部起停。7.1 一个最简的Compose示例我以一个典型配置为例假设你要同时跑MySQL和Redisversion: 3.8 services: mysql: image: mysql:8.0 container_name: app-mysql restart: always environment: MYSQL_ROOT_PASSWORD: root123 TZ: Asia/Shanghai ports: - 3306:3306 volumes: - mysql-data:/var/lib/mysql command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci redis: image: redis:7 container_name: app-redis restart: always ports: - 6379:6379 volumes: - redis-data:/data volumes: mysql-data: redis-data:文件命名为docker-compose.yml放在项目目录里然后执行docker compose up -d-d表示后台启动。这个命令会自动拉取镜像、创建网络、挂载数据卷按依赖顺序启动服务。查看运行状态docker compose ps docker compose logs -f mysql停止所有服务但不删除数据卷docker compose down连数据卷一起清掉docker compose down -v7.2 Compose里容易忽略的三个细节第一version字段在高版本Compose里已经不需要了但为了兼容老环境我习惯保留3.8。如果你用的是Docker 25或更新的版本直接省略也没问题。第二多个服务默认会在同一个自定义网络中相互之间可以用服务名比如mysql、redis直接访问。应用配置里的数据库地址不需要写成IP直接写mysql:3306或redis:6379就行这个特性在微服务联调时特别方便。第三depends_on只是控制启动顺序不保证依赖服务已经“可用”。比如应用容器等MySQL容器启动了但MySQL可能还在初始化。需要真正感知服务就绪时最好给依赖服务加healthcheck然后在应用服务的depends_on里配置condition: service_healthy。从团队协作的角度看Compose文件本身就是基础设施即代码的最佳入门实践。新人加入项目组拉完代码只要机器上装了Docker和Compose一条命令就把数据库、缓存、中间件全部拉起来完全不依赖某个人工搭建好的开发机这套工作流我所见到的团队里推广效果都很好。7.3 多环境差异开发、测试、生产配置怎么管理Compose的原生机制是支持多份配置文件的比如基础配置放docker-compose.yml生产环境的覆盖写在docker-compose.prod.yml启动时用docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d生产配置文件里可以只写差异部分比如端口、环境变量里的密码、镜像标签等。这种“基础文件覆盖文件”的方式比维护一套完全独立的生产配置要清晰得多也是我在实际项目中推荐的做法。需要注意的是环境变量里涉及密码的不要明文写在YAML文件里可以配合.env文件或者宿主机环境变量注入避免配置文件被提交到代码仓库造成密码泄露。8. 进阶方向镜像打包、微服务部署与我的几点体会前面聊的都是直接用现成镜像但真实项目里很多时候需要把自己的应用打成镜像。最常见的做法是编写Dockerfile。比如一个Java应用基础镜像用eclipse-temurin:17-jre构建流程通常是FROM eclipse-temurin:17-jre WORKDIR /app COPY target/app.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]然后执行docker build -t myapp:1.0 .构建镜像时我坚持两个习惯一是基础镜像明确指定版本号不要用latest否则哪天拉到一个不兼容的新版本构建出来的镜像行为变了很难排查二是每行指令尽量让缓存最大化命中把经常变化的文件放在后面复制这样改代码重建时能复用前面的缓存层构建速度飞快。在IDEA里也有一键打包Docker镜像的功能配置好Docker连接后在Run/Debug Configurations里选择Docker指向项目Dockerfile或Build Image即可。这种方式适合个人开发环境的快速验证生产环境还是要走CI流水线比如在代码仓库的Pipeline里触发镜像构建和推送再用容器运行时部署到目标机器。至于微服务项目的容器化部署我的建议是先不要一股脑上KubernetesDocker Compose已经能解决相当大一部分中小项目的编排问题。当你发现自己需要动态扩缩容、滚动更新、服务自动发现这些更复杂的能力时再考虑Kubernetes也不迟。容器化微服务的核心经验其实很简单单个容器只跑一个进程配置全部走环境变量注入日志输出到标准输出stdout数据持久化走数据卷健康检查接口一定要有。最后说一点我的个人体会。Docker用久了以后我最大的感受不是“部署变快了”这么简单而是环境变成了可以随手丢弃和重建的资源。以前调一个线上问题最怕的就是“这台机器被我改过哪里现在不敢动了”有了容器之后我把应用、数据库、中间件全都容器化出问题就删了重建配置都在代码仓库里随时能还原。这种底气才是Docker带给我最大的好处。如果你正在入门Docker我建议的路线是先在一台测试机上把安装和常用命令跑熟然后用MySQL和Redis做两个有状态服务的部署练习再用Compose把多个服务串起来最后才是自己写Dockerfile打包业务应用。走完这条线你再看Kubernetes、云原生这些概念会发现它们其实都是建立在容器这个地基之上的地基打牢了上层的东西都不难理解。