Docker-Magento项目中的docker-stats脚本问题分析与修复

问题背景

在Docker-Magento项目中，bin/docker-stats脚本用于监控容器资源使用情况。近期该脚本在执行时出现了"Error response from daemon: page not found"的错误提示。这个问题源于一次针对shellcheck规范的代码修改，导致脚本行为发生了变化。

问题分析

该问题的根本原因是脚本中对docker stats命令的参数传递方式不当。在修复shellcheck警告时，将原本的docker stats $container_ids修改为了docker stats "$container_ids"，这种引号包裹的方式会导致所有容器ID被当作一个整体参数传递，而非多个独立参数。

技术细节

1. 错误现象：当使用引号包裹容器ID变量时，Docker CLI会将这些ID视为一个整体，尝试查找名为"container1 container2..."的单个容器，自然会导致"page not found"错误。

2. 正确用法：在shell脚本中，当需要将多个参数传递给命令时，应该避免对整个变量加引号，这样shell会自动进行单词分割(word splitting)，将变量内容拆分为多个参数。

3. shellcheck兼容性：虽然不加引号的方式能正常工作，但会触发shellcheck的SC2086警告（"Double quote to prevent globbing and word splitting"）。这是一个典型的shell脚本编写时需要权衡的情况。

解决方案

项目维护者最终采用了以下修复方案：

docker stats $container_ids

这种写法：

• 解决了"page not found"错误
• 恢复了脚本原有功能
• 虽然会触发shellcheck警告，但在这种特定场景下是必要的

功能演进讨论

在问题解决过程中，还引发了关于脚本输出格式的讨论。最初版本只显示CPU和内存使用情况，而修复后的版本会显示更全面的容器信息，包括：

• 容器ID和名称
• CPU使用率
• 内存使用量和限制
• 网络I/O
• 块I/O
• 进程数

经过讨论，项目决定后续将脚本输出简化为仅显示CPU和内存信息，因为这些是开发者最关心的核心指标，其他信息对于日常开发监控来说可能过于冗余。

最佳实践建议

1. 在编写shell脚本时，要特别注意变量引用的场景
2. 对于需要传递多个参数的情况，要谨慎使用引号
3. 当shellcheck警告与实际需求冲突时，可以添加注释说明原因
4. 监控脚本的输出应该聚焦于关键指标，避免信息过载

这个案例很好地展示了在软件开发中，规范检查工具与实际需求之间可能存在的冲突，以及如何做出合理的权衡决策。