Docker把Jetson AGX Orin变成乐高积木|docker|rm|乐高|根目录|积木

2024年，NVIDIA Jetson AGX Orin的Docker 29.3.1版本装机量突破47万台，但官方文档里藏着个冷知识——超过60%的开发者第一次启动容器时，会把本地项目目录搞丢。这不是技术问题，是备份习惯的问题。

jetson-containers项目把这件事摊开了讲。它给新手准备了一套「先存档再冒险」的工作流，核心逻辑像极了游戏里的手动存盘：改配置前按F5，崩了就读档重来。

镜像、容器、卷：三个盒子怎么分

jetson-containers的文档里有个精妙的类比——镜像是ISO光盘，容器是你从光盘启动的电脑，卷则是你插在电脑上的U盘。装系统时ISO只读，运行时的改动全写在内存里，一关机就消失；U盘里的东西才真正留得住。

这个区分在Jetson这类边缘设备上尤其致命。Orin的64GB内存看着宽裕，但跑起多路视频推理时，容器日志和临时文件能把根目录撑爆。把项目代码挂成卷（volume）而不是拷进镜像，是区分新手和老鸟的第一道分水岭。

具体怎么操作？文档给出了三段式备份命令，全部带时间戳：

# 整目录备份 cp -a ~/projects/my-app ~/backups/jetson-containers/my-app_$(date +%Y%m%d-%H%M%S) # 单文件备份 cp docker-compose.yml docker-compose.yml.bak_$(date +%Y%m%d-%H%M%S) # 项目内即时备份 cp config.yaml config.yaml.bak_$(date +%Y%m%d-%H%M%S)

恢复时直接倒过来：从带时间戳的文件夹里把内容拷回原位。没有魔法，就是Linux基础的cp命令，但加上日期后缀后，你能在backups目录里看到完整的修改历史——这比Git的commit更粗暴，也更适合临时改配置的场景。

验证Docker环境：一行命令排雷

Jetson AGX Orin出厂预装的Docker 29.3.1已经带arm64支持，但权限问题仍是坑点。docker info报错permission denied时，90%的人选择sudo运行，这是错的——正确做法是把当前用户加入docker组，然后重新登录。

文档给的测试命令很克制：

docker run --rm arm64v8/ubuntu:22.04 uname -a

--rm表示容器停止后自动删除，不会在系统里留垃圾；arm64v8/ubuntu:22.04是Orin能原生运行的镜像架构。如果这行能输出内核信息，说明Docker引擎、容器运行时、镜像拉取链路全部正常。

jetson-containers项目在此基础上做了封装。它的run.sh脚本会自动检测JetPack版本（这里是6.2.2），匹配对应的CUDA和TensorRT容器标签，省去手动指定镜像名的麻烦。但文档坚持让新手先跑通原生Docker命令——理解底层机制，才能在脚本出问题时不抓瞎。

日常操作：启动、停止、重建的循环

容器化的开发节奏和传统SSH登录完全不同。jetson-containers文档描述的典型工作流是：改代码→重建镜像→启动新容器→验证→停止→清理。这个循环可能一天跑几十次，所以每个步骤都被优化到单条命令。

启动容器时，-v参数把主机目录挂进容器，-p映射端口，--gpus all暴露Orin的GPU。停止用docker stop，彻底删除用docker rm，连镜像一起清用docker rmi。文档特别提醒：docker system prune会删除所有未使用的镜像和卷，执行前确认备份已完成。

重建（rebuild）是新手最困惑的环节。jetson-containers的Dockerfile通常基于dustynv/jetson-inference这类基础镜像，加入项目依赖后构建。文档建议用--no-cache参数强制重新安装依赖，避免旧层缓存导致「在我机器上能跑」的玄学问题。

一个细节：Orin的ARM架构意味着大部分x86镜像不能直接跑。jetson-containers维护了arm64版本的PyTorch、TensorFlow、OpenCV等常用库，docker pull时会自动匹配架构标签。如果看到「no matching manifest」错误，大概率是拉成了amd64镜像。