SST项目中自定义域名与外部DNS配置问题解析

问题背景

在使用SST(Serverless Stack)框架部署服务时，开发者经常需要为服务配置自定义域名。当域名托管在第三方DNS服务商(如Google Domains)而非AWS Route 53时，配置过程可能会遇到一些挑战。本文将通过一个实际案例，分析配置过程中出现的问题及其解决方案。

案例描述

开发者尝试为一个基于Deno的简单应用配置自定义域名"sst-external.jarodriguez.ca"，该域名托管在Google Domains。按照SST官方文档，开发者使用了以下配置：

new sst.aws.Service("JorgeService", {
  cluster,
  loadBalancer: {
    domain: {
      name: "sst-external.jarodriguez.ca",
      dns: false,
      arn: "arn:aws:acm:us-east-1:<account_id>:certificate/<certificate_id>"
    },
    ports: [{ listen: "80/http", forward: "8000/http" }],
  },
  dev: {
    command: "deno task dev",
  },
});

遇到的问题

部署时出现错误："Cannot read properties of undefined (reading 'provider')"。错误指向SST内部处理DNS验证证书的代码部分。这表明即使设置了dns: false，系统仍尝试使用AWS DNS服务进行域名验证。

问题分析

深入分析后发现，问题根源在于配置参数的使用错误。开发者错误地使用了arn参数来指定证书ARN，而实际上SST框架期望的参数名是cert。这是一个常见的参数命名混淆问题。

正确配置方式

正确的配置应该如下所示：

domain: {
  name: "sst-external.jarodriguez.ca",
  dns: false,
  cert: "arn:aws:acm:us-east-1:<account_id>:certificate/<certificate_id>"
}

技术要点

1. 证书验证流程：当使用外部DNS时，AWS ACM证书需要手动完成DNS验证。开发者需要在DNS提供商处添加指定的CNAME记录。

2. 参数命名规范：SST框架对参数命名有特定要求，与AWS原生服务的参数命名可能有所不同，需要仔细查阅文档。

3. DNS验证状态：在AWS控制台中，证书状态会显示为"Pending validation"，直到DNS记录被正确配置并传播。

最佳实践建议

1. 始终仔细检查参数名称，特别是涉及证书和DNS配置时
2. 在配置外部DNS时，准备好手动添加验证记录
3. 部署前先确认证书在ACM中的状态
4. 使用SST的最新稳定版本以避免已知问题

总结

这个案例展示了在使用SST框架配置自定义域名时的一个常见陷阱。通过理解框架的参数命名约定和证书验证流程，开发者可以更高效地完成服务配置。记住，当遇到类似问题时，仔细检查错误信息和参数名称往往是解决问题的第一步。