不使用dotnet-lambda工具构建.NET 8 Lambda镜像遇超时问题排查

我尝试将.NET 8控制台应用构建并部署到AWS Lambda，对应的Dockerfile如下：

FROM public.ecr.aws/lambda/dotnet:8-preview AS base

FROM mcr.microsoft.com/dotnet/sdk:8.0 as build
WORKDIR /src
COPY ["LambdaExample/LambdaExample.csproj", "LambdaExample/"]
RUN dotnet restore "LambdaExample/LambdaExample.csproj"

COPY . .
RUN dotnet build "LambdaExample/LambdaExample.csproj" --configuration Release --output /app/build

FROM build AS publish
RUN dotnet publish "LambdaExample/LambdaExample.csproj" --configuration Release --runtime linux-x64 --self-contained false --output /app/publish -p:PublishReadyToRun=true  

FROM base AS final
WORKDIR /var/task
COPY --from=publish /app/publish .

CMD ["LambdaExample::LambdaExample.Function::FunctionHandler"]

使用dotnet lambda deploy-function部署后，Lambda在AWS上可正常运行；但通过GitLab流水线执行docker build构建镜像并推送到ECR，再基于该镜像创建Lambda函数时，测试出现超时错误：

"errorMessage": "2024-01-24T08:18:16.454Z 8faa9dc0-4971-4d1a-9cd5-f1bce72caeed Task timed out after 3.13 seconds"

流水线构建脚本如下：

script:
    - docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
    - docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

已确认手动创建的Lambda函数与dotnet lambda deploy-function部署的函数使用相同的执行角色和VPC配置，请问还缺少什么配置才能让流水线构建的镜像正常运行？

可以从以下几个方向排查并修复：

• 指定镜像构建平台
  如果GitLab流水线的runner是ARM架构，默认构建的镜像架构会和Lambda要求的x64不匹配，导致函数启动异常超时。修改流水线的构建命令，强制指定x64平台：

  docker build --platform linux/amd64 -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
  

• 调整Lambda的基础配置
  基于镜像创建的Lambda默认超时可能是3秒，而你的函数启动或执行需要更长时间。进入Lambda控制台，把超时时间调高（比如设为10秒），同时可以适当提升内存配置（比如256MB），再测试是否正常。

• 验证镜像入口命令
  虽然Dockerfile里指定了CMD，但构建后的镜像可能存在命名空间或文件路径的偏差。可以本地运行镜像测试入口是否正常，或者在Lambda控制台手动指定处理程序路径，确保和dotnet lambda deploy-function部署的完全一致。

• 清理构建缓存
  GitLab流水线可能复用了旧的构建缓存，导致发布的内容不完整。在构建命令中添加--no-cache参数强制重新构建：

  docker build --no-cache --platform linux/amd64 -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
  

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