简介：资源是一份面向NVIDIA Jetson Nano开发者的Docker部署实战文档，主要解决在ARM架构设备上安装Docker、配置nvidia-docker运行时并实现容器内GPU调用的问题。文档基于Ubuntu系统，从apt源安装Docker CE开始，逐步讲解nvidia-container-runtime的安装、daemon.json默认运行时配置，以及通过deviceQuery测试GPU容器的方法。内容还包含创建自定义容器镜像的Dockerfile示例，以及运行容器时如何映射/dev/nvhost-*设备节点与tegra驱动目录，适合需要在Jetson Nano上搭建深度学习环境的工程师和爱好者参考。资源包为单个docx文档，大小208KB，共1个文件，便携易读，可随时在命令行环境旁边对照操作。目前已有157人学习使用，对于刚接触Jetson平台Docker化的读者而言，是一份可直接上手、少走弯路的实用指南。
1. Docker安装这个事，为什么值得单独写一篇
收到一个叫“Docker安装.docx”的文档，第一反应多半是“安装而已，有什么可写的”。可真在一线装过的人都知道，Docker安装的翻车率远比想象中高：Docker Desktop 起不来、virtualization support not detected 报错、WSL2 内核版本不对、镜像拉取超时、装完跑 redis 主从发现网络不通——每一桩都真实消耗过半天时间。这篇就按我实际操作过的顺序，把 Docker 安装从环境检查、选型、落地到验证讲透，顺带把最坑的几个问题按现象、原因、解决方式列清楚。适合两类人：一是刚接触 Docker 的开发者，想在一台新机器上把环境利索地搭起来；二是被各种玄学启动失败折磨过的老手，想对照检查自己漏了哪一环。内容只围绕“安装”这个动作展开，装完之后的常用操作会作为验证手段出现，不会跑偏到完整的容器编排教程。
2. 装之前先摸清家底：虚拟化、WSL2 与安装选型
2.1 三条安装路线怎么选：Docker Desktop、Docker Engine + WSL2、服务器版
很多人一上来就双击安装包，装完发现跑不起来，回头才查 BIOS、查 Hyper-V，等于把排查顺序搞反了。安装 Docker 的第一步不是下载，是选路线。以我自己的经验，常见路线有三条，适用场景和代价完全不同。
| 安装路线 | 适用场景 | 优点 | 主要代价 |
|---|---|---|---|
| Docker Desktop (Windows/Mac) | 个人开发机、需要图形界面管理 | 一键装全家桶，自带 Kubernetes 选项，UI 直观 | 依赖 WSL2 或 Hyper-V，虚拟化没开直接无法启动；免费版对商用有许可限制 |
| Docker Engine + WSL2 (Windows) | 不想装 Desktop、希望更贴近 Linux 环境 | 纯命令行，资源占用比 Desktop 小，和服务器行为一致 | 需要手动管理 WSL 发行版，没有图形面板，新手容易在 Linux 子系统里迷路 |
| Docker Engine (Linux 服务器) | 生产环境、云服务器、NAS | 最干净、最稳定，性能最好 | 全命令行操作，一切靠配置文件 |
我的习惯是：Windows 开发机直接用 Docker Desktop，配 WSL2 后端，省心；但如果这台 Windows 机器是长期跑任务的，比如跑青龙面板、做本地测试服务，我更倾向只在 WSL2 里装 Docker Engine，内存占用低一截。Linux 服务器则不用多想，直接 Docker Engine。
顺便说一句，Mac 用户虽然也有 Docker Desktop，但不要装完就以为和 Linux 完全一致。Docker Desktop 在 Mac 上默认是跑在一个轻量虚拟机里的，文件挂载性能比 Linux 原生差不少，涉及大量 IO 的场景要提前有心理准备。
2.2 检查虚拟化是否开启：一条命令确认，别急着进 BIOS
路线定了，先检查机器硬件虚拟化是否打开。这一步几乎是“安装后无法启动”的第一大原因。Windows 上打开 PowerShell 或 CMD，执行下面的命令：
systeminfo | Select-String "Hyper-V|虚拟化|Virtualization"如果输出里看到“虚拟化: 是”或者四条 Hyper-V 要求都是“是”，说明硬件虚拟化已经就绪。如果显示“虚拟化: 否”或者“已启用固件中的虚拟化: 否”，那就要重启进 BIOS 开启 Intel VT-x 或 AMD-V。顺便说一下，如果是虚拟机里装 Docker，还需要在宿主机上开启“嵌套虚拟化”，这一步很多人漏掉。
Linux 上检查更简单，看 /dev/kvm 是否存在：
ls -l /dev/kvm能列出设备说明 KVM 可用。没有的话，检查 BIOS 设置，或者确认云服务器的实例类型是否支持嵌套虚拟化。这里有个常见误区：CPU 支持虚拟化不等于虚拟化已启用，必须到 BIOS 里确认“Intel Virtualization Technology”或“SVM Mode”是 Enabled 状态。我遇到过一台机器 BIOS 里显示 Enabled，但系统信息还是“否”，最后发现是 BIOS 版本有 bug，升级固件后才正常，这种属于小概率事件，遇到了不要死磕硬件。
2.3 把 WSL2 装到位：wsl --install 和它的两个关键前提
Windows 下建议优先使用 WSL2 作为 Docker Desktop 的后端。WSL2 不是简单的兼容层，它跑在轻量虚拟机上，和 Docker 的 Linux 容器模型天然匹配。安装 WSL2 的标准做法是管理员身份打开 PowerShell：
wsl --install这条命令会默认安装 WSL2 和一个 Ubuntu 发行版。装完重启，执行wsl --set-default-version 2把默认版本切到 2。注意，Windows 10 较老版本可能不支持wsl --install带发行版安装，需要先手动装 WSL 内核更新包。判断自己 WSL 版本的方法是wsl --status，如果输出里出现“默认版本: 2”就正常。
这里有一个高频问题：wsl --install执行完提示“正在安装”，但重启后 wsl 命令不存在。原因通常是 Windows 版本过旧或缺少“适用于 Linux 的 Windows 子系统”可选功能。解决方式是在“启用或关闭 Windows 功能”里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，重启后再执行一次安装。这一步是 Docker Desktop 启动成功的根基，值得先花十分钟确认好，别等到报错再回头看。
3. 用 Docker Desktop 装出第一个可用环境：步骤、加速与资源限制
3.1 完整安装步骤：从安装包到首次启动
确认 WSL2 就绪后，安装 Docker Desktop 本身没有太多幺蛾子，但一些小细节会影响后续使用。先去官网下 Docker Desktop Installer.exe，双击安装时注意两个选项：一是“Use WSL 2 instead of Hyper-V”要勾上，二是“Add shortcut to desktop”随意。安装过程中不要勾选“Use Windows containers”，除非你确实要跑 Windows 容器，这会导致默认容器运行时切换，后续拉 Linux 镜像会有奇怪的兼容性问题。
装完启动 Docker Desktop，首次启动会比较慢，因为它在后台创建并启动 WSL2 分发版。此时可以通过wsl -l -v查看：
wsl -l -v正常输出应该是一个 NAME 为 docker-desktop 的发行版，VERSION 列为 2。如果这里看不到 docker-desktop，说明 Docker Desktop 没有成功创建 WSL 后端，问题大概率出在上一章的 WSL2 安装环节。
首次启动完成后，打开命令行工具验证 daemon 状态：
docker version分段看输出。Server部分如果能显示 Engine 版本，说明 Docker daemon 已经跑起来。如果只有Client段没有Server段，说明客户端连不上 daemon，常见原因是 Docker Desktop 还在启动中，或 WSL 后端没起来，等两分钟再试。如果一直连不上，右键托盘图标看有没有报错信息，或者直接看日志。Docker Desktop 自带日志查看，在 Troubleshoot 页面可以导出日志包，排查时比盲猜高效得多。
3.2 配置镜像加速与 daemon.json：参数别随便抄
国内网络环境下，拉取镜像经常卡在超时，这不是 Docker 的问题，是镜像源连通性的问题。Docker Desktop 提供图形化的镜像加速配置，在 Settings -> Docker Engine 里编辑 JSON 配置。我刚装完环境第一件事就是把 registry-mirrors 配好：
{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com" ], "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } }第一段是镜像加速地址，第二段 log 配置顺手就把容器日志体积控制住了，这个后面细说。编辑完右下角点“Apply & Restart”，daemon 会带着新配置重启。注意，配置 JSON 必须是合法 JSON，多一个逗号都可能导致 daemon 启动失败，修改前建议先把原配置备份一行注释。
补充一个判断：加了加速地址后，docker info的Registry Mirrors段落会列出所有生效的地址。如果配置没生效，检查是不是修改的对象不对——Linux 上配置文件是/etc/docker/daemon.json，不是/etc/docker/daemon.conf，这个小坑我见人踩过不止一次。
3.3 资源上限与 WSL2 内存回收：默认配置的两个坑
Docker Desktop 默认配置对开发机是能跑，但不合理。第一个坑是内存上限。Docker Desktop 在 Settings -> Resources 里可以设置内存上限，默认可能是 2GB 或自动分配，但如果宿主内存只有 8GB，再开几个容器就容易把机器拖垮。我的建议是：宿主内存 16GB 的机器，给 Docker 设 4GB；32GB 的机器可以给 8GB。设大了宿主卡，设小了容器被 OOM，需要根据实际负载调。
第二个坑是 WSL2 的 vhdx 磁盘文件只增不减。WSL2 用虚拟磁盘存数据，容器镜像、挂载卷全在里面，这个文件会随着使用越来越大，删除镜像和容器后也不自动收缩。处理办法是周期性压缩，在 PowerShell 里执行：
wsl --shutdown diskpartdiskpart 是交互式命令，进到 diskpart 提示符后依次执行“select vdisk file=...”和“attach vdisk readonly”“compact vdisk”“detach vdisk”。注意 vhdx 文件路径通常在%LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx。这个操作适合在磁盘空间报警时做，我自己是每个月做一次，能把虚拟磁盘从几十 GB 压缩回几 GB。
4. 装完必须会的三个验证动作：跑容器、建主从、管依赖
4.1 最小命令验证：hello-world 到端口映射
安装完成的第一个验证是docker run hello-world。这是官方的最小镜像，能正常输出“Hello from Docker!”说明 daemon、镜像拉取、容器运行整条链路是通的。但这条命令只验证了基础能力，端口映射是否正常、数据卷是否挂载成功，它都测不到。我一般会用 nginx 做二次验证：
docker run -d --name nginx-test -p 8080:80 nginx:alpine然后浏览器访问http://localhost:8080，能看到 Welcome to nginx! 说明端口映射和容器网络都正常。注意-p 8080:80的前一个端口是宿主机端口，后一个是容器内端口，习惯了反向写会直接导致访问失败。完事记得清理：
docker rm -f nginx-test这一步不需要纠结镜像大小，重点是确认“从外部能访问容器内服务”这条路径是通的，这是后面所有容器化服务的基础。
4.2 用 Redis 主从验证网络与数据卷：docker-compose.yml 示例
安装完成后，搭建一个 redis 主从是成本最低的完整链路验证，能同时检验镜像拉取、自定义网络、环境变量、数据卷挂载。我通常用 docker compose 一次性拉起主从和哨兵：
version: "3.8" services: redis-master: image: redis:7-alpine container_name: redis-master ports: - "6379:6379" command: ["redis-server", "--appendonly", "yes"] volumes: - redis-master-data:/data networks: - redis-net redis-slave: image: redis:7-alpine container_name: redis-slave depends_on: - redis-master command: ["redis-server", "--slaveof", "redis-master", "6379"] volumes: - redis-slave-data:/data networks: - redis-net networks: redis-net: driver: bridge volumes: redis-master-data: redis-slave-data:在文件所在目录执行docker compose up -d。这个文件有几个值得注意的地方：redis-slave 用--slaveof redis-master 6379指定主库地址，这里用的是服务名而不是 IP，因为 compose 会自动在自定义网络里做 DNS 解析；depends_on只保证 master 先启动，不保证 master 的 redis 进程已经就绪，所以极端情况下 slave 可能连接失败后自动重试，实际使用中 redis 的重连机制能兜住这个问题。
验证方法：
docker exec -it redis-slave redis-cli info replication输出中master_link_status:up就说明主从正常。如果master_link_status:down，先docker logs redis-slave看报错，最常见的原因是网络隔离或主库设置了密码而从库没带。这是安装完成后非常实用的一套“体检套餐”，一次成功可以排除绝大多数环境问题。
4.3 青龙依赖管理场景：容器内依赖安装的正确姿势
很多人装 Docker 不只是为了验证，而是真的要用，比如跑青龙面板这类定时任务工具。青龙依赖管理是组件安装后绕不开的一道坎。依赖装不上、依赖冲突、装完任务还是报错，这类问题几乎都出在同一个地方：依赖装到了容器内，但环境变量或 Node 路径不对。
青龙容器的依赖管理常见做法是进入容器执行各语言的包管理命令：
docker exec -it qinglong bash -c "npm install -g crypto-js && apk add --no-cache python3"但“进容器敲命令”这种方式有个缺点：容器重建后依赖全丢。所以我一般建议把依赖安装写进 Docker 的初始化脚本或自定义镜像里，青龙官方文档支持在启动时执行自定义脚本。思路是先写一个 Dockerfile：
FROM whyour/qinglong:latest RUN npm config set registry https://registry.npm.taobao.org \ && npm install -g crypto-js \ && pip3 install --upgrade pip然后docker build -t qinglong-custom .，用自定义镜像替代官方镜像。这样每次容器重建依赖都在，不会出现“哦我又忘了装 crypto-js”的情况。依赖管理这块的核心认知是：容器是临时的，依赖配置要固化到镜像或脚本里，而不是靠脑力记住手动安装。
5. Docker 安装避坑：5 个高频翻车现场与排查顺序
5.1 Virtualization support not detected：BIOS 里明明开了为什么还报错
现象：Docker Desktop 启动直接弹“Virtualization support not detected”或者“Docker Desktop failed to start because...”，但进 BIOS 看 Intel VT-x 是 Enabled。
原因：排查顺序错了。这个报错不一定代表 CPU 虚拟化没开，还可能是 Windows 的“虚拟机平台”可选功能没启用，或者 Hyper-V 和第三方虚拟化软件冲突，比如老版本 VMware Workstation 同时开启时，Docker 检测不到虚拟化层。
解决：按顺序做三件事。先执行systeminfo确认 Hyper-V 要求是否全部为“是”。然后打开“启用或关闭 Windows 功能”，勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”，重启。最后检查是否存在其他虚拟机软件，有的话先退出再启动 Docker Desktop。按这个顺序能排查掉九成以上的情况，剩下的是 BIOS 固件太老导致 VT-d 没完全暴露，升级 BIOS 可以解决。
5.2 WSL2 内核版本过旧导致启动失败
现象：Docker Desktop 启动后一直转圈，最后提示“WSL 2 installation is incomplete”或 daemon 无法连接。
原因：Windows 10 系统长时间没更新，WSL2 内核停留在旧版，和 Docker Desktop 新版的兼容性出了问题。
解决：管理员 PowerShell 执行wsl --update更新内核，然后wsl --shutdown重启 WSL。更新后执行wsl --status确认内核版本。如果你的系统是 Win10 21H2 之前的版本，wsl --update可能无法识别，需要手动下载 WSL2 Linux 内核更新包安装。这个坑在长期不重启的办公机上尤其常见，因为 Windows Update 被组策略禁掉后，WSL 内核也跟着停了。
5.3 镜像拉取超时：加速地址替换与 DNS 兜底
现象：docker pull执行后长时间停在“Waiting”或者直接报“net/http: TLS handshake timeout”。
原因：默认 Docker Hub 源在国内连接不稳定，单纯加一个加速地址不够，有时是 DNS 解析被污染。
解决：在 daemon.json 的 registry-mirrors 里配置多个加速地址，不要只留一个，一个挂了还有备用。如果配置完仍然超时，检查/etc/resolv.conf里的 DNS 是否正常，可以直接改成nameserver 223.5.5.5再试。另外，企业内部网络或校园网经常有防火墙拦截，这种情况加速地址也没用，需要走代理或换网络再拉。拉取超时是最常见但不难解决的环境问题，别一股脑找 Docker 的毛病。
5.4 容器内时间不对：时区设置的常见遗漏
现象：容器内执行date显示 UTC 时间，和宿主机差 8 小时，定时任务全在错误的时间点触发。
原因：官方镜像默认时区是 UTC，安装 Docker 本身没问题，但不改时区会连带出业务问题。
解决：运行容器时加环境变量：
docker run -d --name app -e TZ=Asia/Shanghai your-imagedocker compose 里对应写environment: - TZ=Asia/Shanghai。这类“不是安装问题是使用问题”的坑挂在安装文章里，是因为很多人刚装完 Docker 就跑定时任务，第一反映是 Docker 装错了，实际上只是时区没传。注意，改了环境变量后需要重建容器才生效，docker exec里 export 是没用的。
5.5 vhdx 体积膨胀：WSL2 磁盘占用只增不减
现象：C 盘空间持续变少，镜像和容器清理了个遍，空间就是不回来。
原因：WSL2 的 ext4.vhdx 虚拟磁盘文件不会自动缩容，删除的数据只是标记为空闲，文件本身不会变小。
解决：按第 3.3 节的方式执行 diskpart 压缩，或者简单粗暴一点，把用不到的镜像导出再重建。日常预防措施是设置 Docker Desktop 的磁盘镜像大小上限，并在 daemon.json 里配好日志轮转。日志轮转这个点特别值得强调：一个不设限制的容器写日志，能把磁盘占满，log-opts必须加。这个是安装后最容易忽视的长期隐患，处理起来不算难，贵在提前配置。
6. 让安装一次到位：离线安装、开机启动与日志清理
安装 Docker 这件事，把前面几步走完已经能覆盖绝大多数场景，但还有三个进阶习惯能让环境更稳。第一是离线安装。内网服务器或现场项目没有外网，apt install docker.io不现实，常见做法是找一台同架构的联网机器，用docker save把镜像导出成 tar，再拷贝到目标机器docker load导入。Docker 引擎本体则是下载 deb/rpm 包后离线安装，Manjaro 这类滚动发行版也可以直接装 docker 包。离线环境里的关键点是架构必须一致，x86_64 的机器不能导入 arm64 的镜像，命令行能识别出来但运行时会直接报 exec format error。
第二是开机启动。Linux 服务器上 Docker 服务默认不随系统启动，需要手动设置，一条命令解决：
systemctl enable docker但这里有个连带问题：如果你用容器跑数据库或业务服务，这些容器依赖 Docker daemon 先起来，所以容器本身要设置restart: unless-stopped策略，否则 daemon 起来了容器却是死的。用 docker 命令手动启动容器时加参数，或写在 docker compose 的 restart 字段里。两者配合，服务器断电重启后服务能自动恢复，这是生产环境的基本要求。
第三是日志清理的日常化。前面 daemon.json 里配置了max-size: 50m和max-file: 3，但那只对之后创建的容器生效，旧容器不受约束。所以我会定期跑一条命令兜底：
docker system prune -af --volumes这条命令会把所有停止的容器、未使用的镜像和悬空数据卷全部清掉。注意-a会把没有在用的镜像全删掉，下次启动要重新拉，所以别在业务高峰跑。删完之后建议顺手做一次 vhdx 压缩，磁盘空间回收才算彻底。
我自己的习惯是配置完环境，马上把 daemon.json、docker-compose.yml 和启动命令同步到 Git 仓库，再写一个三五行的 README，记录这台机器的端口分配和数据卷路径。说实话，干这行久了最大的教训是“能复现的安装才叫安装，不能复现的只是碰运气”。Docker 安装本身不复杂，但前置环境、参数配置和后续策略组合起来，细节会非常多。照着上面的顺序走一遍，遇到问题按章节排查，基本能把环境顺利落地。希望帮到你。
本文还有配套的精品资源，点击获取
