做运维这些年被“环境问题”折腾的次数比被业务问“怎么又挂了”的次数还多。新同事入职第一周光搭开发环境就能搭两天测试说功能没问题一到生产就报依赖缺失老板让扩容新机器从头装JDK、装Nginx、调配置一搞就是一下午。这些事情多了以后我几乎逢人就说该把环境本身也当成代码来管了而Docker正是把这句话落到实处的关键工具。这篇文章不打算抄官方文档我就围绕运维日常从安装部署、常用命令、生产实战、网络排错到企业级落地把Docker这条线完整梳理一遍。适合刚接触Docker的运维新人也适合已经在用但想补齐知识盲区的老手。1. 先搞清楚Docker到底解决了运维的什么痛点1.1 环境一致性从“在我这好好的”到“换台机器也一样”先聊一个所有运维都经历过的场景开发在本地跑得好好的发到测试环境就报缺少某个动态库测试环境验证通过上生产又因为Nginx配置、JDK版本不一致导致服务起不来。传统做法是写一份部署文档从操作系统版本到依赖包版本一行行列清楚然后让执行的人照着敲。问题是文档会过时人也容易漏步骤机房新机器跟老机器系统版本还不一样最后排查出来的问题五花八门。Docker镜像把所有东西一次性打包进去代码、运行时、系统库、配置文件、启动命令全在一个不可变单元里。镜像到哪应用环境就到哪不再有“换台机器就崩”的玄学问题。打一个通俗的比方以前是散装搬家锅碗瓢盆、衣服书报混在一起到新家发现少了个勺子现在是把所有东西分类装进标准集装箱搬到哪里都是同一个箱子内容物完全一致。这个“一致性”是Docker对运维最大的价值也是我向团队推Docker时最常讲的一点。1.2 为什么容器比虚拟机轻内核共享与隔离机制很多运维刚接触容器时会问这不就是轻量级虚拟机吗其实原理完全不同。虚拟机是在宿主机上通过Hypervisor虚拟出一整套硬件每个虚拟机里都有一个完整的Guest OS启动时要经历完整的BIOS、内核引导过程所以慢资源占用也大。容器则直接共享宿主机内核通过Linux的namespace做隔离、cgroup做资源限制。namespace隔离了进程、网络、挂载点、主机名、IPC等资源所以容器里的进程看起来像在一个独立系统里cgroup限制CPU、内存、IO等资源防止某个容器把宿主机资源吃光。用房子来类比虚拟机是各自独立的一栋房子地基、墙体、水电全要重新建容器是同一栋楼里的精装单间公共基础设施内核共享但房间之间互不干扰。正是因为共享内核容器启动才是秒级一台物理机可以同时跑几十个容器而不觉得吃力。还有一个知识点容易被忽略镜像的分层机制。构建镜像时每一行指令会生成一个只读层最终容器运行时在上层加一个可写的容器层。多个镜像如果底层基础镜像相同它们就共享这些底层不需要重复拉取和存储。这也是为什么拉完一个ubuntu镜像再拉基于它的业务镜像时会快很多的原因。2. 从零部署Linux和Windows两条路线的实操记录2.1 Linux安装Docker Engine从换源到开机自启我在生产环境遇到最多的是Ubuntu和CentOS。先说Ubuntu。不建议直接apt install docker.io因为仓库里的版本往往比较旧。我习惯走官方docker-ce仓库如果服务器在境内网络拉不到官方源就换成国内的镜像源。步骤大概是卸载可能存在的旧版本apt-get remove docker docker-engine docker.io containerd runc安装依赖apt-get update apt-get install ca-certificates curl gnupg lsb-release -y添加GPG key和仓库以阿里云镜像源为例curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | 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://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable | tee /etc/apt/sources.list.d/docker.list /dev/null安装apt-get update apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y启动并设置开机自启systemctl enable --now dockerCentOS对应的是yum install yum-utils、yum-config-manager --add-repo然后yum install docker-ce docker-ce-cli containerd.io docker-compose-plugin。装完马上做三件事。第一配置镜像加速。编辑/etc/docker/daemon.json写入registry-mirrors我一般用阿里云或腾讯云的加速地址然后systemctl restart docker。第二检查存储驱动docker info看到Storage Driver是overlay2就没问题如果还是老的devicemapper建议趁早换overlay2性能和稳定性都好很多。第三如果根分区空间紧张改>[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_unicode_ci default-time-zone08:00 max_connections500然后启动命令docker run -d \ --name mysql8 \ -p 3306:3306 \ -v /opt/mysql/data:/var/lib/mysql \ -v /opt/mysql/conf:/etc/mysql/conf.d \ -v /opt/mysql/init:/docker-entrypoint-initdb.d \ -e MYSQL_ROOT_PASSWORD此处替换为强密码 \ -e TZAsia/Shanghai \ --restart unless-stopped \ mysql:8.0解释三个关键点。第一/docker-entrypoint-initdb.d目录下的.sql脚本只在数据目录首次初始化时执行所以建库建表的初始化脚本放这里最合适但注意如果data目录已经有数据脚本不会重复执行。第二时区要双保险既有容器环境变量TZ又有MySQL的default-time-zone不然查NOW()还是返回UTC时间。第三MySQL 8.0默认认证插件是caching_sha2_password旧版客户端连接会报错要么改客户端驱动要么启动时加--default-authentication-pluginmysql_native_password但现在还是建议推驱动升级而不是降级插件。验证的时候进容器跑一下docker exec -it mysql8 mysql -uroot -p然后执行show variables like %character%;和select now();确认字符集和时区都对。数据持久化验证也很简单docker stop mysql8 docker start mysql8数据还在就说明卷挂载没问题。4.2 用Docker Compose搭建Redis主从不写命令也能编排单个容器用docker run还凑合一旦涉及多容器协作比如Redis主从写一堆run命令又长又容易漏参数。Compose的作用就是用YAML把服务定义下来一整个项目可以版本化管理换台机器git clone下来docker compose up -d就起来了。我常用的目录结构redis/ ├── docker-compose.yml ├── master/ │ └── redis.conf └── slave/ └── redis.conf主节点redis.conf核心配置bind 0.0.0.0、protected-mode yes、requirepass 密码、appendonly yes。从节点多一行replicaof redis-master 6379和masterauth 密码。注意这里replicaof写的是服务名redis-master而不是IP这是Compose网络里容器间自动DNS解析的好处。docker-compose.yml核心内容services: redis-master: image: redis:7 container_name: redis-master ports: - 6379:6379 volumes: - ./master/redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf] redis-slave: image: redis:7 container_name: redis-slave depends_on: - redis-master volumes: - ./slave/redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf]启动后验证从节点docker exec -it redis-slave redis-cli -a 密码 info replication看到master_link_status:up就说明主从同步正常。这个部署方式我用了很久胜在配置可视化、可控、可复制。踩过的坑也提醒一下从节点配置里如果忘了masterauth主从一建立就一直处于down状态日志里能看到NOAUTH Authentication required主节点如果设了bind 127.0.0.1从节点也连不上初期调试时bind 0.0.0.0是最省事的。5. 网络问题是运维的隐形杀手docker网络不通排查实录5.1 网络模式与端口映射原理Docker网络出问题很多运维第一反应就是重启Docker结果问题依旧。要靠谱排查先得理解Docker网络的底层逻辑。默认的bridge网络宿主机上有个docker0网桥每个容器创建时会分配一对veth虚拟网卡一头连着容器的eth0另一头插在docker0上。容器之间通过网桥互通容器访问外网时宿主机内核做NAT转发MASQUERADE。外部访问容器映射端口时靠的是iptables的DNAT规则把宿主机端口转发到容器IP和端口。所以-p 3306:3306的本质不是直接开个洞而是加了一条DNAT规则。Docker提供了好几种网络模式bridge默认、host直接用宿主机网络栈没有独立IP端口直接监听在宿主机上、none无网络、container共享另一个容器的网络栈。还有一种用户自定义bridge网络docker network create mynet容器加入后可互相用容器名解析解决了默认bridge网络下容器不能通过名字互相访问的问题。5.2 高频故障与排查手段我整理过一份自查手册列几个高频网络事故容器内访问外网失败。先ping网关、再nslookup确认DNS是否正常。常见原因是宿主机防火墙把FORWARD链搞乱了或者iptables -F把DOCKER链清了。见过一次因为执行了systemctl stop firewalld导致Docker网络全部瘫痪的案例firewalld停止时会重刷iptables规则Docker的NAT规则被清掉重启Docker才恢复。外部访问容器端口不通。先确认服务监听在0.0.0.0进入容器netstat -tlnp看看。如果容器里监听的是127.0.0.1外部自然访问不到。接着看宿主机iptables -t nat -L DOCKER确认DNAT规则存在。再检查云安全组很多云厂商的安全组没有放行对应端口这是最容易忽略的一环。容器之间不通。分别确认两个容器是否在同一个自定义网络里docker network inspect 网络名看Containers列表。跨网络通信需要手动连接docker network connect mynet container名。容器重启后IP变了。这是默认bridge网络下常见问题容器每次启动分配的IP都可能变。解决办法是创建自定义网络加入容器或者在自定义网络里固定IPdocker run --ip 192.168.100.10但前提是网络创建时指定了subnet。排查工具上docker inspect看IP和网络配置nsenter -t 容器PID -n进入容器网络命名空间用宿主机工具排错比在容器里装iproute2方便宿主机上用tcpdump -i docker0抓包定位丢包位置。网络问题别靠猜抓包和看iptables规则往往一抓一个准。6. 从能用走向好用企业级落地要补哪些功课6.1 镜像仓库与版本管理私有仓库和tag规范在一个团队里如果没有统一的镜像仓库所有人各拉各的公共镜像版本乱得没法查。企业级落地第一步就是搭私有仓库。Harbor是我用得最多的功能完备程度明显高于裸的Registry带项目管理、访问控制、漏洞扫描、镜像复制。部署Harbor用官方安装包加一条docker-compose命令即可生产上建议用外部数据库和对象存储别把数据存在Harbor容器里。镜像tag规范要提前定死我团队现在用的是组件名:环境-日期-构建号比如gateway:prod-20250116-8f2a1c3既能快速定位出包时间又能对应到具体代码commit回滚时直接改tag重新拉取。镜像瘦身是另一个效率点。多阶段构建非常实用拿Go项目举例第一阶段的Golang基础镜像编译出二进制第二阶段用alpine或distroless只拷贝二进制和必要资源最终镜像体积可能从几百MB降到几十MB。Dockerfile里记得写.dockerignore把.git、node_modules这些无效文件排除能减少不少构建上下文传输时间。6.2 资源限制、日志与监控别让容器失控生产环境最怕发生的事容器不受控把宿主机内存吃光导致整个服务器上所有服务一起挂掉。所以run的时候必须限制资源我是把单容器内存限制在2G、CPU限制在2核起步核心服务再按压力调docker run --memory2g --cpus2 --pids-limit200 ...cgroup会强制约束这些限制超出的内存会被OOM Killer杀掉容器而不是拖垮宿主机。这个限制带来的副作用是如果业务确实需要更多资源容器会频繁重启所以资源不是拍脑袋定的要结合压测数据来。日志策略也要提前规划。Docker默认的json-file日志驱动会无限增长容器日志把磁盘打爆是生产事故高发项。创建容器时加日志轮转配置--log-driver json-file --log-opt max-size50m --log-opt max-file3或者直接在daemon.json里全局配置省得每个容器单独加。日志集中化我用Filebeat加ELKFilebeat以DaemonSet或systemd服务方式跑在宿主机上采集/var/lib/docker/containers下的日志统一进Elasticsearch。监控方面docker stats只能应急看要长期保留需要上cAdvisor加Prometheus加Grafana这套组合。cAdvisor采集容器CPU、内存、网络、磁盘指标Prometheus负责存储和告警规则Grafana展示面板。初期接入成本不高但对提前发现资源容量问题帮助很大。6.3 安全基线能用和安全是两回事很多团队Docker用得顺手安全基本没意识。这里列几条最基础的安全基线够用了。不要以root运行应用Dockerfile里写USER 1000:1000给应用一个普通用户。不要给容器加--privileged这个参数等于把宿主机的全部权限都交给容器生产上几乎永远不需要。不要轻易挂载/var/run/docker.sock进容器一旦容器被攻破等于拿到了宿主机的Docker控制权。不在启动命令里明文写密码用env_file或密钥管理因为docker inspect能看到环境变量明文密码等于裸奔。镜像扫描用Trivy拉镜像后扫一遍再上线高危漏洞限期升级。6.4 从Compose到编排平台K8s是方向但不是唯一方向企业规模上来以后单机Compose管理几十个容器已经很吃力会想上编排平台。Docker Swarm逐渐边缘化K8s是主流。但我想说实话如果你们服务器规模在几十台以下没有特别强的调度需求先把Compose用利索再配合CI/CD和监控已经很能打。盲目上K8s只会带来额外的运维负担。真要往K8s走运维要补的知识点是Deployment和StatefulSet怎么选、Service与Ingress的流量路径、ConfigMap和Secret的配置管理、PV/PVC的存储抽象、Helm的包管理。迁移思路上一开始不要全量搬挑无状态服务先容器化验证再逐步处理有状态组件。这个演进过程是梯次推进的不是一把梭。最后聊几句心里话。Docker这东西用起来不难难的是把运维该想的兜底都想好磁盘、日志、网络、安全、版本、资源限制每一个都在线上炸过。我在团队里推Docker时反复强调一句话别把容器当虚拟机用镜像和编排才是它的灵魂。先把基础命令跑熟再把生产兜底补完最后再谈K8s这条路走下去运维工作会轻松很多也会有很多时间做真正有价值的优化。