挂载在 Lambda 上的 AWS EFS 工作正常,但如果它导致 CloudFormation 挂起,则销毁



我已经将EFS设置为挂载在lambda上,我似乎使它正常工作,lambda能够挂载文件系统并具有读/写访问权限。

我遇到的问题是,当我试图完全销毁堆栈时,当我试图改变lambda的ID时,CloudFormation会冻结。

import * as cdk from 'aws-cdk-lib';
import {RemovalPolicy} from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as efs from 'aws-cdk-lib/aws-efs';
import {ThroughputMode} from 'aws-cdk-lib/aws-efs';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import {Architecture} from 'aws-cdk-lib/aws-lambda';
import {Construct} from 'constructs';
import * as path from "path";
export class SimilarityEmbeddingsCdkStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const vpc = new ec2.Vpc(this, 'VPC', {
maxAzs: 2
});
const efsSecurityGroup = new ec2.SecurityGroup(this, 'EfsSimilarityEmbeddingSecurityGroup', {
vpc
});
const fs = new efs.FileSystem(this, 'EfsSimilarityEmbeddingFileSystem', {
vpc: vpc,
performanceMode: efs.PerformanceMode.GENERAL_PURPOSE,
throughputMode: ThroughputMode.BURSTING,
removalPolicy: RemovalPolicy.DESTROY,
securityGroup: efsSecurityGroup
});
const accessPoint = fs.addAccessPoint('LambdaAccessPoint', {
path: '/export/lambda',
createAcl: {
ownerGid: '1001',
ownerUid: '1001',
permissions: '755',
},
posixUser: {
uid: '1001',
gid: '1001',
}
});
const lambdaSecurityGroup = new ec2.SecurityGroup(this, 'SimilarityEmbeddingLambdaSecurityGroup', {
vpc
});
const createEmbeddingHandler = new lambda.DockerImageFunction(this, 'CreateEmbeddingLambdaFunction', {
code: lambda.DockerImageCode.fromImageAsset(
path.join(__dirname, '../lambdas'),
{
cmd: ["create_embedding.index.handler"]
}
),
architecture: Architecture.ARM_64,
securityGroups: [lambdaSecurityGroup],
filesystem: lambda.FileSystem.fromEfsAccessPoint(accessPoint, '/mnt/filesystem'),
vpc,
});
}
}

在进一步尝试之后,我让它运行了大约20分钟,它最终成功地销毁了堆栈。我猜只要文件系统挂载在Lambda上,它就不能被删除。

有什么办法可以解决这个问题,还是我只能等它过去?

您的Lambda函数正在使用VPC中的网络接口。这(很可能)是函数需要一些时间来删除的原因。当网络接口正在使用时,不能删除该网络接口。如果该功能正在运行,甚至处于"温暖"状态,则网络接口将处于使用状态。状态。

即使你的函数没有运行,AWS也可能会让函数保持一段时间的"温暖"(保持接口在使用中,防止删除)。

可以尝试使用一个技巧来加速此过程,首先修改网络安全组以禁止所有流量,这将停止所有连接,从而更快地删除接口(以及随后的功能)。

另一个帮助处理'warm' lambda实例的技巧是更新函数环境(如增加或减少内存)并将其并发性设置为0(以防止新的调用/warm实例)。这也可以帮助你的删除运行得更快。

同样重要的是要确保你没有周期性的依赖关系,比如如果你为一个自定义的资源提供程序使用lambda,这个资源提供程序也涉及到堆栈删除。

相关内容

最新更新