简介：围绕Jetson Nano上的Docker与NVIDIA Docker部署，面向需要在ARM架构设备上搭建深度学习容器的开发者，解决Docker容器无法调用GPU、无法访问驱动设备节点等常见问题。文档以实操笔记形式，详细记录从Docker安装、NVIDIA Container Runtime配置，到修改daemon.json将NVIDIA设为默认运行时，再到编写Dockerfile、创建镜像、运行容器时映射/dev/nvhost-*设备节点和/usr/lib/aarch64-linux-gnu/tegra驱动目录的完整过程，命令和配置文件均列出，可对照执行。资源包为单个docx文档，大小仅208KB，内容紧凑、步骤明确，适合边查边操作。目前已有157人学习下载，若想在Jetson Nano上快速复现GPU支持的Docker环境，这份笔记能帮你省去不少排查和翻文档的时间。
1. 装个 Docker 而已，为什么值得单独写一篇
新机器到手，照着网上那句 curl 管道安装脚本敲完，docker run hello-world却卡在 pull 阶段半天不动；Windows 笔记本上双击 Docker Desktop，弹窗直接甩一句virtualization support not detected，Docker Desktop failed to start。这些场景我在过去几年里见过太多次，问题不在命令本身，而在装之前没人告诉你环境长什么样、该选哪条安装路径。这篇笔记就是冲着「Docker安装」这件事来的：把 Linux 服务器和 Windows/Mac 桌面端两条安装路径拆开讲，每一步命令都给出参数说明和失败时的观察点，再补上镜像拉取、依赖管理、存储这几个高频翻车点的排查顺序。适合两类人：刚接触 Docker、想在本地或服务器上把它跑起来的新手，以及要给团队写一份可复现安装规范、不想在同样坑里栽第二次的开发者。
2. 装之前先分清：Docker 引擎、CLI 和 Desktop 各是什么
2.1 引擎三层结构：dockerd、containerd、runc 与 CLI 各管什么
很多人以为「装 Docker」就是装一个软件，实际上你装的是四个相互配合的组件。dockerd是常驻后台的守护进程，负责接收 API 请求、管理镜像和容器生命周期；containerd是更底层的容器运行时管理器，负责镜像解包、容器标准输入输出和进程生命周期；runc是最底层的执行器，真正调用 Linux 内核的 namespace 和 cgroup 把容器进程拉起来；而docker命令本身只是客户端，它把你在终端敲的指令翻译成 REST API 发给 dockerd。
这三层结构的实际意义在于排错。当docker ps没反应时，问题可能在 CLI 到 dockerd 的连接上；当容器创建了但起不来时，问题通常在 containerd 和 runc 这一层；当容器能跑但网络不通、磁盘报错时，又回到了 dockerd 的配置上。CLI 装好但 dockerd 没启动，是新手最常见的「装完了却用不了」的原因。另外，/var/run/docker.sock这个 socket 文件是 CLI 与 dockerd 通信的通道，权限不对直接连不上——这一点后面排错章节会专门展开。
2.2 三种安装形态怎么选：服务器、桌面电脑、离线内网
安装 Docker 的路径取决于你的目标环境。生产或开发服务器上，标准做法是装 Docker Engine 社区版（docker-ce），通过系统的包管理器安装，体积小、无 GUI、便于用 systemd 管理。个人电脑上，Windows 和 macOS 用户通常会装 Docker Desktop——它自带图形界面、Kubernetes 单机集群和文件共享功能，实际是一个虚拟机壳子包着 Docker Engine。而内网离线环境最麻烦：你需要在有网的机器上把.deb或.rpm包连同依赖一起下载打包，拿进去离线安装，GPG 密钥和 APT 源都走不通。
| 环境 | 安装方式 | 主要优点 | 主要代价 |
|---|---|---|---|
| Linux 服务器 | docker-ce + containerd | 轻量、systemd 管理、无 GUI | 所有操作走命令行 |
| Windows / macOS | Docker Desktop | 带界面、集成 WSL2 / Hyper-V | 占内存大、依赖虚拟化 |
| 内网离线机 | deb/rpm 离线包 | 不依赖外网 | 依赖收集麻烦、版本难升级 |
我一般会根据机器的用途来做决定：只要是跑真实任务、要长期维护的机器，一律用 Linux + docker-ce；只有本地开发调试才用 Desktop。如果你只是想在 Windows 上跑几个容器试试，Desktop 确实是最快的路径，但请做好至少 4GB 内存被吃掉的准备。
2.3 安装前必须确认的三项前置条件
无论哪条安装路径，有三件事必须在动手前确认，否则装到一半必然翻车。第一是内核版本，Linux 上 Docker 要求内核不低于 3.10，且要开启 overlay2 存储驱动支持，用uname -r查看；第二是系统版本与包管理器的可用性，Ubuntu 22.04 和 CentOS 7 的安装命令完全不同，别把两篇教程混着抄；第三是虚拟化能力，Desktop 在 Windows 上依赖 WSL2 或 Hyper-V，在 macOS 上依赖 HyperKit 框架，BIOS 里的 Intel VT-x 或 AMD-V 没开，装好了也启动不了。
这三个条件看着基础，却是「安装失败、系统崩溃、白忙一场」的高发原因。特别是第三点，报错信息往往只有一个含糊的virtualization support not detected，很容易让人误以为是软件坏了去重装一遍——实际上 BIOS 里开启虚拟化开关、确认 Windows 功能里的虚拟机平台已勾选就能解决。建议在任何安装动作之前，先把这三项检查结果写下来，再往下走。
3. Linux 服务器上把 Docker 装稳：换源、加仓库、起服务的标准动作
3.1 从卸载旧版和装依赖开始：干净环境才有可复现的结果
在全新服务器上装 Docker 其实很简单，但如果是接手一台别人用过的机器，第一步永远是清理旧版本。Ubuntu 上旧的 docker、docker-engine、docker.io 包如果存在，会和 docker-ce 抢目录和配置，导致装完启动不了。先执行清理：
sudo apt-get remove docker docker-engine docker.io containerd runc这行命令会卸载系统里可能残留的旧 Docker 相关包，但不会删除/var/lib/docker下的镜像、容器和数据卷，卸载是安全的。如果之后确定不再需要旧数据，可以手动清除这个目录，但那是后话。清理完旧包后，更新索引并安装安装 Docker 仓库所需的依赖：
sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg参数说明：ca-certificates用于验证 HTTPS 证书，没有它curl访问 Docker 官方源会报证书错误；gnupg用于校验 Docker 仓库的 GPG 签名。这一步在所有 Debian/Ubuntu 系机器上通用，CentOS 系的依赖名是yum-utils，命令是sudo yum install -y yum-utils，思路一致但别混用。
3.2 添加 Docker 官方仓库：GPG 密钥与 sources.list 的正确姿势
依赖装好后，下一步是把 Docker 的 APT 仓库加入系统。这里有个常见的翻车点：网上很多旧教程直接把curl ... | sudo sh管道执行了，虽然省事，但你完全不知道脚本做了什么。标准做法是手动添加 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 a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null逻辑说明：install -m 0755 -d创建存放密钥的目录并设置权限；gpg --dearmor把下载的 GPG 公钥从 ASCII 格式转换成二进制格式，因为 APT 只认二进制格式；chmod a+r给所有用户读权限，否则 APT 在非 root 下更新会警告。仓库地址中的arch=$(dpkg --print-architecture)会自动填入amd64或arm64，VERSION_CODENAME会读取系统代号（如jammy），这两处的自动取值保证仓库地址与系统匹配。
这里插一句：$(. /etc/os-release && echo "$VERSION_CODENAME")这段里的VERSION_CODENAME需要系统是 Ubuntu 20.04 或更新版本。如果你用的是更老的系统，这个变量可能为空，仓库地址会变成stable开头的错误路径。遇到apt update报 404 时，先检查/etc/apt/sources.list.d/docker.list里的代号是否正确，比我见过有人手打成bionic在 Ubuntu 22.04 上装，结果源里根本没有对应版本，折腾半小时。
3.3 安装 docker-ce 并启动：三个命令确认引擎真的活着
仓库配置正确后，安装过程就是一行命令的事：
sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin sudo systemctl enable --now docker参数说明：docker-ce是 Docker 引擎本体；docker-ce-cli是docker命令行的客户端；containerd.io是容器运行时；docker-buildx-plugin和docker-compose-plugin分别提供多架构镜像构建和 Compose 编排能力，官方现在默认把它们打包进安装，省得后面再补。三者的版本由 APT 统一管理，升级时一条apt-get upgrade就能一起更新。
systemctl enable --now docker的作用是一步完成「开机自启」和「立即启动」，装完不用手动systemctl start docker。接下来确认引擎真正在工作：
sudo docker run hello-world这条命令会从 Docker Hub 拉取一个极小的测试镜像并运行，看到 "Hello from Docker!" 就说明引擎、运行时、CLI、网络拉取四层链路全部正常。如果你的网络环境拉不动官方镜像，可以先用docker version看 Client 和 Server 两段信息——Server 段有内容说明 dockerd 活着，拉取问题是另一章要讲的事。
3.4 免 sudo 与开机自启：日常使用的两个收尾动作
安装完成后，你会发现每次敲docker都要加sudo，因为 dockerd 的 socket 文件默认只允许 root 和 docker 组的用户访问。把自己的用户加进 docker 组，就能免去每次 sudo 的麻烦：
sudo usermod -aG docker $USER newgrp docker参数说明：usermod -aG的-a表示追加（append），不加-a会把你从其他附属组里踢掉，这是个很容易踩的坑；newgrp docker是让当前终端立即生效的临时手段，重新登录后同样生效。加了 docker 组后，这个用户对 docker.sock 拥有完全控制权，等同于 root 权限，所以只把可信用户加进去。
开机自启在上一节的systemctl enable --now docker里已经做了，但值得确认一下状态：systemctl is-enabled docker输出enabled即正常。另外，如果你在云服务器上装完发现docker run报 iptables 相关的错误，多半是云平台的安全组或自带的防火墙策略和 Docker 的 NAT 规则冲突，优先检查systemctl status docker的日志，而不是急着重装。
4. Windows 和 macOS：Docker Desktop 安装与 WSL2 的边界
4.1 Docker Desktop 的下载、安装与首次启动流程
桌面端安装 Docker 的体验比 Linux 直观得多：从官网下载 Docker Desktop 安装包，双击安装，一路下一步。但有一个关键选择在安装过程中会出现——询问你使用 WSL 2 还是 Hyper-V 后端。对于 Win10 2004 以上和 Win11 系统，WSL 2 是更优选择：启动更快、内存占用更可调、与本地文件系统集成更顺畅。而 Hyper-V 后端适合老版本 Windows 或对虚拟机有特殊需求的场景。
安装完成后首次启动，Desktop 会弹出对话框要求启用必要的 Windows 功能并重启。这一步千万别跳过重启直接开，因为 WSL 2 依赖的「虚拟机平台」和「适用于 Linux 的 Windows 子系统」两个功能必须重启后才真正生效。macOS 这边流程类似，安装包拖进 Applications 目录后首次启动会请求管理员权限，用于安装网络和文件共享的辅助组件。
我不建议在安装过程中去勾选「Use WSL 2 instead of Hyper-V」之外的任何高级选项，默认配置足够跑通。等确认容器能正常跑起来，再慢慢研究资源限制和镜像加速不迟。
4.2 virtualization support not detected：这条报错的完整排查路径
这是 Docker Desktop 用户最常遇到的拦路虎，报错原文是virtualization support not detected Docker Desktop failed to start because v——完整信息是 "... because virtualization support is disabled or not present on your system"。它表示 Windows 无法使用硬件虚拟化能力，Docker Desktop 依赖的 WSL 2 或 Hyper-V 虚拟机起不来。
排查路径我按顺序走，每一步都验证后再进下一步。首先检查 BIOS 设置：重启进 BIOS，找到 Intel Virtualization Technology（Intel 平台）或 SVM Mode（AMD 平台），确认状态是 Enabled。这是最根本的原因，也是最多人栽的地方——不少办公电脑出厂默认关闭虚拟化。其次是检查 Windows 功能：
# 以管理员身份在 PowerShell 中执行 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart参数说明：Microsoft-Windows-Subsystem-Linux开启 WSL 功能本体，VirtualMachinePlatform开启虚拟机平台，两者是 WSL 2 运行的基础。执行完norestart参数表示不自动重启，两个都装完后手动重启一次。重启后检查 WSL 内核和默认版本：
wsl --update wsl --statuswsl --update会把 WSL 内核更新到最新版，很多旧内核跑不起来 WSL 2 的容器；wsl --status的输出会显示默认 WSL 版本是否为 2。注意：如果你之前装过 WSL 1 的发行版，需要wsl --set-default-version 2把默认版本切到 2，否则 Docker Desktop 依然起不来。
4.3 WSL2 与 Hyper-V 的冲突：老机器升级时的常见翻车
当你把 WSL 2 和 Hyper-V 混在一台机器上时，会出现一类很隐蔽的冲突。常见场景是：电脑之前为了跑 VirtualBox 或 VMware 关闭了 Hyper-V，装 Docker Desktop 时选了 WSL 2 后端，结果 WSL 2 启动时发现 Hyper-V 相关组件被禁用，直接报错。反之亦然——开了 Hyper-V 的机器上再用 VirtualBox，VirtualBox 也会拒绝启动。
解决冲突的常见做法是检查 Windows 的虚拟机监控程序启动策略：
# 管理员 PowerShell 中查看当前状态 bcdedit /enum | findstr hypervisorlaunchtype如果输出是hypervisorlaunchtype Off，说明 Windows 的 Hyper-V 管理程序被禁用了，WSL 2 无法运行，需要执行：
bcdedit /set hypervisorlaunchtype auto然后重启。bcdedit修改的是 Windows 启动配置，auto表示允许系统自动加载 Hyper-V 管理程序，这是 WSL 2 和 Docker Desktop 运行的前提。注意这个操作只在同一台机器有冲突时做，纯 Linux 服务器上用不到。重启后再跑一次wsl --status确认状态正常。
这类问题的根源在于虚拟化层之间的互斥关系，我见过不少人在 VirtualBox 和 Docker 之间反复卸载重装，最后发现只是hypervisorlaunchtype被某次操作改掉了。如果以上都检查过仍未解决，最后一步是确认 Windows 版本的 SKU——家庭版不支持 Hyper-V，只能走 WSL 2 路线。
4.4 Desktop 与 Linux 引擎的使用差异：哪些设置在桌面上无效
成功启动 Docker Desktop 后，容易忽略一个事实：桌面版和 Linux 引擎虽然命令行接口一样，但底层实现不一样，导致部分配置不生效。最典型的是 Docker Desktop 的内存和 CPU 限制，默认是 2GB 内存和 2 核 CPU，集群跑大一点的任务会莫名卡死——在 Desktop 的 Settings -> Resources 里调大，而不是在daemon.json里改，因为 Desktop 的资源限制作用于 VM 层。
另一点是文件挂载的性能。docker run -v /本地目录:/容器目录在 Linux 上走原生文件系统，在 Desktop 上走的是 VM 的文件共享通道，大量小文件读写会慢一个数量级。如果你要在 Windows 上跑构建任务，把工作目录放进 WSL 2 的 Linux 文件系统里（\\wsl$\...）比放在C:\Users\...下快得多。
镜像加速的配置方式也不同：Linux 编辑/etc/docker/daemon.json，Desktop 在 Settings -> Docker Engine 里改同一个 JSON 文件但不用重启整个 Desktop，点 Apply & Restart 即可。这些差异不影响日常开发，但排查性能问题时知道边界在哪，能省很多时间。
5. 安装与上手阶段的常见问题排查：镜像、权限与依赖三处翻车点
5.1 docker pull 超时或卡住：加速器与 DNS 的排查顺序
现象：docker pull nginx:latest命令执行后长时间停在Waiting或反复超时重试。原因：Docker Hub 的官方镜像服务器在国内网络环境下访问极不稳定，属于镜像分发链路问题，不是 Docker 装错了。解决：配置镜像加速器。常见的做法是编辑/etc/docker/daemon.json：
sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://你的加速器地址"] } EOF sudo systemctl daemon-reload sudo systemctl restart docker参数说明：registry-mirrors是镜像加速器的地址列表，Docker 在拉取镜像时会优先尝试这些地址。加速器地址需要到云服务商的控制台获取专属链接，直接抄网上的公共地址很容易失效。daemon-reload让 systemd 重新读取配置，restart docker应用新配置。如果配置了加速器仍然超时，接下来检查 DNS：docker pull要走域名解析，cat /etc/resolv.conf看nameserver是否是可靠的 DNS（如 114.114.114.114 或 223.5.5.5），有些内网机器的 DNS 解析不到 Docker Hub 的 CDN 节点，换成公共 DNS 或云厂商 DNS 立马恢复。
5.2 镜像跑不起来报 permission denied：docker.sock 权限的归属
现象：docker ps报permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock。原因：当前用户不在 docker 组里，无权访问 socket 文件。解决：把用户加进 docker 组：
sudo usermod -aG docker $USER newgrp dockernewgrp docker让当前终端会话立即生效，不用重新登录。加了 docker 组等于把 root 权限交给了这个用户，所以只给可信用户加。如果加了组还报错，检查 socket 文件的权限是否被人为改过：正常应该是srw-rw---- root docker，即 root 和 docker 组可读写。有些安全加固脚本会把这个权限收紧，导致组内用户也访问不了，恢复默认权限用sudo chmod 660 /var/run/docker.sock && sudo chown root:docker /var/run/docker.sock。
5.3 青龙面板容器起来了依赖却装不上：依赖管理为什么总翻车
现象：青龙面板容器跑起来，登录后台后安装 Python 或 Node 依赖时一直失败或卡在依赖编译。原因：青龙的依赖管理本质上是在容器内部执行包管理器命令（pip或npm），容器内的基础镜像缺少编译工具链和系统库，导致带有 C 扩展的包编译失败。这不是 Docker 安装的问题，而是运行环境的依赖不完整。
解决：进入容器先手动装编译期依赖，再回到面板装业务依赖：
docker exec -it qinglong bash # 在容器内部执行 apk add --no-cache build-base python3-dev参数说明：青龙官方镜像基于 Alpine Linux，包管理器是apk；build-base提供 gcc、make 等编译工具，python3-dev是 Python 头文件。装好后回到面板重试依赖安装，绝大多数error: command 'gcc' failed都能解决。另外注意时区：启动容器时没设置TZ=Asia/Shanghai，面板里的定时任务时间会偏移 8 小时，这不是依赖问题但经常和依赖问题一起被提出来。
5.4 磁盘空间明明够却报 no space left：overlay2 与日志的隐形占用
现象：df -h显示磁盘还剩几十 GB，但docker pull或docker build报no space left on device。原因：Docker 的存储目录/var/lib/docker可能落在了独立的分区或逻辑卷上，磁盘总量够但那个分区满了。另外容器日志文件无限增长，单个容器日志能占到几十 GB，也会堵住分区。
解决：先定位是哪个分区满了：
sudo du -sh /var/lib/docker/* | sort -rh | head -10 sudo docker system dfdu看各目录的占用，docker system df看镜像、容器、数据卷的占用分布。如果确认是日志撑满，限制单个容器日志大小是一劳永逸的做法，在daemon.json中加入：
sudo tee /etc/docker/daemon.json <<-'EOF' { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } EOF sudo systemctl restart docker参数说明：max-size=10m表示单个日志文件超过 10MB 就轮转，max-file=3表示最多保留 3 个旧文件，这样单个容器日志上限约 30MB。清理存量日志用sudo sh -c "truncate -s 0 $(docker inspect --format='{{.LogPath}}' 容器名)"，直接删文件会因文件被占用而失效。覆盖存储驱动问题的处理就到这里，磁盘问题解决了，再回头看运行时的干净程度。
6. 装完别急着跑：验证安装与最小落地场景
6.1 从 hello-world 到真实容器：验证与第一条有效命令
docker run hello-world只是验证安装，它不产生任何可用服务。更进一步，我会用docker run --rm -d -p 8080:80 nginx跑一个真正的 Web 容器，--rm让容器停止后自动删除避免堆积，-d后台运行，-p 8080:80把宿主机的 8080 端口映射到容器的 80 端口。浏览器访问http://localhost:8080看到 Nginx 欢迎页，说明端口映射和网络链路完全正常。docker logs -f 容器名可以实时看日志，这是后续排查所有容器问题的基本手段。
6.2 装完 Docker 的第一件事：做一次镜像备份习惯
我个人的建议是装完 Docker 后立刻把daemon.json、docker version输出和安装命令记到一处——团队场景写成文档，个人场景写成笔记或注释。原因很简单：半年后你大概率记不清当初用哪个版本、改过哪些参数，而这些信息是排查问题最快的起点。另外，docker system prune -a可以清理所有未使用的镜像和容器，但它会删掉本地没有直接引用的镜像，下次用还得重新拉取，执行前三思。
以上是安装 Docker 从选型到落地、再到排错的完整路径。我做这份流程时踩过的最大一个坑，是在 Desktop 报virtualization support not detected后直接重装了三遍软件，最后发现只是 BIOS 虚拟化开关的问题——后来养成习惯，任何安装问题先查环境和日志，再动软件本身。希望帮到你。
本文还有配套的精品资源，点击获取
