简介资源是一份面向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 的标准做法是管理员身份打开 PowerShellwsl --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 设 4GB32GB 的机器可以给 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 的初始化脚本或自定义镜像里青龙官方文档支持在启动时执行自定义脚本。思路是先写一个 DockerfileFROM 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 detectedBIOS 里明明开了为什么还报错现象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 TZAsia/Shanghai your-imagedocker compose 里对应写environment: - TZAsia/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 安装本身不复杂但前置环境、参数配置和后续策略组合起来细节会非常多。照着上面的顺序走一遍遇到问题按章节排查基本能把环境顺利落地。希望帮到你。本文还有配套的精品资源点击获取