SAM应用中PackageType:Image与build --use-container的区别

别把sam build --use-container和镜像部署模式混为一谈，二者根本不是一个层面的配置：

• sam build --use-container 纯粹是构建环节的可选参数：不管你最终交付zip包还是容器镜像，开这个参数只是让SAM拉取和Lambda官方运行时完全一致的容器，在容器内部执行依赖安装、代码编译操作，避免本地Node/Python版本和Lambda运行时不兼容导致的运行错误。你之前用PackageType: Zip的时候开这个参数，SAM确实是直接读模板里的Runtime: nodejs14.x字段，自动匹配对应版本的官方构建镜像，全程不需要你自己写Dockerfile，构建完成输出的还是标准zip部署包。
• PackageType: Image是最终交付产物类型的配置：选这个模式时，你最终推送到仓库、部署到Lambda的是自定义容器镜像，不是zip包，所以模板里不允许配置Runtime/Handler/Layers字段——这些配置全部转移到你自己编写的Dockerfile里，你需要在Dockerfile里指定基础镜像、拷贝业务代码、定义函数启动入口（对应原来Handler的作用）。模板里的ImageUri是镜像最终要推送的ECR仓库地址，Metadata字段是给SAM用来定位Dockerfile路径、指定构建目标用的。

你之前单账号zip模式的流水线不能直接切镜像部署，要调整这几个配置：

• 把模板里对应函数的PackageType从Zip改成Image，删除原有Runtime/Handler/Layers配置，补上ImageUri和Metadata字段，每个函数配套编写对应的Dockerfile
• 重新执行sam pipeline bootstrap时选择镜像部署选项，引导流程会自动为每个阶段/账号配置ECR仓库的跨账号访问权限——镜像模式下每个账号的Lambda必须从本账号的ECR拉取镜像，这部分权限不需要手动编写IAM策略，引导流程会自动完成配置

你提到的两种配置方式作用阶段、生效范围完全不同，选错了会导致环境变量根本不生效：

• 在gitlab-ci.yml构建脚本中加--container-env-var-file：这个参数仅在sam build构建阶段生效，传入的环境变量只提供给执行构建操作的容器使用，比如构建时需要访问私有npm源、注入代码提交版本号这类仅构建环节需要的值，用这个参数。这些变量不会被打包到最终部署产物里，Lambda函数运行时完全读不到。
• 在samconfig.toml的配置段指定环境文件：注意不要把运行时环境变量配到[*.build.parameters]段下，这个段的配置和命令行传给build命令的参数效果完全一致，只在构建阶段生效。如果是不同环境的数据库连接地址、业务密钥这类函数运行时需要读取的变量，要配置到对应环境的[*.deploy.parameters]段，通过--env-vars参数指定对应环境的json文件，这些配置会在部署阶段写入Lambda函数的环境变量配置，运行时可正常读取。

多账号场景下的推荐配置方案：

• 构建环节需要的变量（比如私有依赖源认证信息），所有环境通用，直接在gitlab-ci的构建步骤中通过--container-env-var-file指定统一的构建环境文件即可
• 不同账号/环境差异化的运行时配置，按环境拆分env-dev.json/env-prod.json，在samconfig.toml对应环境的deploy配置段中关联对应文件，部署时SAM会根据当前选择的阶段自动加载对应配置，不需要在流水线脚本里写分支判断逻辑。

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