Autoware项目ARM64架构Docker构建中的磁盘空间问题分析与解决

问题背景

在Autoware项目的持续集成流程中，ARM64架构的Docker镜像构建工作流频繁出现"磁盘空间不足"的错误。这一问题主要发生在使用AWS自托管运行器的ARM64架构环境中，与GitHub托管的AMD64运行器相比，ARM64运行器的可用磁盘空间明显不足。

问题现象分析

通过对比两种运行环境的磁盘使用情况，我们发现：

1. AMD64平台（GitHub托管运行器）

   • 初始状态：73GB总空间，已用52GB，剩余22GB
   • 执行清理后：剩余空间提升至53GB

2. ARM64平台（AWS自托管运行器）

   • 初始状态：97GB总空间，已用56GB，剩余41GB
   • 执行清理后：剩余空间仍为41GB，清理效果不明显

根本原因

深入调查后发现，问题主要由以下几个因素导致：

1. Docker构建缓存积累

   • 多个buildx构建缓存卷占用大量空间（单个缓存卷可达9GB）
   • 旧版Docker镜像、容器和卷未被及时清理

2. 工作目录残留

   • 多次构建后工作目录中积累了多个版本的代码仓库
   • 单个工作目录占用空间可达7GB

3. ARM64构建特殊性

   • ARM64架构的交叉编译和模拟构建会产生更多中间文件
   • 相比原生AMD64构建，需要更多临时空间

解决方案

针对上述问题，我们实施了多层次的解决方案：

1. 基础设施扩容

   • 将AWS EBS卷从100GB扩容至200GB
   • 实际可用空间提升至194GB

2. 构建环境清理优化

   • 定期清理Docker构建缓存和残留卷
   • 实现工作目录的自动清理机制
   • 在作业前后执行预定义清理脚本

3. 监控机制建立

   • 实施磁盘空间使用监控
   • 设置预警阈值，防止空间再次耗尽

实施效果

扩容后，ARM64运行器的磁盘使用情况显著改善：

• 总空间：194GB
• 已用空间：23GB
• 剩余空间：171GB
• 使用率：12%

即使在构建最耗资源的CUDA相关作业时，也能顺利完成，不再出现空间不足的问题。

经验总结

1. ARM64构建环境特殊性：需要比AMD64环境预留更多磁盘空间
2. 缓存管理重要性：构建缓存既能加速构建，也可能成为空间消耗的主要因素
3. 预防性维护：定期清理比被动响应更有效
4. 监控先行：资源使用监控应作为CI/CD环境的基础设施

这一问题的解决不仅保障了Autoware项目ARM64架构的持续集成流程，也为其他面临类似问题的开源项目提供了有价值的参考案例。