最近几年总有人问我docker到底是什么、它到底解决了什么问题、为什么好像一夜之间大家都在用容器技术。我自己的经历挺典型的早年部署一套环境要装依赖、配路径、处理版本冲突每次新环境都要折腾一下午后来把全套服务容器化之后一条命令就能把整个应用栈拉起来几分钟切换环境几乎变成了常态。docker说白了就是一套操作系统层面的虚拟化方案它把应用连同运行环境一起打包成镜像再用容器隔离运行交付时不再是一堆“安装文档配置步骤”而是一个可以直接跑的镜像。这篇文章我打算从原理、安装、配置、实战部署、问题排查几个维度展开。不管你是在Windows上装Docker Desktop被虚拟化折磨过还是Ubuntu下遇到权限报错或者正在琢磨怎么用docker跑MySQL、Redis主从、GitLab这些具体应用这篇内容都会覆盖到。内容偏向实操所有命令和配置我都会解释为什么要这么写方便你遇到变体场景时能自己推导。1. 容器技术到底解决了什么问题1.1 从“在我机器上是好的”说起做开发的都经历过这句话代码本地跑得好好的一上服务器就崩。传统部署方式里环境差异是最大的敌人。操作系统版本不同、依赖库版本冲突、配置文件路径不统一任何一个环节偏差都会让应用“水土不服”。你可以在文档里写清楚每一步怎么操作但换一个人、换一台机器执行结果往往不一样。docker的核心价值就是把这个“环境”本身变成可复制、可版本管理的物件。应用代码、运行时、系统库、配置文件全部打包进一个镜像。镜像一旦构建完成它在任何装了docker的机器上运行行为都是一致的。我经常打一个比方传统部署像把一整套家具从客厅搬到另一个客厅沙发要先拆、柜子要重装、螺丝可能不匹配docker像是整屋打包进集装箱到了新家直接原样放下连摆放角度都不变。1.2 镜像、容器、仓库三件套要分清很多人刚接触docker时会绕晕在三个概念里镜像、容器、仓库。其实拿编程语言里的“类、对象、代码库”做类比就清楚了。镜像image是模板里面包含了一套完整的运行环境。它由一层层只读文件系统叠加而成每一层代表一个构建步骤比如“基于ubuntu 22.04”“安装nginx”“拷贝网站文件”。容器container是镜像运行起来的实例每个容器之间有隔离可以启动、停止、删除。仓库repository用来存放和分发镜像Docker Hub是最出名的公共仓库也可以自建私有仓库。实际操作中你通过docker pull nginx:latest从仓库拉取镜像然后docker run -d nginx创建并启动容器。容器运行时如果需要修改文件会在镜像之上叠加一层可写层这些修改不会影响镜像本身。这个分层设计是docker性能远超传统虚拟机的重要原因后面我会单独讲。1.3 容器和虚拟机的本质区别虚拟机和容器最根本的差异在“隔离级别”。虚拟机利用Hypervisor层虚拟化出一整套硬件每个虚拟机里面都要安装自己的操作系统启动就要几十秒甚至几分钟内存和磁盘开销都很大。容器则直接共享宿主机内核只做进程级别的隔离启动一个容器基本上就是启动一个进程秒级完成内存开销只有几十兆甚至几兆。我实测过一组数据一台8G内存的服务器跑4个虚拟机已经卡得不行同样的机器跑docker二三十个容器都还算从容。这就是为什么现在微服务架构几乎默认选择容器来部署资源利用率差距太大了。但也要注意容器因为共享内核隔离性天然弱于虚拟机多租户强隔离场景下还是要老老实实上虚拟机这个没有银弹。2. 各平台安装与基础配置2.1 Windows装Docker Desktop先搞定虚拟化Windows上的docker安装绕不开Docker Desktop而Docker Desktop的运行依赖虚拟化技术。如果你看到红色的报错“Virtualization support was detected but disabled”或者“Docker Desktop failed to start because virtualisation support wasnt detected”基本都是虚拟化没开或没配置好。最稳妥的检查顺序是按CtrlShiftEsc打开任务管理器到“性能”标签页查看“虚拟化”状态是否显示“已启用”。如果显示“已禁用”需要进BIOS开启VT-x或AMD-V这个操作因主板而异一般在Advanced、CPU Configuration或Security菜单下叫Intel Virtualization Technology或SVM Mode。如果你用的是Windows 10/11专业版确认Windows功能里“虚拟机平台”和“适用于Linux的Windows子系统”这两项已经勾选。开启后需要重启机器。Docker Desktop默认用WSL2后端建议在PowerShell里执行wsl --status确认WSL版本是2如果是1就执行wsl --set-default-version 2升级。还有一个细节很多人不知道如果你同时装了Hyper-VDocker Desktop和旧版Hyper-V偶尔会打架。现在新版Docker Desktop处理兼容性已经好很多了但如果你遇到启动卡死可以试试在控制面板里关闭“Hyper-V”和“Windows虚拟机监控程序平台”这两个功能让Docker完全走WSL2后端。我遇到过一次莫名其妙的启动失败关了Hyper-V就好了。2.2 Linux下安装一条命令和几个坑Linux服务器上装docker要简单得多推荐用官方脚本一把梭curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun--mirror Aliyun是指定从阿里云镜像拉取安装脚本和软件包国内环境下载速度会快很多。脚本执行完先把服务启动并设置开机自启sudo systemctl enable --now dockerUbuntu和CentOS的差异主要在包管理器但官方脚本已经兼容处理了。CentOS 7这种老系统要注意内核版本问题docker新版对内核有要求3.10内核跑新版docker偶尔会出现iptables规则异常导致容器网络不通。如果遇到要么升级内核要么用旧版docker。我在CentOS 7上踩过一次坑升级docker之后容器全部连不上网最后只能回退。奉劝一句老系统别盲目升级docker主版本稳定高于一切。2.3 换镜像源受够了镜像下载慢docker默认从Docker Hub拉取镜像国内直连基本是龟速拉一个大镜像经常卡到怀疑人生。解决办法是配置国内镜像加速器。Linux环境修改/etc/docker/daemon.json{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com, https://docker.mirrors.ustc.edu.cn ] }改完执行sudo systemctl daemon-reload sudo systemctl restart docker。Windows下在Docker Desktop的Settings - Docker Engine里把同样的JSON配置粘贴进去Apply Restart即可。要注意的是公开镜像源存在着失效和速度波动的可能不同地区、不同运营商访问同一个镜像源的速度差异很大。我自己的习惯是配两三个源主源挂掉了有备用的。真正追求稳定的话公司内部可以搭Harbor之类的私有仓库docker pull走内网速度快且不受公网约束。2.4 权限问题permission denied的根源很多人在Linux下执行docker ps会看到permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock。这个报错的含义是当前用户没有访问Docker守护进程socket的权限。docker命令默认需要root权限但我强烈不建议用sudo硬怼每条命令。正确做法是把用户加进docker组sudo usermod -aG docker $USER执行完注销重登或者newgrp docker切换一下当前会话的组身份再执行docker ps就不需要sudo了。这个操作用意很明确Docker通过组权限控制谁能访问守护进程把用户加入docker组就相当于授权。还要补充一句加入docker组的用户和root权限基本没区别因为docker可以挂载宿主机任意目录到容器里实际上等于拿到了宿主机root。所以在生产环境给账号加docker组要慎重这相当于给了半张root通行证。3. 数据库与中间件部署实战3.1 MySQL 8.0安装、时区、编码、外部访问“docker安装mysql失败”是我见过最多的热搜词。其实MySQL容器本身安装成功率极高失败大多出在参数配置和细节处理上。先看一段我常用的启动命令docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDMyPwd123! \ -v /data/mysql/conf:/etc/mysql/conf.d \ -v /data/mysql/data:/var/lib/mysql \ --restartalways \ mysql:8.0几个关键点解释一下。-p 3306:3306是把宿主机3306端口映射到容器3306端口这样外部才能访问到MySQL。-v挂载是把容器内的数据目录映射到宿主机否则容器删除后数据全部丢失这是容器化部署最容易犯的错误。--restartalways让容器在重启后自动拉起服务器意外重启不至于手工恢复服务。MySQL 8.0有几个常见的坑。第一是默认认证插件是caching_sha2_password老版本客户端和部分工具连不上会报Authentication plugin caching_sha2_password cannot be loaded。解决方式是在容器里改用户认证方式docker exec -it mysql8 mysql -uroot -p进入MySQL后执行ALTER USER root% IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;第二是时区问题。容器默认时区是UTC会导致数据库时间比北京时间慢8小时。在启动命令里加-e TZAsia/Shanghai可以解决大部分场景。第三是字符集MySQL 8.0默认字符集已经是utf8mb4但你可以在执行初始化时指定配置文件加强保险。如果你在宿主机挂载了conf目录可以放一个my.cnf[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_unicode_ci还有一个细节如果3306端口被占用了启动会报Ports are not available要么换宿主机端口比如-p 3307:3306要么先排查占用。确认容器启动成功后从宿主机连一次mysql -h127.0.0.1 -P3306 -uroot -p能连上说明一切正常。3.2 Redis主从一条命令一个从节点Redis主从部署在传统方式下要准备两台机器、改配置文件、重启服务步骤繁琐。docker下可以用一条命令拉起一个slave节点先启动masterdocker run -d --name redis-master \ -p 6379:6379 \ redis:7 redis-server --requirepass masterpass --appendonly yes再启动slavedocker run -d --name redis-slave \ -p 6380:6379 \ redis:7 redis-server --slaveof 宿主机IP 6379 \ --masterauth masterpass --appendonly yes--slaveof指定主节点地址和端口。因为容器之间默认通过网络隔离slave容器里访问master的时候不能用localhost必须用宿主机的局域网IP。如果master和slave都在同一个自定义docker网络里可以写容器名比如--slaveof redis-master 6379这是docker网络的一个便利特性。验证主从是否生效进入slave容器执行redis-cli -a masterpass info replication看到role:slave且master_link_status:up就说明连接正常。这里要特别提醒一个坑Redis容器如果没设置--appendonly yes数据全在内存里容器一删数据全没。虽然redis本身是缓存定位但如果你存了需要保留的数据开启AOF持久化是必须的。3.3 GitLab、Kodbox等常见应用容器化除了数据库和缓存很多常用应用都能用docker快速部署。GitLab是个典型的重量级选手官方镜像接近2GB启动时需要比较高的内存。我通常这样跑docker run -d \ --privileged \ --name gitlab \ -p 443:443 -p 80:80 -p 1022:22 \ -v /srv/gitlab/config:/etc/gitlab \ -v /srv/gitlab/logs:/var/log/gitlab \ -v /srv/gitlab/data:/var/opt/gitlab \ --restartalways \ gitlab/gitlab-ce:latest注意-p 1022:22因为宿主机22端口通常被SSH占用我把容器的SSH端口映射到1022这样git clone时要用ssh://githost:1022/group/project.git的方式。--privileged这个参数在GitLab镜像里经常需要否则某些功能会出现权限问题但如果你不需要相关功能可以去掉减少安全隐患。Kodbox可道云这类网盘应用则轻量得多docker run -d \ --name kodbox \ -p 8080:80 \ -v /data/kodbox:/var/www/html \ --restartalways \ kodbox/kodbox:latest跑起来之后浏览器访问http://宿主机IP:8080就能进入安装向导。这些应用容器化的好处很明显不需要关心PHP环境、Nginx配置、扩展安装这些杂事镜像里全配好了。3.4 青龙面板与自动化任务容器青龙面板这两年讨论度很高它本质是一个定时任务管理面板常被用来跑各类签到脚本。部署其实很简单docker run -d \ --name qinglong \ -p 5700:5700 \ -v /data/qinglong:/ql/data \ --restartalways \ whyyourtql/qinglong:latest跑起来后浏览器访问http://IP:5700按向导设置账号密码就完成了。“docker青龙 依赖管理”这个热搜词说明很多人卡在依赖安装上。青龙面板的脚本需要Python、Node.js等运行时依赖面板本身只提供任务调度脚本跑不起来多半是依赖缺失。建议在面板的“依赖管理”里按脚本要求装好依赖或者直接进容器手动安装docker exec -it qinglong bash然后用包管理器装缺失的库。我个人对青龙这类自动化工具持审慎态度建议只在合规的场景下使用。4. Docker Compose把编排写进文件4.1 为什么需要Compose当你只需要跑一两个容器时docker run完全够用。但一旦涉及多容器协作比如一个应用依赖MySQL、Redis、Nginx三个服务再用命令方式逐个启动既繁琐又容易漏参数。Docker Compose的价值就是把多个容器的配置写进一个docker-compose.yml文件用docker compose up -d一条命令拉起所有服务。我用Compose管理过一套完整的微服务开发环境包含配置中心、网关、五六个业务服务、MySQL、Redis、Kafka总共十几个容器。每次新同事入职把代码和compose文件拿过去执行两条命令就能复刻整套环境这个体验在没容器化之前完全不敢想。4.2 compose文件怎么设计与调参以一套简单的MySQLRedis后端服务为例services: mysql: image: mysql:8.0 container_name: app-mysql environment: MYSQL_ROOT_PASSWORD: root123 TZ: Asia/Shanghai ports: - 3306:3306 volumes: - ./data/mysql:/var/lib/mysql restart: always redis: image: redis:7 container_name: app-redis ports: - 6379:6379 command: redis-server --requirepass redis123 --appendonly yes restart: always backend: build: ./backend container_name: app-backend depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/app_db?useSSLfalse SPRING_REDIS_HOST: redis ports: - 8080:8080 restart: always注意一个细节depends_on只控制启动顺序不等待MySQL真正就绪。如果后端启动时MySQL还没完成初始化连接会失败。生产级方案是引入健康检查或者在后端代码里做重试机制。我用过healthcheck方式services: mysql: healthcheck: test: [CMD, mysqladmin, ping, -h, localhost] interval: 5s retries: 10然后把depends_on改成depends_on: mysql: condition: service_healthy这样后端只会在MySQL健康检查通过后才启动基本没有连不上的问题。4.3 网络配置与端口映射那些事Compose默认会创建一个自定义网络同一个compose文件里的服务可以通过服务名互相访问。比如此例中后端访问MySQL用的host是mysql而不是IP这个主机名就是Compose自动DNS解析出来的。端口映射使用宿主机端口:容器端口的格式。要注意的是如果服务只是服务间调用没必要暴露端口到宿主机这样能减少端口冲突面。比如上例中如果MySQL和Redis只给后端用完全可以去掉ports配置让它们在Compose网络内私密通信。对外暴露出来的管理工具如phpMyAdmin再单独映射端口即可。遇到端口冲突时报错一般是Bind for 0.0.0.0:3306 failed: port is already allocated处理方式是改宿主机端口或关掉占用进程。还有一个排查技巧docker compose ps看每个容器的端口映射状态如果用docker ps看所有容器可以加--format参数自定义输出列信息会更清爽。5. 镜像构建与微服务部署5.1 Dockerfile的正确写法自己构建镜像需要写Dockerfile很多新手会把镜像写得又大又乱。我总结过几条经过实战检验的最佳实践。第一尽量使用alpine等精简基础镜像。同样一个Java应用基于openjdk:17-jdk-alpine构建出来的镜像体积可能只有标准版的三分之一。体积小不只是磁盘省拉取快、启动快对部署体验和成本都有直接帮助。第二利用多阶段构建。以Java项目为例构建阶段需要Maven和JDK运行阶段只需要JRE。通过多段构建最终镜像只保留运行所需内容FROM maven:3.8-eclipse-temurin-17 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM eclipse-temurin:17-jre-alpine WORKDIR /app COPY --frombuild /app/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]第一段负责编译打包工具链齐全第二段只拷贝最终jar包干净瘦身。这是当前Java微服务镜像最标准也最稳妥的写法。第三不要忘记.dockerignore文件。它和.gitignore类似把本地缓存、临时目录、IDE配置排除在构建上下文之外。否则COPY . .会把几百MB的target目录全带进去构建慢不说还有可能把本地的敏感文件打进去。5.2 IDE直接打包镜像少记命令很多程序员习惯在IDE里操作一切。Idea系列编辑器配合Docker插件可以直接基于Dockerfile构建镜像并推送全程不离开编辑器。操作路径大致是安装Docker插件 - 配置Docker连接Windows上选择Docker Desktop的socketLinux上指向unix:///var/run/docker.sock - 在Dockerfile文件右键选择“Build Image for xxx” - 弹窗里填镜像名和tag - 构建完成后可以在Services面板看到镜像和容器列表右键即可启动、停止、查看日志。这种方式和命令行docker build本质是一回事但对于不熟悉命令行的同事来说图形化操作门槛低很多也更直观。我在带团队时要求所有后端服务镜像都用这种方式构建配合Jenkins做流水线的时候再改成命令行两套并行不冲突。5.3 轻量设备上的容器实践N100跑20个容器很多人以为容器一定需要强大服务器其实轻量设备上跑容器表现也相当可以。N100这类低功耗处理器在软路由、NAS圈子里很常见因为功耗低、静音、24小时开机不心疼用来跑docker容器非常合适。N100跑20个容器是可行的但有几个约束条件。第一是内存这类设备通常配8G或16G内存每个容器都要占用内存建议给关键容器设置内存上限docker run -d --memory512m --cpus0.5 your-image这样能防止某个容器内存泄漏拖垮整台机器。第二是存储20个容器加镜像很容易吃满磁盘建议上SSD并定期清理无用镜像docker image prune -f是个好习惯。第三是日志不打日志的话容器日志会持续膨胀启动时加上docker run -d --log-opt max-size10m --log-opt max-file3 your-image单个日志文件10MB、最多保留3个日志轮转自动完成避免/var/lib/docker被塞爆。我实测过N100双通道16G内存跑20个左右的轻量容器CPU长期占用率也就20%-30%日常运行很稳定。不过要提醒一点这类设备跑容器尽量选轻量镜像别跑GitLab这种大家伙真跑起来内存会先崩。6. 高频问题排查速查6.1 服务起不来三板斧定位问题容器启动失败时最高频的原因是端口占用、卷挂载权限、镜像启动命令错误、配置错误。排查顺序我一般按下面这样走第一步看状态docker ps -a注意加了-a才可以看到已退出的容器。第二步看日志docker logs 容器名。绝大多数启动失败的原因都能在日志里找到。比如MySQL启动失败日志会直接告诉你是配置文件问题还是数据目录权限问题。第三步看事件docker events --filter container容器名可以看到容器生命周期中发生了什么。有时候启动瞬间退出是健康检查失败导致的这时候docker inspect查看容器状态里的Health字段会有帮助。一个我自己踩过多次的坑挂载目录的权限问题。容器内的进程通常以特定用户运行如果宿主机挂载目录的属主和权限不对容器内进程没有写权限服务就会反复启动失败。比如MySQL容器挂载/data/mysql目录时如果目录属主不是999:999MySQL在容器内的UID就会报Permission denied。解决方式是chown -R 999:999 /data/mysql或者用--user参数指定容器运行用户。6.2 网络不通排查清单“docker网络不通”的热搜排名非常高我遇到过几乎每种可能的原因。核心排查路径是这样的先判断网络类型。默认情况下容器使用bridge网络外部通过端口映射访问容器内部。如果你能正常访问端口映射的服务说明网络基本正常问题出在具体路由或防火墙。容器间互访不通时优先确认是否在同一网络。比如一个容器是Compose启动的另一个是docker run启动的它们大概率不在同一个自定义网络上此时用容器名互相访问会失败。解决方式是让服务挂到同一个网络docker network connect mynet container名。再检查宿主机防火墙。很多Linux发行版默认开着firewalld或ufw即使端口映射了外部流量也会被防火墙拦截。我推荐在本地测试直接用curl从宿主机访问映射端口通就说明docker网络没问题问题在外部防火墙。还有一类隐蔽问题容器内DNS解析异常。表现为容器内能ping通IP但ping不通域名通常需要在/etc/docker/daemon.json里配置dns: [223.5.5.5, 8.8.8.8]重启docker生效。6.3 镜像下载慢和大镜像处理除了配置镜像源拉取大镜像时还可以用延迟拉取策略。比如部署Hadoop镜像hadoop的docker镜像这个热搜词说明不少人卡在这里镜像体积可能有几个GB一次性拉取很容易中断。可以分段重试docker pull registry.cn-hangzhou.aliyuncs.com/hadoop3.3.6/hadoop:3.3.6先从国内镜像源拉拉不动就多试几次docker会从断点继续。如果实在拉不下来改用Docker Hub官方镜像再配合镜像加速。日常使用中构建完镜像后及时推送私有仓库部署新机器时直接内网拉取这是治本的办法。还有一个技巧docker history 镜像名 --no-trunc可以查看镜像每一层的创建命令如果发现某些层异常大可以回溯到对应的构建步骤去优化。6.4 权限与安全细节这个话题值得多说几句。容器权限事故轻则服务起不来重则可能影响宿主机。除了前面提到的访问docker socket权限我还想强调两点。第一非必要不要使用--privileged运行容器。这个参数相当于给容器放开了所有权限限制可以访问宿主机所有设备一旦容器被入侵整个宿主机都暴露了。很多教程为了让容器跑起来直接加--privileged这是典型的知难而退型解法。通常遇到的问题比如挂载设备、调整系统参数都有更精细的参数可以解决。第二注意容器内时间。不少应用对时间敏感如果宿主机和容器时区不一致可能出现日志时间和实际时间错位8小时。启动容器统一加-e TZAsia/Shanghai或者挂载宿主机时区文件-v /etc/localtime:/etc/localtime:ro可以避免很多莫名其妙的时区问题。老系统升级docker这个热点话题也说一句升级前先备份/etc/docker/daemon.json配置文件、镜像tar包和容器数据卷升级完成后用docker run --rm hello-world验证基础功能。生产环境升级docker从来不是小事稳字当头。写在最后我在实际项目中已经很少用传统方式部署服务了凡是能容器化的都尽量容器化。docker这些年让我最深切的体会是部署不该是每次重复踩坑的体力活而应该变成一次性的、可复制的确定性操作。把环境交给镜像把编排写进文件把数据交给挂载卷这三个思维转变基本能覆盖90%的日常容器使用场景。最后再分享一个我自己养成的习惯所有重要容器在启动时都加上--restartalways数据目录全部挂载到宿主机镜像tag尽量用固定版本号而不是latest。前两条保证机器重启后服务能自动恢复、数据不会丢失第三条保证你不会在某一天发现线上环境悄悄变成了一个新版本还没人知道。容器技术本身不复杂核心就是确定性、可复制性、可管理性这三件事把这三点贯穿到每个操作里你很快就会发现部署这件事原来可以这么简单。 
长河君 · 2026/10/6 9:05:34 · 阅读 1.2k Docker容器化实战：原理、部署与高频问题排查
最近几年总有人问我docker到底是什么、它到底解决了什么问题、为什么好像一夜之间大家都在用容器技术。我自己的经历挺典型的早年部署一套环境要装依赖、配路径、处理版本冲突每次新环境都要折腾一下午后来把全套服务容器化之后一条命令就能把整个应用栈拉起来几分钟切换环境几乎变成了常态。docker说白了就是一套操作系统层面的虚拟化方案它把应用连同运行环境一起打包成镜像再用容器隔离运行交付时不再是一堆“安装文档配置步骤”而是一个可以直接跑的镜像。这篇文章我打算从原理、安装、配置、实战部署、问题排查几个维度展开。不管你是在Windows上装Docker Desktop被虚拟化折磨过还是Ubuntu下遇到权限报错或者正在琢磨怎么用docker跑MySQL、Redis主从、GitLab这些具体应用这篇内容都会覆盖到。内容偏向实操所有命令和配置我都会解释为什么要这么写方便你遇到变体场景时能自己推导。1. 容器技术到底解决了什么问题1.1 从“在我机器上是好的”说起做开发的都经历过这句话代码本地跑得好好的一上服务器就崩。传统部署方式里环境差异是最大的敌人。操作系统版本不同、依赖库版本冲突、配置文件路径不统一任何一个环节偏差都会让应用“水土不服”。你可以在文档里写清楚每一步怎么操作但换一个人、换一台机器执行结果往往不一样。docker的核心价值就是把这个“环境”本身变成可复制、可版本管理的物件。应用代码、运行时、系统库、配置文件全部打包进一个镜像。镜像一旦构建完成它在任何装了docker的机器上运行行为都是一致的。我经常打一个比方传统部署像把一整套家具从客厅搬到另一个客厅沙发要先拆、柜子要重装、螺丝可能不匹配docker像是整屋打包进集装箱到了新家直接原样放下连摆放角度都不变。1.2 镜像、容器、仓库三件套要分清很多人刚接触docker时会绕晕在三个概念里镜像、容器、仓库。其实拿编程语言里的“类、对象、代码库”做类比就清楚了。镜像image是模板里面包含了一套完整的运行环境。它由一层层只读文件系统叠加而成每一层代表一个构建步骤比如“基于ubuntu 22.04”“安装nginx”“拷贝网站文件”。容器container是镜像运行起来的实例每个容器之间有隔离可以启动、停止、删除。仓库repository用来存放和分发镜像Docker Hub是最出名的公共仓库也可以自建私有仓库。实际操作中你通过docker pull nginx:latest从仓库拉取镜像然后docker run -d nginx创建并启动容器。容器运行时如果需要修改文件会在镜像之上叠加一层可写层这些修改不会影响镜像本身。这个分层设计是docker性能远超传统虚拟机的重要原因后面我会单独讲。1.3 容器和虚拟机的本质区别虚拟机和容器最根本的差异在“隔离级别”。虚拟机利用Hypervisor层虚拟化出一整套硬件每个虚拟机里面都要安装自己的操作系统启动就要几十秒甚至几分钟内存和磁盘开销都很大。容器则直接共享宿主机内核只做进程级别的隔离启动一个容器基本上就是启动一个进程秒级完成内存开销只有几十兆甚至几兆。我实测过一组数据一台8G内存的服务器跑4个虚拟机已经卡得不行同样的机器跑docker二三十个容器都还算从容。这就是为什么现在微服务架构几乎默认选择容器来部署资源利用率差距太大了。但也要注意容器因为共享内核隔离性天然弱于虚拟机多租户强隔离场景下还是要老老实实上虚拟机这个没有银弹。2. 各平台安装与基础配置2.1 Windows装Docker Desktop先搞定虚拟化Windows上的docker安装绕不开Docker Desktop而Docker Desktop的运行依赖虚拟化技术。如果你看到红色的报错“Virtualization support was detected but disabled”或者“Docker Desktop failed to start because virtualisation support wasnt detected”基本都是虚拟化没开或没配置好。最稳妥的检查顺序是按CtrlShiftEsc打开任务管理器到“性能”标签页查看“虚拟化”状态是否显示“已启用”。如果显示“已禁用”需要进BIOS开启VT-x或AMD-V这个操作因主板而异一般在Advanced、CPU Configuration或Security菜单下叫Intel Virtualization Technology或SVM Mode。如果你用的是Windows 10/11专业版确认Windows功能里“虚拟机平台”和“适用于Linux的Windows子系统”这两项已经勾选。开启后需要重启机器。Docker Desktop默认用WSL2后端建议在PowerShell里执行wsl --status确认WSL版本是2如果是1就执行wsl --set-default-version 2升级。还有一个细节很多人不知道如果你同时装了Hyper-VDocker Desktop和旧版Hyper-V偶尔会打架。现在新版Docker Desktop处理兼容性已经好很多了但如果你遇到启动卡死可以试试在控制面板里关闭“Hyper-V”和“Windows虚拟机监控程序平台”这两个功能让Docker完全走WSL2后端。我遇到过一次莫名其妙的启动失败关了Hyper-V就好了。2.2 Linux下安装一条命令和几个坑Linux服务器上装docker要简单得多推荐用官方脚本一把梭curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun--mirror Aliyun是指定从阿里云镜像拉取安装脚本和软件包国内环境下载速度会快很多。脚本执行完先把服务启动并设置开机自启sudo systemctl enable --now dockerUbuntu和CentOS的差异主要在包管理器但官方脚本已经兼容处理了。CentOS 7这种老系统要注意内核版本问题docker新版对内核有要求3.10内核跑新版docker偶尔会出现iptables规则异常导致容器网络不通。如果遇到要么升级内核要么用旧版docker。我在CentOS 7上踩过一次坑升级docker之后容器全部连不上网最后只能回退。奉劝一句老系统别盲目升级docker主版本稳定高于一切。2.3 换镜像源受够了镜像下载慢docker默认从Docker Hub拉取镜像国内直连基本是龟速拉一个大镜像经常卡到怀疑人生。解决办法是配置国内镜像加速器。Linux环境修改/etc/docker/daemon.json{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com, https://docker.mirrors.ustc.edu.cn ] }改完执行sudo systemctl daemon-reload sudo systemctl restart docker。Windows下在Docker Desktop的Settings - Docker Engine里把同样的JSON配置粘贴进去Apply Restart即可。要注意的是公开镜像源存在着失效和速度波动的可能不同地区、不同运营商访问同一个镜像源的速度差异很大。我自己的习惯是配两三个源主源挂掉了有备用的。真正追求稳定的话公司内部可以搭Harbor之类的私有仓库docker pull走内网速度快且不受公网约束。2.4 权限问题permission denied的根源很多人在Linux下执行docker ps会看到permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock。这个报错的含义是当前用户没有访问Docker守护进程socket的权限。docker命令默认需要root权限但我强烈不建议用sudo硬怼每条命令。正确做法是把用户加进docker组sudo usermod -aG docker $USER执行完注销重登或者newgrp docker切换一下当前会话的组身份再执行docker ps就不需要sudo了。这个操作用意很明确Docker通过组权限控制谁能访问守护进程把用户加入docker组就相当于授权。还要补充一句加入docker组的用户和root权限基本没区别因为docker可以挂载宿主机任意目录到容器里实际上等于拿到了宿主机root。所以在生产环境给账号加docker组要慎重这相当于给了半张root通行证。3. 数据库与中间件部署实战3.1 MySQL 8.0安装、时区、编码、外部访问“docker安装mysql失败”是我见过最多的热搜词。其实MySQL容器本身安装成功率极高失败大多出在参数配置和细节处理上。先看一段我常用的启动命令docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDMyPwd123! \ -v /data/mysql/conf:/etc/mysql/conf.d \ -v /data/mysql/data:/var/lib/mysql \ --restartalways \ mysql:8.0几个关键点解释一下。-p 3306:3306是把宿主机3306端口映射到容器3306端口这样外部才能访问到MySQL。-v挂载是把容器内的数据目录映射到宿主机否则容器删除后数据全部丢失这是容器化部署最容易犯的错误。--restartalways让容器在重启后自动拉起服务器意外重启不至于手工恢复服务。MySQL 8.0有几个常见的坑。第一是默认认证插件是caching_sha2_password老版本客户端和部分工具连不上会报Authentication plugin caching_sha2_password cannot be loaded。解决方式是在容器里改用户认证方式docker exec -it mysql8 mysql -uroot -p进入MySQL后执行ALTER USER root% IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;第二是时区问题。容器默认时区是UTC会导致数据库时间比北京时间慢8小时。在启动命令里加-e TZAsia/Shanghai可以解决大部分场景。第三是字符集MySQL 8.0默认字符集已经是utf8mb4但你可以在执行初始化时指定配置文件加强保险。如果你在宿主机挂载了conf目录可以放一个my.cnf[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_unicode_ci还有一个细节如果3306端口被占用了启动会报Ports are not available要么换宿主机端口比如-p 3307:3306要么先排查占用。确认容器启动成功后从宿主机连一次mysql -h127.0.0.1 -P3306 -uroot -p能连上说明一切正常。3.2 Redis主从一条命令一个从节点Redis主从部署在传统方式下要准备两台机器、改配置文件、重启服务步骤繁琐。docker下可以用一条命令拉起一个slave节点先启动masterdocker run -d --name redis-master \ -p 6379:6379 \ redis:7 redis-server --requirepass masterpass --appendonly yes再启动slavedocker run -d --name redis-slave \ -p 6380:6379 \ redis:7 redis-server --slaveof 宿主机IP 6379 \ --masterauth masterpass --appendonly yes--slaveof指定主节点地址和端口。因为容器之间默认通过网络隔离slave容器里访问master的时候不能用localhost必须用宿主机的局域网IP。如果master和slave都在同一个自定义docker网络里可以写容器名比如--slaveof redis-master 6379这是docker网络的一个便利特性。验证主从是否生效进入slave容器执行redis-cli -a masterpass info replication看到role:slave且master_link_status:up就说明连接正常。这里要特别提醒一个坑Redis容器如果没设置--appendonly yes数据全在内存里容器一删数据全没。虽然redis本身是缓存定位但如果你存了需要保留的数据开启AOF持久化是必须的。3.3 GitLab、Kodbox等常见应用容器化除了数据库和缓存很多常用应用都能用docker快速部署。GitLab是个典型的重量级选手官方镜像接近2GB启动时需要比较高的内存。我通常这样跑docker run -d \ --privileged \ --name gitlab \ -p 443:443 -p 80:80 -p 1022:22 \ -v /srv/gitlab/config:/etc/gitlab \ -v /srv/gitlab/logs:/var/log/gitlab \ -v /srv/gitlab/data:/var/opt/gitlab \ --restartalways \ gitlab/gitlab-ce:latest注意-p 1022:22因为宿主机22端口通常被SSH占用我把容器的SSH端口映射到1022这样git clone时要用ssh://githost:1022/group/project.git的方式。--privileged这个参数在GitLab镜像里经常需要否则某些功能会出现权限问题但如果你不需要相关功能可以去掉减少安全隐患。Kodbox可道云这类网盘应用则轻量得多docker run -d \ --name kodbox \ -p 8080:80 \ -v /data/kodbox:/var/www/html \ --restartalways \ kodbox/kodbox:latest跑起来之后浏览器访问http://宿主机IP:8080就能进入安装向导。这些应用容器化的好处很明显不需要关心PHP环境、Nginx配置、扩展安装这些杂事镜像里全配好了。3.4 青龙面板与自动化任务容器青龙面板这两年讨论度很高它本质是一个定时任务管理面板常被用来跑各类签到脚本。部署其实很简单docker run -d \ --name qinglong \ -p 5700:5700 \ -v /data/qinglong:/ql/data \ --restartalways \ whyyourtql/qinglong:latest跑起来后浏览器访问http://IP:5700按向导设置账号密码就完成了。“docker青龙 依赖管理”这个热搜词说明很多人卡在依赖安装上。青龙面板的脚本需要Python、Node.js等运行时依赖面板本身只提供任务调度脚本跑不起来多半是依赖缺失。建议在面板的“依赖管理”里按脚本要求装好依赖或者直接进容器手动安装docker exec -it qinglong bash然后用包管理器装缺失的库。我个人对青龙这类自动化工具持审慎态度建议只在合规的场景下使用。4. Docker Compose把编排写进文件4.1 为什么需要Compose当你只需要跑一两个容器时docker run完全够用。但一旦涉及多容器协作比如一个应用依赖MySQL、Redis、Nginx三个服务再用命令方式逐个启动既繁琐又容易漏参数。Docker Compose的价值就是把多个容器的配置写进一个docker-compose.yml文件用docker compose up -d一条命令拉起所有服务。我用Compose管理过一套完整的微服务开发环境包含配置中心、网关、五六个业务服务、MySQL、Redis、Kafka总共十几个容器。每次新同事入职把代码和compose文件拿过去执行两条命令就能复刻整套环境这个体验在没容器化之前完全不敢想。4.2 compose文件怎么设计与调参以一套简单的MySQLRedis后端服务为例services: mysql: image: mysql:8.0 container_name: app-mysql environment: MYSQL_ROOT_PASSWORD: root123 TZ: Asia/Shanghai ports: - 3306:3306 volumes: - ./data/mysql:/var/lib/mysql restart: always redis: image: redis:7 container_name: app-redis ports: - 6379:6379 command: redis-server --requirepass redis123 --appendonly yes restart: always backend: build: ./backend container_name: app-backend depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/app_db?useSSLfalse SPRING_REDIS_HOST: redis ports: - 8080:8080 restart: always注意一个细节depends_on只控制启动顺序不等待MySQL真正就绪。如果后端启动时MySQL还没完成初始化连接会失败。生产级方案是引入健康检查或者在后端代码里做重试机制。我用过healthcheck方式services: mysql: healthcheck: test: [CMD, mysqladmin, ping, -h, localhost] interval: 5s retries: 10然后把depends_on改成depends_on: mysql: condition: service_healthy这样后端只会在MySQL健康检查通过后才启动基本没有连不上的问题。4.3 网络配置与端口映射那些事Compose默认会创建一个自定义网络同一个compose文件里的服务可以通过服务名互相访问。比如此例中后端访问MySQL用的host是mysql而不是IP这个主机名就是Compose自动DNS解析出来的。端口映射使用宿主机端口:容器端口的格式。要注意的是如果服务只是服务间调用没必要暴露端口到宿主机这样能减少端口冲突面。比如上例中如果MySQL和Redis只给后端用完全可以去掉ports配置让它们在Compose网络内私密通信。对外暴露出来的管理工具如phpMyAdmin再单独映射端口即可。遇到端口冲突时报错一般是Bind for 0.0.0.0:3306 failed: port is already allocated处理方式是改宿主机端口或关掉占用进程。还有一个排查技巧docker compose ps看每个容器的端口映射状态如果用docker ps看所有容器可以加--format参数自定义输出列信息会更清爽。5. 镜像构建与微服务部署5.1 Dockerfile的正确写法自己构建镜像需要写Dockerfile很多新手会把镜像写得又大又乱。我总结过几条经过实战检验的最佳实践。第一尽量使用alpine等精简基础镜像。同样一个Java应用基于openjdk:17-jdk-alpine构建出来的镜像体积可能只有标准版的三分之一。体积小不只是磁盘省拉取快、启动快对部署体验和成本都有直接帮助。第二利用多阶段构建。以Java项目为例构建阶段需要Maven和JDK运行阶段只需要JRE。通过多段构建最终镜像只保留运行所需内容FROM maven:3.8-eclipse-temurin-17 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM eclipse-temurin:17-jre-alpine WORKDIR /app COPY --frombuild /app/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]第一段负责编译打包工具链齐全第二段只拷贝最终jar包干净瘦身。这是当前Java微服务镜像最标准也最稳妥的写法。第三不要忘记.dockerignore文件。它和.gitignore类似把本地缓存、临时目录、IDE配置排除在构建上下文之外。否则COPY . .会把几百MB的target目录全带进去构建慢不说还有可能把本地的敏感文件打进去。5.2 IDE直接打包镜像少记命令很多程序员习惯在IDE里操作一切。Idea系列编辑器配合Docker插件可以直接基于Dockerfile构建镜像并推送全程不离开编辑器。操作路径大致是安装Docker插件 - 配置Docker连接Windows上选择Docker Desktop的socketLinux上指向unix:///var/run/docker.sock - 在Dockerfile文件右键选择“Build Image for xxx” - 弹窗里填镜像名和tag - 构建完成后可以在Services面板看到镜像和容器列表右键即可启动、停止、查看日志。这种方式和命令行docker build本质是一回事但对于不熟悉命令行的同事来说图形化操作门槛低很多也更直观。我在带团队时要求所有后端服务镜像都用这种方式构建配合Jenkins做流水线的时候再改成命令行两套并行不冲突。5.3 轻量设备上的容器实践N100跑20个容器很多人以为容器一定需要强大服务器其实轻量设备上跑容器表现也相当可以。N100这类低功耗处理器在软路由、NAS圈子里很常见因为功耗低、静音、24小时开机不心疼用来跑docker容器非常合适。N100跑20个容器是可行的但有几个约束条件。第一是内存这类设备通常配8G或16G内存每个容器都要占用内存建议给关键容器设置内存上限docker run -d --memory512m --cpus0.5 your-image这样能防止某个容器内存泄漏拖垮整台机器。第二是存储20个容器加镜像很容易吃满磁盘建议上SSD并定期清理无用镜像docker image prune -f是个好习惯。第三是日志不打日志的话容器日志会持续膨胀启动时加上docker run -d --log-opt max-size10m --log-opt max-file3 your-image单个日志文件10MB、最多保留3个日志轮转自动完成避免/var/lib/docker被塞爆。我实测过N100双通道16G内存跑20个左右的轻量容器CPU长期占用率也就20%-30%日常运行很稳定。不过要提醒一点这类设备跑容器尽量选轻量镜像别跑GitLab这种大家伙真跑起来内存会先崩。6. 高频问题排查速查6.1 服务起不来三板斧定位问题容器启动失败时最高频的原因是端口占用、卷挂载权限、镜像启动命令错误、配置错误。排查顺序我一般按下面这样走第一步看状态docker ps -a注意加了-a才可以看到已退出的容器。第二步看日志docker logs 容器名。绝大多数启动失败的原因都能在日志里找到。比如MySQL启动失败日志会直接告诉你是配置文件问题还是数据目录权限问题。第三步看事件docker events --filter container容器名可以看到容器生命周期中发生了什么。有时候启动瞬间退出是健康检查失败导致的这时候docker inspect查看容器状态里的Health字段会有帮助。一个我自己踩过多次的坑挂载目录的权限问题。容器内的进程通常以特定用户运行如果宿主机挂载目录的属主和权限不对容器内进程没有写权限服务就会反复启动失败。比如MySQL容器挂载/data/mysql目录时如果目录属主不是999:999MySQL在容器内的UID就会报Permission denied。解决方式是chown -R 999:999 /data/mysql或者用--user参数指定容器运行用户。6.2 网络不通排查清单“docker网络不通”的热搜排名非常高我遇到过几乎每种可能的原因。核心排查路径是这样的先判断网络类型。默认情况下容器使用bridge网络外部通过端口映射访问容器内部。如果你能正常访问端口映射的服务说明网络基本正常问题出在具体路由或防火墙。容器间互访不通时优先确认是否在同一网络。比如一个容器是Compose启动的另一个是docker run启动的它们大概率不在同一个自定义网络上此时用容器名互相访问会失败。解决方式是让服务挂到同一个网络docker network connect mynet container名。再检查宿主机防火墙。很多Linux发行版默认开着firewalld或ufw即使端口映射了外部流量也会被防火墙拦截。我推荐在本地测试直接用curl从宿主机访问映射端口通就说明docker网络没问题问题在外部防火墙。还有一类隐蔽问题容器内DNS解析异常。表现为容器内能ping通IP但ping不通域名通常需要在/etc/docker/daemon.json里配置dns: [223.5.5.5, 8.8.8.8]重启docker生效。6.3 镜像下载慢和大镜像处理除了配置镜像源拉取大镜像时还可以用延迟拉取策略。比如部署Hadoop镜像hadoop的docker镜像这个热搜词说明不少人卡在这里镜像体积可能有几个GB一次性拉取很容易中断。可以分段重试docker pull registry.cn-hangzhou.aliyuncs.com/hadoop3.3.6/hadoop:3.3.6先从国内镜像源拉拉不动就多试几次docker会从断点继续。如果实在拉不下来改用Docker Hub官方镜像再配合镜像加速。日常使用中构建完镜像后及时推送私有仓库部署新机器时直接内网拉取这是治本的办法。还有一个技巧docker history 镜像名 --no-trunc可以查看镜像每一层的创建命令如果发现某些层异常大可以回溯到对应的构建步骤去优化。6.4 权限与安全细节这个话题值得多说几句。容器权限事故轻则服务起不来重则可能影响宿主机。除了前面提到的访问docker socket权限我还想强调两点。第一非必要不要使用--privileged运行容器。这个参数相当于给容器放开了所有权限限制可以访问宿主机所有设备一旦容器被入侵整个宿主机都暴露了。很多教程为了让容器跑起来直接加--privileged这是典型的知难而退型解法。通常遇到的问题比如挂载设备、调整系统参数都有更精细的参数可以解决。第二注意容器内时间。不少应用对时间敏感如果宿主机和容器时区不一致可能出现日志时间和实际时间错位8小时。启动容器统一加-e TZAsia/Shanghai或者挂载宿主机时区文件-v /etc/localtime:/etc/localtime:ro可以避免很多莫名其妙的时区问题。老系统升级docker这个热点话题也说一句升级前先备份/etc/docker/daemon.json配置文件、镜像tar包和容器数据卷升级完成后用docker run --rm hello-world验证基础功能。生产环境升级docker从来不是小事稳字当头。写在最后我在实际项目中已经很少用传统方式部署服务了凡是能容器化的都尽量容器化。docker这些年让我最深切的体会是部署不该是每次重复踩坑的体力活而应该变成一次性的、可复制的确定性操作。把环境交给镜像把编排写进文件把数据交给挂载卷这三个思维转变基本能覆盖90%的日常容器使用场景。最后再分享一个我自己养成的习惯所有重要容器在启动时都加上--restartalways数据目录全部挂载到宿主机镜像tag尽量用固定版本号而不是latest。前两条保证机器重启后服务能自动恢复、数据不会丢失第三条保证你不会在某一天发现线上环境悄悄变成了一个新版本还没人知道。容器技术本身不复杂核心就是确定性、可复制性、可管理性这三件事把这三点贯穿到每个操作里你很快就会发现部署这件事原来可以这么简单。