Azure容器应用作业出现‘no space left on device’错误，如何扩展容器存储空间？

我太懂你这种明明做了空间优化却还是碰到底线的憋屈了——浅克隆、用完就删临时文件夹都安排上了，结果还是栽在空间不足上，确实闹心。结合Azure容器应用的特性，给你几个实际可行的解决方向：

1. 直接调整容器的临时存储配额 #

你当前用的是消费计划，虽然配置了8Gi内存，但容器的**临时存储（Ephemeral Storage）**和内存是分开配额的，默认上限通常比较小（比如几个Gi），大概率是这个限制卡了你。

你可以在Azure门户里操作：

• 找到你的容器应用作业，进入配置 -> 容器页面
• 选中你正在使用的容器，找到存储配置项
• 在这里可以手动设置临时存储的大小（比如调到16Gi甚至更大，根据你最大的那个Repo预估大小来定）
• 保存配置后重新触发作业，容器就能获得更大的临时存储空间了

2. 挂载Azure文件共享作为外部存储 #

如果单个Repo的大小已经远超临时存储能调整的上限，那不如把Repo克隆到外部存储里，完全避开容器本身的空间限制：

• 先创建一个Azure存储账户，在里面新建一个文件共享
• 回到容器应用作业的配置页面，添加一个卷，类型选择Azure文件共享，关联你刚创建的共享，指定容器内的挂载路径（比如/mnt/repo-storage）
• 修改你的克隆脚本，把Repo克隆到这个挂载路径下，扫描完成后删除对应的目录即可
  这种方式的好处是存储容量可以按需扩容，而且多个作业实例（如果有的话）还能共享这个存储（当然要注意并发冲突）

3. 再压榨一下克隆和扫描的空间效率 #

你已经用了--depth 1，但还有几个参数可以进一步缩小克隆的体积：

• 加上--filter=blob:none：跳过Repo里的所有二进制大文件（如果你的代码扫描不需要这些文件的话，这个参数能省超多空间）
• 加上--single-branch：只克隆当前需要的分支，避免拉取其他分支的内容
  另外，扫描的时候可以试试边扫边删——比如扫描完某个子目录就立刻删除该目录，不用等整个Repo扫描完再一次性删除，能实时释放空间

4. 排查容器内的“隐形”空间占用 #

有时候空间不够不一定是Repo的锅，容器里还有其他地方在偷偷占空间：

• 日志文件：容器的stdout/stderr日志如果没做限制，积累多了也会占空间。可以在容器应用的监控 -> 日志配置里，设置日志的保留时间或大小上限
• 扫描工具的缓存：有些代码扫描工具会生成缓存文件，你得确认这些缓存是不是被放到了临时文件夹里一起删除，或者手动清理缓存目录
• 系统临时文件：容器内的/tmp目录（和你自己建的tmp不同）如果没清理，也可能积累垃圾，可以在脚本开头加一句rm -rf /tmp/*来清理

备注：内容来源于stack exchange，提问作者MarcBrejner