简介围绕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 detectedDocker 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 / macOSDocker 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 ar /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 ar给所有用户读权限否则 APT 在非 root 下更新会警告。仓库地址中的arch$(dpkg --print-architecture)会自动填入amd64或arm64VERSION_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 和 macOSDocker 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 TechnologyIntel 平台或 SVM ModeAMD 平台确认状态是 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 的机器上再用 VirtualBoxVirtualBox 也会拒绝启动。解决冲突的常见做法是检查 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.jsonDesktop 在 Settings - Docker Engine 里改同一个 JSON 文件但不用重启整个 Desktop点 Apply Restart 即可。这些差异不影响日常开发但排查性能问题时知道边界在哪能省很多时间。5. 安装与上手阶段的常见问题排查镜像、权限与依赖三处翻车点5.1 docker pull 超时或卡住加速器与 DNS 的排查顺序现象docker pull nginx:latest命令执行后长时间停在Waiting或反复超时重试。原因Docker Hub 的官方镜像服务器在国内网络环境下访问极不稳定属于镜像分发链路问题不是 Docker 装错了。解决配置镜像加速器。常见的做法是编辑/etc/docker/daemon.jsonsudo 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应用新配置。如果配置了加速器仍然超时接下来检查 DNSdocker pull要走域名解析cat /etc/resolv.conf看nameserver是否是可靠的 DNS如 114.114.114.114 或 223.5.5.5有些内网机器的 DNS 解析不到 Docker Hub 的 CDN 节点换成公共 DNS 或云厂商 DNS 立马恢复。5.2 镜像跑不起来报 permission denieddocker.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包管理器是apkbuild-base提供 gcc、make 等编译工具python3-dev是 Python 头文件。装好后回到面板重试依赖安装绝大多数error: command gcc failed都能解决。另外注意时区启动容器时没设置TZAsia/Shanghai面板里的定时任务时间会偏移 8 小时这不是依赖问题但经常和依赖问题一起被提出来。5.4 磁盘空间明明够却报 no space leftoverlay2 与日志的隐形占用现象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-size10m表示单个日志文件超过 10MB 就轮转max-file3表示最多保留 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 虚拟化开关的问题——后来养成习惯任何安装问题先查环境和日志再动软件本身。希望帮到你。本文还有配套的精品资源点击获取