在GitHub Actions中构建CDK NodejsFunction时遇文件找不到错误
1. 解决cp: cannot stat '/asset-input/collector.yml'错误
原因:你设置了projectRoot: "../server",bundling时的inputDir指向../server目录的内容,而collector.yml和otel-config.js存放在CDK根目录,因此无法找到文件。
解决方法:修改beforeBundling中的复制路径,直接从CDK根目录复制文件到输出目录(CDK执行bundling时的工作目录为CDK项目根):
commandHooks: { beforeBundling(inputDir: string, outputDir: string): string[] { const cdkRoot = process.cwd(); return [ `cp ${cdkRoot}/collector.yml ${outputDir}`, `cp ${cdkRoot}/otel-config.js ${outputDir}`, ]; }, afterBundling(): string[] { return []; }, beforeInstall() { return []; }, }
或者,将collector.yml和otel-config.js移动到../server目录下,保持原复制命令不变。
2. 优化Docker部署繁琐的问题
本地M1(ARM64)可原生运行部署,避免Docker容器的优化方案:
本地开发构建
设置bundling.local: true,让CDK使用本地安装的esbuild而非Docker容器,前提是本地已安装esbuild(执行npm install -g esbuild或添加到项目依赖):
bundling: { local: true, // 启用本地构建 keepNames: true, nodeModules: ["graphql", "pino", "@opentelemetry/auto-instrumentations-node"], // ...其他配置 }
注意:若部署到X86_64架构Lambda,本地ARM64构建的包会不兼容,此时建议切换回ARM64架构Lambda(适配M1,性能更优、成本更低),并确保OTel层为ARM64版本(你当前使用的层ARN已适配ARM64)。
GitHub Actions CI/CD构建
在CI中使用对应架构的Runner,避免Docker:
- 部署ARM64 Lambda:使用
ubuntu-22.04-arm64Runner,原生构建ARM64包。 - 部署X86_64 Lambda:使用
ubuntu-latestRunner,原生构建X86_64包。
示例GitHub Actions片段:
jobs: deploy: runs-on: ubuntu-22.04-arm64 # 对应ARM64架构 steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 18 - run: npm install - run: npx cdk deploy --require-approval never
3. 架构切换建议(ARM64 vs X86_64)
你之前从ARM64切换到X86_64大概率是因为层不兼容:当前代码中使用的OTel层为ARM64版本(ARN含arm64),但架构设为X86_64,导致层无法在Lambda上运行。
切换回ARM64架构(推荐M1用户)
- 将
architecture改回lambda.Architecture.ARM_64。 - 保留当前的ARM64 OTel层ARN,已适配架构。
- 启用本地构建(
bundling.local: true),本地M1可原生构建,无需Docker,效率更高。
继续使用X86_64架构
需替换为X86_64版本的OTel层ARN,例如:
lambda.LayerVersion.fromLayerVersionArn( this, "otel-layer", `arn:aws:lambda:eu-central-1:901920570463:layer:aws-otel-nodejs-amd64-ver-1-17-1:1` )
(将ARN中的arm64替换为amd64)
内容的提问来源于stack exchange,提问作者James Maguire

