在部署这块真正让我省心的工具Docker 算一个Docker Compose 算另一个。这两个名字经常连着出现很多人以为是一套东西其实一个是容器运行时一个是多容器编排工具。这篇文章不是抄官方文档是我从零开始完整部署 Docker、Docker Compose 之后把踩过的坑一块写出来的实操记录覆盖 Linux 服务器和 Windows 桌面端两种场景。要是你正准备在 Ubuntu 上部署 MySQL、Redis、GitLab、RabbitMQ或者被 Docker Desktop 的虚拟化报错卡到怀疑人生这篇文章能帮你把路线一次性理清。1. 先理清概念Docker 与 Docker Compose 到底谁负责哪一块1.1 容器到底解决了什么问题很多人第一次接触 Docker 时最容易把它理解成“一个轻量级虚拟机”。这么说会误导自己因为虚拟机的思路是模拟整台电脑要分配 CPU、内存、硬盘装完整操作系统而 Docker 的思路是直接共享宿主机内核只把应用和它需要的运行时、依赖、配置打成一个个独立的包也就是镜像。镜像是只读模板基于镜像启动的实例叫容器容器之间相互隔离但底层都是同一个 Linux 内核。这种设计带来的直接好处有三点。第一环境一致。以前在开发机运行好好的服务部署到服务器上就报错多半是依赖版本不对、系统库缺失、环境变量没配。用 Docker 后镜像在本地构建好部署到哪台机器都是一模一样的运行环境不会再出现“在我电脑上明明能跑”的尴尬。第二隔离性强。两个项目需要不同版本的 Node.js、Python 或 Java互相不兼容用容器分开跑各装各的依赖互不干扰。第三资源利用率高。容器不装完整操作系统启动通常在秒级同样一台 2 核 4G 的机器用虚拟机可能只能跑两三个实例用容器跑十几个都很轻松。我之前有一个很直观的体验给客户交付一个资产管理工具服务端依赖 Java 17、Redis 7、MySQL 8还带一个定时任务模块。以前交付要给对方发一堆安装文档要求对方提供对应的操作系统环境来回沟通成本很高。后来改用 Docker Compose 打包整套服务客户机器上只要装了 Docker 和 Compose一个命令就能把完整环境拉起来交付瞬间变成“复制文件 执行命令”两件事。这就是容器化在真实项目里带来的最大价值。1.2 Compose 的引入是为了编排不只是省事Docker 单独能跑容器那为什么还需要 Docker Compose原因很简单真实项目很少只有一个容器。你要部署一个 Web 应用可能需要 Nginx 做反向代理、后端服务、MySQL 存数据、Redis 做缓存这就有四个容器了。如果用 docker run 一条条手动启动需要记住每个容器的端口映射、环境变量、数据卷挂载、网络配置还要手动保证启动顺序——数据库先起来缓存先起来然后才是应用。Docker Compose 把这一切变成声明式配置。你只需要写一个 YAML 文件在里面描述要启动哪些服务、每个服务用哪个镜像、映射哪个端口、挂载哪个目录、依赖哪个服务然后运行 docker compose up -dCompose 会按照依赖关系把服务依次拉起来。后续的启停、查看日志、扩容、清理也都通过 compose 命令统一管理。我个人的习惯是只要项目超过一个服务就一定用 Compose 来管绝不手敲 docker run。原因不只是命令少而是 Compose 文件可以放进 Git 仓库整个项目的部署拓扑都有了版本记录。任何人拿到这个文件执行一条命令就能复现一套一模一样的环境。这对团队协作和故障恢复来说价值远超“省事”这两个字。1.3 五个必记的核心词镜像、容器、仓库、卷、网络在开始实战之前先把几个高频术语说清楚后面用命令的时候才不会懵。术语一句话理解类比镜像Image只读模板包含应用代码、依赖、配置做菜的菜谱加半成品食材容器Container镜像运行起来的实例可读可写按照菜谱最终炒出来的一道菜仓库Registry集中存放镜像的地方Docker Hub 是最大的公共仓库菜谱的云端图书馆卷Volume宿主机目录与容器目录的映射容器删了数据还在给容器插一块外接硬盘网络Network容器之间通信的虚拟网络给容器分配虚拟网卡和 IP卷这个点尤其重要。容器本身是无状态的容器一删容器内写进去的文件就全没了。如果你跑 MySQL数据文件必须存放在卷或宿主机挂载目录里否则容器重启数据就丢了。后面实战部分我会专门演示这个配置。2. 动手之前先做环境检查硬件虚拟化、内核与权限2.1 服务器端和桌面端先分清安装思路Docker 的安装路径主要分两类。一类是 Linux 服务器比如 Ubuntu、CentOS安装的是 Docker Engine也就是 Docker 的核心引擎再加几个官方插件另一类是 Windows 和 macOS 桌面环境一般通过 Docker Desktop 这个图形化工具来使用它底层需要借助虚拟化技术创建一个 Linux 子系统来跑容器。从个人经验来看稳定性最高的部署方式是 Linux 服务器 Docker Engine Docker Compose 插件这也是生产环境最主流的组合。Docker Desktop 更适合开发调试尤其是 Windows 上有图形界面需求的时候。所以我的建议是学习和测试随便选哪种都行但真正部署服务优先准备一台 Ubuntu 服务器。2.2 Linux 内核与 overlay 文件系统检查Docker 对 Linux 内核版本有要求通常建议内核 3.10 以上实际生产环境我建议至少用 Ubuntu 20.04 或 22.04 这种长期支持版本。登录服务器后先用两个命令确认基础环境。uname -r这条命令查看内核版本。如果在 5.4 以上基本无忧。然后检查内核是否加载了 overlay 模块Docker 默认的存储驱动叫 overlay2比旧版的 aufs 性能更好、更稳定。lsmod | grep overlay如果没输出可以手动加载sudo modprobe overlay这一步可以放在安装命令之前虽然大部分新版内核默认支持但确认一下能省掉后面不少排查时间。内核检查完毕后顺手把系统包索引更新一下sudo apt update2.3 Windows 的虚拟化支持检测为什么一上来就卡在这网上关于 Docker Desktop 安装失败的求助帖非常多热搜词里那个 “virtualization support not detected docker desktop failed to start because v” 就是典型。这个问题一句话解释就是Docker Desktop 要在 Windows 上跑 Linux 容器必须借助 Hyper-V 或 WSL2 的虚拟化能力而你的电脑虚拟化功能没开或没配好。检查方法很简单按 Ctrl Shift Esc 打开任务管理器切到“性能”选项卡看 CPU 那一栏有没有显示“虚拟化已启用”。如果显示“已禁用”就需要重启电脑进 BIOS/UEFI找到 Intel Virtualization Technology又叫 VT-x或 AMD SVM Mode把它设为 Enabled。如果是公司统一管理的电脑BIOS 里这项可能被锁死那就得联系管理员处理。另外Windows 功能面板里需要启用“适用于 Linux 的 Windows 子系统”、“虚拟机平台”和“Hyper-V”。开启后重启再装 Docker Desktop。这部分我放在后面专门讲 Docker Desktop 的章节这里先说明白大部分安装失败和虚拟化配置有关不是 Docker 本身的问题。3. Ubuntu 上安装 Docker Engine照着敲就能通3.1 用官方 apt 仓库完成安装在 Ubuntu 上安装 Docker Engine 有几种方式最稳妥的是用官方 apt 仓库安装。网上有些一键脚本 curl -fsSL https://get.docker.com | bash -s docker虽然快但我发现脚本安装的版本和仓库源可控性稍差遇到国内网络环境也容易中途失败。生产环境我习惯手动走官方仓库流程稳。先安装必要依赖sudo apt install -y ca-certificates curl gnupg lsb-release然后添加 Docker 官方 GPG 密钥sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg这里在服务器上把官方密钥和仓库地址固化下来以后 apt 更新就能直接获取 Docker 新版本。接着写入软件源echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.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-buildx-plugin docker-compose-plugin注意这行命令里包含了 docker-compose-plugin这是 Docker Compose 的官方插件包装完 Docker 后 compose 命令也能直接用我装完第一件事就是验证这两个工具是否都到位docker --version docker compose version如果能看到类似 Docker version 24.0.7 和 Docker Compose version v2.21.0 的输出说明核心工具都装好了。别急着高兴还有两件事要做配置镜像加速、设置非 root 用户权限。3.2 配置镜像加速器解决拉取缓慢的问题Docker 安装好了第一件事不是着急跑服务而是先确认镜像能不能快速拉下来。Docker Hub 在国内的拉取速度波动很大很多团队初始化阶段就会把加速器配好否则部署一个 GitLab 可能要等上大半天。配置方式是在 /etc/docker/daemon.json 里写 registry-mirrors 参数。先创建或编辑这个文件sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://你的加速器地址] } EOF加速器地址怎么拿常见做法是使用国内云厂商提供的镜像加速服务登录各自容器服务控制台就能看到专属地址注册后拷贝到配置里即可。我的经验是优先选自己用过的服务商地址这样拉取速度比较稳定。改完文件后一定要重启 Docker 才能生效sudo systemctl daemon-reload sudo systemctl restart docker验证加速器是否生效可以运行docker info | grep -A 2 Registry Mirrors能列出你配置的地址就说明生效了。这里有个细节容易漏daemon.json 必须是合法的 JSON 格式少一个逗号或多一个引号Docker 服务都可能起不来。改完文件后如果 systemctl restart docker 卡住或报错先检查这个 JSON 格式对不对。3.3 非 root 用户操作 Docker 的正确姿势Docker 安装完成后默认只有 root 用户和 docker 用户组的成员能执行 docker 命令。如果你直接用普通用户跑 docker ps会看到类似 docker: permission denied while trying to connect to the Docker daemon socket 的报错。解决方式是把当前用户加入 docker 组sudo groupadd docker sudo usermod -aG docker $USER newgrp docker执行完这三条后重新登录终端再试 docker ps。这一步建议所有人在安装后立刻做不然以后每次敲 docker 命令前面都要加 sudo很烦。补充一个安全提醒加入 docker 组意味着这个用户拥有等同于 root 的权限因为 Docker 的容器管理本质上是操作宿主机的系统调用。给用户加 docker 组的时候心里要有数别在小号或共享机器上随手把不了解的用户加进去。3.4 用 hello-world 验证全套链路工具装完、加速器配好、用户组配置完成现在就该做冒烟测试了。运行docker run hello-worldDocker 会先从仓库拉取一个 hello-world 镜像然后启动一个临时容器输出一段欢迎信息。如果你能看到 “Hello from Docker!” 的输出说明镜像拉取、容器创建、执行流程都是通的。这只是最简单的验证。我一般还会再跑两个命令确认更深层的信息docker version docker infodocker version 看客户端和服务端的版本如果客户端能连上服务端说明 socket 通信正常。docker info 则可以看到存储驱动是不是 overlay2、镜像加速器有没有生效、容器总数、镜像总数等这些对后续排障都有用。到这一步Docker Engine 本身已经部署完毕接下来把 Docker Compose 单独拎出来讲清楚。4. 安装 Docker Compose插件方式与独立二进制方式4.1 注意版本差异docker-compose 和 docker compose很多老教程里写的是 docker-compose带一个横线那是 Docker Compose 早期的独立二进制版本命令格式是 docker-compose up。现在 Docker 官方推荐的是插件方式命令格式是 docker compose中间没有横线作为 Docker CLI 的子命令存在。这个变化会带来一个实际影响如果你在网上搜索某篇两年前的博客复制里面的 docker-compose 命令在新环境里可能会提示 command not found因为插件方式下根本没有 docker-compose 这个命令。判断方式很简单跑一下 docker compose version如果能输出版本号说明你已经有了 Compose如果是 docker-compose version那是旧的独立二进制安装方式。4.2 推荐用官方插件安装两行命令搞定我们前面安装 Docker Engine 时已经通过 docker-compose-plugin 这个包把 Compose 插件安装好了。所以如果是从零开始照着上一章的命令装完 Docker直接就有 docker compose 可用。如果你的系统是旧版 Docker或者之前只装了 docker-ce没有装插件可以单独补装sudo apt install -y docker-compose-plugin还有一种历史遗留情况服务器上已经装了独立二进制 docker-compose但版本很老。我建议把旧版本清理掉再装插件避免两个版本共存造成命令混淆。清理方式sudo rm /usr/local/bin/docker-compose然后按前面方式装上插件即可。4.3 验证 compose 配置与常用命令装完插件后除了 docker compose version我最推荐的验证方式是写一个测试用的 compose 文件样例文件写好后运行docker compose config这条命令会解析 YAML 文件并输出标准化的配置结果。如果 YAML 格式有误、缩进不对、字段写错它会直接报错相当于 lint 工具。我习惯每次部署新服务前都先跑一下 docker compose config确认没问题后再真正启动能避免很多低级错误。Compose 日常最常用的命令也就那么几个命令作用docker compose up -d后台启动所有服务docker compose ps查看服务运行状态docker compose logs -f跟踪查看所有服务日志docker compose exec 服务名 命令进入某个容器执行命令docker compose down停止并删除容器网络docker compose down -v停止并删除容器和卷慎用会清数据这些命令在后面实战中都会用到。5. 实战案例用 Docker Compose 拉起 MySQL 8.0 Redis5.1 设计目录结构与 compose.yaml光讲概念不过瘾直接来一个完整的实战案例在一台全新的 Ubuntu 服务器上用 Docker Compose 部署 MySQL 8.0 和 Redis 7同时解决数据持久化、密码配置、健康检查这几个关键问题。先在用户目录下创建一个项目文件夹每个服务单独建子目录数据目录和配置目录分开mkdir -p ~/app/mysql/{data,conf,logs} mkdir -p ~/app/redis/{data,conf} cd ~/app然后创建 compose.yaml 文件。这里我用的是最新版 Compose 的默认文件名早期版本喜欢用 docker-compose.yml两个名字都能识别但新版统一推荐 compose.yaml。在 ~/app 目录下创建 compose.yaml内容先写 MySQL 部分services: mysql: image: mysql:8.0 container_name: mysql8 restart: unless-stopped ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: YourStrongPass TZ: Asia/Shanghai command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci volumes: - ./mysql/data:/var/lib/mysql - ./mysql/conf:/etc/mysql/conf.d - ./mysql/logs:/var/log/mysql healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -pYourStrongPass] interval: 10s timeout: 5s retries: 55.2 MySQL 8.0 的关键配置密码、时区、字符集、持久化这个 compose 配置里有几个点值得展开说说。第一MYSQL_ROOT_PASSWORD 环境变量。MySQL 官方镜像首次启动时会根据这个变量初始化 root 用户的密码。要注意数据卷已经存在的情况下改这个环境变量不会更新密码。所以首次启动前就要把密码定好。我习惯把密码写成强密码至少包含大小写字母、数字和特殊字符。第二command 里指定了 --character-set-serverutf8mb4 和 --collation-serverutf8mb4_unicode_ci。这是为了避免中文乱码。MySQL 默认字符集在有些版本里不是 utf8mb4而 utf8mb4 才是真正完整的 UTF-8能存储 emoji 和生僻字。新项目我基本必配这两项。第三volumes 挂了三个目录。./mysql/data 是数据文件目录这个必须挂出来否则容器重建一次数据就没了./mysql/conf 对应 MySQL 的配置目录未来要改 my.cnf 可以直接放这里./mysql/logs 是日志目录方便排查 SQL 慢查和错误日志。卷挂载路径要与官方镜像里声明的数据目录一致MySQL 8 的数据目录固定是 /var/lib/mysql。启动 MySQL 后验证服务状态docker compose up -d mysql docker compose ps docker exec -it mysql8 mysql -uroot -p输入密码后如果能进入 MySQL 命令行说明部署成功。5.3 Redis 的关键配置持久化、密码与安全建议Redis 相比 MySQL 简单一些但有几个配置新手很容易忽略。先写 compose 配置redis: image: redis:7-alpine container_name: redis7 restart: unless-stopped ports: - 6379:6379 command: [redis-server, /usr/local/etc/redis/redis.conf] volumes: - ./redis/data:/data - ./redis/conf/redis.conf:/usr/local/etc/redis/redis.conf healthcheck: test: [CMD, redis-cli, ping] interval: 10s timeout: 3s retries: 5Redis 官方镜像本身不带配置文件需要自己在宿主机准备 redis.conf 并挂载进容器。在 ~/app/redis/conf/redis.conf 里写入requirepass YourRedisPass appendonly yes appendfsync everysecrequirepass 是访问密码appendonly yes 开启 AOF 持久化appendfsync everysec 表示每秒刷盘一次兼顾性能和数据安全。Redis 相比 MySQL 更容易被忽视安全以前见过不少 Redis 没设密码直接暴露到公网然后被攻击者利用写定时任务入侵宿主机的案例。所以 Redis 只要涉及网络访问必须设密码端口也尽量不要暴露到 0.0.0.0。启动 Redisdocker compose up -d redis docker exec -it redis7 redis-cli -a YourRedisPass ping能返回 PONG说明 Redis 服务正常。5.4 启动、验证与连接数据库MySQL 和 Redis 配置都写好后一条命令启动全部服务docker compose up -d接下来检查状态docker compose ps正常情况下两个服务都应该是 running 状态同时还显示健康状态 healthy。我在前面配置里写了 healthcheckCompose 会定期执行健康检查命令保证服务“端口通了”之外还“真的能响应请求”。到这里MySQL 8.0 Redis 这套最常见的后端基础设施就部署完成了。应用服务连接的时候如果是宿主机上的进程就连接服务器的 IP 加对应端口如果其他容器连接走 Compose 默认网络即可服务名就是主机名。6. 多服务编排进阶GitLab、RabbitMQ 和青龙面板的部署要点6.1 用 Compose 部署 GitLab 的资源评估和端口规划有了基础案例可以试着部署更复杂的服务。GitLab 社区版是很多人用 Docker 部署的第一个重量级应用也是容易踩坑的一个因为它对内存的要求很直接。先看 compose 配置片段gitlab: image: gitlab/gitlab-ce:latest container_name: gitlab restart: unless-stopped hostname: gitlab.example.com ports: - 80:80 - 443:443 - 22:22 volumes: - ./gitlab/config:/etc/gitlab - ./gitlab/logs:/var/log/gitlab - ./gitlab/data:/var/opt/gitlab shm_size: 256mGitLab 官方推荐至少 4GB 内存跑社区版我的实测是 2GB 内存的机器也能启动但跑一段时间后会变得非常卡甚至 OOM。所以部署 GitLab 前一定要给服务器留足内存。第二个坑是 external_url 配置不在 compose 里而在 /etc/gitlab/gitlab.rb 里。启动后编辑 config 目录下的 gitlab.rb设置 external_url http://你的服务器IP然后执行 gitlab-ctl reconfigure。注意 reconfigure 过程比较耗时容器内执行命令可以用docker exec -it gitlab gitlab-ctl reconfigure第三个坑是端口冲突。22 端口如果宿主机正在跑 SSHGitLab 的 SSH 映射会冲突。解决办法是改成其他端口比如 2222:22但这样 git clone 时就要带上非标准端口对团队使用不友好。建议部署前先检查端口占用情况或者干脆把宿主机 SSH 移到其他端口保持 GitLab 用 22 端口。6.2 短时间内拉起 RabbitMQ 并开启管理面板RabbitMQ 是一个常用的消息队列Docker 部署的优势是省去了 Erlang 环境配置的麻烦。官方提供了带管理插件的镜像一条配置就能同时启动消息服务和管理界面。rabbitmq: image: rabbitmq:3-management-alpine container_name: rabbitmq restart: unless-stopped ports: - 5672:5672 - 15672:15672 environment: RABBITMQ_DEFAULT_USER: admin RABBITMQ_DEFAULT_PASS: YourRabbitPass healthcheck: test: [CMD, rabbitmq-diagnostics, check_running] interval: 10s timeout: 5s retries: 55672 是 AMQP 协议端口业务代码连接消息队列用这个15672 是管理面板的 Web 端口浏览器访问 http://服务器IP:15672 就能看到图形化界面用环境变量里配置的账号密码登录。RabbitMQ 默认的 guest 用户只允许 localhost 访问所以用环境变量创建自定义用户是必须的一步。6.3 青龙面板的依赖管理与目录挂载经验青龙面板是一个定时任务管理工具可以统一调度 Python、JavaScript、Shell 脚本很多自建自动化项目会用到它。部署本身不复杂compose 配置大概长这样qinglong: image: whyour/qinglong:latest container_name: qinglong restart: unless-stopped ports: - 5700:5700 volumes: - ./qinglong/data:/ql/data environment: QL_PORT: 5700青龙面板主要的坑在于依赖管理。面板里跑脚本依赖 Node.js 或 Python 的某些包如果容器里没装脚本启动就会报 ModuleNotFoundError。实际操作中有两种方式一种是在面板的“依赖管理”页面里直接安装比如填入 requests、axios 这类包名另一种是进入容器用 npm 或 pip 装docker exec -it qinglong bash npm install -g axios pip install requests我的体会是面板里的依赖管理页面虽然方便但涉及的包多了以后容器重建后所有依赖都要重装一遍。所以最好的习惯是把常用依赖整理成清单容器重建后第一件事不是急着配脚本而是先把依赖列表跑一遍。6.4 生产环境进阶设置日志限制、健康检查、重启策略多服务编排到后期有个很容易忽视的问题容器日志会无限增大。默认配置下一个打印频繁的容器跑一两个月日志文件可以轻松占满几十 GB 磁盘。解决方法是在 compose.yaml 里给服务配置 logging 参数logging: driver: json-file options: max-size: 10m max-file: 3这样每个容器日志文件单个最大 10MB保留 3 份超过上限自动轮转。生产环境我基本每个服务都会加这个配置防止日志把磁盘写满。重启策略也是生产环境必须考虑的。restart: unless-stopped 是最常用的配置它表示容器异常退出时自动重启但你自己手动 stop 掉的不会强制拉起来。对于数据库这类需要高可用的服务建议再加上 healthcheck让 Compose 能感知服务是否真的健康而不是只靠“进程还活着”来判断。7. Windows Docker Desktop 启动故障排查7.1 virtualization support not detected 的出现场景与处理Docker Desktop 虽然解决了很多人在 Windows 上用 Docker 的痛点但安装过程中的报错也是千奇百怪。最典型的一个就是启动时提示 “virtualization support not detected” 或 “Docker Desktop failed to start because virtualization support wasnt detected”。这个报错的核心原因只有一个Windows 的虚拟化能力没有被 Docker Desktop 检测到。但具体是哪个环节出了问题需要一步步排查。第一步确认 CPU 虚拟化。打开任务管理器性能选项卡查看 CPU 右下角有没有“虚拟化已启用”。如果显示已禁用需要进入 BIOS/UEFI 打开 VT-xIntel或 SVM ModeAMD。不同主板的 BIOS 菜单位置不一样一般在 Advanced 或 Processor 设置里。第二步确认 Windows 功能。按 Win R输入 optionalfeatures 回车在“启用或关闭 Windows 功能”里勾选“Hyper-V”、“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。注意Hyper-V 和 WSL2 其实是两条不同的路线Docker Desktop 默认推荐 WSL2但 WSL2 也需要开启“虚拟机平台”作为底层支持。勾选完成后重启电脑。第三步确认内核隔离没把虚拟化性能拖垮。Windows 安全中心里有个“内核隔离 - 内存完整性”在某些配置下会和 Docker 的虚拟化后端产生冲突导致 Docker Desktop 启动失败或运行极慢。如果开启了可以尝试关闭后再启动 Docker Desktop。还有一条命令行方式可以强制启用 hypervisor 启动类型以管理员身份打开 PowerShell 执行bcdedit /set hypervisorlaunchtype auto然后重启。这个方法对部分开启虚拟化后仍检测不到的场景有效。7.2 failed to connect to the docker api 的排查路径另一个高频报错是 “failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine”。第一次看到这个报错时容易懵npipe 是 Windows 的命名管道看起来像网络地址其实是 Docker Desktop 客户端与后端引擎通信的通道。这个报错的本质是 Docker Desktop 的 Linux 引擎没有正常启动所以客户端连不上。排查顺序我总结为三步。第一步看 Docker Desktop 的托盘图标。如果图标还在转或显示 Docker is starting说明引擎还在初始化等一两分钟再看。如果一直卡在启动中多半是前面的虚拟化配置有问题。第二步在 PowerShell 里执行 docker version 看客户端和服务端版本信息。如果只有 Client 输出没有 Server 部分输出说明客户端和服务端没有建立连接重点检查 Docker Desktop 的引擎是否真的起来了。第三步如果使用的是 WSL2 后端到 WSL 里手动确认 Linux 子系统状态。打开终端执行wsl --status wsl --updateWSL 内核版本太旧也会导致 Docker Desktop 引擎无法启动。更新 WSL 后重启 Docker Desktop大多数情况下能解决。最后还有一个万能重置方法在管理员 PowerShell 里执行 netsh winsock reset然后重启电脑。这个操作会重置 Windows 网络协议栈有时能解决命名管道连接不上的诡异问题。注意执行后务必重启否则不生效。7.3 WSL2 后端与 Hyper-V 两种选择Docker Desktop 在 Windows 上有两种后端老版本用 Hyper-V新版本默认用 WSL2。WSL2 的优势是启动更快、内存占用更可控而且与 Windows 文件系统之间的交互更自然。如果你的电脑能满足 WSL2 的条件我建议优先用 WSL2 后端。使用 WSL2 时有一个隐藏问题WSL 的虚拟磁盘文件会不断膨胀。WSL2 的默认 install 路径下有一个 ext4.vhdx 文件这个文件只增不减即使你在容器里删了大量文件磁盘文件也不会自动缩小。解决方法是手动压缩执行wsl --shutdown然后在资源管理器地址栏输入%LOCALAPPDATA%\Docker\wsl\data\找到 ext4.vhdx用 diskpart 或第三方工具压缩。个人更推荐定期执行 docker system prune 清理无用镜像和容器从源头减少磁盘膨胀。8. 日常高频命令速查与故障自检清单8.1 镜像、容器、卷、网络的常用命令表Docker 的命令很多但日常真正高频的也就二三十条。我把它们整理成了一张速查表贴在服务器终端旁边就能当参考。场景命令拉取镜像docker pull 镜像名:标签查看本地镜像docker images运行容器前台docker run -it --rm 镜像名运行容器后台docker run -d --name 容器名 镜像名查看运行中的容器docker ps查看全部容器docker ps -a查看容器日志docker logs -f 容器名进入容器docker exec -it 容器名 bash停止容器docker stop 容器名删除容器docker rm 容器名删除镜像docker rmi 镜像名构建镜像docker build -t 镜像名 .导出镜像docker save 镜像名 -o 文件名.tar导入镜像docker load -i 文件名.tar查看磁盘占用docker system df清理悬空资源docker system prune -a这里特别提醒一下 docker system prune -a 的用法。它会删除所有未被使用的镜像、容器、网络和构建缓存效果是释放大量磁盘空间但代价是下次要跑某个服务时需要重新拉取或构建镜像。执行前先看清楚输出列表不要盲目加 -f。8.2 端口占用、权限拒绝、daemon 报错的判断顺序部署过程中遇到报错最怕的就是一头扎进日志里乱翻。我的排查顺序是固定的按照可能性从高到低来排。第一类问题是 daemon 相关。报错信息里只要出现 “Cannot connect to the Docker daemon”或者 “failed to connect to the docker api”先确认 Docker 服务是否在运行。Linux 上执行 systemctl status dockerWindows 上看 Docker Desktop 托盘图标。服务没起来后面所有操作都白搭。第二类问题是权限。报错里出现 permission denied大概率是当前用户不在 docker 用户组。前面说过执行 sudo usermod -aG docker $USER 然后重新登录。这个问题我第一次部署时遇到过后来每次在全新机器上装完 Docker都会第一时间把用户组配好。第三类问题是端口占用。启动容器时提示 “port is already allocated” 或 bind: address already in use说明宿主机端口已经被占用。用 ss -lntp 查看端口被哪个进程占用决定是杀掉进程还是换一个映射端口。第四类问题是磁盘空间。容器起不来、镜像拉不下来、日志写不进去都有可能是磁盘满了。df -h 看磁盘使用率docker system df 看 Docker 的资源占用。很多灵异问题其实是磁盘满了导致的。8.3 我的几个清理和备份习惯写到最后分享几个我在实际运维中形成的习惯。第一个习惯是定期清理悬空资源。生产服务器上我每周执行一次 docker system prune -f但不用 -a防止把可能用到的镜像全删了。开发机上一个月执行一次 docker system prune -a彻底清理。第二个习惯是镜像打包备份。每次构建好稳定的生产镜像后我会执行 docker save 把它导出为 tar 文件存到备份盘或对象存储里。这样即使远程仓库出现问题也能用 docker load 在几分钟内恢复本地环境。镜像保存时建议用 gzip 压缩docker save 镜像名:标签 | gzip 镜像名.tar.gz恢复时gunzip -c 镜像名.tar.gz | docker load第三个习惯是卷目录备份。MySQL、Redis 这类有数据卷的服务只备份镜像没用数据卷才是核心资产。最简单的备份方式是直接打包宿主机挂载的目录。我习惯先停掉对应容器再打包避免数据文件在运行中写入导致备份不一致docker compose stop mysql tar czf mysql-backup.tar.gz -C ~/app/mysql data docker compose start mysql这套流程虽然朴素但胜在简单可靠已经帮我处理过好几次误删容器和机器迁移的紧急情况。我个人在实际操作中最深的体会是Docker 的学习曲线其实没那么陡真正容易让人放弃的往往是环境问题和数据安全细节。环境问题按照顺序一步步查数据安全问题上永远不要信任容器默认的无状态配置把卷挂载、备份、健康检查养成肌肉记忆后面部署任何服务都不会心虚。 Docker与Docker Compose部署全攻略：从服务器到Windows实战
在部署这块真正让我省心的工具Docker 算一个Docker Compose 算另一个。这两个名字经常连着出现很多人以为是一套东西其实一个是容器运行时一个是多容器编排工具。这篇文章不是抄官方文档是我从零开始完整部署 Docker、Docker Compose 之后把踩过的坑一块写出来的实操记录覆盖 Linux 服务器和 Windows 桌面端两种场景。要是你正准备在 Ubuntu 上部署 MySQL、Redis、GitLab、RabbitMQ或者被 Docker Desktop 的虚拟化报错卡到怀疑人生这篇文章能帮你把路线一次性理清。1. 先理清概念Docker 与 Docker Compose 到底谁负责哪一块1.1 容器到底解决了什么问题很多人第一次接触 Docker 时最容易把它理解成“一个轻量级虚拟机”。这么说会误导自己因为虚拟机的思路是模拟整台电脑要分配 CPU、内存、硬盘装完整操作系统而 Docker 的思路是直接共享宿主机内核只把应用和它需要的运行时、依赖、配置打成一个个独立的包也就是镜像。镜像是只读模板基于镜像启动的实例叫容器容器之间相互隔离但底层都是同一个 Linux 内核。这种设计带来的直接好处有三点。第一环境一致。以前在开发机运行好好的服务部署到服务器上就报错多半是依赖版本不对、系统库缺失、环境变量没配。用 Docker 后镜像在本地构建好部署到哪台机器都是一模一样的运行环境不会再出现“在我电脑上明明能跑”的尴尬。第二隔离性强。两个项目需要不同版本的 Node.js、Python 或 Java互相不兼容用容器分开跑各装各的依赖互不干扰。第三资源利用率高。容器不装完整操作系统启动通常在秒级同样一台 2 核 4G 的机器用虚拟机可能只能跑两三个实例用容器跑十几个都很轻松。我之前有一个很直观的体验给客户交付一个资产管理工具服务端依赖 Java 17、Redis 7、MySQL 8还带一个定时任务模块。以前交付要给对方发一堆安装文档要求对方提供对应的操作系统环境来回沟通成本很高。后来改用 Docker Compose 打包整套服务客户机器上只要装了 Docker 和 Compose一个命令就能把完整环境拉起来交付瞬间变成“复制文件 执行命令”两件事。这就是容器化在真实项目里带来的最大价值。1.2 Compose 的引入是为了编排不只是省事Docker 单独能跑容器那为什么还需要 Docker Compose原因很简单真实项目很少只有一个容器。你要部署一个 Web 应用可能需要 Nginx 做反向代理、后端服务、MySQL 存数据、Redis 做缓存这就有四个容器了。如果用 docker run 一条条手动启动需要记住每个容器的端口映射、环境变量、数据卷挂载、网络配置还要手动保证启动顺序——数据库先起来缓存先起来然后才是应用。Docker Compose 把这一切变成声明式配置。你只需要写一个 YAML 文件在里面描述要启动哪些服务、每个服务用哪个镜像、映射哪个端口、挂载哪个目录、依赖哪个服务然后运行 docker compose up -dCompose 会按照依赖关系把服务依次拉起来。后续的启停、查看日志、扩容、清理也都通过 compose 命令统一管理。我个人的习惯是只要项目超过一个服务就一定用 Compose 来管绝不手敲 docker run。原因不只是命令少而是 Compose 文件可以放进 Git 仓库整个项目的部署拓扑都有了版本记录。任何人拿到这个文件执行一条命令就能复现一套一模一样的环境。这对团队协作和故障恢复来说价值远超“省事”这两个字。1.3 五个必记的核心词镜像、容器、仓库、卷、网络在开始实战之前先把几个高频术语说清楚后面用命令的时候才不会懵。术语一句话理解类比镜像Image只读模板包含应用代码、依赖、配置做菜的菜谱加半成品食材容器Container镜像运行起来的实例可读可写按照菜谱最终炒出来的一道菜仓库Registry集中存放镜像的地方Docker Hub 是最大的公共仓库菜谱的云端图书馆卷Volume宿主机目录与容器目录的映射容器删了数据还在给容器插一块外接硬盘网络Network容器之间通信的虚拟网络给容器分配虚拟网卡和 IP卷这个点尤其重要。容器本身是无状态的容器一删容器内写进去的文件就全没了。如果你跑 MySQL数据文件必须存放在卷或宿主机挂载目录里否则容器重启数据就丢了。后面实战部分我会专门演示这个配置。2. 动手之前先做环境检查硬件虚拟化、内核与权限2.1 服务器端和桌面端先分清安装思路Docker 的安装路径主要分两类。一类是 Linux 服务器比如 Ubuntu、CentOS安装的是 Docker Engine也就是 Docker 的核心引擎再加几个官方插件另一类是 Windows 和 macOS 桌面环境一般通过 Docker Desktop 这个图形化工具来使用它底层需要借助虚拟化技术创建一个 Linux 子系统来跑容器。从个人经验来看稳定性最高的部署方式是 Linux 服务器 Docker Engine Docker Compose 插件这也是生产环境最主流的组合。Docker Desktop 更适合开发调试尤其是 Windows 上有图形界面需求的时候。所以我的建议是学习和测试随便选哪种都行但真正部署服务优先准备一台 Ubuntu 服务器。2.2 Linux 内核与 overlay 文件系统检查Docker 对 Linux 内核版本有要求通常建议内核 3.10 以上实际生产环境我建议至少用 Ubuntu 20.04 或 22.04 这种长期支持版本。登录服务器后先用两个命令确认基础环境。uname -r这条命令查看内核版本。如果在 5.4 以上基本无忧。然后检查内核是否加载了 overlay 模块Docker 默认的存储驱动叫 overlay2比旧版的 aufs 性能更好、更稳定。lsmod | grep overlay如果没输出可以手动加载sudo modprobe overlay这一步可以放在安装命令之前虽然大部分新版内核默认支持但确认一下能省掉后面不少排查时间。内核检查完毕后顺手把系统包索引更新一下sudo apt update2.3 Windows 的虚拟化支持检测为什么一上来就卡在这网上关于 Docker Desktop 安装失败的求助帖非常多热搜词里那个 “virtualization support not detected docker desktop failed to start because v” 就是典型。这个问题一句话解释就是Docker Desktop 要在 Windows 上跑 Linux 容器必须借助 Hyper-V 或 WSL2 的虚拟化能力而你的电脑虚拟化功能没开或没配好。检查方法很简单按 Ctrl Shift Esc 打开任务管理器切到“性能”选项卡看 CPU 那一栏有没有显示“虚拟化已启用”。如果显示“已禁用”就需要重启电脑进 BIOS/UEFI找到 Intel Virtualization Technology又叫 VT-x或 AMD SVM Mode把它设为 Enabled。如果是公司统一管理的电脑BIOS 里这项可能被锁死那就得联系管理员处理。另外Windows 功能面板里需要启用“适用于 Linux 的 Windows 子系统”、“虚拟机平台”和“Hyper-V”。开启后重启再装 Docker Desktop。这部分我放在后面专门讲 Docker Desktop 的章节这里先说明白大部分安装失败和虚拟化配置有关不是 Docker 本身的问题。3. Ubuntu 上安装 Docker Engine照着敲就能通3.1 用官方 apt 仓库完成安装在 Ubuntu 上安装 Docker Engine 有几种方式最稳妥的是用官方 apt 仓库安装。网上有些一键脚本 curl -fsSL https://get.docker.com | bash -s docker虽然快但我发现脚本安装的版本和仓库源可控性稍差遇到国内网络环境也容易中途失败。生产环境我习惯手动走官方仓库流程稳。先安装必要依赖sudo apt install -y ca-certificates curl gnupg lsb-release然后添加 Docker 官方 GPG 密钥sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg这里在服务器上把官方密钥和仓库地址固化下来以后 apt 更新就能直接获取 Docker 新版本。接着写入软件源echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.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-buildx-plugin docker-compose-plugin注意这行命令里包含了 docker-compose-plugin这是 Docker Compose 的官方插件包装完 Docker 后 compose 命令也能直接用我装完第一件事就是验证这两个工具是否都到位docker --version docker compose version如果能看到类似 Docker version 24.0.7 和 Docker Compose version v2.21.0 的输出说明核心工具都装好了。别急着高兴还有两件事要做配置镜像加速、设置非 root 用户权限。3.2 配置镜像加速器解决拉取缓慢的问题Docker 安装好了第一件事不是着急跑服务而是先确认镜像能不能快速拉下来。Docker Hub 在国内的拉取速度波动很大很多团队初始化阶段就会把加速器配好否则部署一个 GitLab 可能要等上大半天。配置方式是在 /etc/docker/daemon.json 里写 registry-mirrors 参数。先创建或编辑这个文件sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://你的加速器地址] } EOF加速器地址怎么拿常见做法是使用国内云厂商提供的镜像加速服务登录各自容器服务控制台就能看到专属地址注册后拷贝到配置里即可。我的经验是优先选自己用过的服务商地址这样拉取速度比较稳定。改完文件后一定要重启 Docker 才能生效sudo systemctl daemon-reload sudo systemctl restart docker验证加速器是否生效可以运行docker info | grep -A 2 Registry Mirrors能列出你配置的地址就说明生效了。这里有个细节容易漏daemon.json 必须是合法的 JSON 格式少一个逗号或多一个引号Docker 服务都可能起不来。改完文件后如果 systemctl restart docker 卡住或报错先检查这个 JSON 格式对不对。3.3 非 root 用户操作 Docker 的正确姿势Docker 安装完成后默认只有 root 用户和 docker 用户组的成员能执行 docker 命令。如果你直接用普通用户跑 docker ps会看到类似 docker: permission denied while trying to connect to the Docker daemon socket 的报错。解决方式是把当前用户加入 docker 组sudo groupadd docker sudo usermod -aG docker $USER newgrp docker执行完这三条后重新登录终端再试 docker ps。这一步建议所有人在安装后立刻做不然以后每次敲 docker 命令前面都要加 sudo很烦。补充一个安全提醒加入 docker 组意味着这个用户拥有等同于 root 的权限因为 Docker 的容器管理本质上是操作宿主机的系统调用。给用户加 docker 组的时候心里要有数别在小号或共享机器上随手把不了解的用户加进去。3.4 用 hello-world 验证全套链路工具装完、加速器配好、用户组配置完成现在就该做冒烟测试了。运行docker run hello-worldDocker 会先从仓库拉取一个 hello-world 镜像然后启动一个临时容器输出一段欢迎信息。如果你能看到 “Hello from Docker!” 的输出说明镜像拉取、容器创建、执行流程都是通的。这只是最简单的验证。我一般还会再跑两个命令确认更深层的信息docker version docker infodocker version 看客户端和服务端的版本如果客户端能连上服务端说明 socket 通信正常。docker info 则可以看到存储驱动是不是 overlay2、镜像加速器有没有生效、容器总数、镜像总数等这些对后续排障都有用。到这一步Docker Engine 本身已经部署完毕接下来把 Docker Compose 单独拎出来讲清楚。4. 安装 Docker Compose插件方式与独立二进制方式4.1 注意版本差异docker-compose 和 docker compose很多老教程里写的是 docker-compose带一个横线那是 Docker Compose 早期的独立二进制版本命令格式是 docker-compose up。现在 Docker 官方推荐的是插件方式命令格式是 docker compose中间没有横线作为 Docker CLI 的子命令存在。这个变化会带来一个实际影响如果你在网上搜索某篇两年前的博客复制里面的 docker-compose 命令在新环境里可能会提示 command not found因为插件方式下根本没有 docker-compose 这个命令。判断方式很简单跑一下 docker compose version如果能输出版本号说明你已经有了 Compose如果是 docker-compose version那是旧的独立二进制安装方式。4.2 推荐用官方插件安装两行命令搞定我们前面安装 Docker Engine 时已经通过 docker-compose-plugin 这个包把 Compose 插件安装好了。所以如果是从零开始照着上一章的命令装完 Docker直接就有 docker compose 可用。如果你的系统是旧版 Docker或者之前只装了 docker-ce没有装插件可以单独补装sudo apt install -y docker-compose-plugin还有一种历史遗留情况服务器上已经装了独立二进制 docker-compose但版本很老。我建议把旧版本清理掉再装插件避免两个版本共存造成命令混淆。清理方式sudo rm /usr/local/bin/docker-compose然后按前面方式装上插件即可。4.3 验证 compose 配置与常用命令装完插件后除了 docker compose version我最推荐的验证方式是写一个测试用的 compose 文件样例文件写好后运行docker compose config这条命令会解析 YAML 文件并输出标准化的配置结果。如果 YAML 格式有误、缩进不对、字段写错它会直接报错相当于 lint 工具。我习惯每次部署新服务前都先跑一下 docker compose config确认没问题后再真正启动能避免很多低级错误。Compose 日常最常用的命令也就那么几个命令作用docker compose up -d后台启动所有服务docker compose ps查看服务运行状态docker compose logs -f跟踪查看所有服务日志docker compose exec 服务名 命令进入某个容器执行命令docker compose down停止并删除容器网络docker compose down -v停止并删除容器和卷慎用会清数据这些命令在后面实战中都会用到。5. 实战案例用 Docker Compose 拉起 MySQL 8.0 Redis5.1 设计目录结构与 compose.yaml光讲概念不过瘾直接来一个完整的实战案例在一台全新的 Ubuntu 服务器上用 Docker Compose 部署 MySQL 8.0 和 Redis 7同时解决数据持久化、密码配置、健康检查这几个关键问题。先在用户目录下创建一个项目文件夹每个服务单独建子目录数据目录和配置目录分开mkdir -p ~/app/mysql/{data,conf,logs} mkdir -p ~/app/redis/{data,conf} cd ~/app然后创建 compose.yaml 文件。这里我用的是最新版 Compose 的默认文件名早期版本喜欢用 docker-compose.yml两个名字都能识别但新版统一推荐 compose.yaml。在 ~/app 目录下创建 compose.yaml内容先写 MySQL 部分services: mysql: image: mysql:8.0 container_name: mysql8 restart: unless-stopped ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: YourStrongPass TZ: Asia/Shanghai command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci volumes: - ./mysql/data:/var/lib/mysql - ./mysql/conf:/etc/mysql/conf.d - ./mysql/logs:/var/log/mysql healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -pYourStrongPass] interval: 10s timeout: 5s retries: 55.2 MySQL 8.0 的关键配置密码、时区、字符集、持久化这个 compose 配置里有几个点值得展开说说。第一MYSQL_ROOT_PASSWORD 环境变量。MySQL 官方镜像首次启动时会根据这个变量初始化 root 用户的密码。要注意数据卷已经存在的情况下改这个环境变量不会更新密码。所以首次启动前就要把密码定好。我习惯把密码写成强密码至少包含大小写字母、数字和特殊字符。第二command 里指定了 --character-set-serverutf8mb4 和 --collation-serverutf8mb4_unicode_ci。这是为了避免中文乱码。MySQL 默认字符集在有些版本里不是 utf8mb4而 utf8mb4 才是真正完整的 UTF-8能存储 emoji 和生僻字。新项目我基本必配这两项。第三volumes 挂了三个目录。./mysql/data 是数据文件目录这个必须挂出来否则容器重建一次数据就没了./mysql/conf 对应 MySQL 的配置目录未来要改 my.cnf 可以直接放这里./mysql/logs 是日志目录方便排查 SQL 慢查和错误日志。卷挂载路径要与官方镜像里声明的数据目录一致MySQL 8 的数据目录固定是 /var/lib/mysql。启动 MySQL 后验证服务状态docker compose up -d mysql docker compose ps docker exec -it mysql8 mysql -uroot -p输入密码后如果能进入 MySQL 命令行说明部署成功。5.3 Redis 的关键配置持久化、密码与安全建议Redis 相比 MySQL 简单一些但有几个配置新手很容易忽略。先写 compose 配置redis: image: redis:7-alpine container_name: redis7 restart: unless-stopped ports: - 6379:6379 command: [redis-server, /usr/local/etc/redis/redis.conf] volumes: - ./redis/data:/data - ./redis/conf/redis.conf:/usr/local/etc/redis/redis.conf healthcheck: test: [CMD, redis-cli, ping] interval: 10s timeout: 3s retries: 5Redis 官方镜像本身不带配置文件需要自己在宿主机准备 redis.conf 并挂载进容器。在 ~/app/redis/conf/redis.conf 里写入requirepass YourRedisPass appendonly yes appendfsync everysecrequirepass 是访问密码appendonly yes 开启 AOF 持久化appendfsync everysec 表示每秒刷盘一次兼顾性能和数据安全。Redis 相比 MySQL 更容易被忽视安全以前见过不少 Redis 没设密码直接暴露到公网然后被攻击者利用写定时任务入侵宿主机的案例。所以 Redis 只要涉及网络访问必须设密码端口也尽量不要暴露到 0.0.0.0。启动 Redisdocker compose up -d redis docker exec -it redis7 redis-cli -a YourRedisPass ping能返回 PONG说明 Redis 服务正常。5.4 启动、验证与连接数据库MySQL 和 Redis 配置都写好后一条命令启动全部服务docker compose up -d接下来检查状态docker compose ps正常情况下两个服务都应该是 running 状态同时还显示健康状态 healthy。我在前面配置里写了 healthcheckCompose 会定期执行健康检查命令保证服务“端口通了”之外还“真的能响应请求”。到这里MySQL 8.0 Redis 这套最常见的后端基础设施就部署完成了。应用服务连接的时候如果是宿主机上的进程就连接服务器的 IP 加对应端口如果其他容器连接走 Compose 默认网络即可服务名就是主机名。6. 多服务编排进阶GitLab、RabbitMQ 和青龙面板的部署要点6.1 用 Compose 部署 GitLab 的资源评估和端口规划有了基础案例可以试着部署更复杂的服务。GitLab 社区版是很多人用 Docker 部署的第一个重量级应用也是容易踩坑的一个因为它对内存的要求很直接。先看 compose 配置片段gitlab: image: gitlab/gitlab-ce:latest container_name: gitlab restart: unless-stopped hostname: gitlab.example.com ports: - 80:80 - 443:443 - 22:22 volumes: - ./gitlab/config:/etc/gitlab - ./gitlab/logs:/var/log/gitlab - ./gitlab/data:/var/opt/gitlab shm_size: 256mGitLab 官方推荐至少 4GB 内存跑社区版我的实测是 2GB 内存的机器也能启动但跑一段时间后会变得非常卡甚至 OOM。所以部署 GitLab 前一定要给服务器留足内存。第二个坑是 external_url 配置不在 compose 里而在 /etc/gitlab/gitlab.rb 里。启动后编辑 config 目录下的 gitlab.rb设置 external_url http://你的服务器IP然后执行 gitlab-ctl reconfigure。注意 reconfigure 过程比较耗时容器内执行命令可以用docker exec -it gitlab gitlab-ctl reconfigure第三个坑是端口冲突。22 端口如果宿主机正在跑 SSHGitLab 的 SSH 映射会冲突。解决办法是改成其他端口比如 2222:22但这样 git clone 时就要带上非标准端口对团队使用不友好。建议部署前先检查端口占用情况或者干脆把宿主机 SSH 移到其他端口保持 GitLab 用 22 端口。6.2 短时间内拉起 RabbitMQ 并开启管理面板RabbitMQ 是一个常用的消息队列Docker 部署的优势是省去了 Erlang 环境配置的麻烦。官方提供了带管理插件的镜像一条配置就能同时启动消息服务和管理界面。rabbitmq: image: rabbitmq:3-management-alpine container_name: rabbitmq restart: unless-stopped ports: - 5672:5672 - 15672:15672 environment: RABBITMQ_DEFAULT_USER: admin RABBITMQ_DEFAULT_PASS: YourRabbitPass healthcheck: test: [CMD, rabbitmq-diagnostics, check_running] interval: 10s timeout: 5s retries: 55672 是 AMQP 协议端口业务代码连接消息队列用这个15672 是管理面板的 Web 端口浏览器访问 http://服务器IP:15672 就能看到图形化界面用环境变量里配置的账号密码登录。RabbitMQ 默认的 guest 用户只允许 localhost 访问所以用环境变量创建自定义用户是必须的一步。6.3 青龙面板的依赖管理与目录挂载经验青龙面板是一个定时任务管理工具可以统一调度 Python、JavaScript、Shell 脚本很多自建自动化项目会用到它。部署本身不复杂compose 配置大概长这样qinglong: image: whyour/qinglong:latest container_name: qinglong restart: unless-stopped ports: - 5700:5700 volumes: - ./qinglong/data:/ql/data environment: QL_PORT: 5700青龙面板主要的坑在于依赖管理。面板里跑脚本依赖 Node.js 或 Python 的某些包如果容器里没装脚本启动就会报 ModuleNotFoundError。实际操作中有两种方式一种是在面板的“依赖管理”页面里直接安装比如填入 requests、axios 这类包名另一种是进入容器用 npm 或 pip 装docker exec -it qinglong bash npm install -g axios pip install requests我的体会是面板里的依赖管理页面虽然方便但涉及的包多了以后容器重建后所有依赖都要重装一遍。所以最好的习惯是把常用依赖整理成清单容器重建后第一件事不是急着配脚本而是先把依赖列表跑一遍。6.4 生产环境进阶设置日志限制、健康检查、重启策略多服务编排到后期有个很容易忽视的问题容器日志会无限增大。默认配置下一个打印频繁的容器跑一两个月日志文件可以轻松占满几十 GB 磁盘。解决方法是在 compose.yaml 里给服务配置 logging 参数logging: driver: json-file options: max-size: 10m max-file: 3这样每个容器日志文件单个最大 10MB保留 3 份超过上限自动轮转。生产环境我基本每个服务都会加这个配置防止日志把磁盘写满。重启策略也是生产环境必须考虑的。restart: unless-stopped 是最常用的配置它表示容器异常退出时自动重启但你自己手动 stop 掉的不会强制拉起来。对于数据库这类需要高可用的服务建议再加上 healthcheck让 Compose 能感知服务是否真的健康而不是只靠“进程还活着”来判断。7. Windows Docker Desktop 启动故障排查7.1 virtualization support not detected 的出现场景与处理Docker Desktop 虽然解决了很多人在 Windows 上用 Docker 的痛点但安装过程中的报错也是千奇百怪。最典型的一个就是启动时提示 “virtualization support not detected” 或 “Docker Desktop failed to start because virtualization support wasnt detected”。这个报错的核心原因只有一个Windows 的虚拟化能力没有被 Docker Desktop 检测到。但具体是哪个环节出了问题需要一步步排查。第一步确认 CPU 虚拟化。打开任务管理器性能选项卡查看 CPU 右下角有没有“虚拟化已启用”。如果显示已禁用需要进入 BIOS/UEFI 打开 VT-xIntel或 SVM ModeAMD。不同主板的 BIOS 菜单位置不一样一般在 Advanced 或 Processor 设置里。第二步确认 Windows 功能。按 Win R输入 optionalfeatures 回车在“启用或关闭 Windows 功能”里勾选“Hyper-V”、“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。注意Hyper-V 和 WSL2 其实是两条不同的路线Docker Desktop 默认推荐 WSL2但 WSL2 也需要开启“虚拟机平台”作为底层支持。勾选完成后重启电脑。第三步确认内核隔离没把虚拟化性能拖垮。Windows 安全中心里有个“内核隔离 - 内存完整性”在某些配置下会和 Docker 的虚拟化后端产生冲突导致 Docker Desktop 启动失败或运行极慢。如果开启了可以尝试关闭后再启动 Docker Desktop。还有一条命令行方式可以强制启用 hypervisor 启动类型以管理员身份打开 PowerShell 执行bcdedit /set hypervisorlaunchtype auto然后重启。这个方法对部分开启虚拟化后仍检测不到的场景有效。7.2 failed to connect to the docker api 的排查路径另一个高频报错是 “failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine”。第一次看到这个报错时容易懵npipe 是 Windows 的命名管道看起来像网络地址其实是 Docker Desktop 客户端与后端引擎通信的通道。这个报错的本质是 Docker Desktop 的 Linux 引擎没有正常启动所以客户端连不上。排查顺序我总结为三步。第一步看 Docker Desktop 的托盘图标。如果图标还在转或显示 Docker is starting说明引擎还在初始化等一两分钟再看。如果一直卡在启动中多半是前面的虚拟化配置有问题。第二步在 PowerShell 里执行 docker version 看客户端和服务端版本信息。如果只有 Client 输出没有 Server 部分输出说明客户端和服务端没有建立连接重点检查 Docker Desktop 的引擎是否真的起来了。第三步如果使用的是 WSL2 后端到 WSL 里手动确认 Linux 子系统状态。打开终端执行wsl --status wsl --updateWSL 内核版本太旧也会导致 Docker Desktop 引擎无法启动。更新 WSL 后重启 Docker Desktop大多数情况下能解决。最后还有一个万能重置方法在管理员 PowerShell 里执行 netsh winsock reset然后重启电脑。这个操作会重置 Windows 网络协议栈有时能解决命名管道连接不上的诡异问题。注意执行后务必重启否则不生效。7.3 WSL2 后端与 Hyper-V 两种选择Docker Desktop 在 Windows 上有两种后端老版本用 Hyper-V新版本默认用 WSL2。WSL2 的优势是启动更快、内存占用更可控而且与 Windows 文件系统之间的交互更自然。如果你的电脑能满足 WSL2 的条件我建议优先用 WSL2 后端。使用 WSL2 时有一个隐藏问题WSL 的虚拟磁盘文件会不断膨胀。WSL2 的默认 install 路径下有一个 ext4.vhdx 文件这个文件只增不减即使你在容器里删了大量文件磁盘文件也不会自动缩小。解决方法是手动压缩执行wsl --shutdown然后在资源管理器地址栏输入%LOCALAPPDATA%\Docker\wsl\data\找到 ext4.vhdx用 diskpart 或第三方工具压缩。个人更推荐定期执行 docker system prune 清理无用镜像和容器从源头减少磁盘膨胀。8. 日常高频命令速查与故障自检清单8.1 镜像、容器、卷、网络的常用命令表Docker 的命令很多但日常真正高频的也就二三十条。我把它们整理成了一张速查表贴在服务器终端旁边就能当参考。场景命令拉取镜像docker pull 镜像名:标签查看本地镜像docker images运行容器前台docker run -it --rm 镜像名运行容器后台docker run -d --name 容器名 镜像名查看运行中的容器docker ps查看全部容器docker ps -a查看容器日志docker logs -f 容器名进入容器docker exec -it 容器名 bash停止容器docker stop 容器名删除容器docker rm 容器名删除镜像docker rmi 镜像名构建镜像docker build -t 镜像名 .导出镜像docker save 镜像名 -o 文件名.tar导入镜像docker load -i 文件名.tar查看磁盘占用docker system df清理悬空资源docker system prune -a这里特别提醒一下 docker system prune -a 的用法。它会删除所有未被使用的镜像、容器、网络和构建缓存效果是释放大量磁盘空间但代价是下次要跑某个服务时需要重新拉取或构建镜像。执行前先看清楚输出列表不要盲目加 -f。8.2 端口占用、权限拒绝、daemon 报错的判断顺序部署过程中遇到报错最怕的就是一头扎进日志里乱翻。我的排查顺序是固定的按照可能性从高到低来排。第一类问题是 daemon 相关。报错信息里只要出现 “Cannot connect to the Docker daemon”或者 “failed to connect to the docker api”先确认 Docker 服务是否在运行。Linux 上执行 systemctl status dockerWindows 上看 Docker Desktop 托盘图标。服务没起来后面所有操作都白搭。第二类问题是权限。报错里出现 permission denied大概率是当前用户不在 docker 用户组。前面说过执行 sudo usermod -aG docker $USER 然后重新登录。这个问题我第一次部署时遇到过后来每次在全新机器上装完 Docker都会第一时间把用户组配好。第三类问题是端口占用。启动容器时提示 “port is already allocated” 或 bind: address already in use说明宿主机端口已经被占用。用 ss -lntp 查看端口被哪个进程占用决定是杀掉进程还是换一个映射端口。第四类问题是磁盘空间。容器起不来、镜像拉不下来、日志写不进去都有可能是磁盘满了。df -h 看磁盘使用率docker system df 看 Docker 的资源占用。很多灵异问题其实是磁盘满了导致的。8.3 我的几个清理和备份习惯写到最后分享几个我在实际运维中形成的习惯。第一个习惯是定期清理悬空资源。生产服务器上我每周执行一次 docker system prune -f但不用 -a防止把可能用到的镜像全删了。开发机上一个月执行一次 docker system prune -a彻底清理。第二个习惯是镜像打包备份。每次构建好稳定的生产镜像后我会执行 docker save 把它导出为 tar 文件存到备份盘或对象存储里。这样即使远程仓库出现问题也能用 docker load 在几分钟内恢复本地环境。镜像保存时建议用 gzip 压缩docker save 镜像名:标签 | gzip 镜像名.tar.gz恢复时gunzip -c 镜像名.tar.gz | docker load第三个习惯是卷目录备份。MySQL、Redis 这类有数据卷的服务只备份镜像没用数据卷才是核心资产。最简单的备份方式是直接打包宿主机挂载的目录。我习惯先停掉对应容器再打包避免数据文件在运行中写入导致备份不一致docker compose stop mysql tar czf mysql-backup.tar.gz -C ~/app/mysql data docker compose start mysql这套流程虽然朴素但胜在简单可靠已经帮我处理过好几次误删容器和机器迁移的紧急情况。我个人在实际操作中最深的体会是Docker 的学习曲线其实没那么陡真正容易让人放弃的往往是环境问题和数据安全细节。环境问题按照顺序一步步查数据安全问题上永远不要信任容器默认的无状态配置把卷挂载、备份、健康检查养成肌肉记忆后面部署任何服务都不会心虚。