dokku Lambda Builder 使用指南在 PaaS 平台上构建与部署 AWS Lambda 函数【免费下载链接】dokkuA docker-powered PaaS that helps you build and manage the lifecycle of applications项目地址: https://gitcode.com/GitHub_Trending/do/dokku本指南围绕 dokku 的builder-lambda插件展开该插件自 0.28.0 起随 dokku 核心发布通过 lambda-builder 在模拟 AWS Lambda 运行时的环境中构建函数。读完本文你将掌握 lambda builder 的自动检测机制、支持的运行时语言、lambda.yml清单的定位与自定义含 monorepo 场景、builder-lambda:set/builder-lambda:report命令的完整用法以及lambdayml-path属性从应用级到全局级的优先级解析原理。插件概览与定位lambdabuilder 是 dokku 众多 builder 中的一员用于构建 AWS Lambda 函数。它本身不实现构建逻辑而是将语言检测、构建与运行时环境规范全部委托给 lambda-builder 这一独立工具完成。从插件元数据可以看到它是 dokku 的核心插件dokku core builder-lambda plugin。通过该 builder 构建的应用既可以原生运行在 Dokku 上也可以在合适的 scheduler调度器配合下将其构建产物调度到 Lambda 上执行——也就是说构建builder与调度scheduler是解耦的两层。插件对外暴露两个核心子命令builder-lambda:report [app] [flag] # Displays a builder-lambda report for one or more apps builder-lambda:set app key (value) # Set or clear a builder-lambda property for an app检测机制何时自动启用 lambda builder该 builder 会在以下情况被自动检测auto-detected应用仓库根目录下存在lambda.yml文件。这一检测逻辑的底层实现在检测触发器中其核心判断非常简单直接if [[ -f $SOURCECODE_WORK_DIR/lambda.yml ]]; then echo lambda return fi也就是说只要源码工作目录中存在lambda.ymlbuilder-detect触发器就会输出lambda从而选中该 builder。当然也可以绕过自动检测手动指定 builder 类型dokku builder:set node-js-app selected lambda自动检测的边界情况需要留意的是lambda.yml的定位受部署方式影响详见下文「Changing thelambda.ymllocation」一节。当使用git:from-image、git:load-image这类基于镜像的部署时lambda.yml位于 Docker 镜像的WORKDIR此时builder-detect检测的源码工作目录路径与普通 git push 场景不同实际生效的路径以最终提取到工作目录中的文件为准。支持的运行时语言lambdabuilder 插件支持以下 AWS 运行时语言构建环境基于Amazon Linux 2语言备注dotnet-gobuilder 基于 AL1Amazon Linux 1nodejs-python-ruby-关于各语言的具体检测方式例如根据package.json、requirements.txt、Gemfile等文件如何判定语言类型请参阅 lambda-builder 文档中 How does it work 章节。dokku 侧只负责把构建环境搭建好并调用 lambda-builder语言识别细节全部由后者承担。自定义构建环境lambda.yml清单lambdabuilder 插件将所有构建逻辑都委托给 lambda-builder包括语言检测以及构建/运行时环境的规格说明。lambda-builder 工具支持一种名为lambda.yml的文件格式用于定制应用的构建方式如运行时版本、内存、超时、环境变量等。具体选项与字段定义请参考 lambda-builder 的 README。lambda.yml是 lambda builder 的入场券——它既是自动检测的依据也是构建配置的载体。从源码结构看该文件的存在与否直接决定 builder 是否被选中其内容则决定 lambda-builder 如何执行构建。更改lambda.yml位置lambdayml-path属性默认搜索位置lambda.yml默认被期望位于特定目录具体取决于部署方式git:from-image与git:load-image命令产生的部署位于 Docker 镜像的WORKDIR。其他所有部署方式git push、git:from-archive、git:sync位于源码树的根目录。monorepo 场景自定义路径有时可能需要为某个应用指定不同的路径例如从 monorepo 部署时lambda.yml并不在仓库根目录。这时可以通过lambdayml-path属性来指定dokku builder-lambda:set node-js-app lambdayml-path .dokku/lambda.yml关于该属性值需要特别强调两点语义始终为相对路径该值是相对于基础搜索目录的路径在任何上下文中都不会被当作绝对路径处理。文件不存在则构建失败如果仓库中不存在该文件构建会失败。从 core-post-extract 触发器的源码可以看到dokku 在代码提取后post-extract 阶段会把计算出的lambda.yml路径统一规整到工作目录根下再交给 lambda-builderlocal NEW_LAMBDA_YML$(fn-builder-lambda-computed-lambdayml-path $APP) ... if [[ ! -f $NEW_LAMBDA_YML ]]; then rm -f lambda.yml return fi if [[ $NEW_LAMBDA_YML ! lambda.yml ]]; then mv $NEW_LAMBDA_YML lambda.yml fi也就是说如果自定义路径指向的文件不存在插件会直接移除根目录的lambda.yml避免误用错误的清单如果文件存在且路径不是默认的lambda.yml则会将其移动到根目录确保后续构建流程读取到的始终是正确清单。清除应用级配置恢复默认通过传入空值可以清除应用级设置恢复默认行为dokku builder-lambda:set node-js-app lambdayml-path全局配置lambdayml-path属性同样支持全局设置。全局默认值是lambda.yml当应用未设置任何值时使用全局值dokku builder-lambda:set --global lambdayml-path lambda2.yml同样传入空值即可清除全局设置dokku builder-lambda:set --global lambdayml-path属性解析优先级computed path从 internal-functions 脚本的fn-builder-lambda-computed-lambdayml-path实现可以看出完整的三级回退逻辑应用级lambdayml-path若已设置全局lambdayml-path若已设置内置默认值lambda.yml。这一逻辑与 Go 侧的 report.go 中reportComputedLambdaymlPath函数完全一致func reportComputedLambdaymlPath(appName string) string { value : reportLambdaymlPath(appName) if value { value reportGlobalLambdaymlPath(appName) } if value { value lambda.yml } return value }builder-lambda:set命令的行为细节从 set 子命令脚本的源码看该命令还会做严格的输入校验当前合法的 key 只有lambdayml-path传入其他 key 会报错Invalid key specified, valid keys include: lambdayml-path未指定 key 会报错No key specified--global作为应用名时跳过应用名校验verify_app_name有值时执行写入fn-plugin-property-write空值时执行删除fn-plugin-property-delete。查看 builder-lambda 报告查看所有应用的报告使用builder-lambda:report命令可以获取应用的相关状态报告dokku builder-lambda:report示例输出 node-js-app builder-lambda information Builder lambda computed lambdayml path: lambda2.yml Builder lambda global lambdayml path: Builder lambda lambdayml path: lambda2.yml python-sample builder-lambda information Builder lambda computed lambdayml path: lambda.yml Builder lambda global lambdayml path: Builder lambda lambdayml path: ruby-sample builder-lambda information Builder lambda computed lambdayml path: lambda.yml Builder lambda global lambdayml path: Builder lambda lambdayml path:上述输出中的三个字段含义如下lambdayml-path应用级的原始值未设置时为空global-lambdayml-path全局值未设置时为空computed-lambdayml-path构建时实际生效的值回退顺序为「应用级 → 全局值若设置→ 内置默认lambda.yml」。这正是前文所述三级回退逻辑在报告中的直观体现node-js-app设置了lambda2.yml应用级覆盖而python-sample、ruby-sample未做任何设置因此 computed 值回退到默认的lambda.yml。查看指定应用的报告也可以针对单个应用运行dokku builder-lambda:report node-js-app示例输出 node-js-app builder-lambda information Builder lambda computed lambdayml path: lambda2.yml Builder lambda global lambdayml path: Builder lambda lambdayml path: lambda2.yml使用 flag 提取单个值可以通过 flag 只输出你关心的特定信息值便于脚本化使用。例如dokku builder-lambda:report node-js-app --builder-lambda-lambdayml-path输出lambda2.yml从 subcommands.go 的 report 入口可以看到report子命令支持--format参数stdout或json并且针对--global场景报告 flag 只开放 computed 与 global 两个字段因为全局范围没有应用级值。而普通应用场景则额外开放--builder-lambda-lambdayml-path。构建与发布阶段的行为builder-release阶段对应构建触发器在BUILDER_TYPE为lambda时执行以下动作依次触发pre-release-lambda已废弃仅向后兼容会输出警告提示改用pre-release-builder与pre-release-builder触发器使用 builder-release.Dockerfile 对已构建镜像执行一次轻量重建仅用于注入 docker labels其中包含com.dokku.image-stagerelease、com.dokku.builder-typelambda、com.dokku.app-name$APP等元数据触发post-release-builder触发器收尾。这意味着 lambda builder 产出的镜像带有明确的 builder 类型标识后续 scheduler 或其他插件可以据此识别这是一个由 lambda builder 构建的产物。安装与数据目录在插件安装阶段见 install 触发器插件会初始化属性存储fn-plugin-property-setup builder-lambda并在DOKKU_LIB_ROOT/data/builder-lambda下创建数据目录。所有builder-lambda:set写入的属性包括全局与应用级都持久化在插件属性系统中这也是builder-lambda:report能跨会话读取到配置的原因。属性速查表Settable propertiesPropertyScopeDefaultReport flagsDescriptionlambdayml-pathapp globallambda.yml--builder-lambda-lambdayml-path,--builder-lambda-global-lambdayml-path,--builder-lambda-computed-lambdayml-path应用内lambda.yml清单的相对路径供 lambda builder 使用典型工作流总结准备清单在应用仓库或 monorepo 子目录中编写lambda.yml声明函数构建所需的运行时与配置。确认检测默认路径下存在lambda.yml即自动选中 lambda builder否则用dokku builder:set app selected lambda手动指定。可选调整路径monorepo 场景用dokku builder-lambda:set app lambdayml-path relative/path指向清单多应用共享配置时用--global设置全局值。验证配置用dokku builder-lambda:report app确认computed lambdayml path是否为期望值。部署执行常规部署git push、git:from-archive、git:sync、git:from-image等构建产物可运行在 Dokku 上也可通过合适的 scheduler 调度到 AWS Lambda。使用限制说明lambda.yml的自定义路径是纯相对路径不会在任何场景下按绝对路径解析且目标文件缺失会导致构建失败自动检测依赖源码工作目录中的lambda.yml而基于镜像的部署git:from-image/git:load-image会从镜像WORKDIR查找两类部署的搜索起点不同各语言具体的构建参数与lambda.yml字段语法由 lambda-builder 工具定义dokku 侧不负责解释需要以 lambda-builder 文档为准。【免费下载链接】dokkuA docker-powered PaaS that helps you build and manage the lifecycle of applications项目地址: https://gitcode.com/GitHub_Trending/do/dokku创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
dokku Lambda Builder 使用指南：在 PaaS 平台上构建与部署 AWS Lambda 函数
dokku Lambda Builder 使用指南在 PaaS 平台上构建与部署 AWS Lambda 函数【免费下载链接】dokkuA docker-powered PaaS that helps you build and manage the lifecycle of applications项目地址: https://gitcode.com/GitHub_Trending/do/dokku本指南围绕 dokku 的builder-lambda插件展开该插件自 0.28.0 起随 dokku 核心发布通过 lambda-builder 在模拟 AWS Lambda 运行时的环境中构建函数。读完本文你将掌握 lambda builder 的自动检测机制、支持的运行时语言、lambda.yml清单的定位与自定义含 monorepo 场景、builder-lambda:set/builder-lambda:report命令的完整用法以及lambdayml-path属性从应用级到全局级的优先级解析原理。插件概览与定位lambdabuilder 是 dokku 众多 builder 中的一员用于构建 AWS Lambda 函数。它本身不实现构建逻辑而是将语言检测、构建与运行时环境规范全部委托给 lambda-builder 这一独立工具完成。从插件元数据可以看到它是 dokku 的核心插件dokku core builder-lambda plugin。通过该 builder 构建的应用既可以原生运行在 Dokku 上也可以在合适的 scheduler调度器配合下将其构建产物调度到 Lambda 上执行——也就是说构建builder与调度scheduler是解耦的两层。插件对外暴露两个核心子命令builder-lambda:report [app] [flag] # Displays a builder-lambda report for one or more apps builder-lambda:set app key (value) # Set or clear a builder-lambda property for an app检测机制何时自动启用 lambda builder该 builder 会在以下情况被自动检测auto-detected应用仓库根目录下存在lambda.yml文件。这一检测逻辑的底层实现在检测触发器中其核心判断非常简单直接if [[ -f $SOURCECODE_WORK_DIR/lambda.yml ]]; then echo lambda return fi也就是说只要源码工作目录中存在lambda.ymlbuilder-detect触发器就会输出lambda从而选中该 builder。当然也可以绕过自动检测手动指定 builder 类型dokku builder:set node-js-app selected lambda自动检测的边界情况需要留意的是lambda.yml的定位受部署方式影响详见下文「Changing thelambda.ymllocation」一节。当使用git:from-image、git:load-image这类基于镜像的部署时lambda.yml位于 Docker 镜像的WORKDIR此时builder-detect检测的源码工作目录路径与普通 git push 场景不同实际生效的路径以最终提取到工作目录中的文件为准。支持的运行时语言lambdabuilder 插件支持以下 AWS 运行时语言构建环境基于Amazon Linux 2语言备注dotnet-gobuilder 基于 AL1Amazon Linux 1nodejs-python-ruby-关于各语言的具体检测方式例如根据package.json、requirements.txt、Gemfile等文件如何判定语言类型请参阅 lambda-builder 文档中 How does it work 章节。dokku 侧只负责把构建环境搭建好并调用 lambda-builder语言识别细节全部由后者承担。自定义构建环境lambda.yml清单lambdabuilder 插件将所有构建逻辑都委托给 lambda-builder包括语言检测以及构建/运行时环境的规格说明。lambda-builder 工具支持一种名为lambda.yml的文件格式用于定制应用的构建方式如运行时版本、内存、超时、环境变量等。具体选项与字段定义请参考 lambda-builder 的 README。lambda.yml是 lambda builder 的入场券——它既是自动检测的依据也是构建配置的载体。从源码结构看该文件的存在与否直接决定 builder 是否被选中其内容则决定 lambda-builder 如何执行构建。更改lambda.yml位置lambdayml-path属性默认搜索位置lambda.yml默认被期望位于特定目录具体取决于部署方式git:from-image与git:load-image命令产生的部署位于 Docker 镜像的WORKDIR。其他所有部署方式git push、git:from-archive、git:sync位于源码树的根目录。monorepo 场景自定义路径有时可能需要为某个应用指定不同的路径例如从 monorepo 部署时lambda.yml并不在仓库根目录。这时可以通过lambdayml-path属性来指定dokku builder-lambda:set node-js-app lambdayml-path .dokku/lambda.yml关于该属性值需要特别强调两点语义始终为相对路径该值是相对于基础搜索目录的路径在任何上下文中都不会被当作绝对路径处理。文件不存在则构建失败如果仓库中不存在该文件构建会失败。从 core-post-extract 触发器的源码可以看到dokku 在代码提取后post-extract 阶段会把计算出的lambda.yml路径统一规整到工作目录根下再交给 lambda-builderlocal NEW_LAMBDA_YML$(fn-builder-lambda-computed-lambdayml-path $APP) ... if [[ ! -f $NEW_LAMBDA_YML ]]; then rm -f lambda.yml return fi if [[ $NEW_LAMBDA_YML ! lambda.yml ]]; then mv $NEW_LAMBDA_YML lambda.yml fi也就是说如果自定义路径指向的文件不存在插件会直接移除根目录的lambda.yml避免误用错误的清单如果文件存在且路径不是默认的lambda.yml则会将其移动到根目录确保后续构建流程读取到的始终是正确清单。清除应用级配置恢复默认通过传入空值可以清除应用级设置恢复默认行为dokku builder-lambda:set node-js-app lambdayml-path全局配置lambdayml-path属性同样支持全局设置。全局默认值是lambda.yml当应用未设置任何值时使用全局值dokku builder-lambda:set --global lambdayml-path lambda2.yml同样传入空值即可清除全局设置dokku builder-lambda:set --global lambdayml-path属性解析优先级computed path从 internal-functions 脚本的fn-builder-lambda-computed-lambdayml-path实现可以看出完整的三级回退逻辑应用级lambdayml-path若已设置全局lambdayml-path若已设置内置默认值lambda.yml。这一逻辑与 Go 侧的 report.go 中reportComputedLambdaymlPath函数完全一致func reportComputedLambdaymlPath(appName string) string { value : reportLambdaymlPath(appName) if value { value reportGlobalLambdaymlPath(appName) } if value { value lambda.yml } return value }builder-lambda:set命令的行为细节从 set 子命令脚本的源码看该命令还会做严格的输入校验当前合法的 key 只有lambdayml-path传入其他 key 会报错Invalid key specified, valid keys include: lambdayml-path未指定 key 会报错No key specified--global作为应用名时跳过应用名校验verify_app_name有值时执行写入fn-plugin-property-write空值时执行删除fn-plugin-property-delete。查看 builder-lambda 报告查看所有应用的报告使用builder-lambda:report命令可以获取应用的相关状态报告dokku builder-lambda:report示例输出 node-js-app builder-lambda information Builder lambda computed lambdayml path: lambda2.yml Builder lambda global lambdayml path: Builder lambda lambdayml path: lambda2.yml python-sample builder-lambda information Builder lambda computed lambdayml path: lambda.yml Builder lambda global lambdayml path: Builder lambda lambdayml path: ruby-sample builder-lambda information Builder lambda computed lambdayml path: lambda.yml Builder lambda global lambdayml path: Builder lambda lambdayml path:上述输出中的三个字段含义如下lambdayml-path应用级的原始值未设置时为空global-lambdayml-path全局值未设置时为空computed-lambdayml-path构建时实际生效的值回退顺序为「应用级 → 全局值若设置→ 内置默认lambda.yml」。这正是前文所述三级回退逻辑在报告中的直观体现node-js-app设置了lambda2.yml应用级覆盖而python-sample、ruby-sample未做任何设置因此 computed 值回退到默认的lambda.yml。查看指定应用的报告也可以针对单个应用运行dokku builder-lambda:report node-js-app示例输出 node-js-app builder-lambda information Builder lambda computed lambdayml path: lambda2.yml Builder lambda global lambdayml path: Builder lambda lambdayml path: lambda2.yml使用 flag 提取单个值可以通过 flag 只输出你关心的特定信息值便于脚本化使用。例如dokku builder-lambda:report node-js-app --builder-lambda-lambdayml-path输出lambda2.yml从 subcommands.go 的 report 入口可以看到report子命令支持--format参数stdout或json并且针对--global场景报告 flag 只开放 computed 与 global 两个字段因为全局范围没有应用级值。而普通应用场景则额外开放--builder-lambda-lambdayml-path。构建与发布阶段的行为builder-release阶段对应构建触发器在BUILDER_TYPE为lambda时执行以下动作依次触发pre-release-lambda已废弃仅向后兼容会输出警告提示改用pre-release-builder与pre-release-builder触发器使用 builder-release.Dockerfile 对已构建镜像执行一次轻量重建仅用于注入 docker labels其中包含com.dokku.image-stagerelease、com.dokku.builder-typelambda、com.dokku.app-name$APP等元数据触发post-release-builder触发器收尾。这意味着 lambda builder 产出的镜像带有明确的 builder 类型标识后续 scheduler 或其他插件可以据此识别这是一个由 lambda builder 构建的产物。安装与数据目录在插件安装阶段见 install 触发器插件会初始化属性存储fn-plugin-property-setup builder-lambda并在DOKKU_LIB_ROOT/data/builder-lambda下创建数据目录。所有builder-lambda:set写入的属性包括全局与应用级都持久化在插件属性系统中这也是builder-lambda:report能跨会话读取到配置的原因。属性速查表Settable propertiesPropertyScopeDefaultReport flagsDescriptionlambdayml-pathapp globallambda.yml--builder-lambda-lambdayml-path,--builder-lambda-global-lambdayml-path,--builder-lambda-computed-lambdayml-path应用内lambda.yml清单的相对路径供 lambda builder 使用典型工作流总结准备清单在应用仓库或 monorepo 子目录中编写lambda.yml声明函数构建所需的运行时与配置。确认检测默认路径下存在lambda.yml即自动选中 lambda builder否则用dokku builder:set app selected lambda手动指定。可选调整路径monorepo 场景用dokku builder-lambda:set app lambdayml-path relative/path指向清单多应用共享配置时用--global设置全局值。验证配置用dokku builder-lambda:report app确认computed lambdayml path是否为期望值。部署执行常规部署git push、git:from-archive、git:sync、git:from-image等构建产物可运行在 Dokku 上也可通过合适的 scheduler 调度到 AWS Lambda。使用限制说明lambda.yml的自定义路径是纯相对路径不会在任何场景下按绝对路径解析且目标文件缺失会导致构建失败自动检测依赖源码工作目录中的lambda.yml而基于镜像的部署git:from-image/git:load-image会从镜像WORKDIR查找两类部署的搜索起点不同各语言具体的构建参数与lambda.yml字段语法由 lambda-builder 工具定义dokku 侧不负责解释需要以 lambda-builder 文档为准。【免费下载链接】dokkuA docker-powered PaaS that helps you build and manage the lifecycle of applications项目地址: https://gitcode.com/GitHub_Trending/do/dokku创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
