企业官网建设流程全解析

江门城乡建设局官方网站,eclipse 简单网站开发,制作网站视频教程,广州网站建设与实验引言 在使用 Docker Desktop 运行容器时#xff0c;开发者经常会遇到各种复杂的文件系统路径。特别是当我们通过 -v 参数挂载本地目录时#xff0c;Docker 会创建一系列复杂的存储结构。 本文将通过一个具体的 LocalAI 容器案例#xff0c;深入解析 Docker Desktop 中两个不…引言在使用 Docker Desktop 运行容器时开发者经常会遇到各种复杂的文件系统路径。特别是当我们通过-v参数挂载本地目录时Docker 会创建一系列复杂的存储结构。本文将通过一个具体的 LocalAI 容器案例深入解析 Docker Desktop 中两个不同存储路径的区别和原理。先说结论简单说这两个路径是Docker在后台“干活”留下的不同痕迹。第一个是Containerd运行时管理的相当于容器的“原始底稿”就是你挂载卷之前容器里自带的/build目录内容。第二个是Docker自己管理的相当于运行时的“工作现场”包含了卷挂载后的状态。但其实这两个路径你都不用管因为你的数据实际上在Windows的D:/localai-data/里。容器里的/build只是映射过来的窗口你在Windows那边改了文件容器里就能看到。所以记住你的模型和配置都在D盘那个文件夹Docker内部那些复杂路径不用操心。案例背景我运行了以下命令启动一个 LocalAI 容器dockerrun -d --name local-ai --gpus all -p8080:8080\-v D:/localai-data/models:/build/models\-v D:/localai-data/config:/build/config\localai/localai:latest-gpu-nvidia-cuda-12然后发现在 WSL 中有两个看起来相似但不同的路径Containerd 快照路径\\wsl.localhost\docker-desktop\mnt\docker-desktop-disk\data\desktop-containerd\daemon\io.containerd.snapshotter.v1.overlayfs\snapshots\284\fs\buildDocker OverlayFS 路径\\wsl.localhost\docker-desktop\mnt\docker-desktop-disk\data\docker\rootfs\overlayfs\f0e048f2205532a006623a8e02fef1534a391646e84047a51ffb5f560a616967\build技术架构深度解析1. Docker Desktop 的存储架构Docker Desktop 在 Windows 上使用 WSL 2 运行时采用了多层存储架构Windows 主机 ├── WSL 2 │ ├── Docker Desktop VM │ │ ├── Containerd 运行时 │ │ └── Docker 守护进程 │ └── 用户 WSL 发行版 └── Windows 文件系统2. Containerd 快照路径解析路径\\wsl.localhost\docker-desktop\mnt\docker-desktop-disk\data\desktop-containerd\daemon\io.containerd.snapshotter.v1.overlayfs\snapshots\284\fs\build这是 Containerd 的 OverlayFS 快照层结构分解desktop-containerd/daemon/- Containerd 守护进程数据目录io.containerd.snapshotter.v1.overlayfs/- OverlayFS 快照管理器snapshots/284/- 第 284 号快照随机IDfs/- 容器的根文件系统build/- 容器内的 /build 目录特点Containerd 管理由 Containerd 容器运行时直接管理快照机制使用 OverlayFS 的快照snapshot功能原始容器视图展示容器挂载卷之前的原始文件系统状态可写层基础是容器可写层upperdir的基础验证命令# 查看容器在 Containerd 中的信息dockerrun --rm -v /var/run/docker.sock:/var/run/docker.sock\redcoolbeans/dockercontainerspy containerd-list# 在容器内查看 OverlayFS 挂载dockerexeclocal-aimount|grepoverlay3. Docker OverlayFS 路径解析路径\\wsl.localhost\docker-desktop\mnt\docker-desktop-disk\data\docker\rootfs\overlayfs\f0e048f2205532a006623a8e02fef1534a391646e84047a51ffb5f560a616967\build这是 Docker 的 OverlayFS 存储驱动层结构分解docker/rootfs/overlayfs/- Docker 的 OverlayFS 存储驱动目录f0e048f220...- 64 位随机哈希标识特定容器层build/- 容器内的 /build 目录特点Docker 管理由 Docker 守护进程管理存储驱动使用 Docker 的 OverlayFS 存储驱动联合挂载可能包含多个镜像层的联合视图运行时状态包含卷挂载后的文件系统状态验证命令# 查看容器的存储驱动信息dockerinspect local-ai --format{{.GraphDriver}}# 查看具体的存储驱动数据dockerinspect local-ai --format{{json .GraphDriver.Data}}关键区别对比特性Containerd 快照路径Docker OverlayFS 路径管理者Containerd 运行时Docker 守护进程用途容器基础镜像快照容器运行时的存储层数据内容挂载卷前的原始数据可能包含运行时修改持久性基础层通常只读包含可写层生命周期与镜像层关联与容器实例关联实际操作验证1. 查看容器存储详情# 获取容器 IDdockerps-qfnamelocal-ai# 查看容器详情dockerinspect local-ai|grep-A10-B5GraphDriver# 输出示例# GraphDriver: {# Data: {# LowerDir: /var/lib/docker/overlay2/xxx/diff:/var/lib/docker/overlay2/yyy/diff,# MergedDir: /var/lib/docker/overlay2/zzz/merged,# UpperDir: /var/lib/docker/overlay2/zzz/diff,# WorkDir: /var/lib/docker/overlay2/zzz/work# },# Name: overlay2# }2. 在容器内验证挂载# 进入容器dockerexec-it local-aish# 查看 /build 目录结构ls-la /build/# 应该看到 models 和 config 目录# 查看挂载信息mount|grep/build# 输出应显示从 Windows 主机挂载的目录3. 查看卷映射# 查看容器的卷挂载dockerinspect local-ai --format{{json .Mounts}}# 输出应显示# [# {# Type: bind,# Source: /mnt/d/localai-data/models,# Destination: /build/models,# Mode: ,# RW: true,# Propagation: rprivate# },# {# Type: bind,# Source: /mnt/d/localai-data/config,# Destination: /build/config,# Mode: ,# RW: true,# Propagation: rprivate# }# ]为什么有两个相似的 /build 目录1. 挂载覆盖机制当使用-v参数挂载卷时Docker 使用了 Linux 的挂载覆盖机制容器 /build 原始目录卷挂载点Windows D:/localai-data/modelsWindows D:/localai-data/config容器运行时视图 /build2. 两个路径的实际关系Containerd 路径包含容器镜像中原始的/build目录内容在卷挂载前存在卷挂载后这个目录被隐藏maskedDocker OverlayFS 路径是运行时视图的一部分可能包含容器修改的元数据实际的卷挂载在这个视图之上3. 验证实验# 1. 停止容器dockerstop local-ai# 2. 查看 Containerd 路径# 此时应该能看到原始的 /build 目录内容# 3. 启动容器dockerstart local-ai# 4. 再次查看 Containerd 路径# 由于卷已挂载原始 /build 目录被隐藏实际影响和注意事项开发者需要知道的数据存储位置你的模型文件实际存储在D:/localai-data/models/Docker 容器内的路径只是映射视图性能考虑Windows → WSL → Docker 的三层转换有一定性能开销大量小文件操作时尤其明显备份策略备份D:/localai-data/目录即可不需要备份 Docker 内部的路径权限问题Windows 和 Linux 文件权限系统不同可能需要配置 WSL 的权限映射优化建议使用 Docker 卷替代绑定挂载dockervolume create localai-modelsdockervolume create localai-configdockerrun -d --name local-ai\-v localai-models:/build/models\-v localai-config:/build/config\localai/localai:latest-gpu-nvidia-cuda-12性能优化配置// 在 Docker Desktop 设置中添加{wslEngineEnabled:true,wslEngineOptimization:performance}监控存储使用# 查看容器存储使用dockersystemdf# 查看详细存储信息dockersystemdf-v高级调试技巧1. 查看 OverlayFS 层次结构# 在 WSL 中wsl -d docker-desktop# 查找容器相关层find/var/lib/docker/overlay2 -namelower-type f|xargsgrep-llocal-ai# 查看层关联cat/var/lib/docker/image/overlay2/layerdb/mounts/*/mount-id2. 使用 dive 工具可视化# 安装 divedockerrun --rm -it\-v /var/run/docker.sock:/var/run/docker.sock\wagoodman/dive:latest localai/localai:latest-gpu-nvidia-cuda-123. 文件系统事件监控# 在容器运行时监控文件访问dockerrun --rm -it\--pidcontainer:local-ai\--cap-add SYS_PTRACE\alpinesh-capk add strace strace -p 1 -e tracefile常见问题解答Q1: 为什么我的文件修改在容器内看不到A: 检查 Windows 到 WSL 的文件系统同步可能需要重启 Docker Desktop 或 WSL。Q2: 如何清理这些临时文件A: 使用docker system prune -a清理但注意这会删除所有未使用的资源。Q3: 这两个目录哪个是真实的A: 都不是真实的数据存储位置。你的真实数据在 Windows 的 D:/localai-data/ 目录中。Q4: 如何提高文件访问性能A: 考虑将数据放在 Linux 文件系统中或使用 Docker 卷而非绑定挂载。总结通过深入分析这两个路径我们可以理解 Docker Desktop 的复杂存储架构分层管理Docker 使用多层存储镜像层、容器层、挂载层运行时抽象Containerd 和 Docker 守护进程协同工作挂载覆盖绑定挂载会覆盖容器内的原始目录性能优化理解架构有助于优化存储性能对于大多数开发者关键要点是理解你的数据实际存储位置使用适当的挂载方式定期清理不再使用的存储资源监控存储使用情况掌握这些底层知识可以帮助你更有效地使用 Docker并能在出现问题时快速定位和解决存储相关问题。