Windows 8.1系统下Docker启动失败无法创建容器问题咨询

starting docker_web_1 ... done Attaching to docker_web_1 web_1  | Watching for file changes with StatReloader web_1  | Performing system checks... web_1  | web_1  | System check identified no issues (0 silenced). web_1  | November 09, 2022 - 15:29:41

日志输出到上述时间节点后即提示服务启动失败。

首先纠正一个判断偏差：从给出的日志看，容器已经创建并启动成功，不存在容器创建失败的问题。日志打印starting docker_web_1 ... done Attaching to docker_web_1说明docker已经完成容器初始化，进入容器内进程的启动流程，故障出在容器内Django服务启动的最后阶段，和容器创建流程无关。

Windows 8.1系统本身和Docker的适配存在硬缺陷：
Windows 8.1不支持当前主流版本的Docker Desktop，只能使用早已停止维护的Docker Toolbox方案，底层靠VirtualBox虚拟机实现虚拟化，端口转发、文件挂载的兼容性问题非常多。
结合日志停在Django输出启动时间戳的节点（正常流程下这一步之后会打印开发服务器的监听地址），故障基本是两类原因导致：

• 端口映射异常：在docker-compose中配置的服务映射端口（默认一般是8000）要么被宿主机其他进程占用，要么VirtualBox的端口转发规则配置错误，宿主机和Docker虚拟机之间的网络链路不通，导致服务启动时绑定端口失败
• 文件挂载兼容问题：Docker Toolbox靠VirtualBox共享文件夹实现宿主机代码目录和容器的挂载，Windows 8.1下共享文件夹经常出现文件锁、权限不匹配的bug，而日志里的StatReloader是Django的文件热重载监听进程，需要实时读取挂载目录的文件变动，挂载异常时会直接卡死进程，且不会抛出常规错误日志。

• 先排除代码本身问题：执行docker exec -it docker_web_1 bash进入运行中的容器，手动执行python manage.py runserver 0.0.0.0:8000，如果容器内部能正常启动、可以通过curl访问到服务，就可以确认代码和镜像本身没有问题。
• 排查端口冲突：先执行netstat -ano | findstr "你配置的服务映射端口"，确认宿主机没有其他进程占用对应端口；也可以直接把docker-compose里的端口映射改成18000这类不常用端口，重启容器验证。
• 绕过挂载兼容bug：如果调整端口后还是启动失败，先把docker-compose里的本地目录挂载配置注释掉，把代码直接COPY进镜像构建，若此时启动正常，就可以确认是VirtualBox共享文件夹的兼容问题。临时解决方案是启动Django服务时加上--noreload参数，关闭StatReloader文件热重载功能，直接避开挂载点的文件监听逻辑；长期方案是给VirtualBox升级对应版本的增强包，修复共享文件夹的权限bug。

补充提示：Windows 8.1和Docker Toolbox都已经停止官方维护，这类底层兼容问题没有彻底的修复方案，长期运行Docker服务建议升级到Windows 10及以上版本，使用WSL2后端的Docker Desktop，稳定性会有明显提升。

内容的提问来源于stack exchange，提问作者amirhimiii