Azure自托管VMSS执行Zip操作时因磁盘空间不足失败

问题场景 #

• 使用Azure DevOps构建流水线执行Zip操作时，在自托管Linux VMSS（规格Standard_B8ms，单实例）上因磁盘空间不足失败，错误日志：

adding: Data/address_parser/address_parser_postal_codes.dat (deflated 81%) adding: Data/address_parser/address_parser_vocab.trie(deflated 53%) adding: Data/address_parser/address_parser_crf.dat zip I/O error: No space left on device zip error: Output file write failure (write error on zip file)

• 流水线日志显示初始可用磁盘空间16388MB（总29588MB），最终可用空间降至0MB
• 已尝试的方案：
  1. 配置并运行Azure DevOps维护作业清理运行残留文件
  2. 在ArchiveFiles@2任务中设置replaceExistingArchive: true替换同名归档文件
  3. 配置流水线文件清理选项
  4. 为VMSS添加第二块数据磁盘供流水线使用

排查与解决思路 #

1. 修正Zip操作的磁盘路径指向 #

Linux下zip命令默认在当前工作目录生成临时文件，若$(System.DefaultWorkingDirectory)或$(Build.ArtifactStagingDirectory)仍挂载在系统盘，新增的数据磁盘不会被用到：

• 修改ArchiveFiles@2任务的archiveFile路径到数据磁盘挂载目录，例如：

  - task: ArchiveFiles@2
    condition: ne(variables['Build.Reason'], 'PullRequest')
    displayName: 'Archive files - ABC Function'
    inputs:
      rootFolderOrFile: '$(System.DefaultWorkingDirectory)/publish_output_abc_func'
      includeRootFolder: false
      archiveType: zip
      archiveFile: '/mnt/data_disk/$(Build.BuildId)_abc_func.zip'
      replaceExistingArchive: true
  

• 同步调整构建输出、临时文件等目录到数据磁盘，避免系统盘被持续占用

2. 分析Zip压缩的空间消耗逻辑 #

Zip压缩过程会先生成未压缩的临时文件再压缩，临时文件大小接近源文件总大小，需确认空间是否足够：

• 在流水线中添加脚本任务，执行du -sh $(System.DefaultWorkingDirectory)/publish_output_abc_func查看源文件总大小，判断剩余空间是否能容纳临时文件+最终压缩包（通常需要源文件大小的1.5-2倍空间）
• 若源文件过大，改用7z等工具替代原生zip，这类工具支持边压缩边写入，临时空间占用更小

3. 强化VMSS的磁盘清理策略 #

检查现有清理机制的覆盖范围，补充遗漏的缓存目录：

• 添加构建前清理脚本，清理Azure DevOps代理工作目录的旧构建文件：

  rm -rf $(System.DefaultWorkingDirectory)/_work/*
  rm -rf /tmp/*
  rm -rf /var/tmp/*
  

• 配置Azure DevOps代理自动清理，在代理配置文件config.sh中添加--cleanup参数，自动删除超过保留期的工作区

4. 验证数据磁盘的挂载与权限 #

确认新增的数据磁盘已正确配置：

• 执行df -h查看磁盘挂载状态，确保数据磁盘挂载到流水线可访问的目录（如/mnt/data_disk）
• 调整目录权限，确保Azure DevOps代理用户（默认vstsagent）拥有读写权限：

  chown -R vstsagent:vstsagent /mnt/data_disk
  

• 排查系统盘异常占用：执行lsof | grep deleted查看已删除但未释放的文件，重启对应进程释放空间；检查Docker镜像、系统日志等是否占用大量空间

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