如何在GitLab CI Kubernetes runner中用sam local invoke测试带Layer的AWS Lambda

可行方案如下： #

• 方案1：挂载Docker Socket（无dind，配置最简单）
  你当前用的Kubernetes GitLab Runner不需要启用dind，只需要在Runner配置中给CI Job容器挂载宿主机的/var/run/docker.sock文件即可。SAM CLI内部调用Docker时会直接使用宿主机的Docker守护进程，不需要在CI容器内再运行Docker服务。
  仅需要在你预装的debian:buster构建镜像中补充安装Docker客户端即可，不需要额外修改项目代码，你本地的测试配置可以直接复用。
  注意：如果Runner的宿主机Docker版本过新，需要确保容器内的Docker客户端版本和宿主机版本兼容。

• 方案2：预下载Lambda Layer（无Docker依赖，性能最优）
  如果你不需要完全模拟Lambda的运行环境，只是要解决Layer依赖无法获取的问题，可以跳过sam local invoke直接在CI容器内运行测试：

  1. 给CI Job配置有权限访问Lambda服务的AWS凭证
  2. 执行命令拉取指定版本的Layer包：

  # 获取Layer下载链接
  LAYER_URL=$(aws lambda get-layer-version-by-arn --arn arn:aws:lambda:us-east-1:<account#>:layer:MyLayer:1 --query Content.Location --output text)
  # 下载并解压到Python依赖目录（对应Python Layer的标准路径）
  curl $LAYER_URL -o layer.zip && unzip layer.zip -d ./python
  # 将Layer路径加入Python环境变量
  export PYTHONPATH="$PYTHONPATH:$(pwd)/python"
  

  3. 直接在CI容器内运行pytest ./tests即可，不需要用到SAM和Docker，执行速度更快。如果是Node.js等其他运行时的Layer，调整解压路径到对应运行时的依赖加载目录即可。

• 方案3：使用官方dind服务（无Runner全局配置修改，灵活性最高）
  如果你不想修改Kubernetes Runner的全局挂载配置，可以直接在CI Job中启用Docker-in-Docker服务，只需要修改你的.gitlab-ci.yml配置即可，不需要调整Runner本身：

  test:
    image: 你预装依赖的debian:buster镜像
    services:
      - docker:dind
    variables:
      DOCKER_HOST: tcp://docker:2376
      DOCKER_TLS_CERTDIR: "/certs"
    script:
      - sam local invoke -t samtemplate_tests.yaml
  

  该方案不需要你掌握复杂的dind配置，直接复用GitLab CI官方的dind服务模板即可，第一次运行需要拉取Docker镜像，配置缓存后后续执行速度和本地运行一致。

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