MicroVMs：运行具有完整生命周期控制的隔离沙箱

# 运行具备完整生命周期控制的隔离沙箱：AWS Lambda 推出 MicroVM | Amazon Web Services 来源: https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/ 由 Polly (https://aws.amazon.com/polly/) 配音 今天，我们宣布推出 AWS Lambda MicroVMs，这是一种全新的无服务器计算原语，集成在 AWS Lambda (https://aws.amazon.com/lambda/) 中，允许您在隔离、有状态的执行环境中运行由用户或 AI 生成的代码。您将获得虚拟机级别的隔离、近乎瞬时的启动与恢复，以及对环境生命周期和状态的直接控制，而无需管理基础设施或掌握复杂的虚拟化技术。Lambda MicroVMs 由 Firecracker (https://firecracker-microvm.github.io/) 驱动，正是这一轻量级虚拟化技术支撑了每月超过 15 万亿次的 Lambda 函数调用。 **客户为什么需要这个** 在过去几年中，出现了一类新的多租户应用，它们都有一个共同需求：为每个最终用户提供专属的执行环境，以便安全运行应用开发者未编写的代码。AI 编程助手、交互式代码环境、数据分析平台、漏洞扫描器以及运行用户脚本的游戏服务器都属于这种模式。如今构建这样的能力意味着需要做出艰难的选择。虚拟机提供强大的隔离性，但启动需要数分钟。容器在几秒内启动，但其共享内核架构需要大量定制加固才能安全地包含不可信代码。函数即服务针对事件驱动、请求-响应工作负载进行了优化，但不适用于需要跨用户交互保留环境状态的长时间运行交互式会话。 这让开发者要么在性能与隔离性之间做出取舍，要么投入大量工程资源来构建和运维自定义的虚拟化基础设施，以在实现隔离执行的同时为最终用户提供低延迟体验。这需要深厚的专业知识，并会占用本应用于实际产品的工程时间。 Lambda MicroVMs 正是为弥补这一差距而专门构建的。每个 MicroVM 为单个最终用户或会话提供独立的隔离环境，快速启动，在会话期间保留内存和磁盘状态，并在用户离开时暂停至低空闲成本。由于 AWS Lambda Functions 已经使用了相同的 Firecracker 技术，您将继承这一大规模运行该堆栈服务的运营成熟度。 **让我们试试看** 首先，我导航到 AWS Lambda 控制台，左侧导航菜单中现在出现了 Lambda MicroVMs。我需要先创建一个 MicroVM 镜像。我将一个 Flask Web 应用及其 Dockerfile 打包成 zip 文件，上传至 Amazon Simple Storage Service (Amazon S3) (https://aws.amazon.com/s3/) 存储桶。 我的 Flask API – `app.py` ```python import logging from flask import Flask, jsonify app = Flask(__name__) logging.basicConfig(level=logging.INFO) @app.route("/") def hello(): app.logger.info("Received request to hello world endpoint") return jsonify(message="Hello, World!") if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) ``` 我的 Dockerfile ```dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 python3-pip && dnf clean all WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"] ``` 我使用以下命令创建我的 MicroVM 镜像。 ```bash aws lambda-microvms create-microvm-image \ --code-artifact uri= <my-bucket/ my-code.zip> \ --name <my-image-name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <my-role-arn> ``` 您也可以像上图一样在 AWS 控制台中创建 MicroVM 镜像。运行命令后，Lambda 获取 zip 文件，执行 Dockerfile，初始化应用程序，并获取运行中磁盘和内存状态的 Firecracker 快照。构建日志实时流式传输到 Amazon CloudWatch (https://aws.amazon.com/cloudwatch/)，路径为 `/aws/lambda/microvms/`。镜像准备好后，它将与 Amazon Resource Name (ARN) (https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) 和版本号一起显示在控制台中。 ```bash aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:::microvm-image:my-image \ --execution-role-arn arn:aws:iam:: <account-id>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' ``` 也可以通过 AWS 控制台或 CLI 进行启动。我传入了镜像 ARN 和一个空闲策略，配置为在无活动 15 分钟后自动挂起，并在下一个传入请求时自动恢复。无需进行网络设置。Lambda 为 MicroVM 分配了一个唯一 ID，返回一个专用端点 URL，并启动了一个新的 MicroVM，由于是从快照恢复，我的 Flask 应用已经在运行。启动完成的那一刻，我的 Flask 应用就已经在运行了。一次 API 调用即可获得一个完全初始化、引导完成的计算环境。 为了发送流量，我使用 CLI 生成了一个短期有效认证令牌，并通过 `X-aws-proxy-auth` 头部将其附加到普通的 HTTPS 请求中。请求立即到达了我的 Flask 应用。然后我让 MicroVM 空闲超过挂起阈值，此时 MicroVM 被挂起，其内存和磁盘状态被快照并存储。接着我又发送了一个请求，它恢复了，且应用程序状态完全完整。从客户端来看，暂停从未发生过。 **工作原理** 在底层，Lambda MicroVMs 提供了三项迄今为止没有任何一个 AWS 计算服务同时具备的能力。第一是虚拟机级别的隔离性，这得益于 Firecracker。每个会话在其专用 MicroVM 中运行，没有共享内核，用户之间不共享资源，因此一个用户提供的不可信代码被限制在其执行环境中，无法访问其他环境或底层系统。 第二是快速启动与恢复。其模式是先创建镜像再启动：您通过提供 Dockerfile 和打包为 zip 工件（位于 Amazon S3）的代码来创建 MicroVM 镜像，然后 Lambda 运行您的 Dockerfile，初始化您的应用程序，并获取运行环境内存和磁盘状态的 Firecracker 快照。从该镜像启动的每个后续 MicroVM 都是从预初始化的快照恢复，而非冷启动，这意味着启动和空闲恢复都能实现近乎瞬时的启动延迟。即使是多 GB 的交互式会话也能快速恢复在线，给最终用户以响应迅速的感觉。 第三是有状态执行。正在运行的 MicroVM 会在用户会话期间保留内存、磁盘和正在运行的进程。在空闲期间，MicroVM 可以被挂起（内存和磁盘状态保持完整），并在流量到达时恢复。已安装的软件包、加载的模型和工作文件集在用户恢复会话时立即可用。MicroVMs 支持最长 8 小时的总运行时间，并可在配置的空闲窗口后自动挂起，这使得构建各种产品变得简单直接，例如几分钟内完成的软件漏洞扫描、运行数小时的数据分析应用，以及具有长时间空闲期的交互式编码会话。 由于 Lambda MicroVMs 是从预初始化的快照启动，在初始化期间生成唯一内容、建立网络连接或加载临时数据的应用程序可能需要集成服务提供的钩子以实现兼容性。 Lambda MicroVMs 是 AWS Lambda 中的一种新资源，具有独立的 API 接口。Lambda Functions 仍然是事件驱动、请求-响应工作负载的合适选择，而 Lambda MicroVMs 是专为多租户应用构建的，这些应用需要为每个最终用户或会话提供自己的隔离环境来执行用户或 AI 生成的代码。两者相辅相成。使用 Lambda Functions 作为事件驱动骨干的应用可以调用 Lambda MicroVMs 来处理需要隔离运行不可信代码的步骤。您带来应用，服务提供执行环境。 **现已可用** AWS Lambda MicroVMs 现已在美东（弗吉尼亚北部、俄亥俄）、美西（俄勒冈）、欧洲（爱尔兰）和亚太（东京）区域 (https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 推出，基于 ARM64 架构，每个 MicroVM 最多支持 16 个 vCPU、32 GB 内存和 32 GB 磁盘。空闲的 MicroVMs 可以通过 API 调用显式挂起，或通过生命周期策略自动挂起，从而降低运行成本，同时保留完整状态以便快速恢复。定价详情请参阅 AWS Lambda 定价页面 (https://aws.amazon.com/lambda/pricing/)。 要开始使用，请访问 AWS Lambda 控制台 (https://console.aws.amazon.com/lambda/)，或在 Lambda MicroVMs 产品页面 (https://aws.amazon.com/lambda/lambda-microvms) 了解更多信息。文档请参阅 Lambda MicroVMs 开发人员指南 (https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html)。