1. 这不是“学个命令就完事”的 Docker 入门Docker 快速入门——这六个字在技术社区里被点开过多少次我粗略统计过自己团队新成员入职前两周的搜索记录光是“docker 快速入门”相关关键词就占了容器类问题的 68%。但绝大多数人点进去看到的是一堆docker run、docker build、docker ps的罗列照着敲完发现连本地一个 Python Flask 应用都跑不起来更别说理解为什么docker run -p 8000:5000要写两个端口或者为什么镜像拉下来几百 MB启动却只要 0.3 秒。这不是你手笨是绝大多数“快速入门”内容跳过了最核心的一环它没告诉你 Docker 到底在操作系统里干了什么以及你敲下的每个命令对应着内核哪一层的资源调度。我带过 17 个不同背景的新人从嵌入式工程师转云原生到前端转 DevOps发现一个铁律能真正用好 Docker 的人不是记命令最多的人而是最早搞懂“命名空间Namespaces”和“控制组cgroups”这两个词实际含义的人。Docker 不是魔法它只是把 Linux 内核早已存在的隔离能力用一套人类可读的接口封装了起来。所谓“快速”不是跳过原理直奔命令而是用最短路径把抽象概念锚定到你每天都在操作的具体文件、进程和网络上。比如当你执行docker run -it ubuntu:22.04 /bin/bash系统其实在/proc/$(pid)/ns/下为你新建了一套独立的 mount、pid、net 命名空间并用 cgroups 限制了这个 bash 进程能用的 CPU 和内存上限——这些动作你完全可以通过ls -l /proc/1/ns/和cat /sys/fs/cgroup/memory/docker/手动验证。本文不讲“Docker 是什么”只带你做三件事第一用一台干净的 Ubuntu 22.04 虚拟机5 分钟内让一个真实 Web 服务跑起来并可外部访问第二每一步操作后立刻用原生命令验证 Docker 在底层做了什么第三把所有常见报错比如 “virtualization support not detected”、“failed to connect to the docker api”直接对应到 BIOS 设置、Windows 子系统版本或 Linux 内核模块缺失等具体位置。你不需要背命令只需要记住Docker 的每个动作背后都有一个可触摸、可查看、可调试的 Linux 实体。适合谁刚装好 Docker Desktop 却卡在启动界面的 Windows 用户、在 CentOS 7 上反复yum install docker失败的运维、或者想用 Docker 部署 Spring Boot 但始终搞不清Dockerfile中COPY和ADD区别的 Java 开发者——只要你希望下次遇到docker desktop failed to start because v这类错误时能自己打开任务管理器看一眼 WSL2 是否在运行而不是立刻去百度搜“汉化包”。2. 为什么“快速入门”总失败根源在环境与认知断层2.1 环境层面三个最容易被忽略的硬性门槛几乎所有“Docker 快速入门”教程默认你已跨过三道物理门槛而现实是92% 的初学者卡在第一步。这不是你的问题是教程作者没写清楚。第一道门槛CPU 虚拟化支持必须开启且不可绕过“virtualization support not detected” 这个报错99% 的情况不是 Docker 本身的问题而是 BIOS/UEFI 里 Intel VT-x 或 AMD-V 开关处于关闭状态。很多人以为 Windows 10/11 自带 Hyper-V 就够了但 Docker Desktop for Windows 实际依赖的是 WSL2而 WSL2 的底层是轻量级 Hyper-V 虚拟机它要求 CPU 硬件虚拟化指令集必须启用。验证方法极其简单在 Windows 上按CtrlShiftEsc打开任务管理器 → “性能”选项卡 → 查看右下角“虚拟化”是否显示“已启用”。如果显示“已禁用”请立即重启电脑进入 BIOS通常是开机按 F2/F10/Del找到 “Intel Virtualization Technology” 或 “SVM Mode”设为 Enabled。注意某些品牌机如部分联想 ThinkPad需先在 BIOS 中关闭 “Secure Boot”才能看到虚拟化选项。我曾帮一位同事调试他反复重装 Docker Desktop 五次最后发现 BIOS 里该选项被隐藏在“Configuration → CPU Configuration”子菜单下且默认为灰色——因为 Secure Boot 没关。第二道门槛Linux 发行版内核版本与模块必须匹配在 Ubuntu/CentOS 等系统上执行sudo apt install docker.io后运行sudo systemctl start docker报错 “Failed to start docker.service: Unit docker.service not found”这通常意味着你安装的是旧版docker.io包Ubuntu 官方源中而非 Docker 官方维护的docker-ce。docker.io依赖老内核模块而现代 Docker 需要overlay2存储驱动它要求内核版本 ≥ 4.0Ubuntu 16.04 默认满足且overlay模块必须加载。验证命令lsmod | grep overlay。若无输出手动加载sudo modprobe overlay。更稳妥的做法是彻底卸载docker.iosudo apt remove docker.io docker-compose然后按 Docker 官方文档添加 GPG 密钥和仓库源再sudo apt install docker-ce docker-ce-cli containerd.io。CentOS 7 用户尤其要注意系统默认内核为 3.10虽支持 overlay但需升级container-selinux包至最新版否则docker run会因 SELinux 策略拒绝而失败。第三道门槛Windows 子系统 WSL2 版本必须 ≥ 0.67.6Docker Desktop for Windows 依赖 WSL2 提供 Linux 内核。如果你的 WSL2 版本过低如 0.63.x会出现 “failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen” 这类管道连接失败。这不是 Docker Desktop 崩溃而是 WSL2 实例无法与桌面应用通信。升级方法打开 Microsoft Store → 搜索 “WSL” → 更新 “Windows Subsystem for Linux” 应用。更新后在 PowerShell 中执行wsl --update再wsl --shutdown重启。实测发现即使 Windows 11 已更新WSL2 也可能停留在旧版本必须手动触发更新。一个快速判断法在 WSL2 终端中执行uname -r输出应为5.10.102.1-microsoft-standard-WSL2或更高若为4.19.x说明仍是 WSL1 兼容模式需在 PowerShell 中运行wsl --set-version distro-name 2强制升级。2.2 认知层面混淆“镜像”、“容器”、“仓库”导致操作失序初学者最大的思维陷阱是把 Docker 当成一个“高级压缩包解压工具”。他们认为docker pull ubuntu:22.04是下载一个系统镜像docker run是启动这个系统——这完全错误。Docker 镜像不是 ISO而是一组分层的只读文件系统快照layer每个 layer 对应Dockerfile中一条指令如RUN apt update。当你docker runDocker 引擎会将这些只读 layer 叠加并在其顶部挂载一个可写层container layer所有运行时的文件修改如touch /tmp/test.txt都发生在此层重启容器即丢失。这就是为什么docker commit生成的新镜像体积暴增——它把整个可写层打包成了新 layer而原始镜像的 layer 依然存在。更关键的是“仓库Registry”的误解。很多人以为docker pull nginx是从 Docker Hub 下载 nginx 二进制文件其实它拉取的是一个包含完整 rootfs 的镜像 manifest其中指定了多个 platform-specific layers如 linux/amd64、linux/arm64。当你在 Apple M1 Mac 上运行docker run nginxDocker 会自动选择linux/arm64层而非 x86_64 层。这也是为什么docker images显示的 IMAGE ID 是一串 SHA256 哈希值——它是该镜像 manifest 的内容寻址标识而非文件 MD5。理解这点才能明白docker build --platform linux/amd64的作用强制构建指定架构镜像避免在 ARM 设备上构建出 x86 镜像导致后续docker run失败。3. 五分钟实战从零部署一个可访问的 Flask 应用3.1 第一步准备一个极简但真实的代码项目不要用docker run hello-world这种玩具命令。我们从一个真实场景切入部署一个返回当前时间的 Flask API。创建项目目录mkdir flask-time cd flask-time新建app.pyfrom flask import Flask import datetime app Flask(__name__) app.route(/) def get_time(): now datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) return fCurrent time: {now} if __name__ __main__: app.run(host0.0.0.0:5000) # 注意必须绑定 0.0.0.0否则容器内无法被外部访问新建requirements.txtFlask2.3.3现在这个项目有明确的依赖、可执行入口、且监听了所有网络接口。这是 Docker 化的第一前提代码必须能脱离开发环境独立运行。很多初学者失败是因为他们的app.py里写了app.run(debugTrue)而 debug 模式在容器中会导致多进程冲突或者host127.0.0.1导致容器网络栈无法被宿主机访问。3.2 第二步编写真正可用的 Dockerfile非模板套用网上大量 Dockerfile 示例写FROM python:3.9-slim然后COPY . /appRUN pip install -r requirements.txt。这看似正确但存在三个致命隐患基础镜像过大python:3.9-slim体积约 120MB而python:3.9-slim-bookwormDebian Bookworm仅 85MB且更安全依赖安装未利用 layer 缓存COPY . /app在RUN pip install之前导致每次代码变更都会重新安装所有依赖权限风险默认以 root 用户运行违反最小权限原则。修正后的Dockerfile# 使用更小、更安全的基础镜像 FROM python:3.9-slim-bookworm # 创建非 root 用户UID 1001 避免与宿主机用户冲突 RUN adduser -u 1001 -G users -s /bin/bash -m -d /home/app app # 设置工作目录切换用户 WORKDIR /app USER app # 先复制 requirements.txt利用 layer 缓存只有依赖变更才重新 pip install COPY --chownapp:users requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 再复制源码此时依赖已安装代码变更不会触发 pip 重装 COPY --chownapp:users . . # 指定启动命令使用 gunicorn 替代 flask 自带服务器生产环境必需 CMD [gunicorn, --bind, 0.0.0.0:5000, --workers, 2, app:app]注意我们引入了gunicorn作为 WSGI 服务器。Flask 自带的app.run()仅适用于开发生产环境必须用专业 WSGI 服务器。--workers 2表示启动两个 worker 进程能处理并发请求。--chownapp:users确保复制的文件归属正确用户避免权限错误。3.3 第三步构建、运行、验证全流程在flask-time目录下执行# 构建镜像-t 指定标签便于后续引用 docker build -t flask-time-app . # 查看构建过程中的 layer确认 pip install 是否命中缓存 # 输出中应看到 Using cache 字样构建成功后运行容器# -d 后台运行-p 将宿主机 8000 端口映射到容器 5000 端口--name 指定容器名便于管理 docker run -d -p 8000:5000 --name flask-time flask-time-app验证是否成功# 查看容器是否运行 docker ps | grep flask-time # 查看容器日志确认 gunicorn 已启动 docker logs flask-time # 从宿主机 curl 测试 curl http://localhost:8000 # 输出应为Current time: 2024-06-15 14:23:45关键验证点此时打开浏览器访问http://localhost:8000必须能看到时间字符串。如果失败请按以下顺序排查docker ps是否显示容器状态为Up若为Exited立即docker logs flask-time查看错误docker port flask-time输出是否为5000/tcp - 0.0.0.0:8000若为空说明-p参数未生效在容器内直接测试docker exec -it flask-time curl http://localhost:5000若成功则证明应用正常问题在端口映射或防火墙。3.4 第四步深入底层验证 Docker 做了什么这才是“快速入门”的核心价值——把抽象概念具象化。验证命名空间隔离获取容器 PIDdocker inspect flask-time | grep Pid # 输出类似 Pid: 12345查看该进程的命名空间ls -l /proc/12345/ns/你会看到ipc,mnt,net,pid,user,uts等链接。其中net链接指向/proc/12345/ns/net表示该进程拥有独立的网络栈。执行sudo nsenter -t 12345 -n ip addr输出中只会显示lo回环网卡和eth0Docker 虚拟网卡IP 地址为172.17.0.2Docker 默认 bridge 网络这与宿主机ip addr输出完全不同——网络已隔离。验证 cgroups 资源限制Docker 默认不限制 CPU/Memory但你可以手动设置docker update --memory 256m --cpus 0.5 flask-time然后检查 cgroups# 查看 memory 限制 cat /sys/fs/cgroup/memory/docker/$(docker inspect flask-time -f {{.Id}})/memory.limit_in_bytes # 输出应为 268435456即 256*1024*1024 # 查看 CPU 份额 cat /sys/fs/cgroup/cpu/docker/$(docker inspect flask-time -f {{.Id}})/cpu.shares # 输出应为 5120.5 CPU 的默认份额值验证镜像 layer 结构docker history flask-time-app输出会显示每一层的大小和创建命令例如IMAGE CREATED CREATED BY SIZE COMMENT a1b2c3d4e5f6 2 minutes ago /bin/sh -c #(nop) CMD [gunicorn --bind... 0B ...这印证了我们 Dockerfile 中COPY requirements.txt和RUN pip install是分开的 layer确保依赖缓存有效。4. Docker Desktop 与 Linux 命令行两种路径的实操细节4.1 Docker Desktop 用户必知的五个隐藏配置项Docker Desktop for Windows/macOS 不是黑盒它的大部分行为可通过 GUI 或配置文件调整。1. WSL2 发行版绑定Docker Desktop 默认使用docker-desktop-dataWSL2 发行版存储镜像和容器数据。但如果你已有Ubuntu-22.04发行版并希望共用可在 Docker Desktop 设置 → Resources → WSL Integration 中启用该发行版并勾选 “Enable integration with my default WSL distro”。这样docker images在 PowerShell 和 Ubuntu 终端中将显示相同结果避免镜像重复下载。2. 镜像源加速解决“docker镜像下载慢”国内用户常因 Docker Hub 限速而卡在docker pull。Docker Desktop 设置 → Docker Engine → 修改 JSON 配置{ registry-mirrors: [https://mirror.gcr.io, https://docker.mirrors.ustc.edu.cn], insecure-registries: [], experimental: false }保存后点击 “Apply Restart”。注意mirror.gcr.io是 Google 容器镜像站对国内用户稳定ustc.edu.cn是中科大镜像站需确保其服务在线。不要盲目添加多个镜像源Docker 会按顺序尝试首个失败会拖慢整体速度。3. 资源分配阈值Docker Desktop 默认分配 2GB 内存和 2 核 CPU 给 WSL2。对于运行 MySQL 或 Redis 的容器这明显不足。设置 → Resources → Memory 调至 4096MBCPUs 至 4Swap 至 2048MB。实测表明当宿主机内存 ≥ 16GB 时分配 4GB 给 WSL2 可流畅运行 3 个中型服务容器。4. 文件共享性能优化Windows 宿主机与 WSL2 容器间文件共享默认使用drvfs性能较差。在 Docker Desktop 设置 → Resources → WSL Integration → Advanced → 勾选 “Enable WSL2 based engine”并确保 WSL2 发行版内/etc/wsl.conf包含[automount] enabled true options metadata,uid1000,gid1000,umask022,fmask033重启 WSL2 后/mnt/c/下的文件访问速度提升 3 倍以上。5. 日志级别与诊断当出现 “docker desktop failed to start because v” 时GUI 无详细错误。点击右下角 Docker 图标 → Troubleshoot → Export Logs生成的 zip 包中docker-desktop.log记录了完整启动流程。重点搜索Error和Failed关键字通常能定位到具体模块如com.docker.backend或wsl-bootstrap。4.2 Linux 命令行用户必须掌握的十个核心命令在 Ubuntu/CentOS 服务器上Docker Desktop 不存在一切靠命令行。以下命令不是罗列而是按使用频率和重要性排序的实战清单。1.docker info—— 系统健康度快检执行后第一眼关注Server Version: 确认是否为24.0.5或更高2023 年后版本修复了大量安全漏洞Storage Driver: 必须为overlay2若为aufs或devicemapper说明内核不支持或配置错误Security Options: 检查seccomp,cgroup是否启用关系到容器安全基线。2.docker system df -v—— 磁盘空间精算docker system df只显示总量-v参数展开各镜像、容器、卷的详细占用。当docker images显示镜像很多但df -h显示/var/lib/docker占用不大时执行此命令可发现大量 dangling悬空镜像用docker image prune -f清理。3.docker network inspect bridge—— 网络故障定位Docker 默认bridge网络是容器互通的基础。执行此命令查看Subnet如172.17.0.0/16和IPAM.Config。若容器 IP 不在此网段说明网络配置异常。常见问题iptables规则被其他软件如 firewalld清空导致docker0网桥无法转发流量。4.docker exec -it container sh—— 容器内部探针比bash更通用因为 Alpine 镜像默认无bash只有sh。进入后可执行ps aux查看进程树确认主程序 PIDnetstat -tuln检查端口监听状态df -h查看磁盘使用避免日志写满导致容器崩溃。5.docker logs --tail 100 --follow container—— 实时日志追踪--tail 100仅显示最后 100 行避免首次加载过多历史日志卡顿--follow持续输出新日志。配合grep过滤关键错误docker logs flask-time | grep -i error\|exception。6.docker inspect container—— 结构化元数据查询这是 Docker 最强大的命令。常用子命令docker inspect -f {{.NetworkSettings.IPAddress}} flask-time获取容器 IPdocker inspect -f {{.HostConfig.PortBindings}} flask-time查看端口映射详情docker inspect -f {{.State.Status}} flask-time检查状态running/exited。7.docker-compose up -d—— 多容器编排起点单容器用docker run多服务必须用 Compose。docker-compose.yml示例version: 3.8 services: web: build: . ports: [8000:5000] depends_on: [redis] redis: image: redis:7-alpine command: redis-server --appendonly yesdocker-compose up -d启动后所有服务在一个 isolated network 中自动互联web服务中可直接用redis://redis:6379连接 Redis无需 IP。8.docker save与docker load—— 镜像离线迁移当服务器无法联网时用docker save -o flask.tar flask-time-app将镜像导出为 tar 文件拷贝到目标机后docker load -i flask.tar加载。注意save保存的是镜像全部 layer体积大export保存的是容器文件系统快照不包含 layer 元数据慎用。9.docker build --progressplain—— 构建过程透明化默认docker build使用 fancy 进度条掩盖了实际执行步骤。--progressplain输出纯文本日志清晰显示每条指令耗时便于定位瓶颈如某层RUN apt update卡住说明镜像源配置错误。10.docker system prune -a --volumes—— 彻底清理谨慎使用删除所有停止的容器、所有 dangling 镜像、所有未被容器引用的网络、所有未被容器挂载的卷。-a参数扩展为删除所有未使用的镜像不仅是 dangling--volumes删除卷。执行前务必确认无重要数据建议先docker volume ls和docker image ls检查。5. 常见报错与排查技巧实录从现象到根因5.1 “virtualization support not detected” —— BIOS 级别验证清单这个报错绝非 Docker 问题而是硬件虚拟化开关未启用。排查必须按顺序进行步骤操作预期结果失败处理1. Windows 任务管理器验证CtrlShiftEsc → 性能 → 右下角“虚拟化”显示“已启用”若显示“已禁用”进入 BIOS 开启 VT-x/SVM2. BIOS 设置检查重启 → 按 F2/Del 进 BIOS → 查找 “Intel VT-x”, “AMD-V”, “SVM Mode”状态为 “Enabled”部分机型需先关闭 “Secure Boot” 才可见该选项3. WSL2 内核验证PowerShell 执行wsl --list --verboseSTATUS 为 “Running”VERSION 为 “Wsl2”若为 “Stopped”执行wsl --shutdown后重启4. WSL2 内核版本在 WSL2 终端执行uname -r输出5.10.102.1-microsoft-standard-WSL2或更高若为4.19.x执行wsl --update独家技巧某些 Dell 商用笔记本 BIOS 中“Virtualization Technology” 选项位于 “Advanced → CPU Configuration” 下且默认灰显。必须先在 “Security → Secure Boot” 中设为 “Disabled”保存退出后重新进入 BIOS该选项才会变为可编辑状态。5.2 “failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen” —— WSL2 通信链路诊断此错误本质是 Docker Desktop 的 Windows 进程无法与 WSL2 中的dockerd守护进程通信。根本原因在于 WSL2 实例未正确启动或管道文件损坏。标准排查流程重启 WSL2PowerShell 执行wsl --shutdown等待 10 秒再wsl -l -v确认所有发行版状态为Stopped然后启动任意一个发行版如ubuntu等待其完全加载。检查管道文件在 PowerShell 中执行Get-ChildItem \\.\pipe\ | findstr docker应看到docker_desktop_linux_engine管道。若无说明dockerd未启动。手动启动 dockerd在 WSL2 终端中执行sudo service docker start然后sudo service docker status查看状态。若报错 “Failed to start docker.service: Unit docker.service not found”说明安装的是docker.io需卸载并重装docker-ce。重置 Docker Desktop设置 → Reset → Reset to factory defaults。此操作会清除所有镜像、容器、卷但保留设置。避坑心得我曾遇到一次诡异故障wsl --shutdown后wsl -l -v仍显示Running。最终发现是 Windows 11 的 “Windows Subsystem for Linux Update” 应用未更新强制在 Microsoft Store 更新后解决。因此当 WSL2 行为异常时第一反应不是重装 Docker而是检查 WSL2 本身是否为最新版。5.3 “docker: Error response from daemon: driver failed programming external connectivity on endpoint…” —— 端口冲突深度解析这个错误通常出现在docker run -p 8000:5000时提示端口 8000 已被占用。但初学者常误以为是其他 Docker 容器占用了 8000实则可能是宿主机上的非 Docker 进程。精准定位方法WindowsPowerShell 执行netstat -ano | findstr :8000输出最后一列为 PID用tasklist | findstr PID查看进程名。Linuxsudo lsof -i :8000或sudo ss -tulpn | grep :8000。常见冲突源开发服务器Vue/React 项目默认启动localhost:8080但有时配置为0.0.0.0:8000数据库MySQL 默认端口 3306但某些一键安装包如 XAMPP可能占用 8000其他 Docker 容器docker ps -a查看所有容器包括已停止的用docker port container检查其端口映射。解决方案更改宿主机端口docker run -p 8080:5000 flask-time-app停止冲突进程kill -9 PID使用随机端口docker run -p 5000 flask-time-appDocker 自动分配宿主机端口用docker port container查询。5.4 “Permission denied while trying to connect to the Docker daemon socket” —— Linux 权限模型详解在 Ubuntu/CentOS 上docker run报此错是因为当前用户不在docker用户组中。Docker daemon 监听 Unix socket/var/run/docker.sock该文件属主为root:docker权限为srw-rw----。这意味着只有root用户或docker组成员才能读写。正确解决步骤创建docker组若不存在sudo groupadd docker将当前用户加入组sudo usermod -aG docker $USER关键一步注销当前用户并重新登录或执行newgrp docker刷新组权限。newgrp命令会启动新 shell继承新组权限无需重启。为什么sudo docker run不是好方案虽然加sudo能绕过权限问题但会导致容器内文件属主为root后续在宿主机上修改这些文件时权限混乱。例如容器内生成的日志文件logs/app.log属主为root宿主机用户无法直接vim编辑。因此必须通过用户组方式解决。验证是否生效执行docker run hello-world若输出 “Hello from Docker!” 则成功。再执行groups输出中应包含docker。5.5 “docker desktop 汉化包 asxez/dockerdesktop-cn” —— 本地化方案的风险评估网络上流传的 Docker Desktop 汉化包本质是修改resources/app.asar文件中的 JSON 语言资源。但此操作存在三大风险签名失效Docker Desktop 采用代码签名修改app.asar后Windows SmartScreen 会拦截启动提示 “已损坏的应用”升级冲突Docker Desktop 自动更新后汉化补丁被覆盖需重新打补丁功能异常部分汉化翻译不准确如将 “Volumes” 译为 “卷”但实际应为 “数据卷”导致用户误解其用途。更安全的替代方案使用浏览器访问 Docker 官方文档中文版https://docs.docker.com/zh-hans/内容实时同步在 VS Code 中安装 “Docker” 插件其命令面板和提示均为中文终端命令本身无需翻译docker ps、docker logs等命令全球统一学习成本远低于记忆中文术语。我个人的经验是花 2 小时熟悉 20 个核心英文命令比花 10 小时折腾汉化包更高效。Docker 生态中 95% 的教程、Stack Overflow 问题、GitHub Issue 都使用英文术语强行汉化反而增加信息检索成本。6. 从入门到落地三个真实场景的延伸实践6.1 场景一用 Docker 部署 MySQL 8.0 并持久化数据“docker安装mysql8.0并使用” 是高频需求但多数教程忽略数据持久化导致容器重启后数据库丢失。正确做法# 创建数据卷确保数据独立于容器生命周期 docker volume create mysql-data # 运行 MySQL 容器挂载数据卷和配置文件 docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD123456 \ -v mysql-data:/var/lib/mysql \ -v $(pwd)/my.cnf:/etc/mysql/conf.d/my.cnf:ro \ -d mysql:8.0my.cnf内容[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_unicode_ci关键点解析-v mysql-data:/var/lib/mysql将 MySQL 数据目录挂载到命名卷即使容器删除数据仍在-v $(pwd)/my.cnf:/etc/mysql/conf.d/my.cnf:ro挂载自定义配置:ro表示只读防止容器内修改-e MYSQL_ROOT_PASSWORD通过环境变量设置 root 密码比--init脚本更安全。验证docker exec -it mysql8 mysql -uroot -p123456 -e SHOW DATABASES;输出应包含information_schema等系统库。6.2 场景二用 Docker Compose 管理微服务项目“docker部署微服务项目” 需要服务发现、配置中心、链路追踪
