在AWS Lambda中用Rust调用二进制文件出现响应空体问题

问题场景 #

我编写了如下Rust AWS Lambda函数，用于将二进制文件myProgram的输出转换为JSON格式返回：

use std::io::Read;
use std::process::{Command, Stdio};
use lambda_http::{run, service_fn, Body, Error, Request, RequestExt, Response};
use lambda_http::aws_lambda_events::serde_json::json;

/// This is the main body for the function.
/// Write your code inside it.
async fn function_handler(_event: Request) -> Result<Response<Body>, Error> {
    // Extract some useful information from the request
    let program = Command::new("./myProggram")
        .stdout(Stdio::piped())
        .output()
        .expect("failed to execute process");

    let data = String::from_utf8(program.stdout).unwrap();
    let parsed = data.split("\n").filter(|x| !x.is_empty()).collect::<Vec<&str>>();

    // Return something that implements IntoResponse.
    let resp = Response::builder()
        .status(200)
        .header("content-type", "application/json")
        .body(json!(parsed).to_string().into())
        .map_err(Box::new)?;
    Ok(resp)
}

#[tokio::main]
async fn main() -> Result<(), Error> {
    tracing_subscriber::fmt()
        .with_max_level(tracing::Level::INFO)
        .with_target(false)
        .without_time()
        .init();

    run(service_fn(function_handler)).await
}

本地使用cargo lambda watch和cargo lambda invoke测试时，响应体可正常返回myProgram输出转换后的JSON数据；但通过AWS控制台部署到基于Amazon Linux 2的自定义运行时后，测试响应头正常，但响应体为空。

排查思路与解决方案 #

1. 检查二进制文件架构兼容性 #

• 本地编译的myProgram可能适配的是你的本地操作系统（如macOS/Windows），而Lambda运行在Amazon Linux 2（x86_64或arm64）环境下，架构不兼容会导致二进制无法执行，最终输出为空。
• 解决：针对Lambda目标架构交叉编译myProgram，比如使用cargo lambda build指定目标平台，确保二进制与Lambda运行时的CPU架构、操作系统完全匹配。

2. 修复文件权限问题 #

• Lambda运行时需要bootstrap和myProgram具备可执行权限，手动打包ZIP时容易丢失权限，导致myProgram无法被调用。
• 解决：打包前给两个二进制文件添加执行权限：

  chmod +x bootstrap myProgram
  

  重新打包ZIP后再部署。

3. 修正文件名拼写错误 #

• 代码中调用的是./myProggram（多了一个字母g），如果实际打包的文件名为myProgram，会导致找不到文件，stdout为空。
• 解决：修正代码中的文件名拼写，确保与打包的二进制文件名一致：

  let program = Command::new("./myProgram")
      .stdout(Stdio::piped())
      .output()
      .expect("failed to execute process");
  

4. 捕获执行错误并输出日志 #

• 当前代码使用expect和unwrap，执行出错时直接panic，但错误信息可能未被记录到CloudWatch。
• 解决：替换为显式错误处理，将错误信息返回或输出到日志：

  let program = Command::new("./myProgram")
      .stdout(Stdio::piped())
      .output()
      .map_err(|e| Error::from(format!("Failed to run myProgram: {}", e)))?;
  
  let data = String::from_utf8(program.stdout)
      .map_err(|e| Error::from(format!("Invalid UTF-8 output: {}", e)))?;
  

  部署后查看CloudWatch日志，确认是否有执行异常。

5. 确认文件在ZIP包中的位置 #

• Lambda工作目录是/var/task/，代码中用相对路径./myProgram，需要确保myProgram在ZIP包的根层级，而非子文件夹中。
• 解决：打包时检查ZIP结构，确保bootstrap和myProgram直接放在根目录，没有嵌套目录。

6. 临时输出执行状态排查 #

• 可以临时修改函数，返回myProgram的执行状态码和错误输出，定位具体问题：

  let stderr = String::from_utf8_lossy(&program.stderr).to_string();
  let resp = Response::builder()
      .status(200)
      .header("content-type", "application/json")
      .body(json!({
          "status_code": program.status.code(),
          "stdout": data,
          "stderr": stderr
      }).to_string().into())
      .map_err(Box::new)?;
  

  部署后查看响应中的stderr内容，明确执行失败原因。

内容的提问来源于stack exchange，提问作者themartto