在阅读这篇讨论使用 AWS Lambda 函数的主要缺点的文章后，我试图避免作者必须处理的问题并对我自己的代码执行一些清理：

" Lambda 版本每个函数。我们使用无服务器框架来开发 Lambda 应用程序。这意味着无服务器创建 Lambda 函数。我们的平均 Lambda 函数约为 60MB。[...]
当您将 CI/CD 与快速开发和 Lambda 函数结合使用时，你有很多版本。甚至有数百个。而且 Lambda 代码存储被限制在 75GB。我们达到了这个限制，我们很难做到。经过两年的 CI/CD 驱动开发，我们缺乏版本清理导致我们的开发完全陷入僵局过程。”

（强调我的）

关于我的架构。我有 lambda 函数，它们调用存储在layer 中的自制 python 包中的方法。目标是避免在 lambda 中包含太多代码并轻松重用其中的功能。

现在，我找到了如何删除旧版本的 lambda 函数（我也在使用无服务器框架，它提供了一个很好的插件，用于在部署堆栈时自动修剪它们）。但是，我不知道 AWS 是否会自动删除旧层：我还没有找到汇总我所有层版本的总代码大小的仪表板，而且我找不到自动删除它们的插件。

旧的 AWS Lambda 层会自动删除吗？如果没有，我怎么能批量删除它们？

我一直很难让这件事正常工作我试图在本地调用在 docker 容器上运行的 Lambda，但我遇到了以下问题

Docker 文件

FROM public.ecr.aws/lambda/python:3.8


COPY myfunction.py ./

CMD ["myfunction.lambda_handler"]

Python 文件 myfunction.py

import json
import sys

def lambda_handler(event, context):
    print("Hello AWS!")
    print("event = {}".format(event))
    return {
        'statusCode': 200,
    }

步骤1：

FROM public.ecr.aws/lambda/python:3.8


COPY myfunction.py ./

CMD ["myfunction.lambda_handler"]

输出

C:\Users\s.shah\IdeaProjects\YoutubeVideos\Learn>docker build --tag custom .
[+] Building 0.5s (7/7) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                                                                                                                                                                                                                            0.0s
 => => transferring dockerfile: 31B                                                                                                                                                                                                                                                                                                                             0.0s
 => [internal] load .dockerignore                                                                                                                                                                                                                                                                                                                               0.0s
 => => transferring context: 2B                                                                                                                                                                                                                                                                                                                                 0.0s
 => [internal] load …

我使用 VS Code 开发 AWS 托管的无服务器应用程序。该应用程序使用 Lambda。最近，我决定开始使用 Lambda Layers 来提取和重用公共代码。我遇到的问题是 AWS Lambda 需要 Lambda 层的以下导入：

const layer = require("/opt/layer");

我想在层导出函数上获得智能感知：

module.exports = {
    f1(param1, param2) {
        // ...
    },

    f2(paramX, paramY, paramZ) {
        // ...
    }
}

尽管我同时拥有 lambda 和 lambda 层代码，但 VS Code 自然无法解析层文件的路径，因此 Intellisense 不起作用。

我发现如果我将下一个 jsconfig.json 文件放在项目中的任何位置：

{
    "compilerOptions": {
        "target": "ES6",
        "module": "commonjs"
    },
    "exclude": [
        "node_modules",
        "**/node_modules/*"
    ]
}

require 语句停止显示为红色，并且允许一些基本文本自动完成。但它并没有真正正确地显示带有参数的图层导出函数。

我不想创建解决方案，例如在开发期间使用自定义导入，然后在部署到 AWS 期间用“require(”/opt/layer”)”替换它们（或者至少有一些自动化的东西）。

可以做什么？

我正在开发的应用程序中有超过 20 个 lambda 函数。还有一个 lambda 层，其中包含大量通用代码。

Lambda 函数将其挂钩到该层的特定版本，每次更新层时，它都会生成一个新版本。由于它是一个正在开发的应用程序，我几乎每天都有该层的新版本。这会导致 lambda 函数变得混乱，而这些函数每天都必须接触——以升级层版本。

我知道在生产环境中冻结 lambda 函数的代码非常重要，并且必须将 lambda 函数的一个版本挂接到该层的一个版本。

但是，对于开发环境来说，是否可以防止每次更新图层时都生成新的图层版本呢？或者配置 lambda 函数，使最新的 lambda 版本始终引用最新的层版本？

Amazon 建议不要在 lambda 函数中包含大型库/依赖项。据我所知，SQLAlchemy 是一个相当大的 Python 库。你认为在 lambda 函数中使用它是个好主意吗？一种选择是将其包含为 Lambda 层并在所有相关的 Lambda 函数中使用它。

无论如何，最好的做法是什么？

我正在 AWS 上编写一个无服务器应用程序。

我已将该应用程序分解为许多 Clo​​udFormation 堆栈。我正在使用 CDK（Python 中）创建 CF 堆栈来部署应用程序。

当然，我的 lambda 函数的核心要求是能够记录事件。为了处理这个问题（以及应用程序中传递的所有消息），我在我的堆栈之一中创建了一个自定义 EventBridge 总线。事件总线的名称是堆栈的输出。

由于日志记录功能对于许多 lambda 函数来说都是通用的，因此将日志记录功能放入 lambda 层似乎是合适的。然后，我可以让所有 lambda 函数实现该层，并且日志记录将自动可供我的所有 lambda 函数使用。

问题是我的日志记录代码需要知道将事件写入哪个 EventBridge 事件总线。我不想对此进行硬编码，因为我可能会同时部署堆栈的“开发”和/或“测试”和/或“产品”版本，并且每个环境中的日志记录层需要记录到其环境的日志记录总线。

由于 lambda 层在父 lambda 函数的上下文中运行，因此我无法在该层上设置环境变量。

我可以在使用该层的所有 lambda 函数上设置“LoggingEventBus”环境变量。但这似乎是重复的并且容易出错。（虽然这是我目前能想到的最好的解决方案。）

我可以将事件总线存储在 SMS 参数存储中。但是天哪，每次我的应用程序中的任何函数想要记录任何内容时查找该参数都是荒谬的。（我又必须找出一种方法让记录器确定它是否在开发/测试/产品中查找正确的总线。）

我实际上正在考虑“cdk合成器”期间的一些构建过程，该过程修改日志记录层的源代码并对事件总线名称进行字符串替换，以便在部署代码时该名称实际上是硬编码的。但该解决方案存在各种危险信号。

理想情况下，层本身应该有某种“环境变量”。但这样的东西并不存在，而且我承认这样的功能与大多数语言运行时的工作方式不兼容。

其他人是如何解决这个问题的？将设置放入 lambda 层是否有“正确”答案？

我在节点 v14 中有一个 lambda 函数，它从 lambda 层导入 AWS SDK v3。

在我的函数中，只有使用 CommonJS 语法，我才能使用层中的节点模块：

const { parseUrl } = require('@aws-sdk/url-parser');

使用 ES 模块不起作用。

import { parseUrl } from '@aws-sdk/url-parser';

它会抛出一个错误： "errorMessage": "Cannot find package '@aws-sdk/url-parser' imported from /var/task/index.js\nDid you mean to import @aws-sdk/url-parser/dist-cjs/index.js?"

它应该有效。我"type": "module"在package.json本地有进口工作。当我指定 cjs 索引文件的完整路径时，它也会开始工作：

import { parseUrl } from '/opt/nodejs/node_modules/@aws-sdk/url-parser/dist-cjs/index.js';

这真的很奇怪。

我查了一下NODE_PATH，/opt/nodejs/node_modules是这样的，所以不知道问题出在哪里。

完整的实现在这里，因此您可以复制错误： https ://github.com/simon-q/lambda-layer-es-modules-error

是 lambda 层损坏了还是我做错了什么？我真的很感激任何帮助。

谢谢。

我试图在构建 Lambda 函数时使用 TypeScript，但在使用同样用 TypeScript 编写的 Lambda 层时遇到问题。

TypeScript 无法识别我的层的 /opt/nodejs/... 导入（因为它会在 SAM 或 AWS 中运行），因此我无法将我在层中定义的类型导入到我的 Lambda 函数。

我试图查看我是否能够以某种方式 npm 链接该层，但我似乎无法使其正常工作，因为导入是本地路径 '/opt/nodejs...' 而不仅仅是模块名称。

层：

export interface SomeType {
  someField: string
}

拉姆达：

import { SomeType } from '/opt/nodejs/myLayer' // this does not work

我刚刚收到错误消息：Cannot find module '/opt/nodejs/myLayer'.ts(2307)我发现自己不得不用它来抑制它，// @ts-ignore can be ignored as this is a Lambda layer但这意味着我无法使用层中的 TypeScript 类型。

我想在 AWS lambda 函数中使用 npm 包“请求”。

我正在尝试按照本文中概述的程序进行操作：https : //medium.com/@anjanava.biswas/nodejs-runtime-environment-with-aws-lambda-layers-f3914613e20e

我创建了这样的目录结构：

nodejs
?   package-lock.json
?   package.json
????node_modules

我的 package.json 看起来像这样：

{
  "name": "my-package-name",
  "version": "1.0.0",
  "description": "whatever",
  "author": "My Name",
  "license": "MIT",
  "dependencies": {
    "request": "^2.88.0"
  }
}

据我从文章中可以看出，我应该做的就是 run npm i，压缩目录，将其作为图层上传，然后将该图层添加到我的 lambda 函数中。

我已经完成了所有这些，但是当我尝试测试我的功能时，我得到的只是：

{
  "errorType": "Runtime.ImportModuleError",
  "errorMessage": "Error: Cannot find module 'request'\nRequire stack:\n- /var/task/index.js\n- /var/runtime/UserFunction.js\n- /var/runtime/index.js",
  "trace": [
    "Runtime.ImportModuleError: Error: Cannot find module 'request'",
    "Require stack:",
    ...

...好像从未添加过图层。无论是否添加图层，错误都完全相同。如果有某种权限问题需要解决，文章中没有任何内容表明这一点。

我尝试了一些不同的事情，例如我的 .zip 文件是否包含顶级目录“nodejs”或仅包含其内容。我试过用这样的文件添加"main": "index.js",到我的package.json, 中 …

我有一个 monorepo，在自己的文件夹中包含一些函数。我想创建一个具有实用功能的公共层，我可以require/import在本地使用它，也可以在部署到云后使用它。我想添加一个layers/目录来执行此操作，文件夹结构如下所示：

  A
  |- node_modules/
  |- package.json
  |- index.js
  B
  |- node_modules/
  |- package.json
  |- index.js
  layers
    |- nodejs
      |- node_modules
      |- package.json
      |- util.js

我没有设置上面的文件夹结构，并且可以接受它的更改。

目前，我只有A和 以及B它们自己的独立依赖层（使用 编排terraform），并且它们在本地工作和部署都很好。

引入通用实用程序层后，问题是我可以在本地要求/导入，但在云中就不一样了（/opt/nodejs/*），但如果我将其更改为在云上工作，它将无法工作本地。

我没有使用该serverless框架。