Docker Desktop实战、问题记录
概述
在Windows 10/11安装WSL和Docker Desktop，提到过Docker Desktop的安装，以及Docker Desktop与WSL的关系。
本文重点关注于Windows下Docker Desktop使用过程中遇到的问题。
切换目录
默认情况下，Docker Desktop安装在宝贵的C盘，且没有提供安装配置选项，安装成功后也没有配置入口。如何迁移到其他盘？
操作步骤：
- 退出Docker Desktop；
- 移动文件夹
C:\Program Files\Docker到其他地方； - 创建符号链接：以管理员身份打开命令提示符并执行
mklink /D "C:\Program Files\Docker" "D:\Program\Docker"； - 移动数据目录：
mklink /D "C:\Users\johnny\AppData\Local\Docker" "D:\Program\Docker\Data"
出现上述报错，请检查是否已经将源文件夹彻底移动到目标文件夹，并确保源文件夹不再存在。
出现报错：
请退出WSL子系统。
成功是这样的输出：
关闭容器组自启动
本地部署好几个应用（容器组）
启动Docker Desktop时，会自动启动容器组，带来的困扰：
- Docker Desktop启动非常慢；
- 占用内存、CPU等资源非常高。
需求：Docker Desktop启动时不自动启动这些容器，只在需要时手动启动。
在Docker Desktop界面里并没找到设置入口，事实上部分容器组会自启动，其他容器组则不会；看来和docker-compose.yml文件有关。
比如coze-studio分组下面的所有容器自动重启，查看本地\coze-studio\docker\docker-compose.yml，果然所有的服务都是restart: always。
--restart支持的配置枚举值：
no：默认值。容器退出时不会自动重启；on-failure[:max-retries]：只有容器以非 0 状态码退出时才重启。可选设置最大重试次数，如on-failure:3；always：无论以何种状态退出，总是重启容器，包括手动docker stop后Docker重启时也会重新启动；unless-stopped：总是重启容器，除非容器被手动停止（docker stop或docker compose down）。即使 Docker 重启，也会自动启动；
直接删除该行配置，或修改为restart: unless-stopped。
容器分组
还是上面的截图，可看到在docker目录（分组）下有好几个应用：ragflow、supersonic，这样太混乱；没法在Docker Desktop界面上一键启动、停止、重启。
能不能分组展示，和coze-studio一样？
解决思路：参考coze-studio的docker-compose.yml，在docker-compose.yml文件首行新增name: ragflow。
遇到的小问题：
如果已经通过docker compose up -d启动好容器组，此时修改docker-compose.yml新增name: FastGPT，执行docker compose down失败，不能停止容器：
撤销修改，执行docker compose down，修改docker-compose.yml，再执行docker compose up -d，Docker Desktop效果：
另外，Docker Desktop会忽略驼峰命名，改为纯小写。
更大的问题：在执行docker compose up -d之前，若没有提前设置好name信息，则修改name无效。因为这个容器组名称信息已写入到Docker Desktop的配置文件里，在本地安装目录一个个配置文件打开并查看并没有找到相关的配置信息，官方文档也没找到相关说明，GPT也是乱答一气。
绕过问题的方法：删除镜像，重新执行docker compose up -d，分组成功的效果：
镜像分组
抱歉，官方并没有这个功能。比如FastGPT会使用Redis，RAGFlow也要使用Redis。而Redis的分发包不要太多，有官方的Redis（即docker.io/redis），也有其他组织维护的Redis（如bitnami/redis）；估计是这个原因，导致Docker Desktop没办法对镜像进行分组维护。
本地git pull更新代码后，执行docker compose up -d，会重新下载最新版镜像文件，导致出现如下问题：
即本地会有多个不同版本（即标签Tag）的镜像。
只能手动删除不需要的低版本镜像：
新版本Docker Desktop在持续优化性能，解决Bug，优化界面交互，比如下面不同颜色的镜像：
然后呢，官方又使用一个超大文件（咋想的？？）管理所有的容器和镜像，非常不利于容器和镜像管理。
并且在手动删除部分低版本镜像后，上述VHDX文件并没有减小，这意味着我本地磁盘迟早会用尽。重启Docker Desktop之后，还是这么大！
再看看本地磁盘文件：
再去看看专门用于提交问题（Bug、Issue）的GitHub，多达1.4K！
VHDX
VHDX，Virtual Hard Disk v2，微软开发的第二代虚拟硬盘文件格式，主要用于虚拟化环境和原生启动场景。最大支持64TB存储容量。通过更新VHDX元数据，可提供电源故障期间的数据保护机制，并优化动态扩展磁盘与差异磁盘的结构对齐方式以适配现代硬件（可在大型扇区磁盘上更好地工作）。VHDX支持在物理硬件上直接启动OS（原生启动），无需依赖虚拟机或Hypervisor。
其文件类型包含固定、动态和差异三种虚拟硬盘，其中差异磁盘支持通过父子结构实现备份快照功能。测试显示固定类型相比动态类型在连续写入性能上具有优势，且动态类型可节省存储空间。该格式还可通过SCSI控制器实现运行时磁盘容量调整，但动态硬盘不建议用于生产环境服务器。
VHDX最初于2012年随Windows Server的Hyper-V组件发布，旨在应对企业级虚拟化存储需求。文件格式规范历经多次修订，最新8.0版于2024年4月发布。早期Windows版本不支持该格式，可通过PowerShell命令实现与VHD格式的转换。
docker compose报错
智谱chat给出的分析：
正在尝试连接到192.168.99.100:2376，这是一个典型的Docker Machine（使用VirtualBox驱动）配置，而不是Docker Desktop的默认配置。
可能之前安装或使用过Docker Toolbox（包含Docker Machine）
打开控制面板，果然：
命令docker context ls输出：
解决方法：
- 卸载Docker Toolbox
- 切换到Docker Desktop上下文：
docker context use desktop-linux，不管用。
卸载Docker Toolbox，再次执行docker compose up -d，还是有报错：
GPT分析：
Docker客户端仍在尝试使用Docker Machine的配置文件，需要彻底清理Docker配置，确保它使用Docker Desktop而不是Docker Machine。
解决方法步骤：
- 删除
\.docker\machine目录 - 检查并清除Docker环境变量，包括：DOCKER_HOST、DOCKER_CERT_PATH、DOCKER_TLS_VERIFY、DOCKER_MACHINE_NAME。
删除环境变量后，重新打开CMD窗口：
重置Docker Desktop
卸载重新安装。
Docker Desktop启动异常
不管是启动普通启动，还是以管理员身份启动，任务管理器里找不到Docker进程。
找到日志：C:\Users\johnn\AppData\Local\Docker\backend.error.json。
如果文件非常大，不能直接使用Sublime Text打开，需要截止于tail或cat命令行。
实际上都需要查看日志，检查一下配置文件，大概率是daemon.json文件配置有误，不满足JSON格式。
docker version
输入docker version命令：
GPT答复Docker Desktop依赖WSL2，WSL异常会导致引擎无法启动。
重试，一切正常：
检查WSL发行版：
切换为docker-desktop：
还是不行。
解决方法：重启Docker Desktop。
如果不行，多试几次；或直接重启Windows电脑。
服务停止异常
点击服务组Stop按钮：
停止异常，报错信息：
使用终端命令docker compose down，也是同样的报错：
原因分析：同上，还是后端引擎异常导致，重启Docker Desktop。
删除容器
