Packer构建AWS AMI时SSH连接失败问题分析与解决

问题背景

在使用Packer工具构建Amazon EKS优化版Amazon Linux 2 AMI时，开发人员遇到了SSH连接被拒绝的问题。具体表现为Packer在尝试通过SSH连接到临时EC2实例时，反复出现"connection refused"错误，最终导致构建过程失败。

错误现象分析

从日志中可以观察到几个关键错误点：

1. SSH连接被拒绝：Packer尝试连接到实例的22端口时收到"connection refused"响应，表明SSH服务可能未正常运行或网络配置存在问题。

2. HTTP重定向问题：在安装过程中，系统尝试下载某些组件时遇到"301 Moved Permanently"错误，但未提供重定向位置，导致下载失败。

3. 连接超时：在多次重试后，连接最终因i/o timeout而彻底失败。

根本原因

经过分析，这个问题主要由以下几个因素共同导致：

1. SSH服务启动延迟：在实例启动后，SSH服务可能需要额外时间才能完全启动并接受连接。Packer默认的重试机制可能不足以等待服务完全就绪。

2. 网络配置问题：如果实例位于私有子网中且没有配置正确的安全组规则，可能导致SSH连接无法建立。

3. 实例初始化过程：特别是在执行重启操作后，系统需要额外时间重新初始化网络服务和SSH守护进程。

解决方案

针对这个问题，可以采取以下几种解决方案：

1. 调整SSH连接参数

在Packer配置中增加以下参数可以显著提高连接成功率：

"ssh_pty": true,
"ssh_timeout": "10m",
"ssh_handshake_attempts": 30,
"ssh_clear_authorized_keys": true

这些参数会：

• 启用伪终端，改善交互式会话
• 延长SSH超时时间
• 增加握手尝试次数
• 清除已有授权密钥，避免密钥冲突

2. 优化实例启动等待策略

在关键操作（如系统重启）后增加等待时间：

{
  "type": "shell",
  "inline": ["sudo reboot"],
  "expect_disconnect": true,
  "pause_after": "120s"
}

将pause_after从90秒增加到120秒，给系统更充分的恢复时间。

3. 使用Session Manager连接

对于位于私有子网中的实例，可以考虑使用AWS Session Manager作为连接方式：

"ssh_interface": "session_manager"

这种方式不需要直接暴露SSH端口，通过AWS Systems Manager建立安全连接。

4. 检查安全组配置

确保临时安全组包含以下规则：

• 允许来自构建主机的SSH访问（TCP 22）
• 允许必要的出站连接以下载组件

最佳实践建议

1. 分阶段验证：将构建过程分为多个阶段，在每个关键步骤后添加验证点。

2. 详细日志记录：启用Packer的详细日志记录，便于诊断问题。

3. 渐进式超时设置：根据网络环境和实例类型调整超时参数。

4. 资源清理：确保在构建失败时正确清理临时资源，避免资源泄漏。

总结

Packer构建过程中的SSH连接问题通常是由多种因素共同导致的。通过合理配置连接参数、优化等待策略和使用适当的连接方式，可以显著提高构建成功率。特别是在自动化CI/CD流水线中，这些优化措施对于保证构建过程的可靠性至关重要。