您可以在 aws lambda 层中添加文本文件吗？答案

【问题标题】：Can you add text files in an aws lambda layer?您可以在 aws lambda 层中添加文本文件吗？
【发布时间】：2021-11-26 02:41:21
【问题描述】：

我正在考虑使用机密管理器或参数存储，但如果 jwt 过期，那么我必须复制/粘贴方法来处理我所有的 lambda 函数中过期的 jwt，我认为这将是低效的。

接下来我想到的是使用 lambda 层。我正在编写的大多数函数都需要上述 lambda 层，因此我认为这将是跨多个 lambda 函数共享 jwt 的最有效方式。

我的问题是，如果我有一个包含我的 jwt 文本文件的目录的 lambda 层，我的所有 lambda 函数是否能够从层内的所述文本文件中读取和写入，并且它们是否会保持更新？所有使用同一层的 lambda 函数？

【问题讨论】：

如果您想在 lambda 之间共享数据，请使用 DynamoDB、EFS 或 S3。 Lambda 层对此是个坏主意。每次修改它们时都应该重新部署它们。
通常我会同意你的看法，但我不会共享大量数据。它只是一个单一的 jwt，我已经考虑过通过 ddb 和 s3，但它仍然错过了不必编写每次更新我的 jwt 时在所有 lambda 函数中过期的相同代码的要点。跨度>
如果您在层中硬编码 JWT，那么当它到期时，您将 (1) 必须重新部署层，并且 (2) 更新所有 Lambda 以引用新层版本。
@kdgregory 对，所以我想知道是否可以附加一个单独的文本文件，该文件将包含层内的 jwt。如果 jwt 过期，那么是否可以将已生成的新 jwt 写入文本文件，然后在使用同一层的函数中对其进行更新。
那行不通。层只是一个 ZIP 文件，当 Lambda 启动一个新的执行环境时，它会被解压缩。即使您可以对其进行写入，您在一个执行环境中所做的任何更改都不会影响其他任何环境。但这没有实际意义，因为您无法写入图层解包的目录。

标签： python-3.x amazon-web-services aws-lambda aws-lambda-layers

【解决方案1】：

Python 层只是一个 ZIP 文件，它会在启动时解压到 Lambda 执行环境中。

因此，即使您可以修改该层中的文件，其他 Lambda 也不会看到该文件，无论它们是已经在运行还是在您更改后新启动。

但是您不能修改图层中的文件，因为 (1) 一切都归 root 所有，并且 (2) 它以只读方式安装。您可以通过如下 Lambda 函数看到这一点：

import os

def lambda_handler(event, context):
    
    print("")
    print("**** id ****")
    os.system("id")
        
    print("")
    print("****")
    os.system("df -kh")
    
    print("")
    print("****")
    os.system("cat /etc/mtab")

当你运行它时，你会看到如下输出。该层将被解压缩到/opt/python。如您所见，/opt 是卷 /dev/vdc，它像所有其他卷一样以只读方式安装，除了 /tmp 和 - 令人惊讶的是 - /dev（虽然我怀疑你能够写在那里，因为我确定它是由 root 拥有的）。

**** id ****
uid=993(sbx_user1051) gid=990 groups=990
****
Filesystem                                                           Size  Used Avail Use% Mounted on
/mnt/root-rw/opt/amazon/asc/worker/tasks/rtfs/python3.7-amzn-201803  9.8G  8.4G  1.4G  87% /
/dev/vdb                                                             1.5G   14M  1.4G   1% /dev
/dev/vdd                                                             526M  872K  514M   1% /tmp
/dev/root                                                            9.8G  8.4G  1.4G  87% /var/rapid
/dev/vdc                                                             1.4M  1.4M     0 100% /opt
****
/mnt/root-rw/opt/amazon/asc/worker/tasks/rtfs/python3.7-amzn-201803 / overlay ro,nosuid,nodev,relatime,lowerdir=/tmp/es446846401/0e8fe4685588891:/tmp/es446846401/728da5137110572 0 0
/dev/vdb /dev ext4 rw,nosuid,noexec,noatime,data=writeback 0 0
/dev/vdd /tmp ext4 rw,relatime,data=writeback 0 0
none /proc proc rw,nosuid,nodev,noexec,noatime 0 0
/dev/vdb /proc/sys/kernel/random/boot_id ext4 ro,nosuid,nodev,noatime,data=writeback 0 0
/dev/root /etc/passwd ext4 ro,nosuid,nodev,relatime,data=ordered 0 0
/dev/root /var/rapid ext4 ro,nosuid,nodev,relatime,data=ordered 0 0
/dev/vdb /etc/resolv.conf ext4 ro,nosuid,nodev,noatime,data=writeback 0 0
/dev/vdc /var/task squashfs ro,nosuid,nodev,relatime 0 0
/dev/vdc /opt squashfs ro,nosuid,nodev,relatime 0 0

那么，除此之外，如何解决您的真正问题，即向所有 Lambda 传播访问令牌，包括（我认为）当前正在运行的那些。

您可以挂载一个 EFS 文件系统并在那里写入文件。但是您仍然可以使用过期令牌来运行 Lambda，因此您仍然需要编写所有代码来刷新令牌。而且使用 EFS 来存储配置似乎有点过头了。

更好的解决方案取决于您的代币存在多长时间。

如果它们是长期存在的（大约几个月或几年），请将它们存储在 Parameter Store 或 Secrets Manager 中，在首次使用时检索并使用 @lru_cache 缓存值，并在它们到期前几天更新它们.
如果它们存活 30 分钟或更长时间，请创建一个模块来检索和缓存令牌。该模块应该位于一个层中，以便您的所有 Lambda 都可以调用它而不是自己实现逻辑，并且会公开一个函数来访问令牌。此函数应验证当前缓存的令牌（如果有），如果 (1) 已过期或 (2) 从未检索过，则检索新的。
如果它们只存活几分钟，则在每次使用时取回。您可能会在 Lambda 调用开始时检索并重新使用，但这取决于您的 Lambda 运行多长时间。

【讨论】：